Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    Originally posted by mordentral View Post

    Remove all of your intermediate folders, regenerate project files, and re-build first, its an issue with a generated header file and those get re-generated when you do that.
    Thanks, it worked!

    Comment


      Originally posted by mordentral View Post

      Try with a default motion controller, though I do not think you will see any difference.
      I tried with default motion controller component like you suggested and was the same.

      While testing that though I noticed that it only happens on one particular map. Created a new level (and tested some of my other levels) and everything works correctly with my character, your vive character pawn and also with a blank child character of VRCharacter. Any clue what I can have done in my level for it to not be working? It's not a problem I can just create a new level, is only a test map anyway but curious what's causing it.

      Comment


        Originally posted by ctpeepee View Post

        I tried with default motion controller component like you suggested and was the same.

        While testing that though I noticed that it only happens on one particular map. Created a new level (and tested some of my other levels) and everything works correctly with my character, your vive character pawn and also with a blank child character of VRCharacter. Any clue what I can have done in my level for it to not be working? It's not a problem I can just create a new level, is only a test map anyway but curious what's causing it.
        No I actually have no idea, there isn't anything AFAIK that should be able to interfere with that.


        Consider supporting me on patreon

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

        Comment


          Originally posted by mordentral View Post

          No I actually have no idea, there isn't anything AFAIK that should be able to interfere with that.
          Was just searching in this thread for an answer to something else and came across the answer in this post. Sure enough the level I had the problem I was using a scene capture, and after disabling it the problem went away. Any idea why that is? I had noticed before that when the static mesh components weren't late updating correctly for me, in the scene capture things were locked together correctly.

          Comment


            Hi again. I previously had been using the button actor from the template on a map and noticed that some times the button could become out of sync between client/server. I'd assumed at the time it might not be configured properly to work in multiplayer as was only example. Have come back to it now and working with my own actor that has a VRButton component I have the same issue. If you happen to push the button in a certain way (quite easy to replicate if you just press the button lots of times from different angles) the hit can be registered on the server but not the client (and vice versa). Can acheive it with a vr pawn as well as an fps one.

            If I authority guard the OnButtonStateChanged event in blueprint I can ensure my code (changing colour of button eg) is always synced which is fine for a toggle return button but as the internal bButtonState is out of sync the toggle stay button doesn't work correctly. It seems to me its because the collision can sometimes only be considered a hit on either the server or client and as bButtonState is only replicated initially it can become out of sync. Or I'm doing something wrong of course!

            Comment


              Originally posted by ctpeepee View Post
              Hi again. I previously had been using the button actor from the template on a map and noticed that some times the button could become out of sync between client/server. I'd assumed at the time it might not be configured properly to work in multiplayer as was only example. Have come back to it now and working with my own actor that has a VRButton component I have the same issue. If you happen to push the button in a certain way (quite easy to replicate if you just press the button lots of times from different angles) the hit can be registered on the server but not the client (and vice versa). Can acheive it with a vr pawn as well as an fps one.

              If I authority guard the OnButtonStateChanged event in blueprint I can ensure my code (changing colour of button eg) is always synced which is fine for a toggle return button but as the internal bButtonState is out of sync the toggle stay button doesn't work correctly. It seems to me its because the collision can sometimes only be considered a hit on either the server or client and as bButtonState is only replicated initially it can become out of sync. Or I'm doing something wrong of course!
              You should never depend on collision being 1:1 on server / client (network data is compressed and rounded off to save bandwidth), choose one and run your events off of it. As far as the button syncing, currently it would be up to your to sync the button state when your chosen authority detects the change, that actually goes for all of the interactibles, I leave it up to the end user to choose a sync method, whether to automate this had been something I haven't made a solid choice on yet, its been at the back of my list to think about for some time now.

              You can SetButtonState to sync if you need too, normally for it to be perfect you actually wouldn't want anything but your chosen authority even running the button logic. So usually this would mean that you would want it server auth and not toggle-able on clients.

              If you want it server auth a decently quick fix would be to override the IsValidOverlap function and return false if not on an authority connection, and return parent if it is. Then sync button state when it changes and set the button to replicate position (or not).

              *Edit* I could see a use case for a CanSetState function or boolean that would allow the button to follow but not state change locally though.

              Originally posted by ctpeepee View Post

              Was just searching in this thread for an answer to something else and came across the answer in this post. Sure enough the level I had the problem I was using a scene capture, and after disabling it the problem went away. Any idea why that is? I had noticed before that when the static mesh components weren't late updating correctly for me, in the scene capture things were locked together correctly.
              I remember that being brought up recently as a newish issue, but I haven't actually had a scene capture do it for me.
              Last edited by mordentral; 05-27-2019, 07:19 PM.


              Consider supporting me on patreon

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

              Comment


                Originally posted by mordentral View Post
                *Edit* I could see a use case for a CanSetState function or boolean that would allow the button to follow but not state change locally though..
                Yeah. I've done it as you suggested for now but if wanted to keep the client authoritative collision and, hence, smoother movement (maybe more relevant for buttons with larger travel distance) it feels a bit strange letting the client change its state and then subsequently overruling it.

                Comment


                  Originally posted by ctpeepee View Post

                  Yeah. I've done it as you suggested for now but if wanted to keep the client authoritative collision and, hence, smoother movement (maybe more relevant for buttons with larger travel distance) it feels a bit strange letting the client change its state and then subsequently overruling it.
                  Per your request, though you will still get ping delay in the depress to the change, there isn't really a way to avoid that. Also this will only be live in 4.22+ since it uses a new function that they added in it, it was working fairly well on testing.

                  Keep in mind if you set it to "Change On Owner" where it uses the local owner of the interacting actor, you would have to set owner on the actor containing the button in order for it to be able to send out state changes to the server.



                  *Edit* though for a real setup like above it should be a rep-notify bool
                  Last edited by mordentral; 05-28-2019, 08:21 PM.


                  Consider supporting me on patreon

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

                  Comment


                    Hi Mordentral.
                    Super thankful for the amazing plugin. I have a question I've been searching this forum and haven't found the answer to, apologies if it has been asked already.
                    Using a full body mesh for the character and an IK solution (YuriNK's), it works surprisingly well. The only thing is there is the slightest delay with the motion controllers and the hands which seems normal for IK. I was wondering if there is a way to attach the grippable object to a socket on the character mesh's hand, instead of to the motion controller to get movement that seems true to your virtual hands. This would also be useful in not to scale characters that have really long arms, like embodying a giant octopus or something.

                    I've tried the transform offset, and detaching and attaching using event on grip in the actor BP, but it still is affected by the motion controller movement. Nothing works as well as just forgoing the grip system and attaching it to the body mesh, but I lose all your wonderful functionality.

                    Am I missing something, or do I just have to build a grip system from scratch.
                    Many thanks for your time. Oh and your OpenVR work is great. Thank you for knuckles support!

                    Comment


                      Originally posted by Dogū View Post
                      Hi Mordentral.
                      Super thankful for the amazing plugin. I have a question I've been searching this forum and haven't found the answer to, apologies if it has been asked already.
                      Using a full body mesh for the character and an IK solution (YuriNK's), it works surprisingly well. The only thing is there is the slightest delay with the motion controllers and the hands which seems normal for IK. I was wondering if there is a way to attach the grippable object to a socket on the character mesh's hand, instead of to the motion controller to get movement that seems true to your virtual hands. This would also be useful in not to scale characters that have really long arms, like embodying a giant octopus or something.

                      I've tried the transform offset, and detaching and attaching using event on grip in the actor BP, but it still is affected by the motion controller movement. Nothing works as well as just forgoing the grip system and attaching it to the body mesh, but I lose all your wonderful functionality.

                      Am I missing something, or do I just have to build a grip system from scratch.
                      Many thanks for your time. Oh and your OpenVR work is great. Thank you for knuckles support!
                      Yeah sure, from the controller SetPivotOverride on a scene component, you can attach that scene component to the socket that you wish for the grip to follow then. It treats the scene component as the root location of the motion controller then.

                      I start going over it here in this video: https://youtu.be/BwS9Fo1Ozb0?t=349

                      You also could set the controller to be used without tracking and attach the controller itself to the hand and have the hand follow the hard coordinates from the GetTrackedDevicePositionAndOrientation node (don't remember exact node name, its a default head mounted display library node).

                      *Edit* Come to think of it, if you are trying for what I think you are, just setting a tick pre-resiquite to the controllers for the skeletal mesh component that you run the IK in should just fix it for you as well, and keep you tracking to the object itself as long as you have late updates turned off.
                      Last edited by mordentral; 05-29-2019, 08:08 AM.


                      Consider supporting me on patreon

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

                      Comment


                        Hi . I downloaded your example project and it is fantastic . Can you please tell me how to change the default vive controllers to hands. I tried changing it in a few places and I am not succeeding.

                        Comment


                          Originally posted by InfamousDuke View Post
                          Hi . I downloaded your example project and it is fantastic . Can you please tell me how to change the default vive controllers to hands. I tried changing it in a few places and I am not succeeding.
                          In the character graph there is a big red box which contains steamVR specific code. Currently it is loading the hands there where it it has the comment "Load OpenVR Controller Models", just disconnect the timer call there and have it pass on without setting the timer.

                          I have a pull request in for the engine, which if it is ever actually merged will fix the built in controller loading and that will go away and it will just be the check box on the motion controller instead....but that has been sitting for quite some time now.


                          Consider supporting me on patreon

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

                          Comment


                            Originally posted by mordentral View Post

                            In the character graph there is a big red box which contains steamVR specific code. Currently it is loading the hands there where it it has the comment "Load OpenVR Controller Models", just disconnect the timer call there and have it pass on without setting the timer.

                            I have a pull request in for the engine, which if it is ever actually merged will fix the built in controller loading and that will go away and it will just be the check box on the motion controller instead....but that has been sitting for quite some time now.
                            i had wondered about the reason for this before. What's wrong with the display device model checkbox on the motion controller? Seems to work for me when I've used it.

                            Comment


                              Originally posted by ctpeepee View Post

                              i had wondered about the reason for this before. What's wrong with the display device model checkbox on the motion controller? Seems to work for me when I've used it.
                              It doesn't work correctly in packaged games, it uses a texture creation method that is Editor Only as well as using the wrong color format (red and blue channels are reversed), so even in editor the colors are wrong for things that aren't on the black/grey spectrum.


                              Consider supporting me on patreon

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

                              Comment


                                Originally posted by mordentral View Post

                                Yeah sure, from the controller SetPivotOverride on a scene component, you can attach that scene component to the socket that you wish for the grip to follow then. It treats the scene component as the root location of the motion controller then.

                                I start going over it here in this video: https://youtu.be/BwS9Fo1Ozb0?t=349

                                You also could set the controller to be used without tracking and attach the controller itself to the hand and have the hand follow the hard coordinates from the GetTrackedDevicePositionAndOrientation node (don't remember exact node name, its a default head mounted display library node).

                                *Edit* Come to think of it, if you are trying for what I think you are, just setting a tick pre-resiquite to the controllers for the skeletal mesh component that you run the IK in should just fix it for you as well, and keep you tracking to the object itself as long as you have late updates turned off.
                                I tried all three ways with mixed results.
                                SetPivotOverride helped a little but still a noticeable drag when hands are moving fast.
                                Deactivating tracking for the controllers was tricky as I kept getting a strange offset when attaching the controller to the hand on the character mesh, like 2 meters away so I couldn't tell if it worked but it was tracking.
                                Tick pre-resiquite seemed to do nothing, even with late hand updates turned off. Might just be the IK plugin or more likely my fault.

                                I might be thinking about it too hard, the results from set pivot override are probably good enough. Either way I like the functionality of the setpivotoverride method, so I'll probably roll with that for now until I give the reattaching the controllers another shot. Cheers

                                Comment

                                Working...
                                X