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 15 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

 

It would be great if we could get some sort of indication that Unity understands what so many of us are requesting: a separation between rendering and physics layers.

It just seems there’s a complete lack of insight on the issues it causes developers. So if anyone has some simple examples to share perhaps it will get across to Unity how much of a problem this is. I’ll start things off and I have to reiterate, I have hit this problem on every new project I’ve started since (and I’m being serious) Unity v2 in 2007. Every project I have to find the most awkward ways to organise things to try and deal with it and often there’s no good solution.

Here’s an actual problem scenario I have in a project I’m working on at the moment. I have a character on the Player layer, when the character walks behind a building you can see a silhouette of the character. Physics collisions and various raycasts are fine tuned for the Player layer.

Then let’s say I have a small crate that the character can pick up, it needs to be on its own layer, let’s call it the DynamicObject layer. This layer has completely different collision settings and logic which is extremely common and makes sense that it would behave differently in terms of its collisions matrix to the character.

The player has the ability to pickup dynamic objects and when they do I want the silhouette effect to kick in for the character AND for objects that are picked up when walking behind a building. The ideal way of doing this is if I permanently had the character on a SilhouetteEffected rendering layer where the visual effect is applied, and the crate is changed from a default unaffected visual layer to the silhouette layer when picked up. But I can’t do this, I need each object to stay on their Player and DynamicObject layers so their physics collisions and logic continue to work ie. just because the player and the crate being carried are now visually behind a building where the silhouette effect should kick in doesn’t mean their physics collisions and logic should change, and I can’t just apply a silhouette effect to all objects on the DynamicObjects layer. Also if I temporarily change the layer of the crate to Player while it’s being carried then all kinds of things like NPC raycasts could think they’re hitting the player object but are actually detecting the crate ie. all of the physics rules would now be wrong for the crate just because I need to change how it visually renders.

Can someone at unity start to see how problematic this is? If we had visual layers and physics separate we can employ completely different logic on the visual rules for mesh and the physics rules for colliders.

When the new rendering layers were announced in v2022.2 I thought, finally, finally they are fixing this extremely long standing issue, but it just seems that there’s a total lack of understanding what we need or why this feature was requested. What was implemented was a small portion of what is actually needed. As others have pointed out we need this separation across all uses cases of the old layer system, nav mesh, render objects, etc. I know there’s some hacks floating around to change render objects but it’s not good enough, we need this problem fixed properly and across all components.

 

Rendering and physics layers are separated but only in DOTS. I think they will never separate them in vanilla Unity just because of stupid backwards compatibility.

 

I think that "Unity 6" is a perfect opportunity to break backwards compatibility. Not only for this feature, but generally. At least some minor things like .rigidbody etc. could be cleaned up. How many people in the world need to be able to port 15 year old project to Unity 6? Four?

Back to the topic, I personally would very much like to pay the price of breaking backwards compatibility for this feature

 

It’s really quite simple, they don’t need to break anything, they already have an editor setting to enable the use of rendering layers. They can make the newer way opt in while maintaining backward compatibility, new projects could start with the newer setting on by default.

 

Honestly if Unity fixed this issue I would take it as a sign that they're actually refocusing on their core game developer base. It's been at least 12 years since a feedback ticket was created, and 6 years since we were assured it wasn't being ignored and that it was going to get done for sure.

This is something that affects real devs making games.

 

This could be honestly a real thing with all the core changes they are doing for Unity 6. Be cool if it happens.
I mean we got async functions just added for instantiate game object functions yesterday in the alpha and looks like new indexed based get component functions.

Maybe we will start getting these core changes soon.

 

They haven't shown any plans to change the core for Unity 6. It's just a rebrand for 2024 to my understanding.

 

There are some Core API changes already in the 2023.3. Mainly removing the old stuff that are not needed anymore, adding async versions of a lot of functions like instantiate object, indexed based get component functionality, the new GPU Render Drawer, Core CLR which is a change to how you code your project, and a lot more.

CoreCLR being the biggest change which everyone is welcoming a lot. Glad no more app domain reloads when changing scripts.

But that is getting a bit off topic for this thread.

 

There’s definitely still gonna be domain reloads. I’m following the thread about Unity’s efforts to change to CoreCLR very closely and here’s where they are:

The runtime is inching closer towards being able to be build with CoreCLR. What does that mean? Well, the CoreCLR is a compiler, and what compiler you run on the build of your game can differ from the compiler run in the editor. Historically, the compiler on build has been mono (or IL2CPP) while the editor compiler has been the one aligned with the .NET version you’re running.

When Unity is saying they’ll support CoreCLR, it means that they’ll support it for builds, NOT for the editor. This means that the new editor version will domain reload just as it does now.

But that is not to undercut the achievement. @JoshPeterson ‘s team has been working on this for over 1.5 years now at least, and they have moved mountains to align with the CoreCLR. And as they are reassuring us, CoreCLR in the editor is the next step. For that to happen though, they need to make a lot of editor code compliant with its garbage collector, as well as update any code that has been deprecated in .NET 8 (which I believe is the version they’re aiming for). There in lies the wait, the editor needs to become a first class .NET citizen if it wants to reap the benefits.

 

I agree, and if you ask me, the rebrand is really messy. When a company wants to rebrand to turn over a new leaf… well after the Riccisoto-shenanigans I understand, but I haven’t seen any changes that make me believe this will be “an entirely new experience”. More something that got rolled out last minute with no actual significance behind it.

Speaking of significance, the Unity 2023.1, .2, .3 naming was rolled out to better coordinate their development teams, creating specific timelines for teams to integrate features vs aim for stability. It must be pretty confusing for them and I imagine a lot of them will be left kindof in the dark by this change, doing more harm than good for the engine as a whole.

If they were saying “we’re calling it Unity 6, it will have DOTS fully integrated going forward, all the old API will be thrown out, no more stupid SRP separation we fired the guy who came up with that, do NOT update from 2023!” Then I’d be excited to see where Unity would take this going forward. This seems more like “this will keep investors distracted”.

But hey: we’re talking about it.

 

Oops forgot to add context to that last message last night. You are absolutely correct about them adding it for the builds first in phase one. I should of said eventually their should be n domain reload inside of the Unity editor sometime during the Unity 6 Cycle. So possibly 6.2 or later.

Their hard work and open communication about the CoreCLR work has been an amazing experience with Unity developers. .

 

Well good news about some of that in the Unity GitHub for the C# build of Unity you can see them moving old API to new classes called for example GameObjectDeprecated to keep from the breaking old peoples code, but it is removed from the actually used C# classes so when projects are build as long as no one is using the old API those deprecated classes will be stripped.

2023.3 Alpha 16 earlier this week put the Render Graph System out of experimental which is the biggest step forward for unifying the SRP API.

For the DOTS stuff you might be interested in the test multiplayer system update. Where they are aiming to unifying a sort of abstraction layer that both Mono/DOTS can use at the same time. So code for one and you already coded for the other. The Unity Multiplayer Package Discord server had some announcements on that and request for feedback with polls to the community.

So some of the things you mentioned are actually already in 2023.3 alpha that can be downloaded. The 2023.3 Alpha was a huge step forward for what you are talking about.

"cough cough". Just saying if you look through the GitHub changes you might see some new things such as RenderingLaye Enums, masks, UIToolkit fields, new serialized variable types in the inspector to work with them and some other things and more with changes to the core physics module. Image attached to this message as uploaded file.

Key thing to point out here this might not be exactly what you want now, but it is the start of moving into the right direction so it won't be fully used like people want in this thread or could not be used at all like people want in this thread, but it is a step forward. Unity might plan it implement the stuff mentioned in thread outside of these Rendering Layer systems, but wanted to at least share it.

 

Huh… interesting, to say the least. I was just joking around with my comment but I didn’t realize they were deprecating and replacing the GameObject class. That’s… really significant actually.

Perhaps I should get more informed about Unity 6… still skeptical though, it wouldn’t be the first time Unity went in over their heads.

Also it’s good to hear that work is being done to unify the SRP’s again, and to make code work across both Mono and DOTS. Asset store creators have had it hard enough.

 

Just to steer it back on topic, not that it was totally off, I’m finding all of these coming engine changes genuinely interesting… what would be great is if a Unity representative could weigh in and give us some insight into any roadmap or plans to address layer improvements we’ve outlined, and not just for users of the DOTS stack. Speculation is interesting, but we really just need a Unity rep to step in and let us know we’re being heard even if it means waiting 2 more years.. I’ve personally wanted this for over a decade, it’d just be great to know it’s being looked at.

 

Just to be clear not deprecating the GameObject class, but removing some of the old API that was used a long time ago, before awaitables, async updates, old code when there were quick properties for rigidbodies, colliders, and so forth actually on the game object.

Basically a giant clean up of the old code that has been bloating certain important classes that was deprecated, but not removed while updating other code to newer functions.

The nicest change is the AsyncOperations for GameObjects that were added into GameObject Class.

@jason_yak I do agree an update to certain topics are needed. It does seem like we are going to be getting a lot of updates very soon within the next two months or sooner with news of Unity 6.

Some changing the render pipeline and physics pipeline have been huge in the 2023.3 Alpha and haven't seen too many people bring them up. Granted they might of been waiting for some of the VFX Graph updates that came out in the alpha 16 before making comments or preparing more for WebGPU side of things for graphics API.

Really am curious about the physic module changes I have seen in the code.

 

Are there any updates on this? I have a couple of render features and lots of physics layers. I am unable to apply the same render features to objects that exist on different layers for physics reasons. I might also need to switch an objects layer during runtime for physics reasons, but I don’t want that to affect what render features apply to it.

This double-usage of layers for both rendering and physics limits my ability to implement certain solutions that could have been straight forward but are held back to the need for certain layer compositions on either the rendering or physics side.

Does any Unity Dev have any thoughts on this issue? There has been no statement yet, and I would really love to know whether this is something we will ever see in URP for Gameobjects

Edit: I am aware that there are now Rendering Layers, but afaik I can really just use them in custom render features and for decals/lights. As of now, they are not usable within the RenderObjects render feature, the ForwardRenderer layer filtering or when setting the Culling Mask of a camera. Rendering Layers are a good step in the right direction, but they lack integration. Best case scenario for me would be to just have a second dropdown for each GameObject next to the Layer, where you can set a Rendering Layer, which can then be used in the Camera, Renderer filtering etc.

 

I second this question. I’ve been waiting for a solution for literally years. It feels like the rendering layers sorely missed the mark and made things even muddier, they’re only implemented by a very narrow amount of features. I’ve been hoping someone would Unity would acknowledge this also, it just feels like there’s been a complete lack of understanding of what we need when the new rendering layers were added.