SkyrimVR Sexlab Lite Temporary Patch

[prog0111]

V0.6.0 is a giant update that changes a ton.  The body posture system is way overhauled, and can be fully disabled by that new mod setting.  I forgot to mention I added another setting to disable the head animation as well, so you can fully escape the body through mods again.

 

If an animation puts you in a "sitting" state, changes there will also kick in.  While sitting VRIK will be much more aggressive about keeping your head aligned on your shoulders.  It basically shoves the heatset towards the body if you get too far away, and will lift/lower it as needed.  The idea here was that some players like to activate a bar stool and then walk across the room and actually sit down for immersion's sake.  Sitting does not fully eliminate body IK though; you can still lean.  I'm thinking this system might be useful to keep the player aligned to their body for other animations where you can't move.

 

For V0.7.0 I decided to just fix every bug I can, make an easier calibration system, and generally polish the mod.  It seems like a good time to fish for more mod-support features that might help.  Right now I'm looking into ways to detect player animation states (GetAnimationVariableBool and such).  I think I might be able to detect if the player is riding a cart through these.  If I can also use them to detect a special idle animation or a paired animation is going on, then I can activate any special logic necessary.  Let me know if you happen to already know a method (even if it's just some Papyrus).  I was thinking to do something like having hand/arm animations play normally unless you move your real hands too far away, then let normal IK kick in (unless a mod is telling me otherwise).  That way I can support FNIS type stuff more generally.

 

VRIK uses the direction of the first person skeleton for the current facing direction.  If an animation rotates this it might really throw VRIK off, and have the body rotate around.  I actually can use the headset direction instead, but it's slightly less accurate at a low level in practice...

[Ramajam]

Would love for a way for VRIK to "snap" to the players head during SL animations. The clone option works but feels a bit awkward and removed from the scene. I'm not sure how old methods worked on previous versions of VRIK.

[oberag]

This is  exactly depends on animation.  At the begining of scene, actors sets the same  position on marker ref , Then,  according to animation properties , one of actors turns arround .  At this moment youre HMD stays in place. Therefore we see our back and twisted neck.   For example, in flowergirls mod only male actor turns arround after  starting animation.  If you play as female,  positioning looks right.  The same at solo animation.  But )) There is second problem. Actor and our HMD takes position of scene marker not of actor head.  So during animation we are  in center of action and even i disable IK and player controls,  changes only height of camera and never X,Y position.  And even in solo animation sometime you look through youre body  .  I think there are two ways. Create VR specific animations , or  disable VRIK and connect camera to VR clone head (like in immersive fPV view mod) and choose very  calm scene ))   .  Or Prog will save us, one more time )))   

[prinyo]

6 hours ago, oberag said:

If you play as female,  positioning looks right.  The same at solo animation.

How did you test that? Added the VRIK functions and recompiled FG?

 

Writing a long post before actually testing with the new version was a mistake. So I've put it under spoiler tag before I decide which parts to keep. Please ignore it for now.

 

 

 

The fact that it works very well without disabling the IK (and after the runaway thing) means that it can be done "properly". Also there are hundreds of animations accumulated for SL already. Any solution should be able to work with them. And also I'm quite sure the problem is not with the animations themselves.

 

I think I need to explain what do I mean by "disabling IK". VRIK has built in IK calculations and enforcement system where it calculates what the position/posture of the body should be according to the position of the HMD and the controllers. If you enter an animation this system will fight the animation constantly and you get "weird" results. Most often it is a  very quick succession of the body doing the animation and standing upright as corrected by the IK system. The body will start doing the animation, the next moment the IK system will correct it, the next moment the next step in the animation, then the IK correction and so on.

To prevent this prog0111 added a Papyrus functionality that disables the IK system by request so the body can be fully controlled by the animation. This works, but the rotating problem appears. The IK system would have corrected for any rotation but now it is off. That would also affect other animations, for example a dance might want to turn you around.

 

And here is the most important part. I think the problem can be fixed in VRIK itself by rotation correction active even if the other parts of the IK system are off. In fact there is already a way to do this:

 

VRIK.VrikSetSetting("lockRotation", 1)

 

The problem is that it is doing it with the already rotated body. I think the solution is to perform a "calibration" when enabling this. This can be a new Papyrus function ( something like CalibrateRotation() ) or automatically performed when setting the "lockRotation" - to make sure the mapping is right before been locked. Also it seems this settings doesn't give tolerance for looking around without rotating.

 

 

 

 

 

 

6 hours ago, oberag said:

At the begining of scene, actors sets the same  position on marker ref ,

Because you say "marker ref" I assume you mean the calibration that SL performs when all participants appear to stand within each other. I have disabled this for the player character in my tests. And I have made sure to disable the IK system just before the actual animation is sent. I have tried to keep the IK corrections active until the very last moment so any preparation in SL would not affect the body.

 

6 hours ago, oberag said:

So during animation we are  in center of action and even i disable IK and player controls,  changes only height of camera and never X,Y position. 

I don't understand.

 

6 hours ago, oberag said:

And even in solo animation sometime you look through youre body

I now believe this is because of no collision. Like you can walk within NPCs in an animation and see inside of them. There is something in the IK system that prevents this from happening and that is been turned off together with everything else.

 

6 hours ago, oberag said:

like in immersive fPV view mod

First person mods are not a solution. Any situation where the head is animated is not a solution. Too many people will have problems with too many animations. Also having the arms  not animated is a huge factor for better immersion.

 

On 8/16/2019 at 1:48 AM, prog0111 said:

VRIK uses the direction of the first person skeleton for the current facing direction.  If an animation rotates this it might really throw VRIK off, and have the body rotate around.  I actually can use the headset direction instead, but it's slightly less accurate at a low level in practice...

Can you add a Papyrus way to switch this on? I don't think it is usable as constantly running - it will prevent you from looking around. But maybe it can be a way to correct/calibrate the rotation. Or can you add a calibration before "lockRotation" is set?

 
 

 

On 8/16/2019 at 1:48 AM, prog0111 said:

I was thinking to do something like having hand/arm animations play normally unless you move your real hands too far away, then let normal IK kick in (unless a mod is telling me otherwise).  That way I can support FNIS type stuff more generally.

 I personally do not believe having the head and hands/arms animated is a good idea. Outside of a very specific mod scenario where the player is possessed and made to do things outside their will. The base setup/flow of the game + VRIK Is that you always have control over your hands (hence arms) and head and you don't really have control over the rest of the body - it just woks by itself. When this is also the case in the animation  it feels natural. If your hands and head start doing things by themselves this will be a shock and then it will take you out of he experience. Even with the dance animations I would prefer to be able to do my own thing with my hands while NPCs cheer and clap - it adds a sense of pride and accomplishment ? because I'm involved in some way.

[prinyo]

On 8/16/2019 at 1:48 AM, prog0111 said:

V0.6.0 is a giant update that changes a ton. 

Yep, it behaves quite differently. But before I can test further I need to deal with the long neck - the head doesn't move with the body. Is there a setting for this?

[oberag]

Yes, first i recompiled FG and SL scripts with different options of VRIK, but after  added some options in VRIK calibration menu like: Disable (pack of commands to disable IK arms, body, rotation )  , Enable , allow update HMD ..... So i can test it during different stages of animation.  May be this is wrong way, but good for analyse .  ))

[prinyo]

1 hour ago, oberag said:

Yes, first i recompiled FG and SL scripts with different options of VRIK...

Cool ?

What version of VRIK did you test with?

[prog0111]

For the automatic-animated hands idea, I was thinking it would only match the animation if your hands were really close to the animation...  So you'd see the animation if you were mimicing it, but if you move your hand somewhere else, it would quit doing that.  I've seen some VR stuff do this well, like Aperture Hand Labs for example is pretty sneaky about correcting your hand positions to grab things more accurately.  This one's just a fun idea though.

 

Right now I'm thinking that I can probably detect if an idle animation is playing by doing Player.GetAnimationVariableBool("bIdlePlaying").  I found the offset to this function, so I can call it directly from my DLL now.  The plan is to get FNIS setup so I have some dance animations and stuff to test with.  That would be step 1 - I can do more to help if VRIK itself automatically knows that modded animations are playing.

 

The body rotation thing is going to be hard.  I'm not sure which bone the animation is actually rotating to turn the character.  VRIK works by adjusting bones in the skeleton dynamically, so what I see in code is something along these lines (debug output):

BSFadeNode skeleton.nif {BOM=BSBoneMap, BBX=BSBound, BSX=198, BSBoneLOD=BSBoneLODExtraData, SkeletonID=207579012}
.NiNode NPC {rigPerspective="3rd Person", rigVersion="2.22", species="human"}
..BSFlattenedBoneTree NPC Root [Root]
...NiNode NPC COM [COM ]
....NiNode NPC Pelvis [Pelv]
....NiNode NPC Spine [Spn0]

I'm assuming that animations generally rotate the skeleton by rotating the NPC Root bone, but I think they could also rotate the COM bone.  VRIK looks at the NPC node to determine player facing angle.  If an animation rotates the player to face behind them, the NPC bone can point in the opposite direction (normally in HMD direction).  This happens in vanilla animations naturally.  For example, the dual wield animation generally has your body twisted almost 90 degrees to the right, and VRIK has to dynamically correct that into something natural (this was so hard...).  The current posture system adjusts the body's pose by altering the COM bone, all spine bones, the neck and head bones, and both shoulder bones.  Note that I'm not touching ANY special XPMSSE bones; VRIK does not require custom skeletons.  Animations that mess with the "in-between" XPMSSE bones can still totally throw VRIK off.

 

Anyway, we're probably going to need something that can lock the headset position AND rotation to the player's shoulders.  In VRIK 0.6, try sitting in a chair...  Then walk away in room-scale.  This is how I think we can fix the positioning issues for animations that have you moving around.  The player can attempt to follow an animation, but if they get out of range they're shoved towards the body.  There's not much better we can do than this.  I think a mod-feature to tell VRIK to lock-on this way might be adequate?

 

Rotation is tougher, but it's the same deal.  I'd find the rotation angle of the player's in-game head prior to any IK alterations.  If the HMD is rotated more than about 90 degrees away from that angle, I'd have to give the player a spin.  I don't think this would be TOO disorienting if it's quick --- like an automatic "snap turn".  Trouble with this is that I don't have a way to do it.  Pushing the headset around for sitting was a good bit of reverse engineering trouble, so I don't know if I'll have a solution in time for V0.7.  Without this, players would have to turn around on their own, which isn't very good if they play sitting down.  Another mod-support setting would be needed to turn this on.

 

I'm including scripts for my holster and MCM menus now by the way - so all the current mod-support settings will show in the MCM if you uncomment some stuff and rebuild it.

[prinyo]

OK, lets do it step by step. Entering animation with the new VRIK version doesn't seem to need any script calls - the body animates with no issues. Seems there is no need to use "enableBody". But the head stays at the height of the headset regardless of what the body is dong so I end up with a "long neck". How do I prevent that? The new version seems to behave differently, but I can't test it properly if the camera and the head are not moving together with the body. The rotation problem appears when the IK is disabled, but the new version doesn't seem to need this anymore.

[prog0111]

Try setting lockHeightToBody to 1.  That'll force the headset to align to the body on the Z-axis, similar to V0.3's auto height adjustment mode.

[prinyo]

If somebody else wants to also test the animations with the new version of VRIK use this file instead of the one in the VR patch. The file assumes you have VRIK installed. The only thing different in the file is that it has the call to enable the setting mentioned in the above comment.

If you get camera shaking - look forward and press forward on the controller (like you walk forward).

 

sslActorAlias.pex

 

I did a quick test this morning (with about 5 animations) and the results were mixed. I did get put in the middle of the scene as oberag reported.

[oberag]

Hi, there is one function in VR game.pex script 

function PlayerAttachToActor(ObjectReference akActor, Float afOffsetX, Float afOffsetY, Float afOffsetZ, Float afOffsetHeading) global native  

I don't know what it does, but it was added for VR.  May be it  replace some traditional setvehicle or mount functions and resolve some troubles with spin during plaing idle.  May be it was made for cart ride when start new game.  If sombody know, please answer , does it worth to test it?  

The idea is to attach HMD to VRclone. 

Oh, there is one more greate mod for test  - Touring carriages. When IK enabled, you sit in right place with right height , enjoy of ride . And if don't pay attention to youre body flying on back side of cart in crushed cockroach pose, this is awesome immersive experience. ))  And you can see relation between  HMD moving and connected body.  There is only one bug with spin, when plaing short "leave the cart" animation. When you sit all is good.

[prinyo]

50 minutes ago, oberag said:

Hi, there is one function in VR game.pex script 

function PlayerAttachToActor(ObjectReference akActor, Float afOffsetX, Float afOffsetY, Float afOffsetZ, Float afOffsetHeading) global native  

 

Tried PlayerAttachToActor() and PlayerRef.AttachToActor() - in both cases the compiler said "is not a function or does not exist". Couldn't find anything online. How do I get more info about it?

 

[oberag]

It's in game.pex module. Game.PlayerAttachToActor(someref, 0,0,0,0) . May be CK doesn.t see it.  I attached decompiled script.  

 

game.psc

[prinyo]

1 hour ago, oberag said:

Game.PlayerAttachToActor

Ah, Game.PlayerAttachToActor(). Should have guessed that, but testing early in the morning while still sleepy has some limitations ?

Will try it tonight.

[prog0111]

I'll add a function that can lock the headset to the body position, like it does now when the player is sitting.  If you use that in combination with the lockHeightToBody, the headset should get shoved around as actors move to keep you oriented.  I should also be able to add a function to snap the headset position.  I still don't know if I can do anything for locking rotation.

 

Cart rides are fixed in the upcoming V0.7.  It basically disables VRIK while on a cart - and detecting that you were on a cart was much easier said than done...

[prinyo]

2 hours ago, prog0111 said:

I'll add a function that can lock the headset to the body position, like it does now when the player is sitting.  If you use that in combination with the lockHeightToBody, the headset should get shoved around as actors move to keep you oriented. 

This sounds like a perfect solution. And then we can see if the rotation is still an issue.

 

On 8/17/2019 at 10:40 PM, prog0111 said:

The plan is to get FNIS setup so I have some dance animations and stuff to test with. 

That would be great because then you could also put an innocent paired animation - kissing for example. Different animations can create different problems, but even a simple one like kissing can show what the core issues are. I'm afraid I'm a bit out of my depth as an intermediary, but unfortunately the "big brains" here that can be way more helpful than me are not interested in VR so I'm trying to compensate with stubbornness ?  But it would still be best if you can see it yourself.

 

On 8/17/2019 at 10:40 PM, prog0111 said:

Right now I'm thinking that I can probably detect if an idle animation is playing by doing Player.GetAnimationVariableBool("bIdlePlaying"). 

That would help support all animation mods in one go without the need of patching so it sounds like a great idea. The question is is it going to have an impact on the performance?

 

On 8/17/2019 at 10:40 PM, prog0111 said:

For the automatic-animated hands idea, I was thinking it would only match the animation if your hands were really close to the animation... 

I think different people will have different preferences and maybe I'm a bit on the extreme here. I actually think most people would enjoy animations where the hands/arms are also animated. I (and other "purists" like me) would still appreciate a setting to turn it completely off. But I can appreciate that a lot of people would like it.

[prinyo]

I assume Game.PlayerAttachToActor() was an attempt to implement a 3rd person view. It looks exactly like that, except you can not control the character you are following (if it is not the actual player character).

 

It is possible to do Game.PlayerAttachToActor(playerRef, ....) and if you use VRIK you will be able to see and control  yourself but I got visual glitches when I did that. But if somebody is willing to spend the time to experiments with the parameters of the function maybe they will be able to get a satisfactory result. However you will be able to see yourself only from one side and I don't believe even without the glitches there is a potential for a cool mod. But maybe somebody will prove me wrong.

 

This can not be used for a first person mod for SL. Even if the offsets are done precisely this will not attach the camera to the eyes of the clone but will move it inside their head so you will see inside the head and the body. If the body changes position the camera will move in a different way so you will still have 3rd person view.

If somebody is curious to see it in action, replace this file in the VR patch and choose Clone in the MCM. (But keep the old file because you will want to restore it.)

 

sslThreadModel.pex

 

Note that after the animation ends you will need to load a save because even after the actor you are following gets destroyed the view doesn't reset and you will be left hanging in the air.

 

 

[oberag]

10 hours ago, prinyo said:

I assume Game.PlayerAttachToActor() was an attempt to implement a 3rd person view. It looks exactly like that, except you can not control the character you are following (if it is not the actual player character).

 

It is possible to do Game.PlayerAttachToActor(playerRef, ....) and if you use VRIK you will be able to see and control  yourself but I got visual glitches when I did that. But if somebody is willing to spend the time to experiments with the parameters of the function maybe they will be able to get a satisfactory result. However you will be able to see yourself only from one side and I don't believe even without the glitches there is a potential for a cool mod. But maybe somebody will prove me wrong.

 

This can not be used for a first person mod for SL. Even if the offsets are done precisely this will not attach the camera to the eyes of the clone but will move it inside their head so you will see inside the head and the body. If the body changes position the camera will move in a different way so you will still have 3rd person view.

If somebody is curious to see it in action, replace this file in the VR patch and choose Clone in the MCM. (But keep the old file because you will want to restore it.)

 

sslThreadModel.pex 43.79 kB · 1 download

 

Note that after the animation ends you will need to load a save because even after the actor you are following gets destroyed the view doesn't reset and you will be left hanging in the air.

 

 

Ok. Thank you for test!  I'll try to play with offset settings at weekend. May be  it somehow depends on 3rd cam position or skeleton node, then there is a chance to get something.  Even so, the function is alive and this is one more way to research . ))

[prinyo]

3 hours ago, oberag said:

Ok. Thank you for test!  I'll try to play with offset settings at weekend. May be  it somehow depends on 3rd cam position or skeleton node, then there is a chance to get something.  Even so, the function is alive and this is one more way to research . ))

I think the first step would be to find out how to disable this because you are left hanging there forever. I looked at the functions in Game but none seemed to me to reset the position. Maybe it is call the function with playerRef as target and a specific vertical offset?

I was thinking what the center point of the coordinates is synchronized with. The default position is just above the head of the NPC looking forward. But when it's body position changes during animation the camera moves in a logic that I couldn't understand. But if you call the function with playerRef as target and 0, 0, 0, 0 as offsets and you use VRIK then the body gets lifted in the air and the camera/view is in the middle of it. Anyway, enjoy the research ?

[prog0111]

I did some work on this.  I have FNIS setup now, and have figured out how to use the paired animations in FNIS Spells to test.  Those animations seem to be mostly kill-moves where the player does fairly large, fast movements.  I'll probably never be able to make these animations look good, but I tried to improve the situation...

 

I added a mod support setting called "lockHmdToBody" that will prevent VRIK from adjusting body position, and push the HMD around to keep it above the player's shoulders.  For those fast-moving FNIS animations, I had to really bump the speed up to get it to work --- but that's a little nauseating even for me, and I'm mostly immune to VR sickness.  I think it would probably be fine with animations that don't have your head moving and changing directions so quickly though, as the kill-move test animations are just a bit much.

 

I really can't seem to figure out how body rotation is supposed to work with these.  Normally, Skyrim points the 1st and 3rd person body exactly in the direction the HMD is facing.  This seems hard-coded.  If I disable all of VRIK's rotation stuff and face away from the NPC during a paired animation, then I'll always perform the animation in the direction I'm facing.  VRIK normally gets around this by keeping track of its own facing direction, and then modifying whatever Skyrim gives it to point the body in its own direction instead.  What I think we need is the rotation that Skyrim SE would use for the player's part of the paired animation instead, but finding that matrix will likely be another huge reverse-engineering challenge.

 

I also can't seem to detect when special animations are playing.  I've tried using GetAnimationVariableBool on "bIdlePlaying", "bMotionDriven", and "bAllowRotation" so far, but they all seem to always return false.  If anyone knows a way to detect this (even in papyrus) please let me know.  If there's no way to do it, then the only solution would be to require mods to use the VRIK settings to enable/disable things manually.

[prinyo]

On 8/24/2019 at 8:08 PM, prog0111 said:

I have FNIS setup now, and have figured out how to use the paired animations in FNIS Spells to test.

Does the script you use call those two:

 

Game.DisablePlayerControls()

Game.SetPlayerAIDriven()

 

I'm trying to understand if they have any effect on how the body behaves in the animations.

There are also possible differences in how the actors are attached to the location of the animation and I'm beginning to suspect that this is one of the main issues.

I tested the latest VRIK with different parameters this weekend - with or without disabling the IK, with and without the lockHeightToBody, with or without disabling the player controls; standing, kneeling and lying-down animations and it is a bit of a mess in my head, but here are some points, I'm planning to do some more tests in the next few days.

 

I think "enableBody" is not needed in most cases and also it doesn't seem to work anymore - even when it is set to 0 VRIK will still try to control parts of the body.

I think "lockHeightToBody" is helping with standing and sitting, but is breaking the lying down animations. It seems when it is enabled the body just "sinks" underground.

However it really does help with the standing and kneeling animations and the only issue I got with them is ... camera shaking. But ... the shaking goes away after doing  the runaway trick that I have been talking about before.

This runaway trick seems the key to many of the problems and I'm going to make some more tests probably tonight to try to see what does it do. What I imagine happens is that when the movement controls are not disabled and you try to run while in animation the body stays at the marker but the camera/view moves forward (with weird visual effects) and then SexLab is forcing you back. This is handled by those two functions:

 

    function SyncLocation(bool Force = false)
        ;debug.trace("VINFAMY SyncLocation")
        OffsetCoords(Loc, Center, Offsets)
        MarkerRef.SetPosition(Loc[0], Loc[1], Loc[2])
        MarkerRef.SetAngle(Loc[3], Loc[4], Loc[5])
        ; Avoid forcibly setting on player coords if avoidable - causes annoying graphical flickering
        if Force && IsPlayer && IsInPosition(ActorRef, MarkerRef, 40.0)
            AttachMarker()
            ActorRef.TranslateTo(Loc[0], Loc[1], Loc[2], Loc[3], Loc[4], Loc[5], 50000, 0)
            return ; OnTranslationComplete() will take over when in place
        elseIf Force
            ActorRef.SetPosition(Loc[0], Loc[1], Loc[2])
            ActorRef.SetAngle(Loc[3], Loc[4], Loc[5])
        endIf
        AttachMarker()
        Snap()
    endFunction

 

    function Snap()
        ;debug.trace("VINFAMY Snap")
        ; Quickly move into place and angle if actor is off by a lot
        float distance = ActorRef.GetDistance(MarkerRef)
        if distance > 125.0 || !IsInPosition(ActorRef, MarkerRef, 75.0)
            ActorRef.SetPosition(Loc[0], Loc[1], Loc[2])
            ActorRef.SetAngle(Loc[3], Loc[4], Loc[5])
            AttachMarker()
        elseIf distance > 2.0
            ActorRef.TranslateTo(Loc[0], Loc[1], Loc[2], Loc[3], Loc[4], Loc[5], 50000, 0.0)
            return ; OnTranslationComplete() will take over when in place
        endIf
        ; Begin very slowly rotating a small amount to hold position
        ActorRef.TranslateTo(Loc[0], Loc[1], Loc[2], Loc[3], Loc[4], Loc[5]+0.01, 500.0, 0.0001)
    endFunction

 

 

 

Something in the way those functions position the body is making it work better than the initial setup. Somewhere here is the key to eliminating the body flicker that looks different in the new version but it seems is a variation of the one in 0.3.

Will make some more tests with this.

 

 

[lipplog]

On 4/5/2018 at 10:45 PM, haxmo said:

A quick fix to disable the forced 3rd person mode where you float in the air during an animation.

The player model is still invisible though.

Data.zip 13.6 kB · 1,044 downloads

Sorry for the obvious question, but am I putting this file into the Sexlab Lite Scripts folder?

[Ramajam]

I see the latest version of VRIK has in the changelog, "Added mod support feature lockHmdToBody to allow animations to drive the body around" Would this be usable for SL scenes?

[prinyo]

On 9/6/2019 at 12:47 AM, Ramajam said:

I see the latest version of VRIK has in the changelog, "Added mod support feature lockHmdToBody to allow animations to drive the body around" Would this be usable for SL scenes?

The problem that this settings should fix is a very specific one and happens in specific situations. There are several similar script calls that VRIK can handle that are made to help it work in an animation.

The way I see it there are 6 different possible situations in an animation :  standing, kneeling and lying down - in top (male) or bottom (female) position. They can produce different results while using the same settings. My idea is to add the possible script calls as options in the MCM of the VR patch for SL Light so people can set them up the way that works for them and test it.

I'm going to upload a version of the VR patch with those options when I solve the problem that all those situations seem to suffer from with the current VRIK versions - camera shake. Seems this is not a problem of VRIK, but is caused by the way the player character is positioned for the animation. But so far I haven't found a way to fix it.

Regardless, I'm going to upload an experimental version of the VR patch soon, so things can be tested by more people with different setups and use cases.