I am currently developping my first iphone game (it is a 3D tower defense and RTS game at the same time). This is still at beta stage, so please forgive any discrepancies on the screenshots.
For the draggable units in the UI, I am using the SM2 package.
While the game still runs at reasonable frame rate, I am struggling with the number of draw calls:
All glow effects are using the same material. From the unity iphone editor Emulated Draw Calls, it seems to use a 1 to 1 draw call per instance of the glow. Isn t it weird?
The 3D Text objects used for the prices of towers or mobile units seem to require one draw call each. I thought unity would batch the draw calls for those objects. Am I missing something?
By the way, is it true that Unity 3.x will support a 2D sprite engine?
well they look differently so are you sure its the same material (same material means no changes to color or anything at runtime, otherwise you create a new material actually)
these objects are “old day functionality”, they are not integrated with the batching.
Are you sure about the 3D Text objects not being batched?
Our recently released game Word Monkey uses a single 3D Text Mesh object for each block, and those all get batched (we never get above 15 draw calls, and there are easily 60 3D text objects on screen at a time). They should be batched, since they go through the 3D renderer. GUIText, on the other hand, does NOT get batched.
3d text works with regular meshes and should theoretically batch yeah.
My bad, had GUIText in the back of my head again because I use the 3D texts that rarely.
Its only a problem with the gui systems as none of the gui systems, neither the 1.x (guitext / guitexture) nor 2.x (ongui with gui.xx) batch.
@mohydine: a single texture does not mean a single material. Single material really means the one and same material for all in the the editor and not touching any values on it through code at runtime.
This could be an issue related to Unity’s breaking each glow effect into a separate drawcall due to the fact they use a blended shader and are too near to something else depth-wise, causing Unity to think it has to rendering them separately to be blended correctly. This is a little difficult to explain in text, but there’s a visual aid and a lengthy description of this issue, along with some suggestions on how to resolve it, in the latest SM2 docs. Let me know if you have any questions on that.
As for 3.0, yes, it would appear so. No word yet on what exactly it will entail, but I’ll very likely be writing a new version (possibly an SM3, depending on how radical a change it is) to take advantage of the new engine to provide you with even better performance, even MORE features, and an even EASIER workflow.
Hmmm I tried to adjust the depth of the glow, no effect. And I am using the standard Transparent/Vertex Colored Shader.
No lights in my scene.
And… I get a 25 FPS for 41-50 draw calls (looking at the internal profiler stats) on my ipod touch. Havent tried on 3GS yet. I thought I was way over the limit of 30, but I can t see any difference… The game is still responding in a fluid manner. Does anyone have any idea? This isnt bad news but I am afraid I went in the wrong design direction and would have to redo everything later on.
It won’t look right, but try the cutout shader that comes with SM2 and see if it changes the draw call count. You won’t actually want to use that, but it’ll at least tell you if that’s what’s going on.
Yep, that would seem to indicate it’s separating the blended glow sprites because of the reasons described in the SM2 docs.
Adjusting the depth to solve the problem can be tricky if there are lots of other things in the scene since it’s based on the distance from the camera, which increases as an object approaches the edge of the screen, even if it has the same ‘Z’ coordinate. For a UI, try rendering the UI on a separate layer using a separate camera set to orthographic. Then you should be able to radically separate the glows depth-wise from other GUI elements, making sure that nothing could possibly be competing for the same depth queue spot.
Another thing to try is to make sure your glow graphic is on the same atlas (and material) as all other sprites being drawn for the UI. This way Unity can depth sort the sprites with regard to eachother, but since they are all on the same material they can be batched together.
Adding a second camera seems to reduce the frame rate: so I will postpone it for the moment. Not good for me.
HOWEVER, putting every UI elements into the same alias worked fine and reduced the number of draw calls. However, even in that case I had to manually adjust the depth of each object, so that I can get a very low draw call number.
I will go further into that direction and let you know. Thanks guys !
