|
In my iOS game I have many very small transparent objects sitting on a big terrain mesh, wich is about 7000 polygons big. I'm aware of the fact that transparent objects require every underlying object to be rendered multiple times, in fact game performance drops from 60 to 25 FPS, so I tought to split my terrain mesh in many small parts, with no more than 500 polys each. But, as far as I know, Unity combines meshes with the same materials, and this would happen with my splitted terrain mesh (wich is using only one material). So, when rendering these small transparent objects, does the terrain count again as an unique big object like before, requiring to be drawn again entirely, or does it re-render only the parts with overlaying transparent objects (wich is what I want)? Thanks for your help.
(comments are locked)
|
|
This will require some explanation of how graphics cards and their interfaces work. First, Unity very much doesn't combine meshes with the same material. If you go access the .mesh variable, you will find exactly the same thing you sent in the first time. What it does do is keep vertex buffers on the graphics card, and they don't really ever have to move once they get onto it. If you are using the deferred rendering pipeline, transparent objects are rendered though the forward pipeline for complicated reasons, directly onto the output surface. They are only rendered once. What could be doing this is the transparent objects are being re-sent to the GPU every frame, which is probably what is happening. Try turning static on, and see if anything changes. You should still experience large drops in fps (10-20), since transparent objects are rendered in a bit of a expensive way (additive, after most everything else). If nothing changes, you will just have to accept the performance decrease. It is either a non-optimization on Unity's part, or barring a couple unlikely things, is just the expense of rendering transparent objects. As a engine developer, I can say they are quite annoying. There is no deferred rendering on iOS.
Jun 14 '11 at 12:10 AM
Peter G
Okay, the same comments still apply. The exact rendering path is a little different, but the best solution is still bear with it, or avoid transparencies. You could try geometry replacement and billboarding at distance to reduce the complexity of the transparent objects, but there is really no "easy" solution-the only real changes to improve transparent objects would be on the engine developer's side-not the consumers.
Jun 14 '11 at 12:19 AM
ckfinite
Would DrawMeshNow make any difference to this?
Jun 14 '11 at 12:37 AM
save
I think it would most likely make it slower. I think the big problem is that the little objects are not having their Vertex buffers kept in VRAM, so the little objects have to be sent every frame. I think geometry replacement would be the best way to go.
Jun 14 '11 at 12:44 AM
ckfinite
(comments are locked)
|
