Material with a Texture list?

Troubleshooting graphics
1

So, I have spritesheets, right? Each one has a texture assigned to it, as would be expected. However, these sheets will be variable in size, so the TextureArray won’t work in this situation.

So I was wondering, is it feasible to put a Texture2d[] into a material? Or is that going about this the wrong way?

2
@Eliwood said: So, I have spritesheets, right? Each one has a texture assigned to it, as would be expected. However, these sheets will be variable in size, so the TextureArray won't work in this situation.

So I was wondering, is it feasible to put a Texture2d into a material? Or is that going about this the wrong way?

There are a couple ways to handle this:

Scenario 1:

Determine the fractional size of the sprite images by spriteWidth/imageWidth and spriteHeight/imageHeight and the index of the current sprite. Pass this info to the shader and alter the texCoords internally.

Scenario 2:

Do the same as above, but instead of altering the uniforms of the shader, you update the texCoord buffer of the mesh to reflect the current sprite.

I guess the point being is… you only need a single image (sprite sheet). How you update the sprites really depends on what the mesh is going to consist of. If there are many quads, your best bet is to update the buffer of the mesh… though this will be slower than scenario 1, the first option becomes rather difficult with multiple changing areas of a single mesh (as your shader really has no concept adjacent vertices).

3

If I were to pack the spritesheets into a single image, I’d be getting an image that’d be very, very, very large. Isn’t that inefficient? Or is it much better to do that than to use an array of textures?

Also, each sprite on-screen will be a quad. However, I have a class that generates all the quads as a single mesh - is that more efficient than if I were to use individual geometries?

4
@Eliwood said: If I were to pack the spritesheets into a single image, I'd be getting an image that'd be very, very, very large. Isn't that inefficient? Or is it much better to do that than to use an array of textures?

Also, each sprite on-screen will be a quad. However, I have a class that generates all the quads as a single mesh - is that more efficient than if I were to use individual geometries?

How large is very, very, very large?
And… this depends on the potential number of sprite animated quads, how you decide to update the texCoords, etc.

As a general rule of thumb, less objects in your scene = better frame rates and overall engine performance. However, this becomes an issue when (just examples):

  1. You are updating the a very large texCoord buffer of a batched mesh to update a single quads every frame.
  2. Your batching has a negative impact on culling

So, I guess the first things you will need to determine would be:

  • The expected number of sprite animated quads in your final scene
  • Do they constantly update, or is is based on user input/ai/etc
  • Will batching these quads negatively impact frustum culling, etc If so, would smaller batches be more efficient… or simply not batching due to the small number of active quads at an given time

Once you have an idea of the general need for your game, it will be much easier to determine the best approach for optimizing you sprite animations.