Hidden Layer Component not being hidden in Cutout Camera (SelectiveRender List)

[Readun]

Describe the bug?

UIX or Objects hidden by the Hiddenlayer component is still visible in the Cutout Camera. Which is also visible in the Inventory Icons of Saved Avatars/objects.

To Reproduce

Have UIX or (probably, not tested) objects that are hidden by the Hiddenlayer component and make a Photo with the Camera in Cutout mode, or save your avatar and see it in the Thumbnail.

Expected behavior

Hiddenlayer means hidden. Its not Visible in normal Photos aswell.

Screenshots

The UI next to my arm should not be Visible.

Resonite Version Number

Beta 2024.3.12.1169

What Platforms does this occur on?

Windows

What headset if any do you use?

Index, Vive Eye Pro & Desktop

Log Files

READUN-PC - 2024.3.12.1169 - 2024-04-02 21_20_15.log

Additional Context

No response

Reporters

readun

[Banane9]

Yup, definitely happens for non-UIX mesh rendering too - that's what the AudioWings do, and the construct for them can be super visible in the avatar preview x.x

Nesting Hidden Layers also doesn't work - when you are part of a hidden layer, you can see other hidden layer things.

[Banane9]

It should be noted, that things rendering when explicitly marked for selective rendering is a desired outcome for the typical hidden camera rendering setup - perhaps a difference could be made depending on if the camera is part of the hidden layer or not?

[shiftyscales]

Created a simplified replication world. It appears that a SelectiveRender list will indiscriminately render everything under the hierarchy specified regardless to the presence of the hidden layer component.

Seeking feedback from either @Frooxius or @Geenz.

The world can be accessed from this record URL: resrec:///U-Shifty/R-8ff57cd8-ef3d-4953-9338-3b7907b9f412

[VirgilCore]

I thought this functionality was intentional? If a slot with a hiddenlayer is put into the selective render list it should render it. I know of many different systems that use this feature

[Banane9]

I thought this functionality was intentional? If a slot with a hiddenlayer is put into the selective render list it should render it. I know of many different systems that use this feature

Yea, that was what I was mentioning above too. The logic of this gets complicated by the HiddenLayer selectively being supposed to be hidden and then render for specific cameras regardless.

perhaps a difference could be made depending on if the camera is part of the hidden layer or not?

Alternatively: a setting on the camera to respect / ignore HiddenLayers 🤔

[shiftyscales]

I'm specifying the parent slot to the hidden layer in my replication case rather than explicitly the hidden layer's slot. But as mentioned- it appears that the SelectiveRenderList just indiscriminately renders everything under its hierarchy.

@Readun could probably work around this issue by using a RenderTransformOverride/RenderMaterialOverride with a Camera context. I tested that just now, and it appears that a SelectiveRender list still respects the RenderTransformOverride, and RenderMaterialOverride components.

[shiftyscales]

Can you clarify on this point, @VirgilCore?

I know of many different systems that use this feature

Do you have a link to any such systems/or can you otherwise describe how this functionality is being used?

[Banane9]

Do you have a link to any such systems/or can you otherwise describe how this functionality is being used?

I'm for example using it to render an emissive map that shows the music volume for the wings of my avali avatar - the rendering setup itself is under a HiddenLayer to be invisible in regular use, with a camera getting a slot under it as the exclusive render target.

[Frooxius]

This is technically not a bug.

HiddenLayer hides things from rendering, unless they're selected for rendering. Selective render is the mechanism through which you override something to indicate that it needs to be rendered - which overrides HiddenLayer.

This is the purpose of hidden layer - if we made it always hide, there would be no difference from just disabling the hierarchy - meaning it would never render, which would lose the whole point of HiddenLayer.

However I see that in some cases this is not desirable behavior, because you want it to be visible in some selective renders and not in others.

We could potentially approach this in several ways: 1) Have selective render indicate whether or not it should override any HiddenLayers. So for cases where you use it for specifically rendering those, you specify that 2) Have HiddenLayer overriden only when it's directly referenced as the root of selective render - however this might break a lot of existing systems, so we'd be less likely to go this route

[Readun]

@shiftyscales need to see if it works or not..? Its a system setup with a camera under the hidden layer. Not sure, if that camera also gets disabled by the way you described.

My point Im trying to do: The camera under the Hiddenlayer should still be able to see it, while the cutout function (and in general cameras) of normal Cameras should not see it.

[shiftyscales]

Oh I see- if you are using a second camera- then that wouldn't work- because the overrides would apply in all cameras, @Readun - and based on Frooxius's reply above- it sounds like the solution you'd need would be option 2- but that has the possibility of content breakage. Otherwise- it sounds like there isn't a way that a hidden layer could be guaranteed to stay hidden under a selective render, and option 1 that Frooxius proposed wouldn't meet the needs of your issue- you could fix your camera, but you couldn't fix any arbitrary cameras that are set differently.

[Readun]

Would make an ability to whitelist a specific camera make sense in that case? Kinda like with Dynamic bones that it is possible that you can specify a collider, otherwise while nulled, it acts normal.

[5H4D0W-X]

Have HiddenLayer overriden only when it's directly referenced as the root of selective render - however this might break a lot of existing systems, so we'd be less likely to go this route

I think this is the way to go as it's probably how most people would expect it to work. Maybe a toggle can be added to enable this behavior so that it doesn't break old stuff?