Open arionsh2 opened 6 months ago
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:
I was just about to post that recommendation. Does that meet the needs of this issue, @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 :)
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:
Second, a new triggered flux called "SetViewSource". Inputs & Outputs would be:
Third, a new triggered flux called "DisableViewSource". Inputs & Outputs are the same as SetViewSource, with the following modifications:
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