koobas.hobune.stream
Are batching and atlas almost useless ?!!!
hi...
Now that I know batching is also a matter proximity and far objects sharing the same material won't batch (at least for static objects) ,I can come to the conclusion that we can use Atlas only for close objects other than that no matter what, your objects won't batch with or without Atlas and u get extra drawcalls...
with that in mind, this question comes to surface: what good does it have to use atlas ? or lemme even put it this way why bother letting unity batch things for us where it only batches close objects with the same materials ? why not combine objects and forget about batching? or why not at lease use batching for close objects with the same material and combine far objects? I know sometimes it's the matter of optimization. for example combing objects isn't suitable for occlusion culling. but what else can I do ? I don't always have close objects . some r far and some r close with same materials. how u guys deal with it ? thx in advance...
If you don't use atlases, then your game may run much more slowly on some hardware. We had a scene where we had maybe 30 materials and the result was that we had ~95 draw calls and it ran slowly. We took the same scene and reduced it to 5 materials and it was more than twice as fast and smooth 30+ fps.
Essentially my advice is to stick to these principals:
Use texture atlases
Use the same material wherever you can!
Avoid scaling your geometry as it will typically fail to batch
Expect that skinned meshes won't batch
Avoid transparency if you can as I understand this to mess with batching due to draw order
Expect more draw calls if you receive shadows anywhere (looks like just +1)
Expect the numbers to go up as you add lights
Deferred Rendering is cheaper with many lights but will typically have a lot of draw calls and it isn't clear why, but that's just a product of how that renderer works.
The bottom line is - do the above and don't worry if the numbers don't make sense. DO worry if your numbers are much higher than you hoped and then DO check the above.
Removed ? Oh no Bovine :( I thought.... doesn't matter. I don't really know what I would do without your help.. Thank you so much...
This was that bit you identified as being an answer - I tidied it up as I agreed - you might want to check out the comments regarding your scene on the comment further down the page.
"This was that bit you identified as being an answer - I tidied it up as I agreed"
yeah, right. but I thought you'd convert your last comment to answer and you'd keep everything intact as it was. on the other hand I chose it as an answer because there was no answer left. You told me that I don't have to be that sensitive bout the stats. using atlases and having less materials will do the job for you regardless of the stats and I agreed with that. but the real reason why, would always wander in my $$anonymous$$d. I'm sorry for not being clear enough anyway :(
"you might want to check out the comments regarding your scene on the comment further down the page."
TnQ
NP, I brought part of that sentiment into the answer and add some bullet points from my testing in your scene.
If you have an atlas, if your scene consists of 300 objects and 90 are in view, then you could conceivable render the whole lot in 1 draw call - which is very efficient. If you didn't have an atlas and each object had its own material, then you would have 90 draw calls.
I don't know what you mean about a mater of proximity. if two objects are far apart, then you don't want to combine them and indeed Unity seems to suggest that combining objects might not be the best idea:
"Batching in Unity happens after visibility determination step. The engine does culling on each object individually, and the amount of rendered geometry is going to be the same as without batching. Combining geometry in the modeling tool, on the other hand, prevents effecient culling and results in much higher amount of geometry being rendered."
Taken from this page, talking about iPhone in particular but batching is the same deal on every platform:
http://docs.unity3d.com/Documentation/Manual/iphone-DrawCall-Batching.html
Personally we do combine geometry that uses the same material locally but having read this, maybe we shouldn't be. Our concern would be some reports of scenes exploding from 400K to 18MB by relying on static batching.
So, static batching WILL work for objects sharing the same material regardless of how close together they are. If you have some static, crate-like boxes for instance, you might want a couple of variations of these, but you would use the same material on them. If you had 100 in your scene, then you ought only to get 1 drawcall for all the boxes rendered.
Remember that when statically batching, you need to tick select that static flag for each static object.
I am sure I have read that the stats are not nec. accurate - they are an approximation. $$anonymous$$aybe I was reading about stats reported when targeting mobile, but maybe it's true of the stats generally.
The docs aren't terribly clear tbh...
http://docs.unity3d.com/Documentation/$$anonymous$$anual/RenderingStatistics.html
I'm quoting theory as I understand it after doing some reading and the Unity docs - I am quite happy to go on faith of course as well; the numbers may not make sense to me, but the fact I have stuff batching is good, and I know that to achieve the best results, marking things static and sharing materials will allow me to benefit.
Lighting will change things because I think this affects the number of draw calls from reading the docs - objects are rendered once or more per light I believe in forward, unsure about deferred.
I think the point is, despite the fact that the stat numbers don't make perfect sense, there is a definite benefit to batching and sharing atlases. On top of the ability to batch draw calls together, is the fact that you won't be changing state (i.e. material state) between draw calls. You also won't be using up VRA$$anonymous$$ (where you have it).
Your statement in your question is this:
"I can come to the conclusion that we can use Atlas only for close objects other than that no matter what, your objects won't batch with or without Atlas and u get extra drawcalls..."
And I and others are saying that while the numbers might not add up, this isn't a good reason to not use textures atlases or batching. You also can't necessarily define what 'close objects' are unless you're restricting the range of your camera heavily - the player can always move to some other, distant objects, and just because they weren't being batched earlier, doesn't mean they won't be now you are closer - unless of course you used different materials on them.
I just did a quick test of my own:
1 plane 3 near cubes 3 far cubes
ALL are marked as static batching
1 Light
With the Camera in Vertex Lit and forward modes I get 1 draw call and 7 batching. In deferred I get 11 and 14 batching. I'm happy to assume something's going on that I don't need to know about.
If I add a light, then it makes no odds to vertex lit mode, but in forward it seems that I only get batching for the first light (I'm adding directionals, I don't know if it makes a difference), so it goes to draw calls 8, batched 7, then 15/7 and then 22/7 (additional lights are pricey!).
For deferred rendering it's much better: my 11/14 becomes 12/14 and then 13/14 - each additional light, in this scene, amounts to an additional draw call.
Where did you read that about the mac version?
Anyway your scene:
Has a skinned mesh which won't batch (it animates and is over 900 verts for dynamic batching) and will always be two draw-calls (man + wrench)
Your ground cube is not using the same texture and I believe won't batch because you're using non-uniform scaling, so it won't dynamically batch either.
Receiving shadows adds a draw call, probably drawing everything that would batch in one call int the stencil buffer if that's what it's using
Taking all these things into acount everything in your scene will batch and does batch for me in Vertex Lit mode and in Forward mode all 6 cubes batch.
Hope that helps!
If I start your scene as you sent it I get 5 and 2 batching, but as I say above there are reasons for those numbers.
Your ground cube is using a different materia and isn't marked static and won't batch
You have a skinned mesh and a wrench which cannot batch
Your objects are receiving shadows and for some reason this adds a draw call and reduces the number that can batch
