|
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
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:
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.
(comments are locked)
|
|
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.
May 24 '10 at 09:52 PM
equalsequals
(comments are locked)
|

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 assuming 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 SpriteManager (or equivalent) is a lot faster than using individual game objects in either case.