RenderObjects Rendere Feature is missing support for Rendering Layer Mask

Hi there, I was wondering if there was an ETA for this or if this was even on the horizon?

RenderObjects is very convenient! And Rendering Layer's seems just as powerful. A renderer can be a part of multiple different layers. This means we can have different special effects (Like the mage Occlusion example) use a specific Rendering Layer to 'select' renderers to apply the effect to. This way we can have multiple effects similar to the Occlusion example (multiple RenderObjects renderer features) all doing different effects, and renderers will have the ability to 'opt in' to the effect by being ticking on that Rendering Layer..

 

I'd also really like to hear Unity's perspective on this. From whatever angle I look at it, it strikes me as though the Rendering Layer Mask was designed for this exact purpose, so it's somewhat bewildering that the default RenderObjects renderer feature does not make use of it.

Apart from the obvious advantages described in the post above, it would also decouple the URP from the default layer system that comes with a whole host of architectural headaches.

Granted, the modular nature of the SRP system allows developers to create their own Renderer Feature if needed, but if there's one thing that screams "default feature" to me, it would seem this one. Especially since it comes down to something so trivial (?) as switching one bitmask for another. Need be, RenderObjects could allow a choice between the two systems or a separate renderer feature could be added that only differs in the layer mask?

 

Hi, @Tim-C I'm wondering if you were able to poke the team and if they got you an answer?

 

Hey there, I was just wondering if there was any movement on this?

 

Sorry to sound like a broken record but is there an update on this? I've just been asking since last year where I bumped my thread 3 times over 3 months with no response. Getting a response and then seeing you potentially forget about this thread feels a bit like a cruel joke.

https://forum.unity.com/threads/renderobjects-should-allow-filtering-via-renderer-layer-mask.735758/

 

Thanks so much for the reply and explanation! Take your time my dude.

I gave it a quick go myself, where I duplicated all of the classes involved in making RenderObjects work and just added a serialised Rendering Layer field. I tried to copy what you guys had done in the Renderer Editor to render/display a Rendering Layer mask since there doesn't appear to be any built in support for it. I got everything hooked up. The rendered output did change in response to me altering the Rendering Layer on the renderer and/or altering the Rendering Layer mask on my RenderObjectsCopy object, but it didn't look as expected. The wrong renderers were getting filtered out, and I couldn't quite understand what was wrong so I just put it down and moved on.

 

Stoked to hear this. I understand it will take some time, no problem. I think the RenderObject feature will actually gain quite a lot of flexibility for this. Just very glad to hear it's one component of Unity that's being decoupled from the tyranny of the layer system.

 

Renderers should also expose and use this. I've currently copied urp locally so I can make these modifications. It's very powerful. E.g:

I can specify on my renderer2d to not render layer2. Objects on layer2 are used for a screen distortion water effect, so they shouldn't be rendered by default. Then I can create a render objects feature that copies screen color to texture and selectively render those layer2 water objects.

Works great. But of course I had to modify the renderer. Would love this kind of feature added by default

 

Hello, hate to necro this thread again, but any progress here? I checked a recent 7.4 release, but as predicted, it's not included yet. I would be nice to hear an update, especially since I've seen the same problem come up spontaneously elsewhere.

 

Yes it is a shame to have to edit the pipeline package directly or have to copy/paste/manually maintain our own version of this render feature just to expose a single value. I suspect this just keeps being put on the back burner or is lost/forgotten about. Its such a small change but would make the render objects features so much more useful. I have created a suggestion on the Unity Graphics portal. Here's hoping.

 

I'm sure you are swamped with work, but were you ever able to investigate this @Elvar_Orn ? Sorry to ping you directly.

 

I'm also looking for this feature.

I want to create a dynamic "portrait-scene" that will be used to render animated tv-like portraits without having it affect anything in the main scene. I planned to accomplish this with a seperate physics scene and culling all objects in that scene from my normal cameras. Then I have a camera in the portraitscene that only renders objects in the scene.

I do not want to change the layer, since that is used by physics and triggers. But I thought I could just change the renderLayerMask of the GameObjects renderer and have a custom forwardRenderer that only renders that renderlayerMask wih opaque layer mask and transparent layer mask.

But this was not how it worked, very confusing that the renderLayerMask is ignored by the LayerMasks setting in the forwardrenderer.

 

Hiya, just a casual check to see if there's any updates on this discussion. I see some PRs were last modified in December, but since there have been other priorities as mentioned above, I'm wondering if there's any chance on it entering the roadmap soon or if it's just a concept so far. Rendering Layers seem like a match made in heaven for URP, so I'm definitely looking forward to this as well.


I also wanted to point out that this comment added on the PR...

Is there any reason you don't use a 64 bits wide data type for the Rendering Layer Mask? Then you could reserve 32 bits for URP and the remaining 32 bits are given to your users.



I believe it's better change it to 64 bits now, than waiting a few years when URP has been widely adopted and would potentially break a lot of projects. Don't do the same mistake that was done with the physics layer mask.

Deserves a lot of attention as well, since reserving more than half of the layers for internal usage seems limiting thinking as a long-term solution.

 

For those who don't want to click through and read, they are reserving 20/32 Rendering Layers for 'internal usage'.

 

Just to keep everyone updated: The PR for this feature is now closed, and it's not exactly clear why. I am poking the devs for more information and will report back.

 

From what I understand in the PR it's being pushed back to at least 2022.1...

 

It was very unclear.

 

Is anything that the marketing team wants us to use (like Entities, DOTS, URP, HDRP, UI Toolkit) ever finished? And if it is, is it then instantly deprecated for the next halfbaked new whizbangfandangled tech to come out?

 

jeezus F***! having the feature exposed in the UI but not usable is such a tease

 

Finally properly tested and documented features? This should be on pornhub.

 

It's 2023. The world has turned into a barren wasteland and roving bandits terrorize the few surviving remnants of civilization. One man still holds on to a shred of hope that twinkles like the dying embers on the end of the cigarette clenched between his dry, cracked lips.

Has there been any progress on this feature?

 

dogpile
https://github.com/Unity-Technologies/Graphics/pull/1891

 

I actually am running into this issue now trying to build as well. Though I think I could have a work around it is a poor one.

 

Funny, I thought this problem has been around for a year max, but it's more like 3 ... and what is more funny fix is not even in sight.

See you in another timeline then.

 

Fun stuff, it's too ridiculous to believe if you ask me.
I ran into the need for better filtering than the regular layers method multiple times before and it annoys me incredibly that there is so little control here (Layers are by far not enough, I just want arrays of objects but whatever)
Last month I looked into the render objects feature code and discovered totally by accident that rendering layer support is actually implemented there. It's just that 3 files deep in the argument a function uses for the rendering layer mask, the value defaults to uint max and it is never overwritten.
Sooooo if you fork the render objects feature, you can easily implement it yourself. And it is really not very difficult.
You will need RenderObjectsSettings, RenderObjects (ScriptableRendererFeature), RenderObjectsPass and FilterSettings (filter settings to expose the renderinglayermask uint and pass that in the RenderObjectsPass Constructor) and the feature's custom inspector to make the rendering dropdown visible.
Unfortunately I wrote that for work I can't simply share that code.

I am really wondering though why Unity did 99% of the work and skipped that superficial part. There might be a good reason for that.. but I have this working for a while now and so far nothing has exploded.

The best part is rendering layers are not exclusive (opposed to physics layers), so you can combine layer A and layer B in the filter as well as assign multiple different layers to a mesh renderer :brain explodes:.

 

It was not very clear by they gave some explanation on the GitHub issue. Something about users expecting it to "just work" with shadows and other features, and how currently it wont. Or something.

And yes you are right, it's literally just a single parameter that needs to be exposed through 3 levels of code. It's very simple, and ridiculously you need to maintain your own flavour of URP to get it working (or your own copies of those 3 classes)

 

Yes, but you can't recreate exactly the same class because half of it is internal

 

oh i figured out a neat trick using assembly definition references. Create the asmdef reference and select the urp asmdef. Bam all files in that folder will be compiled together with the read only package. You can basically append your own classes to the URP asmdef and using those access all the internal classes

ah yes that makes sense. that applies to the entire render objects feature though doesn't it :-/

 

Anyone tracking progress on this? Some ticket or roadmap or alternative solution?