koobas.hobune.stream
Instance geometry to save polycount?
Hi, I was wondering how Unity handles instancing of geometry. Can you save on polycount by using instance geometry for building the game level?
Let's say I'm building some Roman style building with lots of pillars in it. Each pillar is made out of 50 triangles (just to keep the math simple). There should be 20 pillars in the room. Does it in some aspect help performance if I only import one pillar and makes instances of it in Unity, rather then importing the building with all 20 pillars?
I'm quessing that it will save on file size, the FBX will only contain 50 tris, rather then 1000 tris (50x20). But when all the pillars are on screen it still means that all 1000 (disregarding backface culling in this example) will need to be stored in video memory? Or does Unity do any fancy performance magic here? :)
In short, does it save on performance, and not just file size, to use instanced geometry for static objects? And does it work well with the lightmapper?
Cheers!
Aha, DrawCallBatching, that's what's it called, now I know, thanks!
I've been reading that document and examening the Bootcamp demo scene in Unity, and this in perticular caught my eyes.
"Built-in batching support in Unity has significant benefit over simply combining geometry in the modeling tool [...] 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."
In the Bootcamp demo there is a building and it is made up out of three meshes; one for all concrete (all the walls), one for all metal (window frames) and one for wood (the floor). So all windows frames are one single mesh with one material, but as far as I understand what I quoted above is that would in fact be better to keep each window frame as a sperate mesh but sharing the same material. This way Unity can first cull away all the window frames that are not visable (becuase they are behind an interior wall or something like that) and then combine only the visable window frames and make a single DrawCall for them. $$anonymous$$eeping them all as one combined mesh makes the culling operation suffer, and it cost more performance power? Is that about the size of it, or have I missunderstood the manual?
Cheers
So all windows frames are one single mesh with one material, but as far as I understand what I quoted above is that would in fact be better to keep each window frame as a sperate mesh but sharing the same material.
This would likely result in batching, yes, if the number of vertex attributes on the mesh < 900 (I haven't analysed the meshes so I don't know). If it will help you in your specific case I can't really tell, you'd have to profile it to know for sure. This is one of the most important things when it comes to optimization. Profiling. I don't believe there is a single solution to all problems, every problem has its own set of solutions, each with different implications and it can be hard to foresee the outcome in advance.
This way Unity can first cull away all the window frames that are not visable (becuase they are behind an interior wall or something like that) and then combine only the visable window frames and make a single DrawCall for them.
Right, but Occlusion Culling would have to be enabled and configured for the case where a wall is hiding an object. Otherwise it will go on frustum tests.
$$anonymous$$eeping them all as one combined mesh makes the culling operation suffer, and it cost more performance power? Is that about the size of it, or have I missunderstood the manual?
$$anonymous$$eeping them all as one combined mesh means that if you potentially see even the slightest bit of any frame, then all of the geometry is sent to be rendered. Please remember that culling each individual object also has some performance overhead. There are a lot of variables that play here. For one you have the CPU cost and for second you have the GPU cost of rendering anything. Culling is done on the CPU while rendering is done on the GPU. That means that if the game is GPU bound (GPU takes most time), then reducing the amount of stuff to render will ease the GPU, but doing so you will probably add a little work to the CPU. On the other hand, if you have something very simple to render and you already are very CPU bound then adding extra CPU time to reduce something that already takes little GPU time would make little sense and could hurt performance.
Add to this the variety of GPUs and CPUs and your shader complexity and screen resolutions and you have a pretty hard case to say "Yes, this is exactly what you should do." When in doubt, profile it. Even if you're not in doubt, profile it anyway so you can start doubting again :)
Darn! Nothing's ever as simple as one would wish it to be ;)
But thanks a lot! All that information was very interesting and helpful. I guess my best step from here is to learn more about profiling, thanks for the direction! :)
Cheers!
