Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    Originally posted by cpenny20 View Post
    Hey Mord, thank you for your reply. We very much appreciate you helping us out with that legacy mode. Forgive me for not being up to date on this all as I know you were having this same conversation with him and also others in the discord - but as I understand it my dev partner was unknowingly exploiting a bug to lock the slides or bolts back. Is there currently a better way we should be doing this, or if not, are you introducing this capability soon? From what he tells me I think we will attempt to correct all the math and do it all the right way once we have a solid way of doing this.
    He could have just set the current position as the new base and locked min/max.

    But I'll be adding a cleaner direct lock soon yes. Also I believe that it was mentioned to him that gun slides are actually easier to script with the interactible library functions rather than trying to hack around the slider itself.


    Consider supporting me on patreon

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

    Comment


      Hello Mordentral, am trying to import a skeletal hand mesh to be used instead of the mannequin's skeletal mesh for PhysicsHands with Curl. Up until now everything is fine but, i got to the point where i simply cannot understand how the earth you 've done the physics asset for the hand! You got simple convex collisions, but it seems to my knowledge impossible to transfer those to the root bone!

      So i tried adding capsule shapes as it's quite close to the what i need for a humanoid hand. Now i see that capsule although the naming is correct ( index_01,02 etc ) and location/rotation, i get offsets while testing inengine :-(

      The Rootbone capsule for hand/palm collision seems to be the only one working as it should, but fingers get strange offsets. Maybe this has to do with the location of the rootbone?

      Thank you!

      EDIT : ok i couldnt find how you did it, but i've imported UCX for the hand on a static mesh and imported them for the root bone. My offset issue was caused on grasping hand bp, when it sets welded bone driver, also removing it seemed to fix the physics hand jittering on grabed objects. In case anyone had that issue here it is :-)
      Last edited by GRADgr; 08-10-2020, 11:39 AM.

      Comment


        Originally posted by mordentral View Post

        mmm, yeah that script was sampling the gripped object for its initial transform, i'll make it check by bone too if one is referenced in the grip information.

        It will be up in the repo release in a couple of minutes, need to test it.

        *Edit* its live, let me know how it performs for you.

        Also you don't need the default grip script specifically added to an object unless you want something else to run first (usually not the case since default also overrides the grip transform).

        I applied the latest version code and tested it. We confirmed that the gripped bone name and transform are returned well. However, as a result, lerp to hand did not work normally. As a result of checking with the "vr.DrawDebugCenterOfMassForGrips" command, even though lerp to hand was executed, the lerp start point was seen as a motion controller. And when you override ClosestGripSlotInRange and forcefully perform slot grip with "neck_01" transform, bone grip does not work.


        I think the reason why Lerp to hand didn't work properly is because GetGripSlotInRangeByTypeName function doesn't respond to bone grips. To bone grips with current logics, it must not necessarily be slot grips. When the slot grips come over to true, the bone grips do not work.

        When bone gripping, it must be initialized with newComponentGrip.RelativeTransform = FTransform::Identify to operate normally. But as a result, the result that I want to get is bone grips through slot grips. If the slot is found correctly, but COM is Slot, the bone will not be handling. Can you give me some advice?
        Last edited by CokeKuma; 08-10-2020, 06:09 AM.

        Comment


          I'm really sorry for this super basic question but am at a total loss.

          Problem: on a gun, when grabbing with second hand, primary hand is forced to drop.
          The BP is a child of a Master BP (altered version of the gun from the sample project).
          I have several OTHER guns as child blueprints that use the exact same Master and work fine with the secondary grip, so it's oddly unique to this one child BP.
          The mesh has a socket VRGripP1 and VRGripS1, just like the other guns do
          Differences... this gun has a lever attached, others have a slider. This Secondary socket is also a lot farther forwards?

          Where could it be calling to drop the primary grip for this one particular BP?
          Thanks in advance!

          Comment


            So i'm playing around with the plugin for my project and i've migrated the example character over to my project. I've also tried using the button actor that came with the example, when ever I push the button down my fps drops to 15 for some reason while in the example it was fine. Any ideas what could be causing this?

            Comment


              Originally posted by CokeKuma View Post


              I applied the latest version code and tested it. We confirmed that the gripped bone name and transform are returned well. However, as a result, lerp to hand did not work normally. As a result of checking with the "vr.DrawDebugCenterOfMassForGrips" command, even though lerp to hand was executed, the lerp start point was seen as a motion controller. And when you override ClosestGripSlotInRange and forcefully perform slot grip with "neck_01" transform, bone grip does not work.


              I think the reason why Lerp to hand didn't work properly is because GetGripSlotInRangeByTypeName function doesn't respond to bone grips. To bone grips with current logics, it must not necessarily be slot grips. When the slot grips come over to true, the bone grips do not work.

              When bone gripping, it must be initialized with newComponentGrip.RelativeTransform = FTransform::Identify to operate normally. But as a result, the result that I want to get is bone grips through slot grips. If the slot is found correctly, but COM is Slot, the bone will not be handling. Can you give me some advice?
              No, slots have nothing to do with it, they are just stored relative transforms that get decomposed and passed in to the plugin. You just need to make sure that the relative transform being used for the slot calculation is relative to the bone, and not to the mesh itself, that may be an oversite in the BP side of the template ( need to check) as I never specifically tested slots on per bone gripping. Should be easy enough to override and I could modify it in 4.25+ to handle it correctly.

              You passing out a neck bone name as the slot just makes it use the location of that bone as the slot.

              Slots have no logical effect on the gripping in the plugin (outside of a true/false in the melee script), they are a construct on the users end. The optional snap socket is a helper utility that I actually tend to suggest that people not use in favor of manually passing it in, as its more fully controlled on the users end when they pass it in.

              *Edit*
              Yeah it just needed a couple of node changes:

              https://i.imgur.com/2wtND8U.png - Using the correct world transform with slots

              https://i.imgur.com/1tKtaPZ.png - Changing it to pass out the bone name with slots as well.

              those changes are live in a new template commit.
              Last edited by mordentral; 08-10-2020, 09:01 AM.


              Consider supporting me on patreon

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

              Comment


                Originally posted by joelbenjamin View Post
                I'm really sorry for this super basic question but am at a total loss.

                Problem: on a gun, when grabbing with second hand, primary hand is forced to drop.
                The BP is a child of a Master BP (altered version of the gun from the sample project).
                I have several OTHER guns as child blueprints that use the exact same Master and work fine with the secondary grip, so it's oddly unique to this one child BP.
                The mesh has a socket VRGripP1 and VRGripS1, just like the other guns do
                Differences... this gun has a lever attached, others have a slider. This Secondary socket is also a lot farther forwards?

                Where could it be calling to drop the primary grip for this one particular BP?
                Thanks in advance!
                The template guns default behavior is to auto switch hands if the is no secondary slot in range when gripping with another hand, sounds like your secondary socket is out of the range setting for secondary hands when you go to grip it.


                Consider supporting me on patreon

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

                Comment


                  Originally posted by mordentral View Post

                  The template guns default behavior is to auto switch hands if the is no secondary slot in range when gripping with another hand, sounds like your secondary socket is out of the range setting for secondary hands when you go to grip it.
                  I don't THINK that's what's happening -- should have mentioned that it appears to grip the secondary properly, just that it simultaneously drops the primary.
                  Made a quick video
                  (You can see I tested the Secondary slot range settings to make sure it wasn't that)

                  Comment


                    Originally posted by joelbenjamin View Post

                    I don't THINK that's what's happening -- should have mentioned that it appears to grip the secondary properly, just that it simultaneously drops the primary.
                    Made a quick video
                    (You can see I tested the Secondary slot range settings to make sure it wasn't that)
                    Secondary attachments are not full grips, they are modifiers to the primary grip, so it can't actually exist without the primary grip still being active.

                    That being said the template gun does have the option of gripping the front fully when the rear releases, but that shouldn't be what is going on in your video, that should be the hands swapping.

                    The default gun doesn't use the "multi grip" settings where both hands get full grips at once.


                    Consider supporting me on patreon

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

                    Comment


                      Originally posted by blade32232 View Post
                      So i'm playing around with the plugin for my project and i've migrated the example character over to my project. I've also tried using the button actor that came with the example, when ever I push the button down my fps drops to 15 for some reason while in the example it was fine. Any ideas what could be causing this?
                      Do you have a ton of overlapping components on your hand or something? Or have it controlling a scene capture?

                      There is no button specific reason it would do 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

                        Secondary attachments are not full grips, they are modifiers to the primary grip, so it can't actually exist without the primary grip still being active.

                        That being said the template gun does have the option of gripping the front fully when the rear releases, but that shouldn't be what is going on in your video, that should be the hands swapping.

                        The default gun doesn't use the "multi grip" settings where both hands get full grips at once.
                        I duplicated one of the other BP children that worked, rebuilt it from there and it works.
                        I compared the two BPs (new working vs non working) and can't see any difference, so I'm not sure what I did wrong the first time around.
                        Thanks again

                        Comment


                          Originally posted by mordentral View Post

                          Do you have a ton of overlapping components on your hand or something? Or have it controlling a scene capture?

                          There is no button specific reason it would do that.
                          The hands are the exact same as the physical hands in the example. and even when the button is disconnected from the action I want, it seems to happen when the button bottoms out and the collision on the hand continues into the button. I'll post a video as soon as I can on the issue.

                          Comment


                            Hi again,
                            i have a question concerning multiplayer testing. I am trying to find a way so that i can test multiplayer stuff from within the editor and so that one editor instance uses the HMD while the second instance uses the FPS pawn. Currently - using the template as a starting point - when i choose VR preview in editor and then start a 2-player / listen-server setup both instances seem to spawn the HMD pawn. So i tried to force one of the instances (e.g. the server one) into always using the HMD while the other is forced to use the FPS pawn. Currently i am trying to use the Steam_VR_Player_Controller for that. I am trying to hook into this spot:

                            Click image for larger version

Name:	playercontroller.jpg
Views:	119
Size:	309.9 KB
ID:	1799396 So one thing i tried was to use the isServer node so that i would branch of to the FPS pawn in case isServer was true. However no matter what i do the result is either both instances running the FPS pawn or both instances running the HMD pawn. Would it be possible to achieve what i want anyways? Is this the right spot to look into? Any hints are greatly appreciated.
                            Cheers

                            Attached Files

                            Comment


                              Originally posted by Qianfulong View Post
                              Hi again,
                              i have a question concerning multiplayer testing. I am trying to find a way so that i can test multiplayer stuff from within the editor and so that one editor instance uses the HMD while the second instance uses the FPS pawn. Currently - using the template as a starting point - when i choose VR preview in editor and then start a 2-player / listen-server setup both instances seem to spawn the HMD pawn. So i tried to force one of the instances (e.g. the server one) into always using the HMD while the other is forced to use the FPS pawn. Currently i am trying to use the Steam_VR_Player_Controller for that. I am trying to hook into this spot:
                              So one thing i tried was to use the isServer node so that i would branch of to the FPS pawn in case isServer was true. However no matter what i do the result is either both instances running the FPS pawn or both instances running the HMD pawn. Would it be possible to achieve what i want anyways? Is this the right spot to look into? Any hints are greatly appreciated.
                              Cheers
                              Run the previews as separate instances (there is an option for that), then yes you can check on authority and do vr or not.



                              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, slots have nothing to do with it, they are just stored relative transforms that get decomposed and passed in to the plugin. You just need to make sure that the relative transform being used for the slot calculation is relative to the bone, and not to the mesh itself, that may be an oversite in the BP side of the template ( need to check) as I never specifically tested slots on per bone gripping. Should be easy enough to override and I could modify it in 4.25+ to handle it correctly.

                                You passing out a neck bone name as the slot just makes it use the location of that bone as the slot.

                                Slots have no logical effect on the gripping in the plugin (outside of a true/false in the melee script), they are a construct on the users end. The optional snap socket is a helper utility that I actually tend to suggest that people not use in favor of manually passing it in, as its more fully controlled on the users end when they pass it in.

                                *Edit*
                                Yeah it just needed a couple of node changes:

                                https://i.imgur.com/2wtND8U.png - Using the correct world transform with slots

                                https://i.imgur.com/1tKtaPZ.png - Changing it to pass out the bone name with slots as well.

                                those changes are live in a new template commit.

                                Thanks for answering. Tested again based on the latest commit code. However, if you grip a bone outside the slot range, it will not work properly. And even when the bone slot grip is executed, there are times when the slot transform cannot be found properly. Did it work well when tested?

                                I think the approximate cause is known. The lower socket of neck_01 is found, but the nearest bone name may be head or spine_03 depending on the slot range. There are cases where the parent transform, which is the standard, is incorrectly set.
                                Last edited by CokeKuma; 08-11-2020, 01:10 AM.

                                Comment

                                Working...
                                X