- Home /
How to control render order with DrawMeshNow?
Normally, I can put something like this in a shader to control what order it gets rendered at relative to other shaders:
Tags { "Queue"="Transparent+1" }
In the case of Graphics.DrawMeshNow, the order is controlled by simply when my code calls the function. However, I'm not aware of any way to make my code (which is currently in the OnRenderObject callback) run before all of the queues have been rendered, thus any meshes (transparent or opaque) that I render with DrawMeshNow will always render on top of (and obscure) transparent things such as particle effects and GUI/menu layers.
The only solution I know of is to convert all of my particle effects and menu screens to also render with DrawMeshNow so that I can control the order they get called at relative to these objects and each other. My question is, given that I need to draw certain objects with DrawMeshNow for performance reasons, is there any other way to prevent them from covering up my particle effects and menu screens?
EDIT: I guess I had already thought of a solution to this involving multiple cameras, and had temporarily forgotten about it when I asked this question. Feel free to include that in an answer, but I have heard from several people that using multiple cameras is extremely slow on mobile platforms no matter what they render, so if that's still true I'd like to avoid it (and if it's not true, some confirmation to that effect would be nice).
Define "extremely slow". I had a Portal-esque system running on a iPod touch 2G, that was rendering maybe three portals at a time, each two levels deep, and I was getting 20-30 FPS. No render texture solution was available, though I was rendering the portals only in the necessary screen rectangles. Each one needed a camera. So I think you've been misled.
I think I read recently that Unity copies the framebuffer pixels between cameras if both cameras are rendering to the same framebuffer, which sounds slow for iPhone 4 and iPod touch 4G due to their high resolution (and also sounds unnecessary, but a lot of things in Unity's rendering pipeline are like that...).
Also, perhaps I was exaggerating and should have said "kind of slow" rather than "extremely slow". Either way, an avoidable loss of even a few FPS would be too much.
I don't know what kind of mesh you are rendering manually with Draw$$anonymous$$eshNow but you might just create an empty GameObject for each of those meshes and let Unity take care of things. By changing the gameobject's position accordingly you could kinda make sure that they get drawn first PLUS you get dynamic batching automatically when the conditions are met (same material, etc.).
I'm not using GameObjects here because changing their position is slightly slow, and changing their scale is ridiculously slow when they contain meshes, and they do automatic sorting and culling which I don't need and which use up CPU. And I never use dynamic batching anyway because all it seems to do is cause graphics glitches and reduce the framerate (although I'm making it sound worse than it is; usually it doesn't make a difference either way).
Also, I could use Draw$$anonymous$$esh ins$$anonymous$$d of Draw$$anonymous$$eshNow, but Draw$$anonymous$$eshNow seems to be faster in the tests I've done so far (probably due to it skipping more of the rendering pipeline).
Your answer
Follow this Question
Related Questions
How to replicate renderer.worldToLocalMatrix 0 Answers
Transparent Shader Render Order Issue 0 Answers
Black Texture on Initial Load 1 Answer
Fake PS1 "jittery movement" effect in Unity? 1 Answer
Greyscale shading 0 Answers