Announcement

Collapse
No announcement yet.

VR Expansion Plugin

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

    I love the plugin.

    While extending your vr character classes I found there are a number of headers that are only referenced in the relevant .cpp files which I had to include to successfully compile. Also, in keeping with Epic's conventions, perhaps you could add static variables to store their names for overriding purposes?

    Comment


      I'm also seeing the strange GenerateOffSetToWorld error when I compile a shipping build, same as the guy a couple pages back. It compiles fine though when compiling for editor, and I have compiled it previously in a shipping build (though that may have been in an earlier version). Makes me think there is something linker or configuration related though I haven't found the culprit yet.

      Code:
      [2017.03.19-06.54.05:977][ 72]UATHelper: Packaging (Windows (64-bit)): UnrealBuildTool: UE4-VRExpansionPlugin-Win64-Shipping.lib(VRCharacterMovementComponent.cpp.obj) : error LNK2019: unresolved external symbol "public: void __cdecl UVRRootComponent::GenerateOffsetToWorld(bool)" (?GenerateOffsetToWorld@UVRRootComponent@@QEAAX_N@Z) referenced in function "public: virtual void __cdecl UVRCharacterMovementComponent::ServerMoveVR_Implementation(float,struct FVector_NetQuantize10,struct FVector_NetQuantize100,struct FVector_NetQuantize100,struct FVector_NetQuantize100,struct FVector_NetQuantize100,struct FVector_NetQuantize100,unsigned char,unsigned char,unsigned char,unsigned int,class UPrimitiveComponent *,class FName,unsigned char)" (?ServerMoveVR_Implementation@UVRCharacterMovementComponent@@UEAAXMUFVector_NetQuantize10@@UFVector_NetQuantize100@@1111EEEIPEAVUPrimitiveComponent@@VFName@@E@Z)
      [2017.03.19-06.54.05:979][ 72]UATHelper: Packaging (Windows (64-bit)): UnrealBuildTool: UE4-VRExpansionPlugin-Win64-Shipping.lib(VRCharacter.cpp.obj) : error LNK2001: unresolved external symbol "public: void __cdecl UVRRootComponent::GenerateOffsetToWorld(bool)" (?GenerateOffsetToWorld@UVRRootComponent@@QEAAX_N@Z)
      [2017.03.19-06.54.05:979][ 72]UATHelper: Packaging (Windows (64-bit)): UnrealBuildTool: UE4-VRExpansionPlugin-Win64-Shipping.lib(VRSimpleCharacterMovementComponent.cpp.obj) : error LNK2019: unresolved external symbol "public: void __cdecl UVRBaseCharacterMovementComponent::ApplyVRMotionToVelocity(float)" (?ApplyVRMotionToVelocity@UVRBaseCharacterMovementComponent@@QEAAXM@Z) referenced in function "public: virtual void __cdecl UVRSimpleCharacterMovementComponent::PhysFalling(float,int)" (?PhysFalling@UVRSimpleCharacterMovementComponent@@UEAAXMH@Z)
      [2017.03.19-06.54.05:981][ 72]UATHelper: Packaging (Windows (64-bit)): UnrealBuildTool: UE4-VRExpansionPlugin-Win64-Shipping.lib(VRSimpleCharacterMovementComponent.cpp.obj) : error LNK2019: unresolved external symbol "public: void __cdecl UVRBaseCharacterMovementComponent::RestorePreAdditiveVRMotionVelocity(void)" (?RestorePreAdditiveVRMotionVelocity@UVRBaseCharacterMovementComponent@@QEAAXXZ) referenced in function "public: virtual void __cdecl UVRSimpleCharacterMovementComponent::PhysFalling(float,int)" (?PhysFalling@UVRSimpleCharacterMovementComponent@@UEAAXMH@Z)
      [2017.03.19-06.54.05:981][ 72]UATHelper: Packaging (Windows (64-bit)): UnrealBuildTool: UE4-VRExpansionPlugin-Win64-Shipping.lib(VRSimpleCharacterMovementComponent.cpp.obj) : error LNK2019: unresolved external symbol "public: void __cdecl AVRSimpleCharacter::GenerateOffsetToWorld(void)" (?GenerateOffsetToWorld@AVRSimpleCharacter@@QEAAXXZ) referenced in function "public: virtual void __cdecl UVRSimpleCharacterMovementComponent::TickComponent(float,enum ELevelTick,struct FActorComponentTickFunction *)" (?TickComponent@UVRSimpleCharacterMovementComponent@@UEAAXMW4ELevelTick@@PEAUFActorComponentTickFunction@@@Z)
      If anyone has come across this and knows the fix please let me know. Otherwise once I figure it out I'll post what was the culprit. Tried cleaning, rebuilding all, no dice but I'm sure it's something simple.
      Last edited by J.C. Smith; 03-19-2017, 04:48 AM.

      Comment


        Hi Mordentral. I've been playing around with the scale of the VRRootReference component or the Vive_PawnCharacter, setting it to 0.1 for example.

        I would like this to give the effect of a mini-me in the vr. It sort of works but the tracked positions are not scaled by this value I think, amongst I suspect other issues...

        A usage example. In multiplayer I cast a spell on my friend in a shared vr that shrinks him to 10% size. He runs on to a grippable object (For big me) and I pick up the object to carry him into the air whilst staring menacingly... It'd open up great gameplay possibilities!!! I use RIP locomotion exclusively for this...

        It's a very interesting and very desirable feature to have working in your plugin (along with grippable destructibles fragments!) in my humble opinion ;-)

        Could you see yourself looking into these features please?

        I hope that it will be simple for you with your in-depth knowledge of all things UE4 and VR with relation to your superb plugins.

        Thanks in advance.
        Last edited by IslandPlaya; 03-19-2017, 12:28 PM. Reason: Example usage

        Comment


          Originally posted by IslandPlaya View Post
          Hi Mordentral. I've been playing around with the scale of the VRRootReference component or the Vive_PawnCharacter, setting it to 0.1 for example.

          I would like this to give the effect of a mini-me in the vr. It sort of works but the tracked positions are not scaled by this value I think, amongst I suspect other issues...

          A usage example. In multiplayer I cast a spell on my friend in a shared vr that shrinks him to 10% size. He runs on to a grippable object (For big me) and I pick up the object to carry him into the air whilst staring menacingly... It'd open up great gameplay possibilities!!! I use RIP locomotion exclusively for this...

          It's a very interesting and very desirable feature to have working in your plugin (along with grippable destructibles fragments!) in my humble opinion ;-)

          Could you see yourself looking into these features please?

          I hope that it will be simple for you with your in-depth knowledge of all things UE4 and VR with relation to your superb plugins.

          Thanks in advance.
          You will have to change the VR world scale to allow for this, https://docs.unrealengine.com/latest.../ContentSetup/ world to meters.

          I played around with a movement mode for a while where you grew really big and took steps and then shrunk back down to normal, it was pretty fun. There might be some specific things I would have to account for as well for misscaled height, I will look into it more.




          Also guys i've been collecting new ideas for the plugin over the past few days (was at 3 weeks of 3-4 hours of sleep a day and am recovering). I have a few interesting ideas I look to implement over the next week hopefully.


          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 will have to change the VR world scale to allow for this, https://docs.unrealengine.com/latest.../ContentSetup/ world to meters.

            I played around with a movement mode for a while where you grew really big and took steps and then shrunk back down to normal, it was pretty fun. There might be some specific things I would have to account for as well for misscaled height, I will look into it more.




            Also guys i've been collecting new ideas for the plugin over the past few days (was at 3 weeks of 3-4 hours of sleep a day and am recovering). I have a few interesting ideas I look to implement over the next week hopefully.
            Looking forward to hearing about your new ideas!

            I'm aware of the VR world scale and plan to play with it, thanks for reminding me, but will that work multiplayer?

            What I'd like is the ability to set the scale of the pawn character so that each client can have a different size and hence VR world scale and 'everything works'. I think its an interesting problem. Cheers for giving it some thought.

            Your advice about the late update setting for grips was spot-on. We have a whole new class of grippable objects that now work perfectly. Thank you again.
            Last edited by IslandPlaya; 03-19-2017, 04:15 PM.

            Comment


              Hi guys, desperately need some help here.

              About the teleport mechanic, I'm trying to make the player (VRCharacter) rotate by applying Thumbstick input into it (...similar to HMD+Gamepad setup from the VR Template or the Robo-Recall, I think.) So the player press Teleport button (let's say, on Left Hand) and use the Right Thumbstick to control the final rotation. Because I'm using Oculus 180 degrees setup, not the 360 room-scale one.

              My guess is to do something with the 'TeleportRotation' variable in the 'GetTeleportDestination' and 'UpdateArcEndPoint' function in the BP_TeleportController ?

              However, I'm rather mathematically disabled myself, been trying to add this for a few days now, with no success.

              Comment


                Originally posted by ZeonmkII View Post
                Hi guys, desperately need some help here.

                About the teleport mechanic, I'm trying to make the player (VRCharacter) rotate by applying Thumbstick input into it (...similar to HMD+Gamepad setup from the VR Template or the Robo-Recall, I think.) So the player press Teleport button (let's say, on Left Hand) and use the Right Thumbstick to control the final rotation. Because I'm using Oculus 180 degrees setup, not the 360 room-scale one.

                My guess is to do something with the 'TeleportRotation' variable in the 'GetTeleportDestination' and 'UpdateArcEndPoint' function in the BP_TeleportController ?

                However, I'm rather mathematically disabled myself, been trying to add this for a few days now, with no success.
                The non motion controller pawn from epic is still in the template and implements this functionality. You should take a look at it.

                Originally posted by MountainCow View Post
                I love the plugin.

                While extending your vr character classes I found there are a number of headers that are only referenced in the relevant .cpp files which I had to include to successfully compile. Also, in keeping with Epic's conventions, perhaps you could add static variables to store their names for overriding purposes?
                I'll link it from a clean c++ project and check out what headers need to be in the modules header for auto inclusion.
                *Edit* Actually just including it in the source file for the template so it will auto check after revisions, should help keep the headers clean. Looks like the basecharacter overhaul had some unlinked headers.

                Also you mean like config file overriding static class names? IE: Engine.ini [VRExpansionPlugin] VRRootComponentClass = newClass?

                Or just literally predeclared static names for the classes? Because as far as I am aware that is not a style convention for the engine and doesn't really do anything as you have to edit the header to begin with to change that.

                Originally posted by J.C. Smith View Post
                I'm also seeing the strange GenerateOffSetToWorld error when I compile a shipping build, same as the guy a couple pages back. It compiles fine though when compiling for editor, and I have compiled it previously in a shipping build (though that may have been in an earlier version). Makes me think there is something linker or configuration related though I haven't found the culprit yet.
                Delete intermediate files and regenerate the project files, not just clean in the IDE. Sometimes the generated files get stuck on older versions and I made some changes in those areas going from 4.14 to 4.15.
                Last edited by mordentral; 03-20-2017, 09:33 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
                  Also you mean like config file overriding static class names? IE: Engine.ini [VRExpansionPlugin] VRRootComponentClass = newClass?

                  Or just literally predeclared static names for the classes? Because as far as I am aware that is not a style convention for the engine and doesn't really do anything as you have to edit the header to begin with to change that.
                  I realise I can simply type them manually as an argument for FObjectInitializer, but as an example in the .cpp for a class deriving from AVRBaseCharacter that would use a subclass of UGripMotionControllerComponent:

                  Code:
                  AMyCustomVRCharacter::AMyCustomVRCharacter(const FObjectInitializer& ObjectInitializer)
                  	: Super(ObjectInitializer
                  		.SetDefaultSubobjectClass<UMyCustomMotionControllerComponent>(TEXT("Left Grip Motion Controller"))
                  		.SetDefaultSubobjectClass<UMyCustomMotionControllerComponent>(TEXT("Right Grip Motion Controller")))
                  would be more robust as:

                  Code:
                  AMyCustomVRCharacter::AMyCustomVRCharacter(const FObjectInitializer& ObjectInitializer)
                  	: Super(ObjectInitializer
                  		.SetDefaultSubobjectClass<UMyCustomMotionControllerComponent>(AVRBaseCharacter::LeftMotionControllerComponentName)
                  		.SetDefaultSubobjectClass<UMyCustomMotionControllerComponent>(AVRBaseCharacter::RightMotionControllerComponentName))
                  which would require a declaration in ABaseVRCharacter like:

                  .h
                  Code:
                  public:
                  /** Name of the LeftMotionControllerComponent. Use this name if you want to use a different class (with ObjectInitializer.SetDefaultSubobjectClass). */
                  static FName LeftMotionControllerComponentName;
                  
                  /** Name of the RightMotionControllerComponent. Use this name if you want to use a different class (with ObjectInitializer.SetDefaultSubobjectClass). */
                  static FName RightMotionControllerComponentName;
                  .cpp
                  Code:
                  FName AVRBaseCharacter::LeftMotionControllerComponentName(TEXT("Left Grip Motion Controller"));
                  FName AVRBaseCharacter::RightMotionControllerComponentName(TEXT("Right Grip Motion Controller"));
                  This is a very minor issue and I now feel silly for bringing it up because I'd much rather you spent time adding more functionality to the plugin and fixing bugs. Maybe there's another way to override these components I'm not aware of.

                  Comment


                    Originally posted by MountainCow View Post
                    I realise I can simply type them manually as an argument for FObjectInitializer, but as an example in the .cpp for a class deriving from AVRBaseCharacter that would use a subclass of UGripMotionControllerComponent:


                    This is a very minor issue and I now feel silly for bringing it up because I'd much rather you spent time adding more functionality to the plugin and fixing bugs. Maybe there's another way to override these components I'm not aware of.
                    Ah I see what you are saying, I'll agree that the names are nice to have as a quick method of overriding, I will note though that I found multiple instances of Epic not actually defining them when overriding them myself

                    I'll add it in as it was rather convenient when using ones that had it themselves.


                    Consider supporting me on patreon

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

                    Comment


                      Made the requested changes, have some testing to do on a new feature tonight before committing to main though. Should have it pushed later.


                      Consider supporting me on patreon

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

                      Comment


                        Pushed a new commit to the template / plugin

                        Plugin
                        Code:
                        Added some missing headers to the VRBaseCharacter that were missed in the big refactor.
                        
                        Added static names for the base character default components for easier overriding.
                        
                        Corrected an unclosed #def in VrRootComponent
                        
                        Started work on The VRStereoWidgetComponent (thanks Mitch for the idea/ general concept). Buggy mess WIP, don't touch yet.
                        
                        Added source files from the plugin to the templates blank c++ class to help auto debug missing headers in the plugin for the future.


                        Consider supporting me on patreon

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

                        Comment


                          Hi mordentral! Awesome Plugin! But I found a small problem, DestroyPhysicsHandle - do not destroy phys completely! Still continues to be called an overlap event for this Phys Copy. It looks strange, but it is noticeable only in InteractiveHybridCollisionWithSweep, when first SetUpPhysicsHandle, then DestroyPhysicsHandle all overlaps event for this Grip Start duplicating for a physical copy and for non physical copy! This is clearly seen if we use OnComponentBeginOverlap.AddDynamic() for Grip Actor. In this Event(OnComponentBeginOverlap) A lot of copies are beginning to come(As if we have many identical objects)... This begins to happen when After the installation of physics we try to destroy it in DestroyPhysicsHandle .. Before this DestroyPhysicsHandle is all okey

                          Comment


                            [MENTION=24338]Mord[/MENTION]entral: It turned out it was three FORCEDINLINE definitions that were causing the issue. So it had to be a compilation flag or something in the Shipping version causing it, haven't figured out what but for the time being I just made those not be FORCEDINLINE and it now compiles fine in shipping. Mentioning for anyone else who runs into the same problem. When I figure out what caused the compilation difference between development editor and shipping I'll post what it was.

                            Comment


                              Moreover, if you comment out

                              Code:
                              root-> SetWorldTransform (WorldTransform, true, & HitResult);
                              in InteractiveHybridCollisionWithSweep type!
                              After destroy Phys u can still rotate the object grip

                              Comment


                                Originally posted by anadre View Post
                                Moreover, if you comment out

                                Code:
                                root-> SetWorldTransform (WorldTransform, true, & HitResult);
                                in InteractiveHybridCollisionWithSweep type!
                                After destroy Phys u can still rotate the object grip
                                Interactive hybrid is on the way out, I don't think the penetration issues with it are actually solvable and the standard physics grip is better overall.

                                That being said I should either fix it or remove it entirely so i'll go over it again tomorrow and make a choice. Its strange that you are not having the physics constraint getting removed though, I have a debug flag that auto triggers when there are more physics handles than actual grips so it is at the very least going through with the destruction code.

                                I'll take a look, I did some revisions recently to that grip type.

                                Originally posted by J.C. Smith View Post
                                [MENTION=24338]Mord[/MENTION]entral: It turned out it was three FORCEDINLINE definitions that were causing the issue. So it had to be a compilation flag or something in the Shipping version causing it, haven't figured out what but for the time being I just made those not be FORCEDINLINE and it now compiles fine in shipping. Mentioning for anyone else who runs into the same problem. When I figure out what caused the compilation difference between development editor and shipping I'll post what it was.
                                What are you packaging it for in shipping? A non windows platform? It packages to win32 and win64 bit shipping fine for me and force inline shouldn't have issues.


                                Consider supporting me on patreon

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

                                Comment

                                Working...
                                X