Separate Physics and Rendering layers

https://feedback.unity3d.com/suggestions/separate-physics-and-render-laye

It is a longstanding Unity issue. Layers are used for both Physics and Rendering. This is probably fine for small games but when you start creating custom rendering buffers you can really run into corners. Basically for few games I made in the past (Hard West, Ancient Space) I just couldn't do certain graphics features due this limitation. I just had to cut them out.

The only solution for separating graphics and physics layers is to duplicate your gameobject and assign different layers to each duplicate. That is not acceptable in a complex game due to performance reasons (you are adding considerably large amount of new gameobjects). Imagine doing that for 20 skinned characters (I am not even mentioning the need of syncing animations for each duplicate). I just don't see a reason why layers would be shared between physics and rendering. And also, why one object can be only assigned to one layer? That is a mystery to me.

 

OK, that's an actual production example explaining why this is important for me.

That video is time-stamped.

During a production of this game we had two "dimensions", only one visible at a time. One called Normal and another one called Nightmare. We were switching rendering between dimensions by assigning different objects to either Normal or Nightmare layers. So if Nightmare dimension was being shown, Nightmare layer was rendered and Normal was excluded. This was also used for physics for obvious reasons - we didn't want to do raycasts or interact with currently invisible layer. That worked well.

What was not actually working well were custom render buffers. I wanted to implement screen-space subsurface scattering for characters and foliage. Normally I would assign all foliage to a custom layer called Foliage, render SSS textures into a buffer and do some light calculations in a shader. Easy. What I couldn't actually do is exactly that - assign all foliage to a new layer. This is because we already had to assign all gameobjects to either Normal or Nightmare layers.

But I could have used tags, right? Not really as they were already being used for gameplay purposes.These days I think I could achieve similar results with command buffers but they significantly more time to setup due to lack of proper examples and something you just need that simplicity which layers offer.

Another issue we had and I don't see that being solved with latest Unity is assigning objects to different physics layers. Basically, we wanted to trigger destruction for each object being touched by a weapon's bullet passing by. I wanted to use physics for ragdolls of debris. Super easy but for various gameplay reasons I could not have any colliders on Normal nor Nightmare layer. This means I needed my own physics layer to which I would assign my colliders to interact with.

So the issue was that we had this Normal and Nightmare dimensions which we were switching between. Let's just say I have a destroyable crate which is seen only in Normal dimension and is constructed out of 6 individual pieces

• I had to create 6 gameobjects rendering components only, assign them to Normal layer
• To each piece I had to add a child object with colliders only and assign them to Normal_VFX layer so that I would be interacting with proper physics objects
• That's a total of 12 gameobjects in best case scenario

Let's say that now I need to use the same destroyable crate in both Normal and Nightmare dimensions. I would have to:

• Create 6 gameobjects with rendering components only, assign them to Normal Layer
• Create 6 child objects with colliders and assign them to Normal_VFX layer
• Create 6 child objects with rendering components only, assign them to Nightmare layer
• Create 6 child objects with colliders and assign them to Nightmare_VFX layer
• That's a total of 24 gameobjects

All these problems would be solved if we could only assign the same gameobject to few different layers or have separate rendering and physics layers.

 

+1 for this

 

Can we get an official Unity clarification on on that? Normally I would not push so hard for an official response but Unity staff always suggests putting a feedback ticket. One was created in 2011 and has 278 votes so far so what else there is for me to do?

 

Bump.

 

This has been a requested feature since 2011, and they've ignored it repeatedly. I doubt it's gonna happen, though I'd certainly love for this to be added. It makes zero sense that physics and rendering are linked like they are.

 

But physics and rendering isn't coupled - only in your mind. Just abstract it with your own naming scheme.

 

Not sure if this is irony or not so forgive me if it is

Physics and graphics are coupled simply because you use the same layer system for both camera culling and physics channels. If you need a gameobject to be placed in Layer A which would be used for camera culling but you need it to be using Layer B for physics, both at the same time, you need to clone this gameobject, place one copy into Layer A, and another one to Layer B. This way one can be culled by the camera and the other can be used for physics. Like I said - not a problem for a small game but for something larger with complex physics and culling setup aaaand large amount of gameobjects, this spins out of control quite fast. Have I mentioned that maximum amount of layers allowed is 32?

 

Don't forget light culling. Although you only get (4?) of those to play with.

Not sure why Transparent FX is sitting next to Ignore Raycast. They must really get along like best buds. I'm sure Unity was extremely pro about this part!

Why can't we even change 8 of them? That alone would help a lot. But it is what I meant by being able to repurpose their meanings. The entire thing is illogical and I think, for Unity's convenience more than ours.

HAVING SAID THAT... I don't actually use more than a handful of layers in all the projects I've used, big and small. Because I generally design things that don't rely on Unity systems all that much (it is usually just used for physics only).

 

Is there anyone watching physics forums? What's the purpose of it if noone from Unity staff is watching it? It looks quite dead. Sorry if I am being too rude but it seems that some Unity regions have better community support then others. For example communicating with particle system developers is really easy and straight-forward whilst getting any information on terrain system or physics is basically impossible.
@Adam-Mechtley @MortenSkaaning @yant

@hippocoder
Would you mind sharing your secret on how did you abstract from Unity's layers?

 

Well I just reuse the blank ones, 'reserved' ones and have a class of constants instead so the actual names don't matter. I admit it's of limited use to some, and it's stupid that Unity mixes physics and rendering. Although I'm struggling to find a situation where I can fill it up - even in complex titles over the last 8 years or so I've been doing stuff in Unity.

Even if I don't have a problem with it, I recognise it's a problem for a lot of people and the design is absolute nonsense. Water layer mandatory? Really, Unity? since when do people even desire Unity's water? or use it? These layers should never, ever be shared with Unity internals anyway.

I guess it basically is one of those neglected areas of Unity. It works fine, it's just lower priority I suppose.

 

Just found this thread and wanted to add one voice here... What a strange design decision ...

 

It's a really good (real-world) example that varfare gave, why separating layers makes sense. Too bad Unity staff isn't responding or perhaps not even looking at this thread.

 

I'm 100% sure they know but there is not much user pain from this. Just vague examples and plenty of workarounds. You can see why it's not high priority.

I've just had to moderate laurent posting links to this thread in the beta forum for 2017.3 (which I deleted cos there's a time and a place for nagging and it's totally unrelated to beta), there needs to be more actual ship stopping issues for it to get bumped up in priority.

 

I would just like to set up what is colliding with what layer in code as well, seems a bit painful just using the editor.

 

Sure, if the performance is the same, I'm happy.

 

Sure it does! Thank you for the reply.

Would it be safe to assume that this might appear sometime next year? Or is it something in the back of the backlog?

 

I am very happy about this.

 

Ok, so I started testing new Post Processing v2 beta and I am really concerned now. New Postprocessing system requires user to define which Layers will be postprocessed. This will be massively problematic if Layers will be strictly defined by gameplay and artists will not be able to fully use this selective postprocessing feature. I know, @yant already said that physics and rendering layers will be split this year but I am just voicing my concern that this should happen sooner than later, especially with new graphics features coming which seem to be heavily reliant on layers.

 

Sorry, I don't understand the problem.
You simply set the camera to some layer, and then your post processing volumes to the same layer; and that's it.

It sounds like you're saying that some 3D objects get excluded from post processing because they're on a different layer (which doesn't really make much sense because post processing operates on the final image (that's why it's called post processing)), so what am I missing here?

 

Just started using physics recently, and tripped up a few times with the layers, having to move colliders on to their own gameobjects in some cases. Does seem crazy the same system is used for rendering and physics.

 

I agree that this should be changed. Separate physics and render layers! As is my projects are a tangled mess of weird layer names -- renderInForegroundButHittable etc etc. The current linked system quickly leads to errors as I'm moving stuff to different layers for rendering but forget they're there for physics.

EDIT: found the feedback feature request and added my votes:
https://feedback.unity3d.com/suggestions/separate-physics-and-render-laye

 

Added my votes.

 

try { vote += inf } catch (e) { ++vote }

 

I agree completely, it's very painful to have to create many more gameobjects, so I can have a mesh be culled on a certain layer, while also be an object that has overlapping.

 

I'd like to add that if Unity ever reworks this, I do hope the change the overlap setup at the same time. I actually didn't realize this for a while since it's been so long since I've actually used Unity physics but it's actually impossible to use same collider for colliding some and overlapping others (so that it fires overlap events, which Unity calls triggers for some reason). To do this now, you need to add the same collider twice for your gameobject and mark other as trigger but then you can't change the collision matrix for the trigger only if that is necessary as both would be bound by the same layer then (unless you put the other collider into child so you can swap the layer but this makes an ugly structure).

Basically this could be solved by putting a following collision type selection for colliders: "collision, trigger, all" instead of the current "is trigger" checkbox. For "all" and "trigger", one could setup a new collision matrix in the physics settings for doing the same thing but this time for triggers. This would still be bit more limited than what UE4 for example does (they let you do the collision and overlap selections per layers per each rigidbody basically), but it would still solve most of the issues with the current setup as you could then use same collision setup for getting both hits and overlaps (on different objects).

 

One year have passed. Any news?

 

It seems that the answer is: no.

 

ECS seams best option by far now.

 

What does ECS have to do with this?

 

That you can render most objects, without worry about layers at all, as you can create your own.
Hence keeping away from current layer system.
I am just pointing, this is an option.

 

And there we are, almost one and a half years later. Not sure what to say really.

 

Any updates or roadmap announcements?

 

Still think this is a good idea. Godot achieves this by having a mask and layer bitmask, which are good names imo

 

We probably should wait for GDC Monday. They have a keynote live stream that they are going to be announcing a lot of stuff at. Well at least that is what I heard. Think they made a blog on it on the site. Hopefully we hear more stuff Monday during the live stream on what is all coming.

 

Was this part of any announcements?

 

None that I have seen. The main physics thing coming is Unity revamped physics engine based on DOTS. This will be a new way to do physics in Unity. Also we have the Havoc physics engine being put into Unity. With these I don't know how they work or much about them so not sure how the layers work with them or if they still act like the old layer systems. So don't have any concrete information, but there is a video showing off the new physics system.

 

Goddammit! I can't believe they *STILL* haven't fixed this. It's causing me all sorts of pain

 

Bump

 

Bump +1 for separate layer for Physics and Rendering, especially difficult for multiplayer games where you want to cull rendering based on team color

 

Not really. You just control from the script, which objects to display (Enable/Disable). This way you can just hide meshes of other teams. And you can do this once for example, rather every frame.

 

You can't enable/disable specific objects per camera.

 

You can for each client individually, in case of multiplayer. Most of games use single camera at the time anyway. So I don't see much issue for such cases. Maybe second as radar, in some specific uses.

 

Sure, but you can't do that for a single player game which is the issue I raised in the original post. Today I'd probably use custom rendering to fetch objects which do need to be rendered for each given camera but this is much more work than what would separating rendering and physics layers take to set up if this was implemented.

 

Scriptable Render Pipeline also requires certain objects on specific layers to be rendered behind walls as shown in this video:

Well, I can't just mess up all layers in my physics based game just for the sake of rendering objects like shown in the video...
And using the experimental DOTS Physics is no fun at all. Making Ragdolls? I wasn't able to create any collider during runtime - this combined with runtime destruction physics?

We've got the "new" nested prefabs and a few new buttons in the UI to make them work. Can't we have two seperate layer systems for physics and rendering in a similar style? Or the same system used in ECS/DOTS Physics for PhysX?

 

In DOTS Physics there's no correlation between Render Layer and Physics Mask Bits.