Overhaul view point detection and add new view override controls

[arionsh2]

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

I am trying to write code to control, direct, and monitor the user's viewpoint. Presently, there is a divide between VR users and Desktop users on pre-packaged viewing options. I would like to unify the information available and controls present in flux for controlling the user's viewpoint.

Describe the solution you'd like

To resolve this, I'd like new / updated flux nodes:

First, a new node called "ViewSource". The output of the node should be local for each user (similar to other view flux nodes). The node reports a new enum with the following values / criteria:

• Default is reported when a VR user is taking input from the VRIK or when Desktop user is taking input from their mouse.
• ThirdPerson is reported if the 3rd person camera is activated (currently, F5 on Desktop and unavailable on VR)
• FreeFormCam is reported if the dedicated free form camera is active (currently, F6 on Desktop and unavailable on VR)
• Other is reported if any other source applies a view override (likely via component)

Second, a new triggered flux called "SetViewSource". Inputs & Outputs would be:

• Inputs
  • ISyncInput * - Any synchronous event input
  • OnlyForUser - Similar to "Fire On" nodes, only the specified user will have their view updated (default is LocalUser)
  • ViewSource - an enum that matches to the above listed enums (default is the Default value)
• Outputs
  • OnPass
  • Triggers if the view is set to the new value
  • OnFail
  • Triggers if ViewSource input is Other, but no override is active (viewpoint does not change in this case)
  • Triggers if ViewSource is disabled (see below)

Third, a new triggered flux called "DisableViewSource". Inputs & Outputs are the same as SetViewSource, with the following modifications:

• ViewSource default is Other
• OnPass triggers if the ViewSource is actually disabled. Neither a user nor a SetViewSource node can set the view to a disabled option.
• Running the operation on an already disabled input leaves the option disabled (triggering OnPass)
• OnFail triggers if the view cannot be disabled for some reason. Default view can never be disabled.
• If user is in the selected input when this triggers, they are switched to Default.

Fourth, a new triggered flux node called "EnableViewSource". This does the opposite action of the DisableViewSource, and would have the same input / output options. If ViewSource input is Default, this will always pass (Default view can never be disabled).

Fifth, add new flux nodes "IsThirdPersonViewDisabled", "IsFreeFormCamDisabled", and "IsOtherViewDisabled". These return true if DisableViewSource has turned the options off, false otherwise. These report for LocalUser only.

Sixth, the ViewOverriden node should be updated to only return true if a valid view override is enabled. If the override is not active due to SetViewSource, this ViewOverriden still returns true. If the view override input is null, then this would return false (since current engine behavior doesn't cause the view to shift in the event of a null source).

Behavior of any view override component would switch the ViewSource to Other when a valid view override is first enabled. If ViewSource is Other and the override is either disabled or becomes invalid, switch view to Default. Disablement can occur either by disabling the component applying the override, nulling the source of the override, or the DisableViewSource flux node above

Describe alternatives you've considered

For VR users, I can use the ViewOverriden flux node to see if any component is overriding the view. If it is false, then I can assume they are using the VRIK. The auto generated "Head" slot on each user can be inspected to find that user's specific viewpoint when the view source is the VRIK (also the ViewPosition, ViewRotation, and ViewScale flux nodes for those specific transform details). However, there is no access to 3rd person or free form cameras in VR (though, they could be built via view overrides and input redirection).

For Desktop users, ViewOverriden is always true (I assume because the view is being driven by the mouse). I can compare the ViewPosition, ViewRotation, and ViewScale data to the auto generated "Head" slot, and assume default view if those match exactly. I can infer Free Form Cam use if the slot UserRootSlot/View/BodyNode slot is active. If neither of those are true, I cannot determine the difference between 3rd person cam and any other view override source.

For both VR and Desktop users, there is no generic way to disable / re-enable any view point source.

Additional Context

Visual storytelling in games depends a lot on what the user can see or is permitted to see. As an example, the view from being in the race car as the driver of the vehicle changes the experience and story told compared to viewing it as 3rd person or "from god's viewpoint" where you can see the whole track at once. While VR first gaming generally wants the user in the driver seat, there can be utility in popping "out of body" (say to lessen the trauma of a crash, or get a really cool picture). Desktop users can currently do this freely, but the experience designer can't restrict or very accurately detect when the user is doing this. Specific systems have to be created to give VR users the same options. Harmonizing the experience for desktop and VR users would be helpful.

Requesters

Arion Silverhoof / arionsh

[art0007i]

something similar to the suggested "ViewSource" node can be achieved using UserActiveViewTargettingController, this node will give you the component so to compare against it you'd need to use the GetType node. The possible types that this can have are:

• FrooxEngine.FreeformTargettingController
• FrooxEngine.UI_TargettingController
• FrooxEngine.FirstPersonTargettingController
• FrooxEngine.ThirdPersonTargettingController

[shiftyscales]

I was just about to post that recommendation. Does that meet the needs of this issue, @arionsh2?

[shiftyscales]

[arionsh2]

This is definitely sufficient for what I described in the ViewSource node. However, overriding the view doesn't change the targeting controller, and using the ViewOverriden node always reports "true" on desktop users as near as I can tell. I can track what I apply or remove for view overrides, but I still don't have visibility with this if the user brings in their own view overrides on their avatar or via their inventory.

It looks like the associated controllers are all placed on the user root slot. I don't think there's a way to enable / disable the options, and disabling the controller components in desktop didn't prevent me from going into 3rd person or free form cam modes. I also don't think there's a way for VR users to engage those modes (though, I can probably use view overrides and input redirection to brew my own).

This at least lets me better detect what view the user is in, even if I can't control or direct the user specifically with it. I still think there's merit in the other nodes I've described, but I'll see what I can create with this.

Thanks, @shiftyscales and @art0007i :)