We recently started evaluating Unity tools for iPhone development and we’ve been testing various things with an evaluation license of Unity iPhone basic for a few days now.
So far it looks very good, but I have a few questions:
Looks like there’s something seriously wrong in the polygon count statistics at least in my version (1.5.0f3). Is this a known issue or am I doing something wrong?
I started suspecting Lightwave’s FBX exporter to be buggy because our test models generate roughly 2.5 - 5x more polygons than what’s shown in Lightwave.
Then, I tried creating an empty scene and adding nothing but a camera and a cube generated by Unity’s own tools => the polygon count shows 32 already? I get the same result when I export a cube from Lightwave (it should only have 12 polygons). This amount seems to effectively double if I add a light with “auto” settings to the scene, is this expected behaviour?
Second, we’re considering between the basic version and the advanced one - is there an evaluation version available for the advanced version so we could actually test it? What kind of size/performance enhancements can be expected with the static batching and optimization tools on a typical project?
Third, is it possible to buy one avanced license for the programmer and basic licenses for the graphics designer and the game designer? Is it possible to open / tweak the scenes generated with the advanced version on lower-end versions without breaking something?
That’s exspected behaviour: Unity does only show EFFECTIVE polygons beeing sent to the GPU. And when you have a light casting shadows, you effectively draw the polygon 2 times… Same thing if your cube has various material… etc.
That’s probabily why you display 32 polygons for just a cube.
Just mail Unity @ sales@unity3d.com, they will surely respond to you in a few days, and they usually don’t mind giving away evaluation licences
I don’t think so, but you are better asking Tom or anyone from Unity
Polygon count on the iphone is dependent on the number of passes in your shader, the number of lights and in the scene and also by the polygon order on the model. If the polygon order isn’t optimized in triangle strips the way the iphone likes it, the count increases. I’ve had some models that are around 800 polys become 1.2k models once they were imported.
The only way to get an accurate polygon count for an object is to add it to a scene and check the stats window.
This just doesn’t make any sense, because I’m using a simple diffuse material with single texture, zero lights, and as far as I know the iPhone version doesn’t even support shadows. Switching between the different iPhone default materials makes zero changes to the polygon count, it stays in 32 for a simple cube. That’s pretty much 2.66 times too much
You can try it very easily yourself, just create an empty scene, add a box in there (GameObject → Create Other → Box), make sure you’re using default diffuse material and witness the poly count.
The non-iphone-version displays the polygon count correctly (12 polys, 24 vertices). The same applies for the exported objects.
Oh well, maybe it’s just a bug in the stats view, the stuff runs pretty nicely anyway, but this might be worth checking out.
Hmm, I’m not sure if I found the post you’re talking about but apparently this is caused by the fact that the draw call count is always minimized by Unity, which generates an awful lot of degenerate triangles?
I’m not finding your explanation either ReJ and I did several tests and ended up with a cube with with no lower statistics than:
Tris: 25 Verts: 15
Starting in 3DSMax, I have a single smoothing group and a ‘cardboard box’ UV shell (essentially the only way to unfold a cube properly)…
…bringing it into Unity you immediately get what ookoohko is talking about…32 tris and 24 verts, with no lights and a single diffuse material.
…mucking with the Import Settings, I’m able to get it as low as you see above, which amounts to merely checking Automatically Calculate Normals and setting it to 180. No other options affect the cube stats.
Does Unity actually run the FBX models through some intelligent stripping algorithm? I suspect it has to remap the object if you force the normal generation on with 180 degrees smoothing?
Does it do this for every object, even if the normal generation flag is NOT set? (So, is there any use of trying to optimize the strip of the source model?)
If Unity does not remap the strips, are there any tools available that I could use for minimizing the degenerate vertex / triangle count for the FBX models?
Ha, I’m just surprised I didn’t think to investigate this sooner…now I’m glad you did buddy.
-Steve
EDIT I will add though that this is merely academic for me, as (for the sake of the UT dev’s collective sanity) I don’t see it as a huge issue. Reason one, unless there IS something we can do about it there seems to be nothing we can do about it, and two, unless I’m skirting the upper most poly limit per scene, it really is inconsequential; I don’t feel a scene need be robust in polycount but moreso in composition and artistry. Okay I’m rambling…
Same thing here, I’m just curious if there’s something I can do at my end to ensure better rendering performance for my meshes - if we end up in using Unity in our next game.
AFAIK the degenerate triangles are rejected from the rendering pipe by the hardware (they do waste some bandwidth, though), so I assume this approach was deliberately chosen by the Unity dev team.
Well, triangle stripping can be rather confusing, but that’s the reason for using degenerate triangles; this is a good thing. I think it becomes harder to swallow for many people when you have something as crude seeming as a cube…
…on that note I redid my UV’s to form a soft “S” shape or…
* ****
. . *
…where each asterix (ignore the periods) is a cube face. I ended up with:
Tris 21 Verts 14
…so there’s a small improvement there, but I believe thats about as far as you’re going to get it.
Intel actually had triangle stripping visualizers like, dare I say, 10 years ago and I haven’t thought to look for one since. That would be really about the only way to have control over your meshes.
Beyond that Unity’s method IS the accepted method for dealing with multiple triangle strips, so again it’s not that big a deal as improvements then can come from elsewhere.
I’ve been very confused about degenerate triangles and triangular stripping. All I know about optimizing a mesh is reducing hard edges and minimizing UV seams. I keep reading about triangular stripping and I can’t figure out how this relates to my polygon order on my mesh or my UV layout. Can you please explain how this relates to my mesh triangle and vertex count?
You mention that you formed a soft S for the UV layout. I’ve read some about the UV layout and how UV seams can increase vertex count. Can you please explain how creating the S pattern for UV layout aids in triangular stripping?
Essentially when you have have more than one triangle strip in an object(s), degenerate triangles (non-area triangles; points that share the same space) are created to bridge the two to create a single strip, thus making it all more efficient (more is less? ).
There really isn’t much you can do other than what I proposed in that other thread; single smoothing groups and contiguous UV’s which essentially means minimizing the number of separate UV shells. If you can find an edge to connect another edge to, do it. A quick example is a hand…it’s a complex surface and an inexperienced modeler might UV the top and the bottom separately and just arrange them on their sheet. What you can do in this case is connect all the edges that make up the outside area of the hand of each shell to form a single shell of the hand unfolded. Small improvement but it all adds up.
The “S” shape was an idea as if you follow the form, all the triangles that make up the cube follow one another, so the majority of them share common edges, which will give you a small improvement as that should be one strip (can’t verify).
Now that number started at a whopping 356+/- before I whittled the UV shell to just one (not necessarily ideal mind you, just proving a point). Either way you can see we’re getting 101 extra triangles but only 4 more verts.
So expect that level of difference from most of your objects as modeling low poly inherently introduces irregular surfaces that we NEED to create in order to get the most out of our edge profiles so we have interesting objects beyond spheres and cubes.
So, to make sure I am correctly understanding the process.
From a modeling point of view, to build optimized meshes, I need to pay attention to smoothing groups i.e. hard edges that would cause vertices to split at render time. I also need to pay attention to UV seams and try and make sure the edges are continuous in the UV map as much as possible. And finally, just be conscious of the overall polygon count of the mesh.
Does this sound like I am understanding the process for building optimized meshes correctly? I’m still fuzzy on how triangular stripping works, but it sounds like I don’t need to be too concerned about it if I am follow the above procedures.
…in the console/PC development world(art side), no one talks about it…ever. It’s never been a criteria for modeling. Vert counts, number of materials per model and skin weighting has been at the top of the list. In fact I’d argue that 9 times out of 10, a client has always been most concerned with how many bones per vertice are used during skinning, and even then it’s never been a significant problem.
As far as we’re all concerned with iPhone development, just keep your poly counts reasonable which should lend themselves to more manageable UV shells.
Ultimately, draw calls are what kill performance, so instead of worrying about just one object at a time, concern yourself with managing your texture atlases and batching your objects (if you’re using Unity Basic). Occlusion culling comes next (works outdoors too! Just use large occluders) and between these three things you should be fine.
Well, the problem comes when you try to use the Unity iPhone Advanced dynamic batching on seemingly small objects. We had one model that was around 150 tris in our modeling program, but ended up at nearly 400 once brought into Unity, which effectively meant that the object wasn’t being dynamically batched.
It took a lot of (seemingly magic) messing around with verts and UVs (there were very few edges on the model as it was), and simple things like rotating a UV shell would cause huge differences in the number of tris.
Of course, I could be worrying for nothing. In the end, collision was what brought our framerate down on older hardware (that, and using the character controller… never again). However, I’d still like to find out what the magic sauce is to make an efficient model and UV map.
I would like to know the secret sauce as well! I was testing a simple box with 8 verts and simply rotating the UV shell 45 degrees added more tris and vertices when imported into Unity. I have to say, this makes no sense to me. Perhaps these little differences don’t really matter as long as the I’ve paid attention to poly count, smoothing angles and UV edges. I just want to know what I need to do to create optimized meshes as a modeler.
