Announcement

Collapse
No announcement yet.

VR Expansion Plugin

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by mordentral View Post

    This is unrelated to the plugin, and is base engine setup stuff. The plugins character offsets the hmd from its netsmoother root which is at actor 0,0,0. The behavior you are having would be the same with a normal pawn setup like in Epics documentation.

    Quest setup as far as actors and components is no different than any other VR hardware in engine, its compiling out to it and its limited resources where it differs.

    I haven't heard of an issue like you describe besides from people using the ResetOrientationAndPosition nodes in 4.24 which are broken and don't reset the controllers (though I thought that was a steamVR specific issue in 4.24). Setting floor level tracking makes the 0,0,0 point of your HMD and controllers root component be the center of your tracked space. Have you set up a valid room boundry in your quest?

    Thanks for the tips modentral! Yeah I’ve tried redoing the boundaries with the quest guardian set up a few times to no avail. I’m thinking I’ll start messing around with the VR unreal template and work backwards and then add the plugin in there for testing after I test it with a few basic pawns. Based on what you’re saying I must be overlooking something simple here. I’ll report back here if I do eventually figure it out in case any other newcomers run into this issue.

    BTW I loved the new update video and I’m excited for the future with this plugin!

    Thanks Again!



    Leave a comment:


  • replied
    Originally posted by Andyfilms View Post

    Nope, 4.24.3.

    Again, using the Example Template project.

    It does say that variable is disabled by default to not break backwards compatibility, so does it not make sense to have to enable it?
    It should only be doing anything below 4.24

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    Eh? Not in 4.24 you don't, I guess you are on an older version of the engine?
    Nope, 4.24.3.

    Again, using the Example Template project.

    It does say that variable is disabled by default to not break backwards compatibility, so does it not make sense to have to enable it?

    Leave a comment:


  • replied
    Originally posted by IShootWalkers View Post

    Hello Mordentral!

    I really appreciate the help here!

    I placed the VRCharacter on the level and then made sure I took control of the character as a pawn as suggested earlier by another member here. I also double checked and I am calling this floor level position using the tracking origin in blueprints on event play. After confirming both of these no my character is flying way above the ground and my controller meshes are tiny and super far away.

    I’m considering just using the project template since I’m having these issues but I know you said there are some settings on there which might cause issues with creating a project there?

    If anyone else is using the quest as a starting point I’d love to see settings there or if someone could make a tutorial or template for quest development using this plugin that would be great.

    The YouTube guides on ravens channel are great but I can’t get past the first video with this issue.

    Thanks again!
    This is unrelated to the plugin, and is base engine setup stuff. The plugins character offsets the hmd from its netsmoother root which is at actor 0,0,0. The behavior you are having would be the same with a normal pawn setup like in Epics documentation.

    Quest setup as far as actors and components is no different than any other VR hardware in engine, its compiling out to it and its limited resources where it differs.

    I haven't heard of an issue like you describe besides from people using the ResetOrientationAndPosition nodes in 4.24 which are broken and don't reset the controllers (though I thought that was a steamVR specific issue in 4.24). Setting floor level tracking makes the 0,0,0 point of your HMD and controllers root component be the center of your tracked space. Have you set up a valid room boundry in your quest?

    Leave a comment:


  • replied
    Originally posted by Andyfilms View Post

    A ha! Got it. Had to set the vr.SteamVR.EnableVRInput variable to 1 in the ConsoleVariables.ini file, as per this page:

    https://docs.unrealengine.com/en-US/...put/index.html
    Eh? Not in 4.24 you don't, I guess you are on an older version of the engine?

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    You aren't setting your VR mode to floor level, oculus's module defaults to eye level which means it will zero to the head.

    You need to call this: https://docs.unrealengine.com/en-US/...gin/index.html
    Hello Mordentral!

    I really appreciate the help here!

    I placed the VRCharacter on the level and then made sure I took control of the character as a pawn as suggested earlier by another member here. I also double checked and I am calling this floor level position using the tracking origin in blueprints on event play. After confirming both of these no my character is flying way above the ground and my controller meshes are tiny and super far away.

    I’m considering just using the project template since I’m having these issues but I know you said there are some settings on there which might cause issues with creating a project there?

    If anyone else is using the quest as a starting point I’d love to see settings there or if someone could make a tutorial or template for quest development using this plugin that would be great.

    The YouTube guides on ravens channel are great but I can’t get past the first video with this issue.

    Thanks again!












    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    No, you need steamvr enabled for button mappings, you will also want to check in your steam input setup in steamVR itself and make sure that you don't have a custom mapping setup from before 4.24 that is overriding the default.
    A ha! Got it. Had to set the vr.SteamVR.EnableVRInput variable to 1 in the ConsoleVariables.ini file, as per this page:

    https://docs.unrealengine.com/en-US/...put/index.html

    Leave a comment:


  • replied
    Originally posted by Andyfilms View Post

    Hm, still not working after regenerating them. I also tried creating a custom binding that ensured that the grip was actually corresponding the grip action, but still nothing.

    What do I need plugin-wise besides VRExpansion? If having the SteamVR plugin enabled possibly causing a conflict?
    No, you need steamvr enabled for button mappings, you will also want to check in your steam input setup in steamVR itself and make sure that you don't have a custom mapping setup from before 4.24 that is overriding the default.

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    Sounds like your button mappings need regenerated in the steam menu bar. Its a common issue of the new input system.
    Hm, still not working after regenerating them. I also tried creating a custom binding that ensured that the grip was actually corresponding the grip action, but still nothing.

    What do I need plugin-wise besides VRExpansion? If having the SteamVR plugin enabled possibly causing a conflict?

    Leave a comment:


  • replied
    Originally posted by Andyfilms View Post
    Hi, I'm certain this is my fault, but I'll post here in case someone else can help me resolve this before I do:

    For some reason, my grip is not being detected, neither is the LaserBeam button. I'm using Index controllers, the latest version of the plugin and sample project. No changes made.

    I know the game can tell I am gripping because I can feel the haptic feedback, but it's not translating to the hands or actually gripping objects.
    Sounds like your button mappings need regenerated in the steam menu bar. Its a common issue of the new input system.

    Leave a comment:


  • replied
    Hi, I'm certain this is my fault, but I'll post here in case someone else can help me resolve this before I do:

    For some reason, my grip is not being detected, neither is the LaserBeam button. I'm using Index controllers, the latest version of the plugin and sample project. No changes made.

    I know the game can tell I am gripping because I can feel the haptic feedback, but it's not translating to the hands or actually gripping objects.

    Leave a comment:


  • replied
    Originally posted by Lex713 View Post

    1#. I have CCD on. I also have it set up as a static mesh. Should I switch to using skeletal mesh?

    2# The swords are using the grip interface would those be psychical animations? If so what settings in the interface should I be tweaking to fix my issue? I’m also using the melee grip script if that matters for this

    3# What node should I call to grip a secondary grip? Originally I was using add secondary attachment but should I just be calling a regular grip?
    #1: Then fine tune your global physics substepping (and optionally the object itself) if you are still tunneling with CCD on and large collision bodies, also you want to make sure that your constraints aren't TOO stiff. I can't magically stop tunneling from happening with Physx when using extreme values, you have to work around its limitations.

    #2: I am not talking about the swords, I am talking about what is hitting the swords, if it is an NPC then it needs to use physical animations or manual ones that fall back from collision. If it is other players hitting it and you want to be able to block a swing then you'll have to have the stiffness higher than the incoming swing to stop it or they have to actually manage the hit by deflecting or moving to block at a point close to their grip for more control. That isn't how physics work in game or the real world where two equivalent forces can collide head on and only one of them is affected.

    #3: You don't need secondary grips at all, just calling another grip on the other hand should work, the melee script automatically manages primary / secondary hand assignments based on the settings you use and applies the seperate constraints that you define.

    Leave a comment:


  • replied
    Originally posted by mordentral View Post

    #1: make sure that CCD is setup in the mesh, if it is a skeletal mesh then it needs to be in the physics asset, otherwise it needs to be set in the objects properties. You also will want physics substepping turned on and to tweak the settings for it.

    #2: Not sure if you mean others hitting the sword or not, but if they are just animated and not physically active as well then they don't have a force limit, you need to use physical animations to properly react, or manually handle collision and animate the blocks, there is no way around this. Even when you do use physical animations you will be doing a lot of force tweaking to get everything right, there are no magic bullet here.

    #3: If you are using my melee script it doesn't use secondary attachment points and the properties on them are set to not use them, they use the MultipleGrips setting instead. You can use secondary attachments if you want, it won't be as physically correct but you can just turn on the secondary setting that you want in the properties.
    1#. I have CCD on. I also have it set up as a static mesh. Should I switch to using skeletal mesh?

    2# The swords are using the grip interface would those be psychical animations? If so what settings in the interface should I be tweaking to fix my issue? I’m also using the melee grip script if that matters for this

    3# What node should I call to grip a secondary grip? Originally I was using add secondary attachment but should I just be calling a regular grip?

    Leave a comment:


  • replied
    Originally posted by Lex713 View Post
    Hi,

    I have a couple issues with fast paced melee combat.

    1. When I swing it mostly always blocks. But then if I swing just a little to fast it goes straight thru the mesh. I have tried upping the mass so the sword swings slower, I have updated the mesh and collision to make it thicker but nothing is working.

    2. When I hit the sword I’m holding and trying to block with it just pushes it out of the way. I need it to block it not get shoved out of the way.

    3. When I try to grip with two hands the “add secondary attachment point” keeps failing.
    #1: make sure that CCD is setup in the mesh, if it is a skeletal mesh then it needs to be in the physics asset, otherwise it needs to be set in the objects properties. You also will want physics substepping turned on and to tweak the settings for it.

    #2: Not sure if you mean others hitting the sword or not, but if they are just animated and not physically active as well then they don't have a force limit, you need to use physical animations to properly react, or manually handle collision and animate the blocks, there is no way around this. Even when you do use physical animations you will be doing a lot of force tweaking to get everything right, there are no magic bullet here.

    #3: If you are using my melee script it doesn't use secondary attachment points and the properties on them are set to not use them, they use the MultipleGrips setting instead. You can use secondary attachments if you want, it won't be as physically correct but you can just turn on the secondary setting that you want in the properties.
    Last edited by mordentral; 04-06-2020, 01:06 PM.

    Leave a comment:


  • replied
    Hi,

    I have a couple issues with fast paced melee combat.

    1. When I swing it mostly always blocks. But then if I swing just a little to fast it goes straight thru the mesh. I have tried upping the mass so the sword swings slower, I have updated the mesh and collision to make it thicker but nothing is working.

    2. When I hit the sword I’m holding and trying to block with it just pushes it out of the way. I need it to block it not get shoved out of the way.

    3. When I try to grip with two hands the “add secondary attachment point” keeps failing.

    Leave a comment:

Working...
X