Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    Originally posted by MagicBots View Post
    Hi Mordentral,

    Hoping you might be able to point me in the right direction in tracking down a bug.

    So I set up the 4 way base station with my vive pro's via this page:
    http://holocafe.de/en/blog/posts/how...-base-stations

    Everything works with my setup in 4 way until I launch the game with the trackers turned on, which causes the crash.
    The crash seems to be a null pointer issue.

    The issue seems to be specifically with using the 4 way lighthouse tracking setup and the 2.0 htc trackers and the template. Maybe openVR, grip motion controller component, or something else.

    To narrow down the issue:
    -I tried your latest template, and it has the same crash so it isn't isolated to my setup.
    -I checked the default steamVR space which does show the trackers moving around so they do seem to work in 4 way lighthouse setup within steam itself.
    -The 2.0 trackers have been working in a 2 way lighthouse setup so no issues there.

    I realize I'm probably out on a limb here with the 4 way tracking setup, but I'd like to try and isolate the issue and continue to push forward with my tracking setup with the much needed robust tracking. I'm trying to move into using C++ more often,and hoping since you know the code, you might be able to point me in the right direction in terms of where to put breakpoints or what else to try to isolate further on the issue.
    Did you try it with the engines default template? That is very unlikely to be caused by my code. It is more likely that something is taking the tracker index as a controller.

    I know that there is a current crash with multiple trackers enabled (like 4) which would make sense because the the lighthouses take up tracking index's so you have the same total number of tracked devices (6).

    Yurinik made a patch for it that I don't think has made it in to the engine yet

    https://forums.unrealengine.com/deve...ackers-support

    The bug report is currently listed as unresolved:

    https://issues.unrealengine.com/issue/UE-54387


    Consider supporting me on patreon

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

    Comment


      I'm currently fixing my project after updating from 4.16 to 4.19.
      I had a no vr option to test stuff (flying pawn). This was working in multiplayer. Now on 4.19 my Client gets reset by the server all the time to Rotation(0,0,0).
      I used AddControllerYawInput/AddControllerPitchInput nodes, but that does not work anymore. For the server everything is fine, but clients gets reset all the time.

      Made a normal unreal character for testing. No issue there. Rotation is synced.

      AddActorWorldRotationVR does not work either when executed on the client. When executing AddActorWorldRotationVR via ServerRPC on the server, only YAW works, PITCH is not set (bUseYawOnly = false).

      Any idea why the server does not get the rotation information for the client?
      DebugWidget - Helper for debugging in VR
      WidgetBox - Recycle your widgets the smart way
      NotificationBackbone - Send notifications via Feeds
      SteamWorkhop - Blueprint and Cpp
      UnrealPluginBuilder - Package via Drag&Drop
      RuntimeMeshImportExport - Sync and Async

      Comment


        Hi mordentral Im getting this error when packaging my project using the prebuilt plugin
        "Creating library C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.lib and object C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exp
        UE4-VRExpansionPlugin.lib(Module.VRExpansionPlugin.cpp.obj) : error LNK2019: unresolved external symbol __libm_sse2_sincosf_ referenced in function "public: virtual void __cdecl FStereoWidget3DSceneProxy::GetDynamicMeshElements(class TArray<class FSceneView const *,class FDefaultAllocator> const &,class FSceneViewFamily const &,unsigned int,class FMeshElementCollector &)const " (?GetDynamicMeshElements@FStereoWidget3DSceneProxy@@UEBAXAEBV?$TArray@PEBVFSceneView@@VFDefaultAllocator@@@@AEBVFSceneViewFamily@@IAEAVFMeshElementCollector@@@Z)
        C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exe : fatal error LNK1120: 1 unresolved externals
        ERROR: UBT ERROR: Failed to produce item: C:\Users\Jimmy\Documents\UnrealProjects\Zombie\Binaries\Win64\Zombie.exe
        Total build time: 64.61 seconds (Local executor: 0.00 seconds)"


        Comment


          Originally posted by Rumbleball View Post
          I'm currently fixing my project after updating from 4.16 to 4.19.
          I had a no vr option to test stuff (flying pawn). This was working in multiplayer. Now on 4.19 my Client gets reset by the server all the time to Rotation(0,0,0).
          I used AddControllerYawInput/AddControllerPitchInput nodes, but that does not work anymore. For the server everything is fine, but clients gets reset all the time.

          Made a normal unreal character for testing. No issue there. Rotation is synced.

          AddActorWorldRotationVR does not work either when executed on the client. When executing AddActorWorldRotationVR via ServerRPC on the server, only YAW works, PITCH is not set (bUseYawOnly = false).

          Any idea why the server does not get the rotation information for the client?
          You should reference the migration guides when upgrading versions, they list things like that

          https://bitbucket.org/mordentral/vre...ine%20versions)

          Specifically though this section

          Code:
          FPS Test pawns
          
          I converted the VRcharacter over to a server authoritive rotation model early on in 4.19. If you are using FPS pawns for testing or need the legacy "Trust the client" rotation model then you need to set bUseClientControlRotation to true in the VRCharacterMovementComponent.
          If you set that boolean to true than it will work as it did before, however the now default and preferred method is to use the SnapTurn / and SetRotation movement actions instead so that rotation is processed inline with the movement system.

          Epics default rotation model is client authoritative, I switched the plugin over early in 4.19 to server authoritative with rollback for rotations.

          As for pitch, you might want to use the old model or use a custom MoveAction where you send the full rotator, by default I only send Yaw as generally characters aren't supposed to be pitch/roll modified.


          Consider supporting me on patreon

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

          Comment


            Having just a bit of trouble, and hoping that maybe somebody can help me.

            I'm working on a VR weapon system using the VR Expansion plugin. For my bolt action rifle, I've got it set so that if the player is holding the rifle with two hands, upon secondary used, the trigger hand will drop the rifle and the secondary hand will grip (with a primary slot grip), allowing the player to work the bolt on the rifle with their primary hand. When the player grips the rifle back, it releases the secondary grip, and I've made it so that it instantly regrabs the secondary grip (as a secondary slot grip). All of this functions properly.

            The issue I'm having is that if the player hits the secondary use, and is now holding the rifle just by his secondary hand, if he drops with the secondary hand, the rifle just floats in the air, but only for the server. On clients, the rifle simulates properly as it should and falls to the ground. I am honestly not too sure how to get this to work right. Dropping the rifle like normal works just fine.

            Thanks in advance for any help.
            Last edited by Lone_Rebel15515; 05-10-2018, 02:48 AM.

            Comment


              Originally posted by Lone_Rebel15515 View Post
              Having just a bit of trouble, and hoping that maybe somebody can help me.

              I'm working on a VR weapon system using the VR Expansion plugin. For my bolt action rifle, I've got it set so that if the player is holding the rifle with two hands, upon secondary used, the trigger hand will drop the rifle and the secondary hand will grip (with a primary slot grip), allowing the player to work the bolt on the rifle with their primary hand. When the player grips the rifle back, it releases the secondary grip, and I've made it so that it instantly regrabs the secondary grip (as a secondary slot grip). All of this functions properly.

              The issue I'm having is that if the player hits the secondary use, and is now holding the rifle just by his secondary hand, if he drops with the secondary hand, the rifle just floats in the air, but only for the server. On clients, the rifle simulates properly as it should and falls to the ground. I am honestly not too sure how to get this to work right. Dropping the rifle like normal works just fine.

              Thanks in advance for any help.
              What type of grip are you using? client authoritative or clientside_movement?

              Client authoritative does everything client side and informs the server, it is the correct mode to use for personal weapons as there is no delay in action, clientside_movement has to wait around for the server to respond.

              Also what logic do you have on secondary use? secondary use doesn't do anything in the plugin itself.


              Consider supporting me on patreon

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

              Comment


                Originally posted by mordentral View Post

                You should reference the migration guides when upgrading versions, they list things like that

                https://bitbucket.org/mordentral/vre...ine%20versions)

                Specifically though this section

                Code:
                FPS Test pawns
                
                I converted the VRcharacter over to a server authoritive rotation model early on in 4.19. If you are using FPS pawns for testing or need the legacy "Trust the client" rotation model then you need to set bUseClientControlRotation to true in the VRCharacterMovementComponent.
                If you set that boolean to true than it will work as it did before, however the now default and preferred method is to use the SnapTurn / and SetRotation movement actions instead so that rotation is processed inline with the movement system.

                Epics default rotation model is client authoritative, I switched the plugin over early in 4.19 to server authoritative with rollback for rotations.

                As for pitch, you might want to use the old model or use a custom MoveAction where you send the full rotator, by default I only send Yaw as generally characters aren't supposed to be pitch/roll modified.
                Thanks. I was not expecting a change there as it is unreal default.

                It basically works, but only on the client properly.
                When set in the class defaults bUseClientControlRotation=true, it works as expected.

                When set at runtime, the client can move as expected (no reset), but the server does NOT apply the PITCH/YAW/ROLL to its client character instance when APawn::bUseControllerRotationPitch/Yaw/Roll is checked. (APawn::bUseControllerRotationPitch/Yaw/Roll does not seems to have any effect when bUseClientControlRotation=true is set through defaults)

                Cheers

                EDIT: I understand your decision for only replicating YAW. In generall we will not need anything else. But for proper and easy testing (especially multiplayer) FPS controlls are badly needed. You realy should add a PerformMovement function that replicates a whole rotator by default.
                I also was wondering that you have a AddCustomReplicatedMovement (which does only take a vector for translation) but not a AddCustomReplicatedRotation. I understand that there is the issue of rotation with pivot (pivot is actor or headset). Would be nice to also have a checkbox on that function to decide what pivot to use (or enum).
                Last edited by Rumbleball; 05-10-2018, 11:50 AM.
                DebugWidget - Helper for debugging in VR
                WidgetBox - Recycle your widgets the smart way
                NotificationBackbone - Send notifications via Feeds
                SteamWorkhop - Blueprint and Cpp
                UnrealPluginBuilder - Package via Drag&Drop
                RuntimeMeshImportExport - Sync and Async

                Comment


                  Originally posted by Rumbleball View Post

                  Thanks. I was not expecting a change there as it is unreal default.

                  It basically works, but only on the client properly.
                  When set in the class defaults bUseClientControlRotation=true, it works as expected.

                  When set at runtime, the client can move as expected (no reset), but the server does NOT apply the PITCH/YAW/ROLL to its client character instance when APawn::bUseControllerRotationPitch/Yaw/Roll is checked. (APawn::bUseControllerRotationPitch/Yaw/Roll does not seems to have any effect when bUseClientControlRotation=true is set through defaults)

                  Cheers

                  EDIT: I understand your decision for only replicating YAW. In generall we will not need anything else. But for proper and easy testing (especially multiplayer) FPS controlls are badly needed. You realy should add a PerformMovement function that replicates a whole rotator by default.
                  I also was wondering that you have a AddCustomReplicatedMovement (which does only take a vector for translation) but not a AddCustomReplicatedRotation. I understand that there is the issue of rotation with pivot (pivot is actor or headset). Would be nice to also have a checkbox on that function to decide what pivot to use (or enum).
                  Engine default is bad for VR, it has no true rotation control so rollbacks or out of sync packets can cause misaligned clients and improper rollbacks. If I ran it more like the simple character it wouldn't be an issue, but a large part of the VRCharacter is my attempting to keep the relative space concept in place in multiplayer. Whether that is worth the effort or up is up in the air, but I enjoy some of the benifits of it (de-coupled capsule and full room to location mapping retention).

                  Also I think you mis-understood me, if you have bUseClientControlRotation = true, then you can keep using axis input yaw/roll/pitch to rotate, I tested it, it works fine.

                  You only need MoveAction to rotate if bUseClientControlRotation=false, that way it inputs the rotation as it happens into the movement array.

                  IE: bUseClientControlRotation=true = everything is default engine behavior.


                  Consider supporting me on patreon

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

                  Comment


                    Originally posted by mordentral View Post
                    Engine default is bad for VR, it has no true rotation control so rollbacks or out of sync packets can cause misaligned clients and improper rollbacks. If I ran it more like the simple character it wouldn't be an issue, but a large part of the VRCharacter is my attempting to keep the relative space concept in place in multiplayer. Whether that is worth the effort or up is up in the air, but I enjoy some of the benifits of it (de-coupled capsule and full room to location mapping retention).
                    ...
                    "it has no true rotation control" I gues you mean the relative rotation of the camera component? If that is the case for the actor rotation, how can it be of any use in multiplayer?

                    I actually do not understand much of that stuff. Multiplayer is its own world of wonders and VR only adds on top of that.
                    I'm very thankful to you to so much effort and support into this plugin.

                    Originally posted by mordentral View Post
                    ...
                    Also I think you mis-understood me, if you have bUseClientControlRotation = true, then you can keep using axis input yaw/roll/pitch to rotate, I tested it, it works fine.
                    ...
                    Yah, it does work when set in Blueprint Defaults. But it works different when set at runtime (PIE).
                    DebugWidget - Helper for debugging in VR
                    WidgetBox - Recycle your widgets the smart way
                    NotificationBackbone - Send notifications via Feeds
                    SteamWorkhop - Blueprint and Cpp
                    UnrealPluginBuilder - Package via Drag&Drop
                    RuntimeMeshImportExport - Sync and Async

                    Comment


                      Originally posted by Rumbleball View Post
                      "it has no true rotation control" I gues you mean the relative rotation of the camera component? If that is the case for the actor rotation, how can it be of any use in multiplayer?

                      I actually do not understand much of that stuff. Multiplayer is its own world of wonders and VR only adds on top of that.
                      I'm very thankful to you to so much effort and support into this plugin.



                      Yah, it does work when set in Blueprint Defaults. But it works different when set at runtime (PIE).
                      When set at runtime you have to set it both on the server AND on the client, if the value differs then they are out of sync, it won't know to assign the value. This is actually true for 90% of the character options.


                      Consider supporting me on patreon

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

                      Comment


                        Originally posted by mordentral View Post
                        When set at runtime you have to set it both on the server AND on the client, if the value differs then they are out of sync, it won't know to assign the value. This is actually true for 90% of the character options.
                        That fixed it, thanks.

                        Something else:
                        GrippableStaticMeshActor does not seem to replicate its StaticMesh to the client. Just placing GrippableStaticMeshActor in the world, giving it a mesh and going for PIE, the GrippeableStaticMeshActor does exist on the client, is visible and hiddenInGame=false, so it should be there. But quering the StaticMesh of the StaticMeshComponent on the client returns MatineeCam_SM from the engine content (it should be a Cube mesh), which does not render nor does it return a name. I tried adding another StaticMeshComponent, but that also does not render.
                        All replication settings I found on the GrippableStaticMeshActor are set to true.
                        The StaticMeshComponent is actually a UOptionalRepStaticMeshComponent, maybe something missing there?
                        DebugWidget - Helper for debugging in VR
                        WidgetBox - Recycle your widgets the smart way
                        NotificationBackbone - Send notifications via Feeds
                        SteamWorkhop - Blueprint and Cpp
                        UnrealPluginBuilder - Package via Drag&Drop
                        RuntimeMeshImportExport - Sync and Async

                        Comment


                          Originally posted by Rumbleball View Post
                          That fixed it, thanks.

                          Something else:
                          GrippableStaticMeshActor does not seem to replicate its StaticMesh to the client. Just placing GrippableStaticMeshActor in the world, giving it a mesh and going for PIE, the GrippeableStaticMeshActor does exist on the client, is visible and hiddenInGame=false, so it should be there. But quering the StaticMesh of the StaticMeshComponent on the client returns MatineeCam_SM from the engine content (it should be a Cube mesh), which does not render nor does it return a name. I tried adding another StaticMeshComponent, but that also does not render.
                          All replication settings I found on the GrippableStaticMeshActor are set to true.
                          The StaticMeshComponent is actually a UOptionalRepStaticMeshComponent, maybe something missing there?
                          Static meshes are "static", they don't replicate their meshes like skeletal meshs do. This is why you can't dynamically drop normal static mesh actors into the level.

                          You can load them by setting them to bNetLoadOnClient in replication settings though, I have that off by default. I'll reset that to true by default.

                          Think defaulting that to false was a fallover from some of the test objects.


                          *Edit*

                          Patch is up on the repository

                          Code:
                          Removing bNetLoadOnClient = false from defaults of grippable actor classes.
                          
                          Leaving it as engine default instead.
                          
                          My bad, this shouldn't have been reset, people may want to check their settings after this.
                          I'll note that the primary reason for having this off is to force the client to receive the current position of an object on net load. If an object is held with client side movement (movement replication is off during this to lower network load), then its initial position will be its level placement on load, not its current location.

                          Setting bNetLoadOnClient=false forces the initial replication to send current position, while it generally should be the default setting for grippables, it does prevent place and set grippable static meshes.
                          Last edited by mordentral; 05-10-2018, 09:46 PM.


                          Consider supporting me on patreon

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

                          Comment


                            speaking of guns. im confused as to how it finds and attaches the hands to the gun. ive tried editing the gun and swaping out the mesh but i cant seem to get it to connect to my sockets.

                            im trying to make a flash light, and then a hand gun. but i want it to snap like the rifle does.
                            im also completely baffled by how the sliding mesh above the rifle works. i cant find any reference or code for it.
                            can you point me to a write up or give me a basic explanation as to how these work

                            Comment


                              Originally posted by sphinix257 View Post
                              speaking of guns. im confused as to how it finds and attaches the hands to the gun. ive tried editing the gun and swaping out the mesh but i cant seem to get it to connect to my sockets.

                              im trying to make a flash light, and then a hand gun. but i want it to snap like the rifle does.
                              im also completely baffled by how the sliding mesh above the rifle works. i cant find any reference or code for it.
                              can you point me to a write up or give me a basic explanation as to how these work
                              The sockets have a prefix ID on them that the plugin searches for VRGripP for primary and VRGripS for secondary, but you can use any override prefix if you set it, or override the GetClosestSocketInRange function and return whatever you want.


                              As for the sliding cube, in the latest template it is a VRSlider component. In older ones it uses the interactible settings, but I am removing those in 4.20 so I wouldn't suggest 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

                                What type of grip are you using? client authoritative or clientside_movement?

                                Client authoritative does everything client side and informs the server, it is the correct mode to use for personal weapons as there is no delay in action, clientside_movement has to wait around for the server to respond.

                                Also what logic do you have on secondary use? secondary use doesn't do anything in the plugin itself.
                                I'm using client authoritative, but I've tried other modes as well just for the hell of it, but same result.

                                The relevant code for 'on secondary used,' is below. It properly drops the primary grip, regrips at the secondary grip point. However, if you drop the weapon from that secondary (now a primary) grip, on the server instance, the weapon floats in mid air. You can still re-grip it and everything like normal, it just doesn't simulate (while it does appear to properly simulate on connected clients).

                                If need be I can take a video of the issue, as my description might not be good enough.
                                Last edited by Lone_Rebel15515; 05-10-2018, 10:57 PM.

                                Comment

                                Working...
                                X