Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    Originally posted by mordentral View Post

    Attach it to the ParentRelativeAttachment and set the ParentRelativeAttachment to "foot mode" which will place it on the floor before the HMD.
    Holy ****... it can't seriously be that easy. Thank you! I'm excited to get this working. I've been putting off "figuring out" roomscale and I think it's time. Where is this "foot mode" you mentioned?

    Comment


      Originally posted by Nostrildumbass View Post

      Holy ****... it can't seriously be that easy. Thank you! I'm excited to get this working. I've been putting off "figuring out" roomscale and I think it's time. Where is this "foot mode" you mentioned?
      On the parent relative attachment, most other things just work, with the difference that when calculating positions for things and such you should be using GetVRLocation / GetVRRotation as that is the offset position.


      Consider supporting me on patreon

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

      Comment


        Originally posted by mordentral View Post

        On the parent relative attachment, most other things just work, with the difference that when calculating positions for things and such you should be using GetVRLocation / GetVRRotation as that is the offset position.
        Got it working, truly amazing! I'm going to have to resort to using a different mesh for myself versus what other players will see like most games. I was trying to avoid having to do that but it seems to be the way to go. I'll be patronizing ASAP!

        Comment


          Originally posted by mordentral View Post

          Someone a few posts up made one just by copying the static mesh component and changing the base class. The issue is that the default slicing functions only generate the default procedural mesh components so they would have to be copied over to the new base class then.

          You can grip them normally with a Grip command, if you want more control than just the stiffness and damping though, in the latest releases, post the actual grip you can either call SetPhysicsHandleSettings to set an axis by axis stiffness / damping, or you can alter the grip structs advanced grip settings (set members) to choose the options that you want and then call UpdatePhysicsHandle to update the values (on the server if multiplayer, when it replicates down the changes the clients should auto update).

          That gives you full control over the grips physics settings without it being interfaced as it forces it to re-init to the new values.
          Thanks for your support! Unfortunately I've been playing with your suggestions for two days and I don't manage to get it to work properly..

          My main goal is to set up the grip as "Sweep with Physics", as well as to use the Grip Priority to filter between multiple overlapping objects.

          I have some questions on your input:

          Originally posted by mordentral View Post
          ​​​​​​
          Someone a few posts up made one just by copying the static mesh component and changing the base class.
          You mean duplicating it manually in the BP? Or creating a new component and setting up the attributes one by one?

          Originally posted by mordentral View Post
          ​​​​​​
          The issue is that the default slicing functions only generate the default procedural mesh components so they would have to be copied over to the new base class then.
          Yes exactly.. and as far as I can understand there is no way to copy over the ProcMesh (though the individual attributes 'Vertices', 'Triangles', etc) without losing the collision.. and there's no good way to dynamically create a high quality new collision.

          My best attempt so far is to spawn a second copy of the actor and to do the whole thing twice (destroying one ProcMesh component in each actor after the slice).. But it's not very efficient.

          Is a Grippable Procedural Mesh at all on the roadmap?

          Comment


            Originally posted by Warner V View Post

            Thanks for your support! Unfortunately I've been playing with your suggestions for two days and I don't manage to get it to work properly..

            My main goal is to set up the grip as "Sweep with Physics", as well as to use the Grip Priority to filter between multiple overlapping objects.

            I have some questions on your input:


            You mean duplicating it manually in the BP? Or creating a new component and setting up the attributes one by one?


            Yes exactly.. and as far as I can understand there is no way to copy over the ProcMesh (though the individual attributes 'Vertices', 'Triangles', etc) without losing the collision.. and there's no good way to dynamically create a high quality new collision.

            My best attempt so far is to spawn a second copy of the actor and to do the whole thing twice (destroying one ProcMesh component in each actor after the slice).. But it's not very efficient.

            Is a Grippable Procedural Mesh at all on the roadmap?
            He just copied my static mesh component class and changed the base class to a procedural mesh one (in c++). Then made it so after he slices something he copies the mesh from the proc mesh that it made to a new one of the grippable type and then deletes the original.

            I could easily make a grippable proc mesh class, the issues I had with it was I am not really willing to support the slicing part by deleting originals and copying the data to newly spawned copies, its unwieldy and overly complex (and inefficient), so I would have to then go and make a custom slicing function to handle slicing specifically grippable procedural meshes (wish they took a class type pointer instead for that function).

            At that point it is almost easier to contain the sliced components in seperate GrippableActors instead for ones that you want to pick up, and set the proc mesh to the root component.
            Last edited by mordentral; 07-10-2019, 04:39 PM.


            Consider supporting me on patreon

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

            Comment


              I'm going absolutely nutty here. I cannot grip anything. I'm using the motioncontrollermap from the template and all of the template items with a copied Vive_PawnCharacter - labelled VR_PawnCharacter.

              I walk over and try to grip anything, it always denies grip...I'm using the potion on the table as the tester with a bunch of print strings around now and it makes Absolutely zero sense:

              For the PotionActor on Event BeginPlay I've Set Deny Gripping to false for the potion mesh and stopped, then printstring for IsDenyGrips for the actor, potionmesh and stopper, as well as used the interface and the message for actor, potionmesh and stopper --- the printstring reports IsDenyingGrips is false for every one of these:

              LogBlueprintUserMessages: [PotionActor_620] Potion is denying grips: falsefalsefalsefalsefalsefalsefalse

              I also added printstrings in ShouldGripComponent functions and SelectObjectfromHitArray printing out the Object Hit: and the Should Grip: from after Should Grip Component function runs.

              in ShouldGripComponent I added printstring statements after relevant parts.... see log:

              LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Does not implement interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Component Owning Actor Implements Interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Trigger Grip
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Implements interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Object Hit: PotionActor_620.PotionMesh Potion Should Grip: false
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Does not implement interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Component Owning Actor Implements Interface
              LogBlueprintUserMessages: [VR_PawnCharacter_2] Is Valid To Grip? False

              How the heck is it possible that after checking isdenyinggrips in the potion actor when triggered by the hand it's returning a true from the interface!? (I've checked class defaults for VRGrip Interface and the interface function in the actor too.)



              Comment


                Originally posted by zSwitchz View Post
                I'm going absolutely nutty here. I cannot grip anything. I'm using the motioncontrollermap from the template and all of the template items with a copied Vive_PawnCharacter - labelled VR_PawnCharacter.

                I walk over and try to grip anything, it always denies grip...I'm using the potion on the table as the tester with a bunch of print strings around now and it makes Absolutely zero sense:

                For the PotionActor on Event BeginPlay I've Set Deny Gripping to false for the potion mesh and stopped, then printstring for IsDenyGrips for the actor, potionmesh and stopper, as well as used the interface and the message for actor, potionmesh and stopper --- the printstring reports IsDenyingGrips is false for every one of these:

                LogBlueprintUserMessages: [PotionActor_620] Potion is denying grips: falsefalsefalsefalsefalsefalsefalse

                I also added printstrings in ShouldGripComponent functions and SelectObjectfromHitArray printing out the Object Hit: and the Should Grip: from after Should Grip Component function runs.

                in ShouldGripComponent I added printstring statements after relevant parts.... see log:
                Sounds like you migrated parts of the example template to a different project? The example template is overly featured in order to make a good test bed (its my primary test ground) and to show a bunch of different interactions, its not exactly the best thing to migrate. What you likely ran into is that you didn't port the gameplaytags that it uses to run the templates gripping off of, both are defined in the config files.

                I generally don't suggest that a game from the ground up use the gameplay tags, you generally don't need to switch what button does what on a per object bases. However if you want them you can import the datatable that defines them, set it as your gameplay tag table in editor (or also transfer the config file that sets it) and make sure that the GripDropOrUse_Clean functions have the tags that they are likely now missing (or re-import that part after importing the tags).


                Consider supporting me on patreon

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

                Comment


                  Originally posted by mordentral View Post

                  Sounds like you migrated parts of the example template to a different project? The example template is overly featured in order to make a good test bed (its my primary test ground) and to show a bunch of different interactions, its not exactly the best thing to migrate. What you likely ran into is that you didn't port the gameplaytags that it uses to run the templates gripping off of, both are defined in the config files.

                  I generally don't suggest that a game from the ground up use the gameplay tags, you generally don't need to switch what button does what on a per object bases. However if you want them you can import the datatable that defines them, set it as your gameplay tag table in editor (or also transfer the config file that sets it) and make sure that the GripDropOrUse_Clean functions have the tags that they are likely now missing (or re-import that part after importing the tags).
                  Indeed, I migrated the examples over to try to better compare to how i could integrate it into some test systems -- I actually have all the gameplaytags and they are set in editor, but I don't see how that's relevant to the function and interface interactions? It's failing in the function before checking for relevant gameplay tags. The printstrings indicates it is returning when it fails calling the interface message IsDenyingGrips on the actor (branch is true w/ SG None and returns)

                  P.S.

                  Thank you kindly for your support!
                  Last edited by zSwitchz; 07-11-2019, 08:24 PM.

                  Comment


                    Originally posted by zSwitchz View Post

                    Indeed, I migrated the examples over to try to better compare to how i could integrate it into some test systems -- I actually have all the gameplaytags and they are set in editor, but I don't see how that's relevant to the function and interface interactions? It's failing in the function before checking for relevant gameplay tags. The printstrings indicates it is returning when it fails calling the interface message IsDenyingGrips on the actor (branch is true w/ SG None and returns)

                    P.S.

                    Thank you kindly for your support!
                    Check to make sure that what you are trying to grip is actually the potion, the interface isn't going to be failing out unless you are trying to grip an uninterfaced object. It may be that during your migration you didn't port the trace channel so it reverted to a default one and is trying to grip your hand mesh or something.


                    Consider supporting me on patreon

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

                    Comment


                      Originally posted by mordentral View Post

                      He just copied my static mesh component class and changed the base class to a procedural mesh one (in c++). Then made it so after he slices something he copies the mesh from the proc mesh that it made to a new one of the grippable type and then deletes the original.

                      I could easily make a grippable proc mesh class, the issues I had with it was I am not really willing to support the slicing part by deleting originals and copying the data to newly spawned copies, its unwieldy and overly complex (and inefficient), so I would have to then go and make a custom slicing function to handle slicing specifically grippable procedural meshes (wish they took a class type pointer instead for that function).

                      At that point it is almost easier to contain the sliced components in seperate GrippableActors instead for ones that you want to pick up, and set the proc mesh to the root component.
                      Yeah, I see your point with the output of the slicing function.. Perhaps it's conceivable to make a separate node for such a copy (or to set the pointer)? Similar to the existing "Copy Procedural Mesh from Static Mesh Component". That way you wouldn't have to touch the slicing and the code remains clean (would still be inefficient.. but so are all the other solutions it seems).

                      I found that:
                      - Copying the Mesh from the ProcMesh after slicing will make you lose the collision (as you highlighted in the example project). The only way around this I can see is to mirror the actor, do the slicing twice, and delete one half from either actor. It's really this collision that is creating issues..
                      - Parenting to a Grippable Sphere (with Welding), messes up completely the collision of the ProcMesh (also made a bug report to Epic for this..), so that's not a solution either

                      Ideally, we would remain with one actor -- also because after slicing we need some logic to determine which sliced part was held by a hand and so on..

                      Comment


                        Originally posted by Warner V View Post

                        Yeah, I see your point with the output of the slicing function.. Perhaps it's conceivable to make a separate node for such a copy (or to set the pointer)? Similar to the existing "Copy Procedural Mesh from Static Mesh Component". That way you wouldn't have to touch the slicing and the code remains clean (would still be inefficient.. but so are all the other solutions it seems).

                        I found that:
                        - Copying the Mesh from the ProcMesh after slicing will make you lose the collision (as you highlighted in the example project). The only way around this I can see is to mirror the actor, do the slicing twice, and delete one half from either actor. It's really this collision that is creating issues..
                        - Parenting to a Grippable Sphere (with Welding), messes up completely the collision of the ProcMesh (also made a bug report to Epic for this..), so that's not a solution either

                        Ideally, we would remain with one actor -- also because after slicing we need some logic to determine which sliced part was held by a hand and so on..
                        After copying you just need to generate convex collision, the slicing does that part automatically so you likely just weren't aware that it was part of making a proc mesh and has its own node.

                        The example template doesn't "lose collision" it loses the body instance of a physics grip which wouldn't matter anyway with a sweep grip type. Also as of 4.22 I added a way to detect a physics body being ripped out from underneath the physics constraint and re-init it with the new body context so that doesn't happen anymore anyway.

                        As for a node for the slicing with a different base class? The problem wasn't the copy, the problem was the slicing function automatically spawning and filling a new procedural mesh component, and then having to spawn yet another procedural mesh component and copy the results over before destroying the one that slicing had made. You can limp along by making a manually interfaced subclass of the procedural mesh component and copy after slices, I just would rather not make that an official part of my plugin or keep a re-write of the slicer around that is a seperate function.

                        Would be better off reporting it as an issue with the suggestion that the class type of slicing be either copied from its parent class during creation or allowed to be passed in. This would get it fixed in engine, after which a grippable form of the procedural mesh component would "just work".


                        If you make a grippable actor and set its root component to a procedural mesh, then do your sliced copies duplication off of its children on a subclass with a manual interface integration (see pickup cubes) then you should be fine. You'll want the original to be the root of a grippable actor anyway for most uses if you intend to work with replication.


                        Consider supporting me on patreon

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

                        Comment


                          Originally posted by mordentral View Post
                          If you make a grippable actor and set its root component to a procedural mesh, then do your sliced copies duplication off of its children on a subclass with a manual interface integration (see pickup cubes) then you should be fine. You'll want the original to be the root of a grippable actor anyway for most uses if you intend to work with replication.
                          So I guess I'm stuck with the "duplication" that I'm doing wrong.. so far I'm doing the "Get Section from Proc Mesh" of the sliced copy, and "Create Mesh Section" in the spawned actor, where I have to re-create collision. I did not find a way to copy a ProcMesh over to a new component (in the same actor or in a new one.. or even copying a static mesh the same way). How do you duplicate/copy? In c++ I guess that's possible, but in BP?

                          (thanks for your patience on this, by the way..)

                          Some additional info: After slicing, the MultiSphereTraceForObjects does not detect the resulting objects. The default Vive_PawnCharacter has to fall back on overlap detection for the grip (which messes with the grip prios a bit)
                          Last edited by Warner V; 07-12-2019, 11:27 AM. Reason: additional info

                          Comment


                            Originally posted by Warner V View Post

                            So I guess I'm stuck with the "duplication" that I'm doing wrong.. so far I'm doing the "Get Section from Proc Mesh" of the sliced copy, and "Create Mesh Section" in the spawned actor, where I have to re-create collision. I did not find a way to copy a ProcMesh over to a new component (in the same actor or in a new one.. or even copying a static mesh the same way). How do you duplicate/copy? In c++ I guess that's possible, but in BP?

                            (thanks for your patience on this, by the way..)

                            Some additional info: After slicing, the MultiSphereTraceForObjects does not detect the resulting objects. The default Vive_PawnCharacter has to fall back on overlap detection for the grip (which messes with the grip prios a bit)
                            Copying mesh sections is the correct way of doing it, there is no direct "copy" no, but copying the sections IS copying the mesh.

                            As for tracing not working, you need to enable collision with the VRTracechannel likely, you still have to manage collision settings on spawned objects, if you are copying to a new subclass then that subclass can have the collision settings already defaulted.

                            What you are doing for copying is literally what I would have to do "officially" unless I re-made the slice function, its a result of the procedural mesh component not being very flexible is all. Rather the engine improve here than patch on a hacky fix that you can do yourself anyway.
                            Last edited by mordentral; 07-12-2019, 11:55 AM.


                            Consider supporting me on patreon

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

                            Comment


                              Originally posted by mordentral View Post
                              What you are doing for copying is literally what I would have to do "officially" unless I re-made the slice function, its a result of the procedural mesh component not being very flexible is all. Rather the engine improve here than patch on a hacky fix that you can do yourself anyway.
                              Ok good. I'll make sure to send you my solution when I'm done, in case you want put it in the example project.


                              Originally posted by mordentral View Post
                              As for tracing not working, you need to enable collision with the VRTracechannel likely, you still have to manage collision settings on spawned objects, if you are copying to a new subclass then that subclass can have the collision settings already defaulted.
                              That was the first thing I tried.. Perhaps I made a mistake somewhere, but it might also have to do with the collision bug that is present in ProcMeshes.

                              Comment


                                Hi Everyone. Wondering if anyone has had this problem.

                                I'm using a VRCharacter, but for some reason, the VRRootReference is not following the HMD. It remains at 0,0,0. I'm wondering if I switched something off by accident.

                                When I spawn as a fresh VR character (e.g. empty blueprint), the capsule follows as expected.

                                When I duplicate my VRCharacter, then delete everything so that it's got only the inherited components and no code, the capsule still remains at 0,0,0.

                                I'm hoping this is an easy fix before I start migrating my character code to a new blueprint.

                                Thank you.

                                Comment

                                Working...
                                X