VR Expansion Plugin

Would love to know more about VRLever component and it’s XY axis setting. When picking up only one axis to follow, current angle returns either positive and negative values, which are great for, for instance an input/controller mechanic. Whereas when going with XY Axis setting it will always return positive angle value no matter the rotation of the lever. I’ve noticed the comment in the plugin code, however is there a way to actually make it work so it’d return positive and negative values based on both X and Y axis’ ?

1 Like


Hello mordental,
I was working with a flat widget for my widget class and your laser is working great for selection of the button.
But I changed my widget to a geometry Mode Cylinder and your laser beam is colliding not the curved surface of the widget but a ghost invisible flat surface of the widget.
see here with the debug (in Blue) the endpoint is hitting the curved surface and your laser in red stop on that flat surface as if the widget was flat.
Do you have a solution for that ?
thank you.

XY setting returns the levers facing normal (seperate variable), and then the angle is the angle in that direction.

A singular angle can’t represent XY since X could be + and Y could be - at the same time.

way you can translate that 2D plane normal into a direction, and angle into a magnitude.

Edit

// Bearing Direction, for X/Y is their signed direction, for XY mode it is an actual 2D directional vector
FVector CurrentLeverForwardVector;

That variable to be specific, it is an FVector instead of an FVector2D to make using it simple (just multiply into other vectors).

The laser is hitting the collision geometry, there isn’t much to do there unless you override how the component generates its collision. You can fake it for cylinder ones by progressing the pointer forward but not sure that is worth it.

shows the collision on it if you are curious

https://i.imgur.com/1aQ5SA5.png

Thank you for your Light !:slight_smile:

Pushed a commit to the master (4.19) branch



 Adding Ids to the grip structure, need to expand on their use  

 it was possible to drop the wrong grip if it is replacing one that had the same  
 object.  

 Should also start limiting how fast someone can grip/drop something    

 Hashing the ID was overkill, incrementing a uint8 now, which should be fine  
 as I can't see anyone going over 256 concurrent grips per hand (if they do...well they will have  
 to make it a uint16).  

  works because the uint8 will wrap around back to 0 when it hits Max_Value + 1  
 due to the modulo operation that is performed. Apparantly  is NOT undefined behavior  
 for unsigned variables like it is for signed..live and learn.  

 Also set the drop to pause a grip instead of removing it from the arrya, which rarely caused some  
 corruption.  lets normal replication remove it from the array instead.  

 Also now searching for other grips with the same object in both arrays, if one is found then it  
 skips some of the init dropping functions that would screw with the other grip ( shouldn't happen  
 but who knows...)    
 Adds new GetGripByID node,  is safer than GetGripByObject if you are referencing a grip already. 

TL;DR when picking up and dropping items as fast as you could (like…really fast, 1 grip/drop per frame levels of speed), it was remotely possible to get a client to receive a drop and grip notice for the same object at the same time since grips were defined solely by the object they were holding, could result in deleting a fresh grip and the client having an empty grip array and the server having a 1 grip array (server thinks that the replication is done and doesn’t update the client again).

Now it only drops if the Incremental ID matches, and the drop RPC in the template passes that ID in instead of the object as well, also I am no longer forcing a drop client side (early out to stop tick grip happening on it after drop if the array hasn’t repped yet), now I am just pausing the grip since that functionality exists now which lets the server fully auth the grip array

Man why is 60% of everything in template needed for climbing? can you please make different templates that only have the required functions for the specific thing :frowning: for example 1 template for movement with controllers only, no grabbing or nothing, and one template for climbing only, one for grabbing things and so on, like making it more easy to get started. I really want to use your plugin but i cant get started cuss its a mess in the template and unreadable i don’t know what is needed for what or anything, would help so many beginner VR developers to get started with your plugin.

With all due respect, the plugin in general isn’t intended for beginner devs, and upkeeping multiple templates is outside of my time constraints.

The template is typically showing some of the more complicated features and how to implement them, for experienced devs. Very basic stuff is attainable without all of the framework, but I don’t have time to specifically tutorial out each element at time.

You have been complaining about my plugin for months now, months you could have used to either learn enough to use it, or move on and do something yourself instead,

You also seem to be heavily confusing the TEMPLATE with the PLUGIN, which are not the same thing, And climbing in general does not take “60%” of the template to use, it is two functions and some control variables.

i love the plugin but wish there was more tutorials / documentation

Pushed a new commit to the repository (minor)



 Split grip IDs between local and remote for clients  

 Client local grips run 128 - 255  
 Client remote grips run 0-127  

  lets me use the same variable but not overlap IDs across client controlled  
 local grips and server controlled remote grips.  

 Server doesn't care and uses full scale between them as it is authority  
 for both local and remote grips for its own pawn.  
  Grip IDs are local to the motion controller they are being used for, there can be ID overlap across motion controllers
(to keep replication costs down).    

Made the button components IsValidOverlap function blueprint overridable so people can allow set objects to toggle buttons
instead of just things attached to / held by the motion controllers.  Fixed a bug with button overlap filtering that wasn't
allowing some held grippables through for overlapping.  

 Added a bSkipOverlapFiltering option to the button component that skips all  
 filtering and just lets collision channels handle what can toggle the button. 

Pushed a new commit to the repository



 Fixing Center of mass with scaled root bones and scaled meshes  

 Also now using the full root bone transform instead of just rotation for correction.  
( fixes cases where weirdly scaled / transformed root bones were screwing up physics grips).    
 Using the actual body instances rotation for the center of mass calc now instead of the
 calculated world transform one (in case they differ).  

 Added cvar to turn on COM visualization for grips  
 "vr.DrawDebugCenterOfMassForGrips"  

Pushed a new commit to the repository

TEMPLATE


Removed the Interactible.Door/Lever/Dial gameplay tags, they aren't needed for the template.
Rather people define their own categories if they use them for that.

Removed UseSeperateTouchSockets from the gameplay tags and from being used in the BP character.
Now that BP controller profiles exist I would rather that they be used instead as they do  in a better
manner anyway.

Set the FPS test pawn to the Oculus_Touch controller profile so that objects align correctly.


PLUGIN


Adding log message warning of interactible setting deprecation when trying to grip an object using it
Think 4.20 is the patch that I finally remove  capability and force interactibles
and custom grips instead.

Added events that are thrown on the motion controllers for when an object is
gripped and dropped.  is useful for feedback like hand attachment and
hiding or specific operations based on what was gripped. (ported back to 4.18 as well)

Renamed DenyGripping interface event to "IsDenyingGrips" for blueprints.
Having the node show up as a callable node was not considered when it was originally added.
The function name remains the same so C++ should require no changes.

Hi ,

While updating my setup to 4.19 for my Vive Pro I noticed that in your latest template version there seems to have an issue with double gripped scaling where the secondary grip location seems to use the primary gripped location or something to that effect. To be sure it’s in the template and not something with my setup, I downloaded the version of the template from today ( bcdec50 ) and checked in there directly by scaling the console actor you have in the level, and it has the same issue as my scalable objects. If you try scaling the console actor there, you’ll see what I mean. It’s somehow scaling towards the primary gripped location currently and not a spot between both grips.

I started listen client without HMD by using -emulatestereo in commandline. causes all connected clients are not working correctly (goes out from character’s body and teleport turned off).
Same behavior if used dedicated server.

Why? Are there ways to fix it?

mmm, just noticed that too, i’ll fix it.

Edit Yeah fixed, it was a bug from changing a bunch of the BP nodes in 4.19 to smooth out some logic, accidentally was passing in a null transform.
The latest version of the 4.19 template has it fixed now.

No idea, that was kind of vauge as to what the issue is, but emulate stereo isn’t that good to begin with, you can emulate a headset in the SteamVR drivers themselves with some config edits.

Thanks for the fix. I think I just found another little bug with “Event Tick Grip” in the interface. That event doesn’t seem to be firing any more. I noticed my VR sliders setup wasn’t behaving the same as it was before so I put a print statement after “Event Tick Grip” and it doesn’t print with the new template. Checked and made sure my tick was enabled etc.

No it fires, if it didn’t then none of the interactibles would work anymore, it requires the Custom grip type or you ticking on AlwaysTickGrip in the motion controller settings.

Hey,
I’ll be using fantastic plugin in very short time for a demo I’m developing…I checked your patreon and notice that the goal for the tutorials was reached, but ( at least on your youtube channel ), there’s nothing, so are those available only for Patreons or are still in standby?
I kinda had my way around all the features, but I notice lately a lot of request for tutorials, so I was wondering if you’re planning some

I only went over one so far (custom grips), lost 90% of my free time over the winter after that.

I’m planning on going back to them again, first up is I wanted to go over the general concept of the interactibles that are in, and a very very basic gripping setup.

Regardless, don’t expect a ton of tutorials from me, its a lot of time investment for something I am not all that good at, I want to keep them mostly to the hardest to grasp concepts.

The Q&A I did ended up being far more useful as it directly answered peoples questions live and I could show examples, I would like to do more of those.