Build() performance

[schragnasher]

Is Build() a large performance hog? We need to be able to scale our mesh collider when we scale a tk2dsprite and the only way to work it without adding new draw calls is with Build(), i just want to make sure this is a decent way of doing it. Scaling the transforms seems to add to my draw calls.

[unikronsoftware]

You should avoid scaling mesh colliders at runtime if you can avoid it. Its not exactly cheap whichever way you do it. Scaling using transform is a lot cheaper than Build, which rebuilds the meshcollider, but neither of them are ideal. Avoid if you can, but if you must - you can workaround by doing this -

Make sure all your sprites have a different z-scale to the x & y. For example, give everything a z-scale of 1.00001 - and now you can scale on x & y and retain batching. Just make sure that the scales are non-uniform ALWAYS, and you will be golden

I'm glad you brought this up - it gave me an idea to work around this much easier by making scales nonuniform whenever .scale is used. Should be able to make this work retroactively as well.

[schragnasher]

Ok that seems to work...i don't understand WHY it works lol but it does. What is happening differently when i use the workaround that doesn't add to draw calls? When i started with 1,1,1 uniform scale each asteroid i scale with the transform would add to the draw calls. That is quite odd.

[unikronsoftware]

There are few different optimized render codepaths in Unity which it picks depending on parameters, number of rendered meshes, phase of the moon, etc. This is one of them