VR Expansion Plugin

Development Platform & Builds XR Development
1435

Yeaaaaa…

Welcome to the broken DebugDraw issue, I reported it back in 4.16 preview but it still exists in 4.17 p3.

You have to hide anything that is rendering as a debug draw (generally you only have debug draw visible for debugging anyway). You are seeing the gun example box and the controllers overlap spheres duplicated.

I had it accepted as a bug way back in preview 2 of 4.16 but it continues to be unresolved, its pretty strange that they are taking long / putting low of priority on it considering that in VR editor it could be a problem and 4.13 had the same issue in a preview release and it was fixed before final release.

1436

i noticed too when I allowed my collision spheres to be visible for testing.

1437

I’ll just disable them, thanks, sucks it’s not fixed!

Other than that your advice about Secondary OnUse worked great, thanks man, VR backpack is working awesome (think Ultima Online but a 3D backpack instead).

1438

Its funny how much overlap there is with the plugin, two others are working on inventory / backpacks in the discord currently as well. Pretty cool to see the different approaches though.

1439

I’m gonna try and make a version that just uses Epic’s VR template and put it on the Marketplace, I think it’s a really good inventory system for VR.

1440

which i desperately need

1441

The Wiki does not give examples on “plugging” into an existing project (which was created using the built-in VR template).
How would I do so?

1442

Likely by referencing the example templates implementation, that is its actual use.

“Plugging it in” has many different meanings for the plugin, there are a ton of different features that could be used or not. The basic is just making the main character based off of a VRCharacter, or if only wanting the grip setups to change the motion controllers to GripMotionControllers.

1443

Just merged the 4.17 beta branches into the repositories and uploaded the 4.17 pre-packaged binaries.

1444

Excellent work as always :slight_smile: Thank you !!!

1445

whats the benefit of 4.17 right now?

1446

The spectator / mixed reality / async multiplayer features.

Knuckles support

Some fixes

1447

Nope, got latest 4.17 sources from master branch yesterday and same result from VS or ue build tool



2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystem' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystem'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemUtils' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemUtils'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'AdvancedSessions' as a dependency, but module 'AdvancedSteamSessions' depends on 'AdvancedSessions'.
2>EXEC : warning : Plugin 'AdvancedSteamSessions' does not list plugin 'OnlineSubsystemSteam' as a dependency, but module 'AdvancedSteamSessions' depends on 'OnlineSubsystemSteam'.

Any suggestions?
thx!

1448

Just modify the .uplugin file from AdvancedSession and AdvancedSteamSession to add the module dependencies. is a warning as inter-module dependencies where added in 4.17.

I modified it to silence those warnings:


{    "FileVersion" : 3,
 
    "FriendlyName" : "Advanced Sessions",
    "Version" : 1.9,
    "VersionName": "1.9",
    "Description" : "Adds new blueprint functions to handle more advanced session operations.",
    "Category" : "Advanced Sessions Plugin",
    "CreatedBy" : "Joshua Statzer",
    "CreatedByURL" : "N/A",


  "Modules": 
    {
      "Name": "AdvancedSessions",
      "Type": "RunTime",
      "LoadingPhase": "PreDefault"
    }
  ],
  "Plugins": 
    {
      "Name": "OnlineSubsystem",
      "Enabled": true
    },
    {
      "Name": "OnlineSubsystemUtils",
      "Enabled": true
    }
  ]
}
1449

Yeah a file had missed the commit, I added it back in last night, you can re-download.

Yeah I had it fixed on my end since preview 1, but the uplugin didn’t get committed. Its in there now.

The pre-packaged binaries should be without the warning as they were off of my local copy.

1450

Pushed a new commit to the repository


Some VRDial component fixes / re-implementations, should be functional now and out of 
"beta".

Likely needs some additional features and clean-up in the future.
 makes it: Button, Lever, Dial being at least initially done remaking to c++.
1451

I’m using the Procedural Bridges Template to create bridges for the player to walk over. The bridges are a core part of my project, so I don’t want them to be simple static meshes. The Procedural Bridges are made of a bunch of meshes linked together by physics constraints. Each mesh plank simulates physics and you end up with an awesome wobbly rope bridge.

I’m using VivePawn from the template, and in order to get the pawn to stand on the bridges, I have to disable Ignore Simulating Components. Unfortunately causes the pawn to jitter while it’s on the bridge. It’s not too extreme to make it unplayable, but I’d like to fix it. Is there a way to resolve jitter without ignoring interactions with simulated components?

1452

I mean…you are placing a character on a “wobbly” surface and trying to have them walk across it. Character movement components don’t simulate physics through the physics scene, so they approximate the floor/surface they are standing on and the other physics object is supposed to move out of the way. You are always going to get some unpredictability with simulating components and a movement component, you can try increasing the strength of the constraints so they hold the players mass better and it doesn’t have to adjust to the surface as often. Its made worse by the fact that the capsule retains Z up orientation so when the bridge tilts the character does not.

Sounds like a true vomit simulator though having a swaying bridge.

You can try using the “flat bottom” setting on the movement component, it doesn’t treat the bottom of the capsule as a radius’s cylinder, you may get less jitter that way.

I’ll note that the package you are using has the option to turn off simulation, that may be better.

Edit A video of the jitter you are experiencing would be helpful, you never know, maybe I can do something about it. Did you try it with an FPS character as well and see if it had similar behavior?

Also you could try playing with the “Impart Velocity” settings for the character movement components



Public variable	uint32 : 1 	bImpartBaseAngularVelocity	If true, impart the base component's tangential components of angular velocity when jumping or falling off it.
Public variable	uint32 : 1 	bImpartBaseVelocityX	If true, impart the base actor's X velocity when falling off it (which includes jumping)
Public variable	uint32 : 1 	bImpartBaseVelocityY	If true, impart the base actor's Y velocity when falling off it (which includes jumping)
Public variable	uint32 : 1 	bImpartBaseVelocityZ	If true, impart the base actor's Z velocity when falling off it (which includes jumping)

ReEdit

Yeah I was curious enough to check the base project you are using, even third / first person characters are effected, the bridge is not in any way stable and has some massive jitter from badly set physics constraints.

The blueprints and/or method being used needs some changes, though flat based movement component for find floor DOES help, it doesn’t fix the most unstable parts of the bridge (upswing / downswing jitter from low damping constraints). Also the extra rope “bridges” are conflicting / colliding at one point in the default one making the second to last planks jitter very badly.

Its likely that you just didn’t notice the jitter before being in VR because it wouldn’t seem as extreme on the monitor, while in VR that up/down motion is going to be very noticeable.

1453

no warnings at all, many thanks

1454

I have a few sweeping changes that I would like to make to the plugin to make it more fluid. I have been holding back on them because it would cause people to have to re-do parts of their projects in order to switch to the new setups. Figured I would throw what I would “like” to do in here, with the up and downsides to it and then get feedback on if its worth the pain of transitioning projects to the new methods.

All of these are things that can totally stay “as is” without hurting things too much, however I keep them on my personal list of “Hate” due to either being outdated with new features that have been added, or just not being as robust as I would like now that the plugin has matured more.

**#1: Switch the Interface OnUsed / EndUsed / OnUsed Secondary / EndUsed Secondary events into a singular event instead with enums and more flexibility. **


OnUsedEvent - Type Of use (Start, Stop, ect) - Identifier (Primary, Secondary, Custom1, ect).

**Upsides: **
More input possibilities into interfaced objects without custom interfaces or casting,
more flexibility,
a smaller less bloated interface signature (one event instead of 4)

Downsides:
All current uses of OnUsed and OnEndUsed would have to be switched over to the new format.

**#2: Switch the bIsInteractible boolean into a custom nested struct **

Upsides:
During initial grip info replication none of the interactible settings would replicate unless the boolean is ticked to true, would save on load up bandwidth,
I could more directly control replication of these items,

Downsides:
All interactible objects would need to have references to the boolean re-set as it would move,
All interactible settings would need to be re-made

**#3: Change Initial/Min/ interactible settings location variables to a compressed form **

Upsides:
Would greatly lower bandwidth when sending them

Downsides:
I already tried once, the editor does not recognize them as being the same base type and all current settings are lost and would have to be re-entered.

*Note: If done at once, #2 and #3’s downsides would all happen at once since they overlap and would be less painful *

**#4 (Extreme, not likely, but wishful): Entirely remove the interaction settings **

Why:
Now with the custom grip and the c++ Button, Dial, Lever there is actually very little reason to retain the old interactible settings, they are essentially outdated.
All of their functionality can be re-created with a custom grip, and with more fine grained control over how they behave (though requiring some more work).

Upsides:
Far less grip structure bloat,
Far less replicated variables,
A faster tick on the Motion controllers as they don’t have to check for bIsInteractible every time using an interface call,
I would be forced to basically finish the c++ versions and make slides / drawers and the like to cover what would be then missing.

Downsides:
No more entering a few variables for working drawers and sliders, would have to use base classes that I make or make your own using the custom grip (not hard to do though),
All current objects that rely on interactible settings would need re-made.