Player position, but not rotation, relative streaming camera

[Earthmark]

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

I saw this requested by sonicgott during one of their neos streams, and saw how it is useful during chroma's office hours where the camera facing them but moving with their head was somewhat disorienting.

It seems like tracking the users head position makes sense for a chase cam, but if the camera is facing the user it's like having this effect active the whole time.

In competing platforms it seems like the camera anchoring in the users play space, and being physically moveable is a effective feature. It allows the user to move without disorientation of the audience, and doesn't require dragging the camera around like in physical mode. Dragging is only needed when moving the camera around the play space.

Relevant issues

None found oddly... Feels like streaming camera issues would be related

Describe the solution you'd like

Add a mode to the streaming camera where it is under the user root, but does not move on it's own, and is grabbable by the streaming user only (at least by default).

This is a mix of existing behaviors, where chase cam is under the user root but follows, and static is outside the user root bit doesn't follow.

Describe alternatives you've considered

LogiX to auto reparent the static camera. - this feels like it may not be reliable, or may grab the wrong camera. This also requires set up and existing knowledge, which is non optimal.

Manually reparent the static camera, this is what someone ended up helping Sonic with multiple times, however the camera respawning broke this repeatedly leading to frustration on the streamers part. This required inspector usage and technical skill, which was non optimal. (A 'streamers shouldn't need to know how the pie is made to show off the pie' kind of thing)

It may be possible to have a checkbox that turns off auto movement when under the user root, that would also resolve the issue. In this case the camera would need to be physically moveable though.

Additional context

It seems like this behavior is frequently used in platforms like vrchat, and supporting a similar behavior out of the box may be a positive.

This may also better support users who stream both their physical self and vr self from the same perspective as it would be quite easy for them to set up the camera once, and no runtime adjustment would be needed.

[shiftyscales]

I had tried to create a 'pin' button on the camera, but unfortunately manual mode seems to fix the camera to its existing hierarchy in the root.

I then tried to create a button that would duplicate a camera anchor from the camera under the user's root. This approach almost worked except that a camera's position and rotation are smooth transformed if the anchor moves from its global position. A tweak to make the camera remain perfectly afixed to the position of the anchor would also allow a user-made solution potentially.

I noticed if the interpolate between anchors setting was unchecked, the camera remained fixed in the anchor's position as desired.

This solution presents other issues though, e.g. the inactive template anchor appears in the anchor list, etc. so unfortunately this seems it'll need at least some change made to how the stream camera related components or UI are handled.

[Earthmark]

In this context I'm worried about users who come to stream and not build things. If the come testing viability, I'm not sure they will hunt around if they find their preferred camera style isn't supported and don't realize users can make solutions.

[Frooxius]

Would adding a "Playspace" option that behaves similar to "World", but instead ensures it's parented under the user work?

[shiftyscales]

@Earthmark Yeah, I was in particular mentioning that approach as an option that could be taken on now from a content building approach, e.g. the current default Neos camera was set-up in-app by our content builders. They can't currently change the hardcoded camera control panel, but can improve the camera itsel.

That same approach is planned to be implemented basically everywhere so eventually all UIs could be improved/updated in-app.

@Frooxius - I emulated that result by putting the camera in the world mode, and parenting it under my user root.

That solution doesn't quite resolve it fully.

The camera still tracks the user's head- to my understanding the request is to remain in a completely fixed position and rotation in the playspace.

[Frooxius]

So Manual mode that simply puts it under your user root then? We could potentially make that a checkbox, to always ensure it stays in the user's root for any of the modes, similarly how we have button to ensure it stays in worldspace.

[shiftyscales]

So Manual mode that simply puts it under your user root then? We could potentially make that a checkbox, to always ensure it stays in the user's root for any of the modes, similarly how we have button to ensure it stays in worldspace.

This sounds like a potentially good option. I would have slight concern about it getting 'lost' among the other settings though in the short-term.

It may be better as a discrete mode on its own unless you decide to make the user root mode the default behavior- because then the user could place it in manual, and move it where they'd like, and it'd just-work as they were expecting.

[Earthmark]

I think this seems like three possible modes use case wise:

• Relative to world
• Relative to playspace
• Relative to head - this gets all the fancy offset bits

I think where these statically go is an implementation detail, I think a user picking between these three options may be fairly user friendly?

Long term wise I think picking from a combo box as to what the camera is relative to ('relative to' may not be the best wording) may be clear to a user. From there smoothing, and different sub-menus appear based on context? If it's relative to head then offsets and such pop up, if it's world then camera anchor options pop up... that may help with the getting lost issue you brought up Shifty, which I do agree can be an issue.

[Frooxius]

I don't know how would that mesh with the existing system. What would "Relative to head" be? There are modes that are already implicitly relative to the head, like First Person or Third Person. The only ones that can change are World and Manual, which could be parented under different spaces.