koobas.hobune.stream
Problem with render order using 3 cameras!
Problems with rendering order using 3 cameras!
Hello guys! My project is structured as follows: - A "Main Camera" that renders the game properly; - A "GUI Camera" to render the GUI! I had to separate the GUI from the Main Camera, because for some reason the "Bloom" effect did not work on the GUI buttons in "Overlay" mode, so I had to create a GUI Camera in Screen Space - Camera mode; - A "Skybox Camera" to render only the Skybox. It was the only way I found that I had a little control in the position of the Skybox;
The problem is that even setting the Depth correctly on the cameras, the rendering order gets messy when I press Play. In the editor, everything is fine, but in Play mode, the Main Camera is rendered in front of the GUI Camera.
Could someone help me with this problem?
The problem is with the combination of canvas plane distance, gui camera near clip plane and mainCamera near clip plane values. These values should be in the following order: GUICameraNearClipPlane < CanvasPlaneDistance < GUICameraFarClipPlane < MainCameraNearPlaneDistance
Try these values:
GUICameraNearClipPlane = 0.01
CanvasPlaneDistance = 0.02
GUICameraFarClipPlane = 0.03 (Not required though, but should be greater than CanvasPlaneDistance)
MainCameraNearPlaneDistance = 0.3
In your case you are using more cameras than required, each new camera has got performance overhead, to achieve the bloom effect on UI elements just make the canvas render mode as world space and parent it to the moving camera.
Hope this helps :)
Thank you for this. I've spent the whole afternoon trying to fix a problem that I was sure was caused by camera rendering order. Unity docs state that rendering order is controlled by the camera's depth setting. This is the only mention I've found anywhere of the clipping planes affecting render order, but sure enough this has fixed my problem.
The problem is the DontClear setting (on GUICamera in the middle). Things you want shown as overlays should be DepthOnly, which means: always draw the whole sprite, covering up lower-depth cameras, and being coverable-up-able by higher depth cameras.
DontClear is DepthOnly with an extra restriction: it says to check each pixel of your sprite for being behind a rock or a tree from a previous camera. Not only do you almost never want that, but it makes no sense for a GUI camera off to the side, with different settings. Even so, the computer tries. Technically, a sprite's depth is its percent distance between the near and far clipping planes. That's why messing around with them "fixes" it (there are a million ways to make the sprite count as "very low depth".
A way to use DontClear would be to have a world canvas, actually in the scene, using a camera exactly following the 3D scene camera. Then the depths would be computed using the same scale as the world, and parts would be properly blocked by closer 3D objects (I think).
