koobas.hobune.stream
Is it possible to utilize iphone dynamic batching with "traditional" animated sprite techniques?
By traditional animated sprite techniques, I mean having an sprite sheet that I simply animate the UVs on over time.
I have an animated sprite class that accomplishes animations on a sprite sheet by doing something like this
renderer.material.SetTextureOffset( "_MainTex", offset );
The problem, it seems, is that calling renderer.material does a lazy copy, which means that the material on that particular game object is now an instance of the base material. Since my game objects all have "unique" materials now, the engine can't batch my sprites.
I was hoping to avoid having to batch my spites manually (through something I roll myself or something like Sprite Manager).
Basically, I guess, is it possible to set the texture offset without having the material be instantiated?
Answered: As suggested, modifying the UVs of the model instead of the texture instance offset worked. Without pasting my entire AnimatedSprite class, this is the bit that matters:
void OnFrameChanged() { // split into horizontal and vertical index int uIndex = frameIndex % uvAnimationTileX; int vIndex = frameIndex / uvAnimationTileX;
// v coordinate is the bottom of the image in opengl so we need to invert.
vIndex = uvAnimationTileY - vIndex - 1;
// build offset
Vector2 offset = new Vector2( uIndex * tileUVSize.x, vIndex * tileUVSize.y );
Vector2[] newUVs = new Vector2[ uvs.Length ];
for( int i = 0; i < uvs.Length; ++i )
{
Vector2 previousUV = uvs[ i ];
previousUV.x *= tileUVSize.x;
previousUV.y *= tileUVSize.y;
newUVs[ i ] = previousUV + offset;
}
mesh.uv = newUVs;
}
I haven't done enough benchmarking to know if this is significantly slower/faster than using something like SpriteManager, but at the very least it's plug and play into my existing feature set.
Just a followup for anybody who may be reading this again. In my particular use case, doing this to get my draw count down was actually SLOWER than doing the material offsets and having each sprite have its own instance of the material. I'm assu$$anonymous$$g it's because modifying the UVs requires resubmitting the VBO to the card and would turn out to be more expensive than eating the draw call saved by doing dynamic batching.
Followup #2: using Sprite$$anonymous$$anager (or equivalent) is a lot faster than using individual game objects in either case.
The problem is that if you modify the texture offset (and you were using the same material for all of your objects), it would change all of the objects' texture offsets (Since it'd be the same instance of the material class).
The only way to get around that really would be to modify the uvs of the models instead, which may or may not be easy
With 2D sprites the UV map data wouldn't be too difficult to modify since it's likely just done on Quads.
Also, kudos on that idea.
