A hidden layer component, but for the headset viewport only (and reverse)

[Earthmark]

Is your feature request related to a problem? Please describe.

Seeing your own face

I have seen a number of new users who encounter nausea with being able to see their own face, and whom are also annoyed at needing often quite large near clips to mitigate the seeing-my-own-face issue. As it stands competing platforms get around this by shrinking the head bone, but that leads to cursed looking avatars in Neos such as this:

However, when I'm inside the avatar nothing is wrong and it's only when I look into a mirror that the problem arises.

This helps by allowing a dual-renderer avatar, an avatar would have two copies of the skinned mesh renderer

One configured to be local user active and viewport only, this is the local view avatar

The other tagged to be non active user, and if active user then non-viewport only, this is the world view avatar.

A slot with a very small scale is added to the avatar's head, and for the local view renderer only the small scale slot is used as the bone for the parts of the head that need to be out of the way.

The actual head bone used by the world view (and physics) remains at unit scale.

This allows interactions like playing with your own ears to still occur, by making those bones in the local view reference the origional bones (hence the very cursed singulariyote above).

As an added side effect, this would allow the users head to move in any direction, even if they wanted to still see their own face. This would allow avatar viewports to move farther back, giving another path to try to reduce spine tugging as described in #2916 and that contributes to the issues around #1120

Helmets

This would also be good for helmets that require a different internal view mesh than from the outside (which is quite common in games to my knowledge).

Horror Maps

Horror maps where items may only be visible in mirrors or are only visible through direct observation would be enabled by this, although this does raise an open question about the streaming camera and which bucket it would be in.

Private UI

This also resolves private UI being visible inside pictures or mirrors, instead users could tag their private UI elements with this component and then they would only see the UI from their headset, no more picture clutter!

In the case of most of these, combining both a user value override like private UI does currently, along with this component would provide the desired effect.

Relevant issues

#1957 was trying to resolve the same issue, but it was going datamodel diversion based, this is trying to be based on existing features.

#2916 as this may mitigate some of the issues around spine tugging outlined in that issue.
#1120 for the same reason, as it may allow more flexibility around full body tracking as the head could translate locally only.

Describe the solution you'd like

A version of the Hidden Layer component that hides only from the headset/desktop viewport, and the ability to negate that components effects (so it is only visible from the headset/desktop viewport).

This component would operate just like a hidden layer component otherwise, turn the component off and the filtering turns off, turn it on and whatever configured filtering applies.

Describe alternatives you've considered

#1957 but it got turned down as not viable, which I can understand.

Users keep needing to set really big near clips - this is non optimal as it's something I see users getting discouraged by.

Private UI is visible in cameras, this is status quo so not really an alternative?

I think something about render layers has come up before, that might apply here.

Additional context

My hope is this is less impossible than the drive-alternate-value version, my end goal here is to try to give users more flexibility around their head position, face clipping, and near clip settings.

[H3BO3]

Something like this is already planned when Froox implements transform offsets based on the renderer (if it's a camera, if it's in a mirror, etc)

[H3BO3]

https://discord.com/channels/402159838827905024/439422161657135106/683205637009965068

[Earthmark]

Odd, that's what #1957 was but that request was labeled as not possible.

[Frooxius]

Unfortunately this approach isn't quite feasible or desirable either. HiddenLayer works by just hiding everything completely. Then to actually make the stuff render, you need to use Selective Render which temporarily re-enables that part of hierarchy for rendering.

This would mean that the normal viewport would have to be constantly running through the hierarchy, re-enabling those hidden parts, which would be very inefficient way to go about it.

Generally this is why we advise against making issues requesting very specific ways to solve a particular underlying issue - often they can clash with how the engine works and it puts us in a bit of a difficult position where we have to say no, even though there are different approaches for it.

We recommend making issues about the problem you're trying to solve, not about your proposed solution, because that makes it easier for us to focus on finding solution that'll work well with the engine.

As I suggested in the last issue, we already have a rough planned solution for this kind of thing, which is submitting rendering overrides. That's different from #1957 though, because it doesn't involve the driving mechanism in Neos' data model - it's not possible to do it that way, since that could drive anything with arbitrary logic and cannot happen in the render pass which is in parallel. This will allow to override only specific properties with specific values while rendering in specific contexts.

Is there a reason you want to actually have two copies of the avatar for this? The render overrides would let you change parts of the transform for specific rendering context, so you could do the shrink bone solution.

[Earthmark]

The three other use cases I listed above besides avatars would not be well satisfied with bone overrides.
They could kind of solve it by collapsing models into zero scale, but at that point you might as well save the gpu bandwidth.

helmets

Helmets and local helmet representation is rendering a different model over the users face, two renderers would still be needed but one is zero scale for each viewport.

horror maps

With horror maps this is less sketchy, as only one model would exist and it's collapsed into zero scale on one viewport.

private ui

With private ui this is trying to reduce noise in pictures and mirrors, collapsed UIs would work for that but considering physical uis can be a lot of renderers, that's a lot of bone overrides on non-skinned mesh renderers (the bone solution may not be applicable for this reason).

this was the common denominator

I saw two renderers as a good superset solution for all of these use cases. My need is still rendering different things between the headset and mirrors/other, skinned or not.

x y issues here

For this issue and others I don't really care about the specific implementation, I was basing this proposal on an existing component.

Hidden layers were used as a basis cause they work well for tagging part of the hierarchy.

From my perspective any kind of need to have a renderer be selectively visible would work, if it's some combination of fields on the renderer that works, if it's a shader setting that works.

The template requires a requested solution, perhaps that should change at it seems providing one has an adverse effect on my feature requests.

[Earthmark]

And fat fingered both the submit and close buttons, damn you GitHub mobile!

[Frooxius]

Those other usecases could be handled with those overrides as well potentially. We might add specific layers for view as well, which might be a lot more efficient too, but I'll have to see about those.

The main thing is what are the actual base requirements. The requested solution doesn't mean necessarily the technical approach, but in this case could be something like "Solution that lets me hide/scale this and that unless it's the first person view".

It sounds like there's essentially following that'd be most beneficial for this:

• Selectively override transform (position/rotation/scale) based on rendering context (e.g. first person view)
• Layer that's only visible in first person view
• Layer that's only visible in anything other than first person view

[shiftyscales]

Worth noting as well there is already issue #1277 regarding rendering layers, but the issue itself is pretty old/out of date with our modern formatting.