I was always so worried about poly count, always trying to keep it to a minimum, but I love it that in this video you went from 0.5 FPS to hundreds without reducing a single polygon, always kept with those 21M.
@@Domarius64 why not apply all of the performance techniques at once? As soon as you solve the original problem, shouldn't you apply the other techniques?
@@xomvoid_akaluchiru_987 if you have infinite time, sure, you can do everything. But in the real world you are always making trade offs to get something produced in a way that still turns a profit.
@@Domarius64 Ok, time constraints, sure, but if a product is finished and you're coming back to fix some things then I don't see why implementing all of them would be an issue if the product really does benefit from it. If it doesn't benefit much then I just trust myself to have common sense and see that it's not worth it.
@@xomvoid_akaluchiru_987 that "extra time at the end" literally never happens in game dev :) you always end up releasing the game when its good enough, not because its finished, because it never is. And so you cant justify spending time on things that have no tangible benefit - remember, you said "why not do all of them?" Well, thats why not. If the game runs on the target hardware acceptably, there is no reason to optimise. Plus when you say "why noy do all techniques" like there are only 5 or something. Every different programmer could know any number of techniques they learned about somewhere, too numerous to list, you cant just "do them all". And more importantly, those changes will not have zero impact, there will always be knock on changes related to that, and plenty of opportunity for new bugs to be introduced at every step of the way, all which will have to be fixed, taking even more time. If its working, you leave it alone.
Btw. GPU Instancing will NOT work, if you have enabled SRP Batching in the Render Pipeline Settings. The SRP Batching is also better in performance reasons, because your gameobjects do not need to share the same Mesh/Material.. just the same Shader.
I’ve never tried to measure the difference in performance by myself. But according to what people write at Unity forum, SRP batcher is generally slower than static batching. It has less memory footprint and easier to use though. And in some cases GPU instancing may be more efficient than SRP batching. In case of dense grass field made of 1 instanced mesh, for example.
Thank you! One of the reasons I'm hesitant to try 3D is because I'm worried about performance. 2D is just so much easier and you don't need to worry about performance as much.
Loved it !! when i was about to upload my game i searched this and all the top results were just making the game look like potato 🥔 and today i found this video :) honestly RU-vid should push this video more...
If you have rooms I recommend using a tileset, not joining then into 1 object Just set all the not moving objects to static and enable static batching. That way they can be combined into just a few draw calls! (Same as your windows. All windows and the building should take 2 draw calls if I'm not wrong)
@@Tymon0000 instead of 1 big 3D model you can make it into modular parts. That way unity can cull them with occlusion culling or just batch them with static batching
I have a question about your 3rd point. 4:05 What should I use for organic material? For example, grass, trees, bushes, etc. - but these only "move" by a shader. should I use GPU instancing or static mesh?
Good question, static batching should work for them. When I say no movement what I mean is that objects transforms should not change. Any movement done through the shader is fine.
After a few Unity courses, a few mini games and a whole lot of youtube tutorials, than you! I've come across some tips, but nothing as relevant (and clear) as this one. One thing I struggle with is doing performant UI. I made a small game where the UI uses the same assets as the game, but my god the main menu is slow.
Thank you! If you're looking for tips on UI performance I strongly recommend watching this talk from Unite: Squeezing Unity Tips for Raising Performance. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-_wxitgdx-UI.htmlm38s
I would probably add a fifth point to optimization to disable your own custom gizmo, when checking performance. I was wondering why my project was staying at 30 FPS, when I had very unoptimised gizmo running in background 😅
Why did you combine the meshes in Maya? Doesn't Blender already do that for you when you merge the objects with Ctrl + J? Also, maybe you should mention the SRP Batcher somewhere, even as a pinned comment, I think It's probably worth mentioning.
Hey there! thanks for the great tutorial, really helped me understand this concept, but i have a question now... what if my game is 3d tile based, and these tiles are destructible and walkable? i need them to be individual units but a scene can have around 100K of those tiles... how can i go about it? the tiles are pretty simple already! would really appreciate your input. 🙏🏽
I've created an simple cube object. They have same materials & mesh (cube); I also enabled their GPU instancing in material & and also in URP settings. But batch count is not decreasing. What might be missing? It is same before & after
This dropped my batches from 3k to 2k However, FPS is still the same at 20fps. Profiler says it is due to Rendering. I have 200 animated goblins from Mixamo, animating an idle animation Have a feeling its got to due with Realtime Lighting...
Great explanation, thank you for the video! Now I better understand how it works, but I still can't find the answer I'm looking for. Maybe you could help me (please^_^)? I have 1 meshRenderer that has 46 materials fields set by the same material. This material has GPU instancing enabled and once again it's the same material instance used 46 times in the same mesh. And inspector shows me that it gets 46 batches to render it. Do you know if it is possible to combine these batches in unity without reexporting the mesh in blender or maya? I get it from the server so I can only use runtime operation with it...
Objects do not need to have the same rotation or scale. GPU instancing will work regardless. The requirements for GPU instancing is objects with the same mesh and the same material. Hope this helps.
Outstanding! If I have a big city with lots of different models, do I have to choose between this tecnique vs Occlusion culling? Let's supose that I combine all the meshes in one in Blender. Thanks!
Thanks for the good explanation. Does this apply in the same way for HDRP though? The official docs unfortunately seem to be missing/outdated on that topic.
"they"? - still using unified materials - buildings are static -> static checkbox -> will be combined into fewer meshes, which reduces draw calls - LODs
