Separate Physics and Rendering layers

Thanks, but this doesn't address the recent questions/feedback on whether we can expect the rendering layers to be fully implemented in a way that is completely separate from the collision layers.

As I said earlier this week, it feels like this is close to being finished. It would be a shame to have the remaining functionality be ignored into 2023 and beyond after making good progress recently. Maybe it's not being ignored; it could be being worked on right now, but we don't have any visibility into what's going on. The concern that it will fall by the wayside is reasonable given that this has been an open issue for 5+ years.

A comment from someone at Unity with knowledge of the situation like @LukasCh or @LeonhardP could help clarify expectations here.

 

Yes, Rendering layers is included, but lighting gets totally messed up when you enable it. Just to clarify, if all layers are culled, then lights do not light any objects, but even a single layer enabled means ALL layers receive light, regardless of culling - it's totally effed up... the layer system has become a binary ON/OFF system - in other words, utterly useless.

If you switch back to Forward renderer, it goes back to normal. Though I'm having a lot of problems with Raycasting not working as it's supposed to, so I'm having to abandon 22.2 for now.

Normal behaviour is deciding which layer receive lights through the culling of rendering and also what layers the objects are sitting on. I did manage to switch to the LIght layers for some effects, like spot lights mimicking moonlight through a window and putting the MeshRenderer building's outside walls on another mesh light layer to stop it receiving the spot light. But then at some point, that stopped working... who knows why.

So while Forward+ fixes some of the point-light limitations, it hasn't implemented core functions on layer rendering... and there was nothing in the release blurb to explain. Disappointing.

Hopefully these things are ready by the time the next LTS comes out that tries to fully implement Forward+.
I'm still not convinced that releasing half-implementations of new features is that good an idea. And by half, I mean you are breaking some very core functionality in the process.

 

Adding more mess on top of current layers:

AI Navigation package also uses them

 

Yeah, it's a mess. Systems I am aware of that share the old built-in layers system:

• Post Processing Volumes
• Camera Culling
• Navmesh
• Physics
• UI
• Particle System Force Fields
• Light Culling
• Rendering in general

 

"Layers" should really be a Scriptable Object where you can assign layers, then have a field for it inside:
- Physics Settings
- Rendering Settings
- Navmesh Settings
- e.g. Cinemachine could use this to easily implement camera layers
- e.g. any new functionality in the future may implement its own layers

As games get bigger and feature functionality expands, layers need to be more versatile to accommodate. Having these as scriptable objects has the added benefit that you can create samples that provide your own layer settings, so that if your asset store asset needs to be tested, users need only swap out the layers instead of doing some kind of extensive trial and error, remembering all the settings they had before.

 

chiming in that I've wanted this separation since I started using Unity about 12-13 years ago, hoping that URP Rendering Layers in 2022.2 solves this

 

Hi, mildly horrified newcomer here.
I've just learned about Rendering Layers after trying to have URP decals affect only a subset of meshes (which are all grouped on the same Layer for lighting purposes - shame on me for still using those in Unity 2022.2 I guess?)

Can we please have a clear distinction between layering systems?

 

Stay calm sir, I am here to help! Here you will find everything that Rendering Layers affect. Anything not listed here is unchanged from built-in pipeline.

https://docs.unity3d.com/Packages/c...al@16.0/manual/features/rendering-layers.html