Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    VR Expansion Plugin

    VR Expansion Plugin

    *Updated: 10/107/2019*

    Click image for larger version

Name:	EpicMegaGrants_Badge_Dark_Small.png
Views:	117
Size:	37.7 KB
ID:	1697558

    Playable Template Demo
    Template Packaged Download

    Plugin Website:
    https://vreue4.com/

    Plugin Partial Features List:
    https://vreue4.com/features

    Documentation
    https://vreue4.com/documentation

    Website Hosted Patch Notes
    https://vreue4.com/patch-notes


    This plugin is intended to ease the creation of VR games/experiences in UE4. It is up to quite a few different additions now and has a fleshed out wiki to help ease into it (may be a version or two behind at times, I attempt to update it when I can, the template is generally the best informational tool). It is also intended to be compatible with multiplayer experiences without any direct changes from the end user, most of the relevant components / actors replicated themselves over the network with some customization included.

    It is fully Blueprint implemented but can be manually linked to and used in c++ if needed.

    Consider Supporting Me On Patreon

    Latest informational video


    Some Games In progress or released that currently use the plugin (These are just ones I know about)
    https://vreue4.com/games


    Plugin Pre-built Downloads
    https://vreue4.com/binaries


    Plugin Repository
    https://bitbucket.org/mordentral/vrexpansionplugin

    Plugin Example Template Repository
    https://bitbucket.org/mordentral/vrexppluginexample


    Open Input Module (Knuckles/ect until its a main part of the engine it will be a separate module)
    https://vreue4.com/ovri-howto


    Repository Installation articles By Community Member kusogaki77

    Basic Installation Step-By-Step


    Specific Commit Download Tutorial


    Pre-built binary useage

    Template Note:

    I would like to note by the way that everything currently in the template is an example of what I think is best practices (though maybe not implemented as well as I would for an actual game), not everyone is going to need the same set up and not everyone is going to need a full VRcharacter. Custom pawns that just use the motion controllers and camera / parent relative component would be useful to people that don't want gravity / collision. It also has to give examples of far more things than an average game is likely to use, so there WILL be refactoring involved if it is used as a base for one (input bindings for one).

    Latest Patch notes:

    https://vreue4.com/4-24-patch-notes
    Last edited by mordentral; 12-12-2019, 09:57 AM.


    Consider supporting me on patreon

    My Open source tools and plugins
    Advanced Sessions Plugin
    VR Expansion Plugin

    #2
    Fantastic! That replication is going to make life so much easier for me.
    Gonna have to download it and give it a try!

    Comment


      #3
      Awesome work, this looks great!

      [MENTION=4285]mordentral[/MENTION] - If I wanted to use Mitch's template for the pickup system, do you think I'd be able to just replace the Attach calls with your Grip function (e.g., would replication still work there?)? I found the system in the SteamVR template that uses the GripMC to be a little cryptic in terms of being able to easily extend it and implement different sorts of items.

      ---------

      As an aside, I still think it would be beneficial to change how the Lock to HMD functionality works so that it would move the *actor* itself, rather than just components attached to the camera. I looked into it and it seems like that could be done by just recalculating the camera's matrix relative to the new actor matrix and then setting it on the actor where it currently does the component-move.

      I still think only moving the components could eventually cause gameplay problems (especially in cases of larger levels, multiplayer etc.), and have seen a few posts to that effect.
      Last edited by n00854180t; 07-12-2016, 06:56 PM.
      Storyteller - An immersive VR audiobook player

      Dungeon Survival - WIP First person dungeon crawler with a focus on survival and environmental gameplay ala roguelikes

      Comment


        #4
        Originally posted by n00854180t View Post
        Awesome work, this looks great!

        [MENTION=4285]mordentral[/MENTION] - If I wanted to use Mitch's template for the pickup system, do you think I'd be able to just replace the Attach calls with your Grip function (e.g., would replication still work there?)? I found the system in the SteamVR template that uses the GripMC to be a little cryptic in terms of being able to easily extend it and implement different sorts of items.
        Yeah it shouldn't be a problem, you'd have to keep in mind that Mitch's examples use attached simulating components with max Damping to keep them relative to the controller (if interactive), this plugin uses the sweeping functions to move items manually relative to the controller instead (and sends their components to the late update function). So there would have to be "some" changes, the plugin forces simulation off when gripping an actor so a bunch of nodes could / should be skipped from his example if using the grip function. I was considering implementing AttachTo as well as an option but after playing with it I didn't like how it worked so I scrapped my plans to support it.

        In my demo project I run all of the "Character has this in his left/right hand, drop this if he picks up that, ect ect" logic in BP and just call Grip/Drop in the plugin on what I decided to do from the server. It is game logic agnostic and just handles holding and dropping and triggering OnHit events.

        The steamVR template is very WIP and I get the idea that proteus is lacking in free time at the moment. The basics of gripping an object with my plugin is fairly simple, there is a write up on the motion controller wiki page with the basics and some best practices. I would have used Epics "World/Relative/Snap" enum like in attachment but passing in actual transforms has more total flexibility.

        wiki/VRGrippableMotionController

        *Note* Attachment is already replicated by default in the engine, when you attach a component it turns off replicating movement from the server and the clients handle it from then on out (until detached). That is one of the reasons why it doesn't sweep hit events on attached actors. You don't actually have to use the grip functions at all if you don't want to, they are just my preferred way of doing it.

        I may add back in having the server manually sweep actors attached to the controllers so that OnHit events still trigger, it was originally something I had it doing but removed it when I went over to only using the grip functions.

        Originally posted by n00854180t View Post
        ---------
        As an aside, I still think it would be beneficial to change how the Lock to HMD functionality works so that it would move the *actor* itself, rather than just components attached to the camera. I looked into it and it seems like that could be done by just recalculating the camera's matrix relative to the new actor matrix and then setting it on the actor where it currently does the component-move.

        I still think only moving the components could eventually cause gameplay problems (especially in cases of larger levels, multiplayer etc.), and have seen a few posts to that effect.
        It wouldn't be that difficult to create a custom pawn that samples the HMD position instead of the camera and offsets its location by the difference from the last sample point.

        The thing is that OpenVR returns the HMD location in relative space to the tracking volume you have set up so using the camera in relative space to the chaperone in the engine is a very clean solution to it as the pawn can act as the tracking space (that you move with teleport / other movement inputs) and the components as the relative location within that tracking space, you are essentially moving around the tracking volume with you.

        Do you have any quotes/links about the concerns? As I said it wouldn't be hard to implement I just don't see the point in doing so, but I would like to read about any issues that the current method presents as if they are significant enough I would have to reconsider LockToHMD. I haven't been able to think of anything that would be a problem for me so far and also haven't run into any issues with the default setup. You aren't moving component farther from the pawn itself than the size of the tracking volume in the default setup.
        Last edited by mordentral; 07-12-2016, 09:45 PM.


        Consider supporting me on patreon

        My Open source tools and plugins
        Advanced Sessions Plugin
        VR Expansion Plugin

        Comment


          #5
          Originally posted by lambomang View Post
          Fantastic! That replication is going to make life so much easier for me.
          Gonna have to download it and give it a try!
          I'm looking into smoothing replication at lower update rates by the way. I'll need to test of bunch of different rates and try some lerp/prediction tests to see what feels best and where it actually becomes a problem first. The default 100htz (matching pawn default) rate didn't need any smoothing that I could see so I left it out to get it out the door but I could see needing to add it in for 30htz or so (though it is only a per client network load and isn't that heavy).


          Consider supporting me on patreon

          My Open source tools and plugins
          Advanced Sessions Plugin
          VR Expansion Plugin

          Comment


            #6
            Hey Mordentral. Thanks for putting in the effort to make this awesome plugin! It really helps with jumping straight into VR and building stuff. I've been using your VRGrip plugin for about a month now. It helped a lot, but I have run into some issues.

            Migrating to VR Expansion Plugin
            I'm interested in migrating from your old plugin to this one, but I'm seeing some issues trying to rip out the old one and replace it with this one. I wonder if there's something simple I'm missing. Depending on how many people used your other plugin, it might be helpful to add a How-To to the readme.

            Collision Event Bug.
            I have a SphereCollision component parented under the grip controller. I'm using the begin/end overlap events on this collision to determine which object I can pick up. I'm noticing that when the grip controller is holding an object then BOTH overlap begin and end events are triggered on every tick. The events are only triggered on the colliders close to the object, but they are triggered on every tick regardless of which controller is holding the object. That is to say, if I hold an object in my right hand, then my right collider is triggered on every tick. Then if I bring my left hand close enough to my right hand, that collider is also being triggered on ever tick - even though the right hand is holding the object.

            This rapid-fire of begin/end overlap events is causing incorrect results when I poll which objects I can pickup. If I had to guess, I'd say something about the way the plugin is updating the gripped object position is causing collision events to freak out. I noticed the wiki suggests that I use a sphere trace instead of overlap events - probably for this reason. I'll use the sphere trace for now, but performing a sphere trace every tick is probably more expensive than using overlap events.


            Better Physics Behavior
            Have you read Nick Abel's article and TomorrowTodayLabs' followup on how they solved physics-based object movement in unity? It's a really interesting read, and they put their work up as a plugin for Unity called NewtonVR. Here's a sweet video from the article of the final interaction they achieved:




            Obviously their solution won't be ideal for everyone, but I do think they address a number of areas that the sweep-to method falls short in. Namely...

            Objects get caught on floor easily.



            You can't pick up objects with another object on top.



            You can't push/pull objects, and objects have no mass.



            What do you think about trying to port some of their ideas to UE4?

            Comment


              #7
              Originally posted by AssumptionSoup View Post
              Hey Mordentral.

              Migration
              Being a new plugin the classes technically are considered separate from their old versions, you actually have to place them back into the pawn and re-place their functions. I decided to rename it as the old name no longer suited the project but this is a sad consequence being a one time hit of placing the nodes again.

              Overlap Triggering
              I set move ignore to the controller when gripping an object, it is possible that overlap is triggering anyway as the current movement is swept location. You can either not use overlaps or set it to ignore the channel you place the overlap on after gripping (I have a special collision channel for traces / overlaps). I also don't call traces every frame, I call it on button press, but if you are looking to highlight objects to pick up I see your point. But you can always run traces on a timer set to 30-60 htz for highlighting and call the trace on button press for the actual pick up (my voxel project does this for block highlights).

              Push / Pull
              Yes you actually can, the object has to be simulating though for it to move it, i'll agree that the interaction is less than steller currently and I am going to provide a better option for real physics. The current grip is intended just for when you don't need full physics solving on the gripped object itself as it will be cheaper. It was also the fastest one out of the gate to implement so I could look at other things.

              New Grip Styles
              I fully intend to make a better grip option using physics, I originally had AttachTo set up and ran into it not being up to what I wanted from it and removed it from the grip function. Unity's solution is effectually what I am currently doing with location but done through the physics system instead so it actually slots right in. It is next on my Trello list actually to look into it now that I have decided to throw away AttachTo (spent my free time in the last day mulling over if AttachTo was worth it and trying it out).

              I don't like the visual drag latency in how they are doing it in Unity though and am pretty sure that there is a way around it by extending my current solution and using constraints (ripping from grab handles but forcing late updates and removing the lerp). I really like the interaction in say Hand Guns, Horseshoes, and Hand Grenades but don't like that the guns themselves lag behind hand movements visually (for actual shooting location they are correct so there is something to be said for that).


              TL;DR yes all of those things bug me as well and as a user of my own plugin I am fixing them. I'll move experiments to the side for now (was playing with movement options) and just implement the new grip option instead.

              The cool thing about the plugin is when the new grip is in you'll just have to select it from the grip style drop down and it should work.


              *Edit* Oh and I was looking into both hands on the same object interactions. Eventually both options should support that as well; but I will wayside it until the new grip is in too.
              Last edited by mordentral; 07-14-2016, 08:59 AM.


              Consider supporting me on patreon

              My Open source tools and plugins
              Advanced Sessions Plugin
              VR Expansion Plugin

              Comment


                #8
                Originally posted by AssumptionSoup View Post
                Hey Mordentral.
                I actually had this done yesterday but got side tracked trying to make a hybrid system (not sure how stable I can get that one yet). It needs some going over to make sure that multiplayer works fine with the new grip style before I merge it in but I think the video is pretty much what you wanted.

                Its up to 5 grip methods now I think (6 with hybrid if it makes it), you pick what one you want per item you are picking up and how you want it to behave. When it comes out this method will have several configurable options (you probably don't notice in the video but I have the grip strength 1000x higher on my right hand than my left so it doesn't free float as much in the video).

                I'll get it pushed out to the main branch of the plugin by the end of the weekend, I was off on a tangent for awhile there experimenting with a bunch of random things (VR gets me excited) or this would have already been in.

                Cheers



                Consider supporting me on patreon

                My Open source tools and plugins
                Advanced Sessions Plugin
                VR Expansion Plugin

                Comment


                  #9
                  Migration
                  Being a new plugin the classes technically are considered separate from their old versions, you actually have to place them back into the pawn and re-place their functions. I decided to rename it as the old name no longer suited the project but this is a sad consequence being a one time hit of placing the nodes again.
                  Thanks for the help. As it turns out, I had to delete the original VRGrip components before deleting the plugin, or my game would crash on load. After deleting the components, it was okay if I still had any variables with the VRGrip type (they got reset to Object). Then I just had to put the new plugin in place and run around reconnecting everything (that was less fun). Next time around, I think I'll integrate the plugin with my game via C++ so it's easier to refactor things. Blueprints makes refactors surprisingly hard with it's propensity to disconnect nodes! And speaking of C++, I don't know if you intended the plugin to be using in C++ or not. I'm definitely a noob at both C++ and Unreal, but it looks like the plugin classes are missing the VREXPANSIONPLUGIN_API (macro? keyword?) in order to be exposed to game logic. I can send a pull request that adds this if you're interested.

                  Overlap Triggering
                  I set move ignore to the controller when gripping an object, it is possible that overlap is triggering anyway as the current movement is swept location. You can either not use overlaps or set it to ignore the channel you place the overlap on after gripping (I have a special collision channel for traces / overlaps). I also don't call traces every frame, I call it on button press, but if you are looking to highlight objects to pick up I see your point. But you can always run traces on a timer set to 30-60 htz for highlighting and call the trace on button press for the actual pick up (my voxel project does this for block highlights).
                  You're correct, I'm using it for highlighting. I forgot to mention that in my original post. I'll have to play around with running my traces on a slower frequency, that's a good idea! I'm a little worried that there will be a disconnect between the feedback the user sees and the action that occurs - but I won't know how bad it is without testing.

                  I don't like the visual drag latency in how they are doing it in Unity though and am pretty sure that there is a way around it by extending my current solution and using constraints (ripping from grab handles but forcing late updates and removing the lerp). I really like the interaction in say Hand Guns, Horseshoes, and Hand Grenades but don't like that the guns themselves lag behind hand movements visually (for actual shooting location they are correct so there is something to be said for that).
                  I totally agree. I think having really good physics interaction is worth the trade off of having some latency on gripped objects, but it's definitely not a compromise I'd like to make if I don't have to.


                  I actually had this done yesterday but got side tracked trying to make a hybrid system ...
                  Oh man, this looks super awesome!! Yeah, it looks like most of the things I was interested in. I can't wait!

                  Comment


                    #10
                    Yeah I forgot the macro on the classes, I'll add it in to them today.


                    Consider supporting me on patreon

                    My Open source tools and plugins
                    Advanced Sessions Plugin
                    VR Expansion Plugin

                    Comment


                      #11
                      Merged the physics grip branch into main, it needs more play time to lock down bugs but was working for me during initial multiplayer testing (don't forget to replicate movement on physics objects so they stay sync'd). The hybrid setup "works" but needs to be finished still.


                      InteractivePhysicsGrip is the style you were looking for, it also adds two properties to the motion controllers for Stiffness and Damping when holding physics simulating objects, I may break that out into a object by object basis later.

                      There are also a few new functions and features, i'll document them tomorrow.
                      Last edited by mordentral; 07-17-2016, 10:38 PM.


                      Consider supporting me on patreon

                      My Open source tools and plugins
                      Advanced Sessions Plugin
                      VR Expansion Plugin

                      Comment


                        #12
                        Would any of the exposed OpenVR functions be able to return what kind of HMD is in use? Rift/Vive/OSVR. I need to change player class since the haptic events are very different on Vive vs Rift.

                        Comment


                          #13
                          Originally posted by Fantasifall View Post
                          Would any of the exposed OpenVR functions be able to return what kind of HMD is in use? Rift/Vive/OSVR. I need to change player class since the haptic events are very different on Vive vs Rift.
                          I think someone requested of Rama to have his library include that function. It is already in GEngine so I will throw it in anyway since it makes sense and is easy, but if you don't intend to use the rest of my plugin and already use Rama's library then you should be able to find it there.

                          Regardless I'll have it in this by the end of the day (have to push out some cleanup for things anyway later).


                          *Edit* Pushed the new function early as the rest of my work today will be on a new branch

                          GetHMDType - static
                          Last edited by mordentral; 07-18-2016, 11:49 AM.


                          Consider supporting me on patreon

                          My Open source tools and plugins
                          Advanced Sessions Plugin
                          VR Expansion Plugin

                          Comment


                            #14
                            Oh my, this Plugin couldn't have come at a better time. Literally just spent this last weekend testing my Vive game with some friends, and one of the biggest issues was the grabbing system I had made. My solution, using merely the built in blueprint functions was to turn off gravity on grabbed components. This wasn't the ideal solution but it worked for the most part. That said it seems this plugin gives far better control and I hope to implement it.

                            Could you by chance give some insight into the setup of the "New grip style" video? I've got a line trace on the controller trigger, then checking my grabbed object and then calling grip actor from your plugin, but it seems to go a bit crazy once attached. Will have a further tinker, but this does look promising. Great work!
                            Portfolio

                            Default Interactive

                            A Skip And A Hop Too Far Into Light Speed

                            Comment


                              #15
                              Thank you so much for the HMD type! This makes my life so much easier. However, ParentRelativeAttachmentComponent does not seem to work at all. I looked at the code and it seems like it should but all that's happening is occasionally, there will be an offset of the child component of the ParentRelativeAttachmentComponent. It just sticks at an odd rotation, and keeps following the HMD rot at that offset rotation 1 to 1. I tried with both Static and Skeletal meshes, and tried yaw values between 1-3 as well as much higher, locked on pitch and roll.

                              Comment

                              Working...
                              X