Like any optimization Static batching is a trade. It uses more (gpu) memory for the merged meshes than individual instances (if they are not each unique themselves already). Static batching works at the same time as the scriptable renderer batching. You can combine both for best results. There are many reasons a static batch can be broken apart, figuring those out and fixing them can drastically improve the efficiency of the batches (like manually sorting some materials via renderqueue).
Props for this video and most of all not spreading misinformation about the "magic numbers". This is a good rundown of all the various data that can and need to be watched for batching to works. SRP is way stronger and "interfere" with static batching tho. SRP dosen't required any set up, plus it also disregard and remove the atlassing texture requirements, since it is Shader-based. So as long as you are using URP and keep track of good shader practice/architecture, you'll have free performance. I'll even throw a bonus here if some people are still on the fence about standard vs URP, it's out of the box around 30% more performant right away with just an empty scene/box setup to test on low end device. URP/HDRP is just so OP and totally not understood under the hood.
I know someone who works in a VR company and when they did scene optimizations, for them, disabling the SRP batcher and only using material instancing was more performant for their scene setup. So it might be worth to test by a case by case basis
@@dreamisover9813 Yep optimisation is an art by itself, more akin to a science. Its a series of educated guess and test based on the context the game. There is no one size fits all solution, but there are some constant nonetheless, the number of calls, the drawcall times, but ultimately the combined ms from cpu and gpu time is king. I've optimzed over 50 projects in my career and i can 100% confirm that URP are insanely faster. The main issue is the inability from unity to communicate these changes/people not understanding the lower lever of how rendering now work. For instance they also release the shadergraph at the same time, consequence of this ? anyone can create a shader for a specific need, ergo breaking SRP batcher out of the box optimisation. When planned accordingly 10 shaders always been close to what I needed for entire projects, nowadays when i go to help studio optimise their game I see 300+. SRP if you have 10 shader it would be more or less 10 drawcalls for the entire scene. there are way more consideration to take in like render order, but essentially it auto-batch shaders regardless of their model and texture input, contrary to static batching which merge the meshes on the cpu level, need to be carefully planned, and will in some instance break world space effect + frustum culling, since the meshes are purely merged with a new pivot. Any use case are different but VR are the most hardcore to optimized, you render the scene twice in insane resolution, you need 72 fps and the devices are sometimes akin to the lower end platform. For performance to work flawlessly game studios need to adress this as early as prototyping and keep validating every step of the way, establish the correct guidelines and act accordingly within the production, sadly the reality is that people wait at the end when everything is on fire.
@@2Jackrabbit Yeah, you're either bottlenecked by the cpu or gpu. gpu seems to be more common with games nowadays. As far as I understand, URP/HDRP has some cpu/main thread overhead to do processing in order to make the rendering steps more optimal. Comparing a blank project between urp and builtin also results in a faster builtin project for me, but it depends what you put into the scenes as to what's more optimal. The SRP batcher is pretty great for sure.
@@dreamisover9813 Yep ! on that note tho what I teach studios is that GPU-bound almost never exist. Because in order to be GPU-bound you need to have a Idle CPU aka you can only really validate this by having optimized the CPU-boundness ;). So always start up with the CPU optimization, then if the frame still clogged in the response time, yep you are GPU bound. And for the result to work don't forget to check the box in player settings "Graphic Jobs", they work hand in hand with a couple other settings
@@2Jackrabbit makes sense, good tips! (Well I'd expect for a lot of games with simpler graphics, cpu bound might be more common, but for open world titles, games with quite complex shaders etc., gpu bound might be more common if unoptimized). I guess with modern profiling tools though it should be easier to figure out where the overhead lies.
Does this work if i want to delete an object from the scene (or add) after the whole thing is drawn?(for example if you have 10 cars and wana remove one or more) Or after drawn it stays as 1 whole mesh?
The biggest drawback for me is that static batching happens on build and all static meshes gets combined and saved into huge meshes which can dramatically increase build size. I would prefer it doing the combine in runtime on scene load, like CombineMeshes for example.
Static Batching combines meshes together that use a MeshFilter and MeshRenderer. I expect if you’re using sprites and sprite renderer, you will not benefit from this.
1. How ?, Doesnt it still render the same amount of vertices ? 2. Only works for non controllable obj right ? ( No script, no move, ...) 3. Can i do smth with the movig obj ?, Im making a 2d fighting game and it should have a lot of projectiles
It does render the same number of vertices. This is about reducing the communication between the CPU and GPU by batching draw calls together. You can have scripts on the objects, but they cannot move. For 2d, this is probably not the right tool for you because this works on MeshFilter and MeshRenderer. For 2d you are most likely using Sprites and SpriteRenderers which do not support Static Batching.
Hey can you tell me only clock wise rotation towards target I used Quaternion slerp and much more but some time clock wise and some time anti clockwise take
When I use Quaternion.Slerp, it always takes the shortest rotation to that new rotation. To ensure it always turns clockwise, you’d need to check if it’s shorter to go the “wrong” direction, and instead split the turn to 2 parts, forcing clockwise rotation with at most
Thanks for this tutorial But you may have known that static batching work only for objects having the same material My unity scene is just busy of different materials
I do believe I mentioned that in this tutorial. One optimization for your scene is to combine materials and use texture atlasing to minimize the number of materials
Hello! I've been following your videos for some time now, I implemented the suface/impact manager but have problems when trying to optimize my scenes using static batching. I lose the ability to read the textures on my meshes, despite having them on Read/Write enabled, after some research I figured out that it was due to the change to static batching. Is there any way to access the textures despite being static batched?
Hmmm… not sure. I think the static batching creates an unreadable mesh. You could maybe use the runtime API to statically batch on level load and maybe that would give you a mesh you could read.
![[Full] 4 ต่อ 4 Celebrity EP.922 | 10 พ.ย. 67 | one31](http://i.ytimg.com/vi/zmV5HRIxIBI/mqdefault.jpg)
Like any optimization Static batching is a trade. It uses more (gpu) memory for the merged meshes than individual instances (if they are not each unique themselves already). Static batching works at the same time as the scriptable renderer batching. You can combine both for best results. There are many reasons a static batch can be broken apart, figuring those out and fixing them can drastically improve the efficiency of the batches (like manually sorting some materials via renderqueue).
Great Info! Ill keep this in my back pocket for later!
PLEASE give us a tutorial on the runtime batching calls!!
✔ I hear you!
Props for this video and most of all not spreading misinformation about the "magic numbers". This is a good rundown of all the various data that can and need to be watched for batching to works. SRP is way stronger and "interfere" with static batching tho. SRP dosen't required any set up, plus it also disregard and remove the atlassing texture requirements, since it is Shader-based. So as long as you are using URP and keep track of good shader practice/architecture, you'll have free performance. I'll even throw a bonus here if some people are still on the fence about standard vs URP, it's out of the box around 30% more performant right away with just an empty scene/box setup to test on low end device. URP/HDRP is just so OP and totally not understood under the hood.
I know someone who works in a VR company and when they did scene optimizations, for them, disabling the SRP batcher and only using material instancing was more performant for their scene setup. So it might be worth to test by a case by case basis
@@dreamisover9813 Yep optimisation is an art by itself, more akin to a science. Its a series of educated guess and test based on the context the game. There is no one size fits all solution, but there are some constant nonetheless, the number of calls, the drawcall times, but ultimately the combined ms from cpu and gpu time is king.
I've optimzed over 50 projects in my career and i can 100% confirm that URP are insanely faster. The main issue is the inability from unity to communicate these changes/people not understanding the lower lever of how rendering now work. For instance they also release the shadergraph at the same time, consequence of this ? anyone can create a shader for a specific need, ergo breaking SRP batcher out of the box optimisation. When planned accordingly 10 shaders always been close to what I needed for entire projects, nowadays when i go to help studio optimise their game I see 300+. SRP if you have 10 shader it would be more or less 10 drawcalls for the entire scene. there are way more consideration to take in like render order, but essentially it auto-batch shaders regardless of their model and texture input, contrary to static batching which merge the meshes on the cpu level, need to be carefully planned, and will in some instance break world space effect + frustum culling, since the meshes are purely merged with a new pivot.
Any use case are different but VR are the most hardcore to optimized, you render the scene twice in insane resolution, you need 72 fps and the devices are sometimes akin to the lower end platform.
For performance to work flawlessly game studios need to adress this as early as prototyping and keep validating every step of the way, establish the correct guidelines and act accordingly within the production, sadly the reality is that people wait at the end when everything is on fire.
@@2Jackrabbit Yeah, you're either bottlenecked by the cpu or gpu. gpu seems to be more common with games nowadays. As far as I understand, URP/HDRP has some cpu/main thread overhead to do processing in order to make the rendering steps more optimal. Comparing a blank project between urp and builtin also results in a faster builtin project for me, but it depends what you put into the scenes as to what's more optimal. The SRP batcher is pretty great for sure.
@@dreamisover9813 Yep ! on that note tho what I teach studios is that GPU-bound almost never exist. Because in order to be GPU-bound you need to have a Idle CPU aka you can only really validate this by having optimized the CPU-boundness ;). So always start up with the CPU optimization, then if the frame still clogged in the response time, yep you are GPU bound.
And for the result to work don't forget to check the box in player settings "Graphic Jobs", they work hand in hand with a couple other settings
@@2Jackrabbit makes sense, good tips! (Well I'd expect for a lot of games with simpler graphics, cpu bound might be more common, but for open world titles, games with quite complex shaders etc., gpu bound might be more common if unoptimized). I guess with modern profiling tools though it should be easier to figure out where the overhead lies.
Great video, keep going!
Does this work if i want to delete an object from the scene (or add) after the whole thing is drawn?(for example if you have 10 cars and wana remove one or more)
Or after drawn it stays as 1 whole mesh?
At LOD0 you can add/remove objects at runtime without consequence. Each LOD1-N are baked though, so they will not reflect any changes made at LOD0
New dev here, can this be used in tandem with occlusion culling? Or should i use one over the other in specific circumstances.
Yup! It works with the built-in occlusion culling
Thanks
On unity wean I have object that doesn't move,
I always add static as opinion but I don't know Wich opinion is enabled wean I add this option
We want more optimization tutorials. If possible then please create.
✔ I hear you!
Amazing 👏
Subscribed!
The biggest drawback for me is that static batching happens on build and all static meshes gets combined and saved into huge meshes which can dramatically increase build size. I would prefer it doing the combine in runtime on scene load, like CombineMeshes for example.
That is a good idea if your build size balloons too big using static batching
Hi Chris, I haven't had the chance to watch all your video yet, but will this work in 2D ?
Static Batching combines meshes together that use a MeshFilter and MeshRenderer. I expect if you’re using sprites and sprite renderer, you will not benefit from this.
@@LlamAcademy oh yea, I didn't think about that! Thnx
1. How ?, Doesnt it still render the same amount of vertices ?
2. Only works for non controllable obj right ? ( No script, no move, ...)
3. Can i do smth with the movig obj ?, Im making a 2d fighting game and it should have a lot of projectiles
It does render the same number of vertices. This is about reducing the communication between the CPU and GPU by batching draw calls together.
You can have scripts on the objects, but they cannot move.
For 2d, this is probably not the right tool for you because this works on MeshFilter and MeshRenderer. For 2d you are most likely using Sprites and SpriteRenderers which do not support Static Batching.
@@LlamAcademy Thank you for helping. Btw is there any way to improve fps on 2d games ?
Sorry, I don’t have any good tips. I have actually never worked in a 2d environment within Unity.
@@LlamAcademy oh, thank you then.
@@starplatinum3305 use Sprite Atlas for decrease batches in 2d game ( I have only this tips still finding more tips)
Hey can you tell me only clock wise rotation towards target I used Quaternion slerp and much more but some time clock wise and some time anti clockwise take
When I use Quaternion.Slerp, it always takes the shortest rotation to that new rotation. To ensure it always turns clockwise, you’d need to check if it’s shorter to go the “wrong” direction, and instead split the turn to 2 parts, forcing clockwise rotation with at most
@@LlamAcademy i can't able to understand please tell me in code ?
@@LlamAcademy I slerp doesn't work in nagative speed
Thanks for this tutorial
But you may have known that static batching work only for objects having the same material
My unity scene is just busy of different materials
I do believe I mentioned that in this tutorial. One optimization for your scene is to combine materials and use texture atlasing to minimize the number of materials
@@LlamAcademy I did what you said with texture baker but it still doesn't work
My scene is like 5 fps running
I don't know what to do
2:49 shadows turned on
🙂 good eye. I just took the screenshots in the other order. The shadows remained off the whole time
Hello! I've been following your videos for some time now, I implemented the suface/impact manager but have problems when trying to optimize my scenes using static batching. I lose the ability to read the textures on my meshes, despite having them on Read/Write enabled, after some research I figured out that it was due to the change to static batching.
Is there any way to access the textures despite being static batched?
Hmmm… not sure. I think the static batching creates an unreadable mesh. You could maybe use the runtime API to statically batch on level load and maybe that would give you a mesh you could read.
@@LlamAcademy cool! I'll look into it! Thanks a lot 🙌🏼🙏🏻
Waiting for new optimization videos
Thx
❤
🧡
noicee
tHANK FOR THE VIDEO BUT UR INTO So cringe and uh i dont know