koobas.hobune.stream
Using an Animator vs. simply manually setting uv's
I am trying to understand if there are any performance advantages to using an Animator and an Animation Clip as opposed to manually switching the mesh.uv array during update() to create an animated sprite on a quad.
Currently I am using the manual method, and it seems to work fine, so I have not looked into the Animation apparatus. I'd rather not create an animator, but before I continue down this path, I wanted to make sure I'm not missing out on a performance advantage that I'm not aware of.
The situation is that I have up to 200 bullets (animated sprite quads) flying around in the scene. They all use different sections of the same large texture atlas. They are each instances of a single prefab which is just a quad with script attached that has a property that holds all the predefined arrays of Vector2 that are the different sets of uv's. During update(), the script sets mesh.uv to the next Vector2 array, and the quad animates perfectly.
I just wanted to get some feedback about this approach before going further having forgone the use of an Animator. Thanks!
@penneyworth1 Your question is a bit context dependent. Of course the Animator has some performance overhead (it probably uses Reflection which creates the most of this overhead), which is not noticeable in simple cases. But if you have hundreds of objects on a complex scene on a mobile devices, things may appear to be different.
You can make a simplified performance test to see if it fits your requirements, prior to making a complex manager class.
One more consideration. Having a black box (the Animator solution), gives you less ways to optimize the behavior of your system. For example, you may decide to skip your calculations on some frames or camera views, etc., or probably make them more complex if your bullets comes very close to the camera.
So if you were just planning the system, checking the Animator solution could be a faster way to accomplish the task. But if you have already made a working solution, just stay cool :)
IMHO, if you have already made a system that does what you need, with appropriate performance - just go on with your other tasks, don't waste your time for unneeded perfection. But if it is just a sort of fun / educational project - checking the alternative solution might be a good point.
I appreciate the response! Yes, I do have a working solution, but I ask this because I don't know what I don't know. For instance, a while ago I didn't know that changing the material's color at runtime would instance another material and add another draw call, which is a huge performance disaster if you want 100 simple bullets to flash between colors and you choose that approach. I was really trying to find out if there was some similar gotcha when rapidly switching the uv array on a mesh. $$anonymous$$aybe it rebuilds the mesh or something I couldn't have imagined. I can't find any examples of anyone creating sprites by simply cycling arrays of uv's on a mesh, which seems like the simplest solution by far to me, and that worries me a lot. If it isn't a standard practice, there must be some drawback that I don't yet understand. Hope that makes sense.
