added texture UV instancing

[GordonTombola]

Features

• Ability to Flip X and Y on the texture UV's of a mesh, GLTF has a habit of flipping mesh UV's
• standard material can be supplied a spritesheet and instances supplied a texture which, so long as it corresponds to the spritesheet, should supply the instance with an index for accessing the corresponding UV transform for the texture
• frag color was being incorrectly interpolated from full colour to black by its alpha

[jnsmalm]

I guess you want to render many object with same shape but different textures? Just wondering if using StandardMaterial is the way to go? Because if you can set baseTexture, why can't you set normal, roughness/metallic and so on? And at that point the instancing stuff will need a lot of vertex data, sounds expensive but haven't tested it. Actually not too sure about adding the BaseTexture to instancing either because some devices have a low amount of max vertex attributes. Did you do any testing on lower end devices?

If you just need the BaseTexture, maybe it would be good to create a completely new Material, called BasicMaterial maybe? This material shouldn't do any lighting calculations at all and just could handle a single texture, and also instancing. What do you think?

[GordonTombola]

I guess you want to render many object with same shape but different textures? Just wondering if using StandardMaterial is the way to go? Because if you can set baseTexture, why can't you set normal, roughness/metallic and so on? And at that point the instancing stuff will need a lot of vertex data, sounds expensive but haven't tested it. Actually not too sure about adding the BaseTexture to instancing either because some devices have a low amount of max vertex attributes. Did you do any testing on lower end devices?

If you just need the BaseTexture, maybe it would be good to create a completely new Material, called BasicMaterial maybe? This material shouldn't do any lighting calculations at all and just could handle a single texture, and also instancing. What do you think?

Yes, specifically being able to render from the same spritesheet with individual UV transforms. If we were to have a new material that was built for this then would a uniform Mat3 array with a length supplied by a pixi spritesheet be more appropriate? That way each instance would only have to supply an index accessor to the appropriate Mat3 transform

[jnsmalm]

That way each instance would only have to supply an index accessor to the appropriate Mat3 transform

Yes, that might be a good idea. Now when you say it maybe that could also be used for some properties in StandardMaterial? Have no idea how it affects performance but would be interesting to test.

[GordonTombola]

I've sorted out a spritesheet method, not the cleanest implementation but gives an idea of what could be achieved with an extra single float per instance

[jnsmalm]

Maybe you can explain a bit what you want to achieve so I can understand a bit more.

Some questions:

1. Why is a baseTextureSpritesheet needed together with a a list of spritesheetTextures? Too me that just sounds like a regular BaseTexture and Texture's, is there really a need to add dependency to a spritesheet? Textures from spriteheets are already supported by StandardMaterial.
2. It may be cool to support different textures in different instances, but can't that just be achieved with the instances having there own TextureTransform instead of a different texture? By doing this it is also not needed to have flipx/flipy because that can then be done using the TextureTransform (each instance can/will have it's own anyway).
3. This seems to be a pretty specific use case, still not sure adding these features to a already complicated shader makes sense. Again, would be interesting to know more what you want to achieve. Could be a better option to create another shader/material for this use case.
4. Are these dynamic (moving) objects or are they static?

[GordonTombola]

Maybe you can explain a bit what you want to achieve so I can understand a bit more.

Some questions:

1. Why is a baseTextureSpritesheet needed together with a a list of spritesheetTextures? Too me that just sounds like a regular BaseTexture and Texture's, is there really a need to add dependency to a spritesheet? Textures from spriteheets are already supported by StandardMaterial.
2. It may be cool to support different textures in different instances, but can't that just be achieved with the instances having there own TextureTransform instead of a different texture? By doing this it is also not needed to have flipx/flipy because that can then be done using the TextureTransform (each instance can/will have it's own anyway).
3. This seems to be a pretty specific use case, still not sure adding these features to a already complicated shader makes sense. Again, would be interesting to know more what you want to achieve. Could be a better option to create another shader/material for this use case.
4. Are these dynamic (moving) objects or are they static?

I think the idea of abstracting it down to simply supplying uv transforms in an array of uniforms on the material and supplying an index for that transform would probably be the most appropriate and wouldn't change a great deal of the existing shader. In my case, these were different textures on dynamic instances of same mesh

I think I was trying too hard to make use of the existing class spritesheet in pixi to handle the logic of ensuring the textures belonged to the base texture