User Tag List

Page 25 of 26 FirstFirst ... 1523242526 LastLast
Results 961 to 1,000 of 1030

Thread: VR (OpenVR) Expansion Plugin

  1. #961
    0
    Quote Originally Posted by mordentral View Post
    Yeah ok, I exposed the boolean that deals with that yesterday as well as I figured it might be the problem.

    The simplecharacter doesn't keep the HMD at a relative position to the actors root, it moves the actors root WITH the hmd and keeps the HMD at X/Y 0,0,0. Due to this there is a boolean in the motion controllers bOffsetByHMD that offsets the tracking frame back by the HMDs position as otherwise they would have that offset you are talking about. (The VRCharacter doesn't do this so it defaults this boolean to false).

    Before yesterday this was a private variable to c++ because I was manually setting it on the default components on the simple character. However tracked devices are not default components and will have it defaulted to false.

    So with the new version (commit as of 4/12) you should be able to go in to the TrackedDevice and set bOffsetByHMD to true and get your correct transform on the tracked devices, as well as the 7 additional index's.


    I realized that people trying things like the simple character and only using my motion controllers would need that boolean exposed anyway, so its a good thing to have regardless.

    *Edit* Oh forgot to mention, pretty sure that the SteamVR driver rollback a day ago took away the new Index's of the trackers again. You'll want to be on the SteamVR Beta branch as it is still correct and is what the main will be once they fix the oculus issue.

    Thanks it's working now with the Offset by HMD toggle. I noticed they are showing up under "Invalid" with "getValidTrackedDeviceIds" after the driver rollback, but they're still working though your plugin without SteamVR beta branch somehow, and thanks for enabling more trackers.

  2. #962
    0
    Quote Originally Posted by alltrueist View Post
    Thanks it's working now with the Offset by HMD toggle. I noticed they are showing up under "Invalid" with "getValidTrackedDeviceIds" after the driver rollback, but they're still working though your plugin without SteamVR beta branch somehow, and thanks for enabling more trackers.
    Mmm, Invalid is just on epics end, I just assumed that the rollback would have changed their index's back to the old values, but appears not. So should be good to go for awhile.

  3. #963
    0
    Quote Originally Posted by kusokuso1 View Post
    ---------
    Downloaded the VR template zip for this plugin (https://bitbucket.org/mordentral/vrexppluginexample)

    Built it and PIE'd. (Just made sure hands were getting tracked and grabbing was working.)

    Stopped PIE.

    Opened my broken project.

    After it finished loading, I tried to PIE on the VREx.plugin template again and found out hands were broke. (Actually, the left hand skeletal mesh from the broken project was taking the place of both hands in the new project, and were locked at 0,0,0). I never copied this skeletal mesh over to the VREx.plugin template. No changes were made to the ex. project whatsoever.

    Shutdown the broken project, then the VREx.plugin template project.

    Relaunched the VREx.plugin template project

    Steam Motion controllers are now taking the place of the hand skeletal meshes and are getting tracked. UI widget is visible on the MCs, but buttons do nothing.

    I pm'd you a link to the bad project.
    ---------
    I didn't realize that you were opening two projects at once, that WILL break SteamVR, actually I am surprised that it let you get away with it, used to fully crash out of the editor if something else tried to take over.

    I downloaded your project anyway but it doesn't appear to have anything wrong in it, I would suggest never loading up two projects at once with VR plugged in, if you want to migrate then use the migration feature or just don't expect the tracking to work in both projects at once. Even when not running PIE the editor still keeps hands on SteamVR due to being able to hotload into and out of the VR editor, as well as the SteamVR Plugin module loading up references when accessed.

    *Edit* Also for future reference, if sharing a project in the future, delete all Intermediate and Binary folders (one for the project and one for each plugin module). This will greatly reduce the size of the upload / download.
    Last edited by mordentral; 04-14-2017 at 09:16 AM.

  4. #964
    0
    Quote Originally Posted by mordentral View Post
    I downloaded your project anyway but it doesn't appear to have anything wrong in it, I would suggest never loading up two projects at once with VR plugged in, if you want to migrate then use the migration feature or just don't expect the tracking to work in both projects at once...
    Thanks a lot for the info. I actually looked around for threads about running 2 projects (not VR, tho) at the same time, but didn't find anything. I know now it's not.
    Whenever I open up that rocket2 project while another, good project is running, the good one gets permanently ruined (whether I save or not before killing everything, and then relaunching the formerly good one solo).

    Is there some kind of cache (like in SteamVR) somewhere that's mucking up the motion controllers?

    Quote Originally Posted by mordentral View Post
    *Edit* Also for future reference, if sharing a project in the future, delete all Intermediate and Binary folders (one for the project and one for each plugin module). This will greatly reduce the size of the upload / download.
    You got it. I apologize for that. I'll never do that again unless instructed otherwise.
    Last edited by kusogaki77; 04-14-2017 at 10:09 PM.

  5. #965
    0
    I'm trying to do a sanity check and was hoping some other could chime in with experience. I'm trying to figure out what is different between a clean install of the examples project for the VRextension plugin and the vanilla epic VR template in a fresh project. (Switched to the forward render) as far of optimization or performance with lighting.

    I've got a really small scene about 16ft x16ft with with only 30-50 at any time in a scene. Nearly everything is a moveable object and I'm not using any static lighting.

    - 1 Direction with Shadows (moveable) Lighting Channel 0 (default)
    - Skylight pulling from a texture (moveable)
    - 1 point light NO SHADOWS on Lighting Channel 1 lighting 2 characters
    - 1 point light NO SHADOWS on Lighting Channel 2 lighting some set objects

    Everything runs smooth in the default Epic template, but one of those shadowless point lights in the VRextension example scene will induce judder on a Vive.

    Anyone have any thoughts. I can't find much talking about dynamic lights in the forward render an what is a good target. I wish I could bake some lights, but I'm moving and turn them off over and over.

    Would love anyone one's thoughts on this. I'm going to go take a walk.

  6. #966
    0
    I'm just going to chalk it up to too much overhead in forward rendering. I wouldn't think shadow-less point lights would be such a hit. But I'm just guessing. For the moment, I just dialed back the screen percentage in the Player Controller from 150 to 110 , at least it's buttery smooth again, and that it's my number one goal. I'm working with a 980, so considering it's a target machine experience, I might see if we can work with a Titan or something extravagant.

    I'm just happy to have to points in separate channels and a direction (with skylight) running smooth, but it's tough after looking at the sharper res.

  7. #967
    0
    Seems once I reach a certain velocity threshold, the motion controllers' position tracking gets more sensitive while airborne. (Using "launch character" on "get player character".) I mean, at higher speeds the slightest change in pos/rot of the actual Vive controller produces an extremely exaggerated/amplified pos/rot of the one rendered in game.

    This is the same issue I had experienced before using this plugin, when I had everything (Camera and motion controllers) parented to a box. (Using "add force" on the "box collision".)
    Last edited by kusokuso1; 04-17-2017 at 04:16 AM. Reason: Issue doesn't occur when controller is at rest.

  8. #968
    0
    Quote Originally Posted by kusokuso1 View Post
    Seems once I reach a certain velocity threshold, the motion controllers' position tracking gets more sensitive while airborne. (Using "launch character" on "get player character".) I mean, at higher speeds the slightest change in pos/rot of the actual Vive controller produces an extremely exaggerated/amplified pos/rot of the one rendered in game.

    This is the same issue I had experienced before using this plugin, when I had everything (Camera and motion controllers) parented to a box. (Using "add force" on the "box collision".)
    Yeah, its because of the late update transform, it doesn't handle high velocities very well, you can turn off the late update at high velocities to prevent it happening. I started investigating a fix for it last week but still haven't entirely tracked down the root cause yet (or if I can fix it just for the plugin, not all of the scene information is accessible and they opened up a function specifically for late updates that they use).

    Epic also switched over to a new method of attaining the transforms for the late update but it has the same problem as well.

    *Edit* mmm, even has a ticket for it, been unresolved since 10/16 https://issues.unrealengine.com/issue/UE-37811


    Quote Originally Posted by pixelvspixel View Post
    I'm just going to chalk it up to too much overhead in forward rendering. I wouldn't think shadow-less point lights would be such a hit. But I'm just guessing. For the moment, I just dialed back the screen percentage in the Player Controller from 150 to 110 , at least it's buttery smooth again, and that it's my number one goal. I'm working with a 980, so considering it's a target machine experience, I might see if we can work with a Titan or something extravagant.

    I'm just happy to have to points in separate channels and a direction (with skylight) running smooth, but it's tough after looking at the sharper res.
    Forward renderer while mostly functional is also still somewhat unfinished, if you are finding issues with it you should report them in the top thread of this forum subsection to let the developers know so they can look into it.
    Last edited by mordentral; 04-17-2017 at 08:25 AM.

  9. #969
    0
    Hey mordentral.

    I've been attaching my weapon AActors to UGripMotionControllerComponent in the usual way (GripObject()), with the default GripCollisionType of EGripCollisionType::InteractiveCollisionWithPhysics. The weapon behaves exactly as I want it when it comes to blocking collisions. However, I've noticed that the gripped actor doesn't remain perfectly locked to my hand's skeletal mesh (which is a child of the UGripMotionControllerComponent). I'm assuming this has to do with the full physics simulation going on. Switching over to EGripCollisionType::InteractiveHybridCollisionWithSweep seems to have solved this, which is perfect. I'm very glad you added in this hybrid collision type.

    However, in your wiki docs at https://bitbucket.org/mordentral/vre...tionController I see you've marked InteractiveHybridCollisionWithSweep as incomplete. Anything I need to be aware of while using this collision type? So far it seems to be working perfectly, but are there any known cases where it could break? I'll be using these gripped actors in a multiplayer game.

    Thanks!

    - Dave
    Latest Demo, Turtle VR: http://www.turtlevr.com
    Mobile VR Jam 2015 Entry: Circumpaint
    VR game, Here Come The Dead: http://www.herecomethedead.com/
    Main web site: http://www.gnometech.com/

  10. #970
    0
    Quote Originally Posted by Gnometech View Post
    Hey mordentral.

    I've been attaching my weapon AActors to UGripMotionControllerComponent in the usual way (GripObject()), with the default GripCollisionType of EGripCollisionType::InteractiveCollisionWithPhysics. The weapon behaves exactly as I want it when it comes to blocking collisions. However, I've noticed that the gripped actor doesn't remain perfectly locked to my hand's skeletal mesh (which is a child of the UGripMotionControllerComponent). I'm assuming this has to do with the full physics simulation going on. Switching over to EGripCollisionType::InteractiveHybridCollisionWithSweep seems to have solved this, which is perfect. I'm very glad you added in this hybrid collision type.

    However, in your wiki docs at https://bitbucket.org/mordentral/vre...tionController I see you've marked InteractiveHybridCollisionWithSweep as incomplete. Anything I need to be aware of while using this collision type? So far it seems to be working perfectly, but are there any known cases where it could break? I'll be using these gripped actors in a multiplayer game.

    Thanks!

    - Dave
    Since it is a simulating object that is "constrained" in away to your hand it doesn't get the perfect 1:1 that a non simulating object gets. You can up the constraint strength and lower the damping to reduce this effect but you have to accept the fact that the higher strength the constraint is the less "giving" it is when colliding with surfaces. I changed the gun in the template last month at some point to increase the constraint strength so that it kept to the hand cleaner.


    The hybrid grip works perfectly in 99% of cases, that 1% edge case just bothers the hell out of me so I refuse to flag it as finished (it clips through geometry in very narrow circumstances).

  11. #971
    0
    Pushed new commit to template and Plugin, this will likely be the final update before I move the main branch to 4.16 and lock 4.15 down (major changes in 4.16 to a lot of relevant systems). I wanted to make sure that these changes and features got in on 4.15.

    Template
    Code:
    Made several changes to correct blueprint compile errors due to new OpenVRExpansionLibrary setup.

    Plugin
    Code:
    Final refactor push before 4.16
    
    Added GoogleVR to HMD Types in GetHMDType to keep sync with Epics
    
    Finally was able to convert OpenVRExpansionFunctionLibrary to a blueprint library only now
    that it is in its own module. Uses a static OpenVRGenericInterface just like SteamVRHMD.
    
    *WILL REQUIRE BP NODE CHANGES: Due to not being a component anymore all Expansion library nodes will need to be replaced with the same node again
    but without the parent calling component.
    
    Added more notes for incoming 4.16 upgrade (Plugin should be good to go day1 of 4.16).
    
    Added SteamVRKeyboardComponent that allows for displaying, interacting with, and getting
    data back from the SteamVR Keyboard while in game. Positions itself with the component
    wherever it is and polls the events from the keyboard through an overlay it creates to host it.
    
    Is a little finicky due to the keyboard eating controller inputs and displaying the other steam overlay objects.
    But is a nice tool at the very least for dev work.
    
    Component has several events that can be Binded to in Blueprint and the OpenVRKeyboard and CloseVRKeyboard
    functions.

  12. #972
    0
    Hi Mordentral.

    I'm running into a issue with using SimpleVRCharacter with an IK plugin I'm using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. This is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I'm wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.
    Last edited by alltrueist; 04-18-2017 at 12:01 AM.

  13. #973
    0
    How do I update the plugin to the latest version if I already have an older one implemented?

  14. #974
    0
    Quote Originally Posted by alltrueist View Post
    Hi Mordentral.

    I'm running into a issue with using SimpleVRCharacter with an IK plugin I'm using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. This is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I'm wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.
    Not without breaking a lot of what epic set up for VR behavior (room scale bounds for one, they will rotate with you then which is incorrect, though I guess they are likely already incorrect for simplechar). Also driving view rotation off of character in a networked environment was not something I felt comfortable doing.

    If your IK plugin does not have a variable to expose to drive different elements than I suggest you contact the dev and ask for some, because a closed IK system is not exactly suited to VR (or lots of other uses honestly). Generally any good IK system should allow you to pass in your own Forward vector....which would be the VRForwardVector. Without that, it is incompatible with literally every VR setup currently in use in the engine.

    I could maybe add an optional rotate with HMD option, but like I said, I don't like the concept currently.


    Quote Originally Posted by Link_AJ View Post
    How do I update the plugin to the latest version if I already have an older one implemented?
    Safe Method, should be hassle free, has more steps

    1. MAKE A COPY OF YOUR PROJECT (can't stress this enough, if you don't have a backup system you do this regardless of plugin updates, even just engine updates).

    2. Replace the current vr plugin folder with the new one (delete old one first)

    3. Delete the intermediate folder for your project

    4. Right click on the UProject and Generate Project Files

    5. Compile

    6. Make any required blueprint changes for things that were changed.


    Unsafe method, may have to revert to safe method if the engines reference precompiled files are messed up


    1. MAKE A COPY OF YOUR PROJECT (can't stress this enough, if you don't have a backup system you do this regardless of plugin updates, even just engine updates).

    2. Replace the current vr plugin folder with the new one (delete old one first)

    5. Compile

    6. Make any required blueprint changes for things that were changed.
    Last edited by mordentral; 04-18-2017 at 09:19 AM.

  15. #975
    0
    Thanks! Will update soon then. Your plugin is amazing btw, saved me a bunch of time setting up basics like movement and multiplayer.

  16. #976
    0
    I would like to note that I did finally get around to testing on 2017 and it all compiles fine, you just have to make sure that the editor is set to use Visual Studio 2017 and re-generate the solution so that it is correctly set up.

    Quote Originally Posted by alltrueist View Post
    Hi Mordentral.

    I'm running into a issue with using SimpleVRCharacter with an IK plugin I'm using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. This is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I'm wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.
    Oh, something else, if it just pulls rotation from what it is attached to, then attach it to the ParentRelativeComponent instead of the root capsule.
    Last edited by mordentral; 04-18-2017 at 02:33 PM.

  17. #977
    0
    Hi Mordentral,

    Many thank you for your plugin, it has been great to play with. I have a question regarding the Rift and your plugin, do the Run in Place/Arm swing work with touch controllers as they do for vive controllers? If not, is that mechanic possible with the rift?

  18. #978
    0
    Quote Originally Posted by darinsmyth View Post
    Hi Mordentral,

    Many thank you for your plugin, it has been great to play with. I have a question regarding the Rift and your plugin, do the Run in Place/Arm swing work with touch controllers as they do for vive controllers? If not, is that mechanic possible with the rift?
    It should work the same yes, button mappings in the template are likely to be wrong for Oculus since I don't own any of their hardware anymore but that is obviously fixable.

  19. #979
    0
    Quote Originally Posted by mordentral View Post
    Not without breaking a lot of what epic set up for VR behavior (room scale bounds for one, they will rotate with you then which is incorrect, though I guess they are likely already incorrect for simplechar). Also driving view rotation off of character in a networked environment was not something I felt comfortable doing.

    If your IK plugin does not have a variable to expose to drive different elements than I suggest you contact the dev and ask for some, because a closed IK system is not exactly suited to VR (or lots of other uses honestly). Generally any good IK system should allow you to pass in your own Forward vector....which would be the VRForwardVector. Without that, it is incompatible with literally every VR setup currently in use in the engine.

    I could maybe add an optional rotate with HMD option, but like I said, I don't like the concept currently.
    Ok, makes sense. It wasn't the capsule forward vector it was using, but the knee bones' forward vector according to the character input anim, and I was confused because there is basically no input anim, so just the T pose. Yesterday, I was able to get around this issue by just rotating my skeletal mesh T pose, in the anim graph before the IK does it's thing. So far it's working for me. In the worst case I can just make my own look at behavior for the knees. Out of curiosity would VRCharacter have this room scale capsule rotation capability, or same behavior there?
    Last edited by alltrueist; 04-18-2017 at 10:33 PM.

  20. #980
    0
    Quote Originally Posted by alltrueist View Post
    Ok, makes sense. It wasn't the capsule forward vector it was using, but the knee bones' forward vector according to the character input anim, and I was confused because there is basically no input anim, so just the T pose. Yesterday, I was able to get around this issue by just rotating my skeletal mesh T pose, in the anim graph before the IK does it's thing. So far it's working for me. In the worst case I can just make my own look at behavior for the knees. Out of curiosity would VRCharacter have this room scale capsule rotation capability, or same behavior there?
    Yeah VRCharacter doesn't move the root itself, it moves the physical representation of it in the physics scene and uses the offset location in every function instead of the actual actors location. It far more complicated but allows for some additional features, it still doesn't rotate the actor with it though.

    Like I said in my second reply though (you may have missed it), if the problem is the skeletal mesh having to have a rotation (IE, be parented to something that follows rotation), use a Parent Relative Attachment attached to the camera and place the skeletal mesh under that. The whole point of the parent relative attachment is to provide a solid base for Bodies and waists and chests and such and to rotate them with the YAW/Z axis of the head.

  21. #981
    0
    Pushed a new commit to the Plugin


    Code:
    Using override CallServerMove now instead of custom function
    
    New grip type Beta InteractiveHybridGripWithPhysics (when not colliding this grip makes the constraint stiffness 10x what the setting is so the object matches the hand more closely)
    
    Moved some magic numbers up into const static variables in motion controller component
    
    Some bWalkingCollisionOverride fixes, needed to manually check for walking movement mode to ensure
    that it can't run during falling and the like. Removed checking for it in floor find function.
    
    Fixed having actor grips stop simulation on ALL components during grip with physics only.
    Should only stop simulating the root comp now.
    
    Made the notify grip and notify drop functions slightly more performant (can be even better but low priority)
    
    Added ability to set a grips Stiffness and Damping after grip.
    *Edit 04/20/2017 Pushed another commit to the plugin (Trying to get small bugs and cleanup done before 4.16 so the locked 4.15 branch is as stable as possible).

    Code:
    Fixed server sided navigation, client side was overwriting it.
    (Still think client side is way to go for VR).
    
    Removed extra code in GripNotify function now that is has been cleaned up.
    
    Added some explanation to the LocalOnly_Not_Replicated grip replication mode.
    Both in comments in source and on the wiki.
    Last edited by mordentral; 04-20-2017 at 01:23 PM.

  22. #982
    0
    Quote Originally Posted by mordentral View Post
    Yeah VRCharacter doesn't move the root itself, it moves the physical representation of it in the physics scene and uses the offset location in every function instead of the actual actors location. It far more complicated but allows for some additional features, it still doesn't rotate the actor with it though.

    Like I said in my second reply though (you may have missed it), if the problem is the skeletal mesh having to have a rotation (IE, be parented to something that follows rotation), use a Parent Relative Attachment attached to the camera and place the skeletal mesh under that. The whole point of the parent relative attachment is to provide a solid base for Bodies and waists and chests and such and to rotate them with the YAW/Z axis of the head.
    I had tried using the parentRelativeAttachment before, and would love to use it, but the issue for me is that I need to drive the base body movement from the pelvis and not the head. Otherwise my IK looks funky because when I rotate my head the whole underlying animation is rotated.

    I tried adding an extra parentRelativeAttachment component besides the inherited one, and attaching it beneath my pelvis tracker in hopes that it would use that as the parent, but it still seems tied to the HMD as the parent. Is there any way to make it accept any parent rather than just HMD? I think if I could have the pelvis tracker as parent it would work well for my body tracking setup.
    Last edited by alltrueist; 04-21-2017 at 07:58 AM.

  23. #983
    0
    Quote Originally Posted by alltrueist View Post
    I had tried using the parentRelativeAttachment before, and would love to use it, but the issue for me is that I need to drive the base body movement from the pelvis and not the head. Otherwise my IK looks funky because when I rotate my head the whole underlying animation is rotated.

    I tried adding an extra parentRelativeAttachment component besides the inherited one, and attaching it beneath my pelvis tracker in hopes that it would use that as the parent, but it still seems tied to the HMD as the parent. Is there any way to make it accept any parent rather than just HMD? I think if I could have the pelvis tracker as parent it would work well for my body tracking setup.
    Mmmm, forgot that with that many trackers that you would be using a pelvis tracker. The problem is that with a pelvis tracker I need to do the orientation math differently and it has to be based off of the initial position of the tracker (trackers aren't attached facing up for the waist and aren't at center of mass but rather at rear or front of body).

    I was going to start working on that anyway because my capsule location needs to have the option to work off of a tracker for waist tracking. It will just take some calibration functions or properties to manage (tracker relative location / rotation around capsule, ect).

    I should have something done this weekend, had to get my trackers functional again.

  24. #984
    0
    Hello Mordentral! I have a question about VR Character. Would it be possible for users to set the VRCharacter to move the root as well?
    If I am correct, when anything is attempting to get the world location/forward vector of the VRCharacter, it can't just generically get the actor's location, it needs to cast specifically to VRCharacterPawn and get the VRLocation/VRForwardVector.

    If people want to avoid this, is the only real option to use the VR Simple Character instead?
    Michael Wentworth-Bell - 3D Generalist / Virtual Reality Designer
    Reel Pictures
    Melbourne, Australia

    Personal Folio Website: http://thelode.com.au/
    Creator of Espire 1 - VR Stealth game: Espire1.com

  25. #985
    0
    Quote Originally Posted by michaelwbell View Post
    Hello Mordentral! I have a question about VR Character. Would it be possible for users to set the VRCharacter to move the root as well?
    If I am correct, when anything is attempting to get the world location/forward vector of the VRCharacter, it can't just generically get the actor's location, it needs to cast specifically to VRCharacterPawn and get the VRLocation/VRForwardVector.

    If people want to avoid this, is the only real option to use the VR Simple Character instead?
    There would be no point to VRCharacter moving the root, it would be the same as SimpleVRCharacter then (and lose a couple of features like bWalkingCollisionOverride and the capsule head offset).

    I will note that most VR setups in engine (including epics) have that same Actor location limitation that VRCharacter does, Simple character, while it solves that can't use those two specific extra features.

    Also the Simple character doesn't rotate the actor anyway, you would still need to use the VRForwardVector.

    *Edit* I may look into an optional camera to actor rotation for the simple character, however it will break some things like epics teleport system and their chaperone component.
    Last edited by mordentral; 04-21-2017 at 11:57 AM.

  26. #986
    0
    Is there a way to disable the step up on feature? I love the climbing and grip systems but would like to disable stepping up on the stuff you are climbing and make the player do it the old fashioned way ;D

  27. #987
    0
    Quote Originally Posted by MagusShade View Post
    Is there a way to disable the step up on feature? I love the climbing and grip systems but would like to disable stepping up on the stuff you are climbing and make the player do it the old fashioned way ;D
    You mean like have to throw themselves up onto stuff?

    Set the climbing step up height to 0.0f. That should make it impossible to actually be able to step up while climbing, that value is "max height for step up" so at 0.0f you can never actually step up unless its a flat plane with you.

    96.0f or so would let them step up from waist height on the other hand.
    Last edited by mordentral; 04-21-2017 at 12:28 PM.

  28. #988
    0
    where is the climbing step up height variable located? I was looking in Vive_PawnCharacter but i couldn't find it

  29. #989
    0
    Quote Originally Posted by MagusShade View Post
    where is the climbing step up height variable located? I was looking in Vive_PawnCharacter but i couldn't find it
    PHP Code:
        // Height to auto step up
        
    UPROPERTY(EditAnywhereBlueprintReadWriteCategory "VRMovement|Climbing")
            
    float VRClimbingStepHeight
    Its in the movement component

  30. #990
    0
    Quote Originally Posted by mordentral View Post
    PHP Code:
        // Height to auto step up
        
    UPROPERTY(EditAnywhereBlueprintReadWriteCategory "VRMovement|Climbing")
            
    float VRClimbingStepHeight
    Its in the movement component
    Thank you!

  31. #991
    0
    Quote Originally Posted by alltrueist View Post
    I had tried using the parentRelativeAttachment before, and would love to use it, but the issue for me is that I need to drive the base body movement from the pelvis and not the head. Otherwise my IK looks funky because when I rotate my head the whole underlying animation is rotated.

    I tried adding an extra parentRelativeAttachment component besides the inherited one, and attaching it beneath my pelvis tracker in hopes that it would use that as the parent, but it still seems tied to the HMD as the parent. Is there any way to make it accept any parent rather than just HMD? I think if I could have the pelvis tracker as parent it would work well for my body tracking setup.

    Mmm, actually think I have a workable solution already, i'll mount up a test tonight and do a video about it.

  32. #992
    0
    Awesome Plugin. I've watched all of your videos, huge fan, but I cant for the life of me figure out how to get it to work. I've downloaded the files and I've updated everything on my UE4.14. Anyone have a video tutorial about the download process?

    Side Note: I'm a 3D designer that's just starting in UE4 so my coding background is not as robust as many of the people on the forums; I'm thinking that's why I'm having such a hard time just launching the project. A Video or Screenshots would be super helpful to get me started.

    Thanks,
    -Sketch

  33. #993
    0
    Yeah, here is a video featuring "some" of the new stuff (whatever I could remember at the time) and the waist tracking I added in today.


  34. #994
    0
    Quote Originally Posted by mordentral View Post
    Mmm, actually think I have a workable solution already, i'll mount up a test tonight and do a video about it.
    Awesome! Thanks for the video, and the update looks super helpful. Is that already released? Capsule movement off of pelvis would be amazing. Then I can remove my hacks altogether.

    One thing I was wondering... I'm finding that with 5 trackers per player, plus controllers, it's starting to be quite a bit to replicate, and I was wondering if it would be possible to add an option to the components to quantize the transforms for the trackers/controllers to reduce the replicated data. Before switching to your plugin, I was quantizing the transforms for replication and it made a pretty big impact, but even with that, I find your plugin replication (w/o quantizing) faster than the blueprint replication.
    Last edited by alltrueist; 04-22-2017 at 06:37 AM.

  35. #995
    0
    The plugin already quantizes the vectors and compresses the rotations to shorts prior to replication. However I did go in yesterday to clean it up a bit and set it up so the quantization level could be configurable instead of just whatever default I use. I have it defaulted to 100/2 decimals of accuracy and 10/1 should be enough for mm level accuracy. Technically with only replicating the relative pos within the tracked space I can also provide an extreme mode that reduces it even farther.

    Also there is a replication speed setting on all of the plugin replicated objects that you can reduce below the default 100 htz (at 90 fps this will trigger every frame) there is naive smoothing that you can turn on that will lerp in between updates at lower htz settings. The smoothing needs rate balancing and some additional checks but since you are working with so much data I guess now would be a good time to take a look at that again.

  36. #996
    0
    Hi Mordentral

    Thanks for the update and appreciate your hard work. Need a small help with opening drawers. Since i am not a blue print expert i am using your template and replacing the mesh in your blueprint class the achieve the same effect. but when i run in HTC as soon as i grab the drawer it updates to the previous position of the drawer. How can i change this.

    Thanks in Advance

    regards
    J

  37. #997
    0
    Quote Originally Posted by Jomax3d View Post
    Hi Mordentral

    Thanks for the update and appreciate your hard work. Need a small help with opening drawers. Since i am not a blue print expert i am using your template and replacing the mesh in your blueprint class the achieve the same effect. but when i run in HTC as soon as i grab the drawer it updates to the previous position of the drawer. How can i change this.

    Thanks in Advance

    regards
    J
    In the interaction settings for the drawer component you need to change the Initial location and min / max location values. That is how the non physics drawers know when and where to start / stop movement.

    If you changed the mesh and location it will have the wrong settings for those.

  38. #998
    0
    What is the best way to lean over a table to pick something up? Currently the table collision is preventing me from leaning over.

  39. #999
    0
    Quote Originally Posted by Link_AJ View Post
    What is the best way to lean over a table to pick something up? Currently the table collision is preventing me from leaning over.
    Several options

    1. WalkingOverride on the table and handle how much depth you want before pushing them back out or however you want to deal with it.

    2. Inset player collision on tables

    3. Don't run player collision at all on tables, there really isn't a point to it, if you want to stand on them then the floor finding still works with the walking collision override.

    4. Waist tracker.....least useful method as it depends on additional hardware (but has best results obviously)


    Tables aren't exactly a "solvable" issue collision wise with HMD + Hands, a lot of people are letting freewalk though things like tables and then teleporting the player out if the overlap goes over a set distance (with warning), but that only works for leaning if the player chooses to lean, they are free to just walk into the object to the extent you set anyway, so at that point why even bother with the faked lean mechanic and not just turn off table collision with the player?

    Just like all gamedev, VR is currently a series of hacks and tradeoffs to get what you want.

  40. #1000
    0
    Thanks for the idea's, yeah it's all about finding the right way to fake the desired effect. I think I'll just disable the collision for the player on the table.

Page 25 of 26 FirstFirst ... 1523242526 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •