I am pretty new to Unity and this is basically my first project. I simply want to animate some 2d-balls (circles) that bounces in the scene, however since as far as I have understood it Unity can’t draw circles very well I figured I wanted to do it using meshes.
My solution is thus to add a CircleCollider2D to each ball-object, then I attach a mesh-filter/renderer to each object and then I simply just use the CircleCollider2D-function CreateMesh() and attach it to the mesh-filter/renderer.
This gives me what I want, however, I don’t know the impact on performance this has, because now I have one mesh-filter/renderer PER object instead of one mesh-filter/renderer for the entire scene.
What should I ultimately use for the best performance?
That seems like unnecessarily convoluted way of doing things. It’s not like CircleCollider.CreateMesh() can magically create round mesh which isn’t made from triangles. You might as well create a mesh asset with sufficient amount of corners ahead of time that way Unity can easily do it’s optimizations for drawing many instances of same mesh with no extra work from you. Or depending on your needs you could create a suitably sized circle sprite.
Yeah I agree! It is just that I want to generate the mesh in runtime because in my program I can instantiate balls with a button press and they will each have a random radius from a random range, I thought that if I scaled the collider radius according to the ball radius then the resulting mesh from .CreateMesh() would be the correct size from the get-go with no real hassle.
But in general, is it more efficient to use one single mesh renderer or one per object, or is the overhead basically the same for N draw calls in 1 mesh renderer versus 1 draw call in N mesh renderers?
As a general rule for newcomers, I would avoid optimization early on. Get it working in the first place and then see if it needs optimization. Unless you are doing it as a learning exercise, don’t optimize until you need to. A lot of newbies (myself included) start out trying to make the most performant and optimized foundation but don’t realize we ended up wasting our time. For one, we don’t actually know how to properly optimize early on (like using the profiler). And two, its more important to see if the gameplay is actually fun before spending time on optimization. What if you spend 20 hours optimizing your perfect circle creation and then realize the game isn’t fun to play 5 minutes after you run the scene?
At the end of the day, do what you wish. It is just a suggestion. I came into Unity with no programming background so i learned Unity and how to code simultaneously. You may have previous coding background and actually understand optimization techniques and can efficiently optimize as you go.
Amen, amen, amen. Unity is a BEAST of an engine. So much angst and wasted time and abandoned projects happen just from optimizing stuff that doesn’t need it. Here’s my blurb.
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
At a minimum you want to clearly understand what performance issues you are having:
running too slowly?
loading too slowly?
using too much runtime memory?
final bundle too large?
too much network traffic?
something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.