Glitching with multiple cameras LWRP

Hey so I use 3 camera with 2 being Depth only and the last being a solid color. This worked fine up until I started using the LWRP. I've tried searching a few topics about this and trying a few things but I can't figure it out. If anyone else has any ideas regarding this I'd really appreciate it

https://drive.google.com/file/d/1ezqy8IUmW2uLHEholuIaHK-UnCjV4Gat

 

LWRP and HDRP don't support multiple layered cameras. Github Changelog

This was changed/updated for SRP versions 4.2.0 and above.

 

Ah okay I guess that explains it. I appreciate the reply

 

Does that mean I also won't be able to use cameras with different Viewport Rects, like an extra camera rendering an object in a corner? Also, are they taking that out for good or do they plan to bring it back in at some point?

 

Update: this answered my question about Viewport Rects https://forum.unity.com/threads/hdrp-camera-viewportrect-broken.546102/#post-3962893

 

wait, what? this breaks known rendering techniques for post fx in AR. weird decision...

 

What about rendering of huge worlds in the space simulators? For example I have three cameras one with near/far clip planes 1 - 5000, second - 5000-100000, and the third one is rendering scaled space. So, how to properly implement this in the LWRP?

 

What about if I want to use a orhto camera on top of a perspective camera for a 2.5D game?

Is that still possible without camera stacking?

 

up

 

up

 

Why would you actually need multiple cameras for that?

Can't you just make those further out planet offset their locations with the camera so they follow it and don't get any closer. I'd suggest faking the planet scale so you can have planets closer to camera in scene to avoid floating point issues. You should be able to achieve similar result as with multiple cameras but more efficiently.

 

If you launch your spaceship from the surface of planet with 600km radius (1/10 of the actual Earth and almost 1/2 of the Moon), even 50 km far clip plane is not enough for distant view and you already have z-buffer precision issues like z-fighting or inaccurate results when calculating atmospheric scattering. 2 cameras solved this very easily. I want to know how to solve this with one camera setup.

 

How to render geometry that requires special camera setup

Users need to create a ScriptableRenderPass and inject in LWRP code to render things that require different camera matrices/fov. These vary on a case by case scenario, f.ex, rendering weapons in an FPS.


This is worrying me, it sounds so complicated, that the end result is that will not be using LWRP but stay with unity classic render pipeline, is that not backwards of the goal of helping users get better performance?

I need two cameras with different perspectives on top of each other. and I don't like it if the option is talken away.

Just keep it in there with a warning use at your own risk.

Or make the requered injected render pass for us, because I can't program a render pass but I can stack two cameras.

Please put my worries to rest, and clarify how it will work for someone who is not a programmer

 

Thanks thats good to hear! really appreaciate that these use cases are taken in consideration.

 

Thanks thats brilliant!

 

I man not sure if I understand the issue correctly. Does that mean with the current LWRP we cannot do things such as a split-screen with two cameras or an inventory window that renders 3d obejcts over the regular game camera?
If not, would rendering the cameras to a render texture serve as a work-around?

 

@Holy-Manfred Split-screens should work the same as before, issue here is mainly stacking multiple cameras into same view. In splitscreen you just render the camera views side by side, the whole setup is different.

 

Split screen didn't work when I tested it (at least in HDRP). Forced 1 camera (whatever was selected in editor, not sure what will happen when building) to take the full view rect regardless of what you set it as.

 

@tertle what happened when you tried it? I tried this myself some time ago (on 2019.1) and I could render two cameras side by side with it but I didn't test it extensively. But there's also been this PR recently: https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/2700 so chances are that it works better(?) on next version.

 

Only 1 camera rendered the entire screen. Didn't matter what I set view rect to it'd render whatever camera I had selected to the whole screen. Was back in December on 2018.3

 

Hi there, since the update i have some problems..
If stacking isnt possible anymore... how can i achieve sepperating post-processing effects?
I.e. i had a camera for my "main stuff" wich had a bloom (and more).
And i had a camera just for particles (weather effects) and one for UI wich should not be affected from post-processing. Now that i need to put them all into one camera i dont find a solution. Would be great if you could (at least) exclude layers from post processing stack, and even better to have different effects applied to different layers ? maybe its possible?

 

What about common techniques used in first person games to display the gun ontop of everything?

Any work around besides using shaders, which would be hell.

 

Wouldn't it have been better to have these fixes/alternatives in place before removing camera stacking? And only having Screen Space Camera UI working in 2019.2? That's April / May?

I totally get that we have to break things to move forward, but this seems a bit quick.

 

Hi. In our use case, we utilize layered cameras because VR requires submillimiter accuracy. It is a vehicle game where you can be 100km from origin (we could not use the floating origin technique where you offset everything because hiccups are not acceptable), so to keep accuracy we have a cockpit camera that renders a stationary cockpit at the origin, and a exterior/world camera that moves around. I understand with the new system in SRP, the view distance jitter problem is mostly solved, but it does not solve the floating point accuracy of transforms etc. How could we adapt to it? Also, if we inject a render pass with different view matrices etc, will lights work correctly for that space? Thanks!

 

hello, what about using multiple cameras for large fields of view? like a 180d and beyond for simulators, i don't suppose there is a workaround other than going back to built-in pipeline?

 

Yes, I know about that. But it only solves the jitter of far geometry. My issue is that for VR, you need submillimiter accuracy in transforms, or else for example the flight yoke would move in a jittery way. When you are more than 5km or so away from the origin the positions are only accurate to the cm scale; we solved that by keeping the cockpit at the origin and overlaying it over the moving camera. A bit off-topic, but are there any plans to support 64bit transforms in the long term?

 

Yes it is if you render the ortho camra to a render texture and then assign that render texture to a raw image.

 

Hi,

Is this the same in HDRP?

I need to render an object (sword, gun, tool etc) on top to prevent it clipping into geometry in the world. I've relied on camera stacking to do this in the past and now I am completely lost at how to solve it.

 

Losing this feature really hurts! Creating parallax/depth in 2D games is something I'll have to go back and restructure now. Not to mention no UI particles since screen space camera isn't supported.

 

2019.2.b4 the second camera not work·············

 

Is there any solution for 2nd Camera in LWRP?
I am using UI camera. UI has particles and 3d object for character selection.
Not upgrading to latest LWRP. Currently using LWRP 4.6.

 

Hello!

I don't have any locked-in production use cases or anything, but I'm very interested in experimenting with stacking cameras combined with shader graph. This seems like it could produce some really interesting results!

I understand that Unity is working to bring something like camera stacking to LWRP, but there was also some talk about adding a custom render pass on your own. Is there a code sample going around for doing this (here or at Unity)?

For people looking to experiment with graphics, I feel like the "stack an additional view" use case would be a wonderful entry point to getting into SRP coding.

Thanks~

 

Did stacking cameras and depth-only clearing get into 2019.1beta ???

 

I may be wrong but I think they said 2019.2. I tested my project this week in the latest 2019.1.0b9 with the latest LWRP package and Screen Space UI cameras (with transparent backgrounds) are not working yet, so I believe it's still scheduled for 2019.2.

 

A demonstration of the new Camera Stacking setup is shown here. https://forum.unity.com/threads/lwr...5-2-1-19-1-are-out.562291/page-9#post-4314634

 

Do we have clarification as to whether this is in 2019.1 or 2019.2?

 

This. Many years ago I shifted my artwork away from Processing because I like the tools Unity provides for experimentation and all of the SDK's that provide support for Unity. Also, stability and performance has been getting better. That said, closing down a common rendering technique (Don't Clear) to create experimental graphics is not a good thing.

I understand that I have two choices, inject my own SRP pass or use the built-in renderer. It's a disappointing choice, as someone experimenting with the engine, I would really like to get more into Shadergraph or use the VFX graph, but if I do that I lose out in terms of rendering options. If I knew how to write a SRP pass, that would be the solution but I would not know where to begin!

 

I was actually fine with the removal of camera stacking - I've seen it used too often as a work around for issues which could be better solved by other means.

 

I'm also having this issue, but not using LWRP: I'm using the built-in legacy pipeline. Is this supposed to be the case?

 

This is the equivalent of removing layers from photoshop. I'm sure it is more performant to remove camera stacking. It'd also be more performant to remove the ability to render colors. In fact let's just render a black screen -- that will be amazing for frame rate! I think this decision sounds crazy. And the reply that oh just write your own SRP pass is absurd. I pay money to a game engine to render depth passes for me -- that's what the game engine is supposed to do. Imagine if photoshop said hey if you want layers sure just write some code to make that happen. Unity is a tool that is supposed to empower development by making artistic choices quick and easy to iterate on and execute. This choice is the opposite of that. The worst part is, you guys are trying to solve a problem no one is asking you to solve. We've been developing games with stacked cameras using Unity for years on much older devices and they work fine. So the notion that non-depth cameras is some vital performance feature that we suddenly need in 2019 doesn't hold water.

One approach could be a super optimized single layer camera as an option that those who decide they need the extra performance can choose to use. Locking the entire Unity developer community out of stacked cameras with no alternative solution aside from writing SRP passes ourselves is extremely frustrating, and for me personally, broken.

Someone will surely make the point that the default render pipeline still works with stacked cameras. But how long will default be supported? None of the new features like shader graph or vfx graph are supported with the default render pipeline. It sure feels like it's being phased out. ECS and burst are a great model for how to add performance to an engine: they are optional.

 

I’m AcTuAlLy FiNe WiTh THe ReMOvAl of 2D functionality because I’m making a 3D game.

Here are some examples of where camera stacking is imperative:
- I want particles in my UI. UI cameras can’t render particles
- I want my FPS gun to not intersect that bush - the only solution is a layer
- I purchased a super complicated asset store asset that is totally the wrong scale - either spend 3 months refactoring at the right scale or drop it into a different camera
- I want a character to flash on a black background when they get hit: new camera overlay makes this possible
- I want to add 3D graphics (is rotating coins) to my 2D UI: add an orthographic camera
- I want to experiment with some visuals the pipeline render team hasn’t thought of