Announcement

Collapse
No announcement yet.

Razer Hydra Plugin

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

  • replied
    Originally posted by dmorgan View Post
    I was up and running in Unity with Razer Hydra in seconds. I already spent hours with Unreal and no results. What gives.

    Unity with this plugin works without any issues, and this plugin was from January 2015. https://www.assetstore.unity3d.com/en/#!/content/7953

    Why isn't there better controller support, tutorials, demos, and info on VR for Unreal?
    This is an unofficial, community plugin. Sixense doesn't currently provide any official plugins for the hydra.

    The current architecture for this plugin is hardware agnostic so that you can transition from the hydra to any of the other motion controller inputs with minimal code adjustments, but you can also use the Hydra Specific component to get specialized functions if you need them.


    If you follow the instructions, adding hydra support can be easily done <5min. If the instructions are still troublesome, try following this step by step tutorial video series by Weevilman:

    Part 1


    Part 2


    The only difference is that you can use the master branch since it has been merged for 4.10.

    Leave a comment:


  • replied
    I was up and running in Unity with Razer Hydra in seconds. I already spent hours with Unreal and no results. What gives.

    Unity with this plugin works without any issues, and this plugin was from January 2015. https://www.assetstore.unity3d.com/en/#!/content/7953

    Why isn't there better controller support, tutorials, demos, and info on VR for Unreal?

    Leave a comment:


  • replied
    I loaded up the ContentExamples project and loaded the VR level. I am unable to get UE4 to recognize input from the Left controller. I can press either trigger, and any number of buttons, but input is always coming from the Right controller in the output.

    I followed instructions from the plugin documentation
    https://github.com/getnamo/hydra-ue4

    and

    Epic docs:
    https://docs.unrealengine.com/latest...ler/index.html
    Simply following the epic docs did not work for me, and they are lacking detail and explicit instructions.

    I am using UE 4.10, Windows 10, Hydra 1.01, Firmware 1.00

    I read comments of others needing to use 2 player controllers and routing input to only one of them, but I hope this would not be the case. Please advise if there is anything I can do, or a starter project / tutorial that shows how to use both hydra controllers on 1 character if possible.

    If there is anything I can provide let me know.


    Thanks for this plugin.

    Leave a comment:


  • replied
    Thank you for responding to my block game problem, getnamo. I am now combining rotators the right way and I removed rotation from my calibration system. I also added a block highlighting system. Unfortunately, I've tried a couple more times to solve the rotation problem, but I can't figure it out how to do it.

    Originally posted by getnamo View Post
    From your videos it appears as if you're setting the cube rotation in world space but you forget to add the parent actor (pawn) rotation so it will always show as if your hands are 'in front' of the stack. You are using add controller yaw input to pan the camera, which rotates the pawn controller orientation, you need to combine this orientation with the MC orientation to get the expected behavior.
    I don't quite understand what you mean. The way I interpreted this was to add the pawn's world rotation to the physics handle's rotation on every Event Tick. This technically solves the rotation problem, but introduces another one: The moment I grab an object, it's perceived 'front' immediately spins to face my camera... knocking all sorts of stuff over in the process. Once the block has spun to face my point of view it will rotate as expected, however, I need it to maintain its initial position when I grab it.

    Current Grabbing Behavior:,
    If I grab a block while the camera is pretty much square on with it's perceived 'front', it will hardly move when it snaps to face the camera. However, the further I am rotated away from a block's perceived front, the bigger and more violent the snap rotation will be.

    Could I get more direct instruction on how to solve this? What exactly do you mean by "combine the pawn controller orientation with the MC orientation?"

    Thank you.


    Bonus Question: I am also a bit confused about positional movement scale. When I first got the hydras working, the scale of their positional movement was ridiculously tiny. If you look at my Tick blueprint (http://imgur.com/a/bWAZe) you can see that the first section scales all movements up by a factor of 20 to make them feel natural. Should I be doing this, or should I just make the world and objects really tiny to match the hydra's default movement scale? My end goal is to convert the project over to the HTC Vive / Oculus Touch VR systems. I want to be able to walk around the stack in the real world with everything scaled to feel like a board game. I think I should be designing for this scale with the hydra from the outset, but I have no idea what it should be. Any advice would be appreciated.
    Last edited by JPStark; 12-09-2015, 07:48 PM.

    Leave a comment:


  • replied
    I was able to separate the hmd and hydra via the wiki instructions but. I would prefer a way to keep the pawn rotation attached to my hmd but unlink the Hydra from the rotating hmd. Could someone explain how to do this? Basically I still want to steer with my head but I don't want the hydra's to rotate when I just turn my head. I want to stand up and play.

    Leave a comment:


  • replied
    To be clear its through the standard motion controller interface that things aren't working? The event graph for a pawn? Have you possessed the pawn with the player controller?

    Leave a comment:


  • replied
    hey guys. I'm using the 4.10 version and till now everything worked fine.
    Until i tried to react on button specific events. they just won't fire. I can trag them into my event graph (for example right trigger click) but they wont react.
    the events derived directly from the hydra plugin element are working fine though (like button released for example). i can't find a workaround to get to know when the right trigger is released. anyone else with this issue?

    Leave a comment:


  • replied
    I created a new pull request to fix a crash on exit created by my changes yesterday. I handled the original problem when components are initialized before CreateInputDevice is called but I failed to account for those created afterwards (such as when P.I.E. or when multiple maps are opened on a cooked/VS run). This fix handles components created both before and after the CreateInputDevice call.

    Github

    Leave a comment:


  • replied
    Originally posted by astonish View Post
    I have to run to an engagement, but I've submitted a pull request that should fix two issues from the thread.

    First, the blueprint reference in a C++ class error when loading up the editor (see my previous posts). It also is a first pass at the order of initialization issue that is causing crashes when launching any non-editor based game that has a hydra component in one of the actors (ie from visual studio or on a cooked game). The fix works by simply deferring both the registration of the hydraPlugin actor component event delegates as well as setting the reference within the component itself to the DataDelegate until after the controller has been initialized via CreateInputDevice. For some reason input devices are created after actors are loaded? EventDelegate recipients are now cached in a TArray in the plugin until CreateInputDevice is called and at that time everything is properly registered and a non-nullptr to the DataDelegate is set on the components.

    This might not be the most elegant way to fix this problem, some better understanding of why CreateInputInstance happens after actor components is probably something to ask Epic devs, but this solved my crashes.

    https://github.com/getnamo/hydra-ue4/pull/6
    This looks great, thanks for all your hard work!

    I will probe epic to see if there is a cleaner way but in the meantime, I'll merge your pull request, it seems like a good workaround. Previous hydra plugin versions did not have this issue due to having delegates attached at component or actor creation stages which were always loaded later, with singular delegates; being attached to CreateInputDevice changed things. Understanding the specific load sequence will be key to finding a the final solution.

    Originally posted by ionbordura View Post
    Hi there,

    does anyone have a working c++ example / tutorial? I noticed the youtube tutorial or the answer #68 are very outdated.

    Thanks,
    Andrei
    Yep since the 4.9 re-architecture, it's very different. I don't have working examples to share at this time, but the gist of getting it to work would be to either use the hardware agnostic methods e.g.standard input mapping (for buttons) and motion controller abstraction (add motion controller component)

    or through hydra specific functions and multicast delegate events found in HydraComponent. To reference hydra specific functions from a C++ context, include the HydraPlugin as a module dependency in your project build.cs, including the right header, and subscribing to the relevant Multicast delegates via e.g.

    Code:
    Add()	Adds a function delegate to this multi-cast delegate's invocation list.
    Last edited by getnamo; 12-02-2015, 10:07 PM.

    Leave a comment:


  • replied
    I have to run to an engagement, but I've submitted a pull request that should fix two issues from the thread.

    First, the blueprint reference in a C++ class error when loading up the editor (see my previous posts). It also is a first pass at the order of initialization issue that is causing crashes when launching any non-editor based game that has a hydra component in one of the actors (ie from visual studio or on a cooked game). The fix works by simply deferring both the registration of the hydraPlugin actor component event delegates as well as setting the reference within the component itself to the DataDelegate until after the controller has been initialized via CreateInputDevice. For some reason input devices are created after actors are loaded? EventDelegate recipients are now cached in a TArray in the plugin until CreateInputDevice is called and at that time everything is properly registered and a non-nullptr to the DataDelegate is set on the components.

    This might not be the most elegant way to fix this problem, some better understanding of why CreateInputInstance happens after actor components is probably something to ask Epic devs, but this solved my crashes.

    https://github.com/getnamo/hydra-ue4/pull/6

    Leave a comment:


  • replied
    I've done some more digging and something is definitely up with the loading order for HydraPlugin Component. With the component is added to a pawn (along with generic motion controller and static meshes) things work fine in the editor, PIE or any other ue4editor -game mode. However, when running development builds out of visual studio or stand alone .exe versions there is a nullptr error. Someone is attempting to AddEventDelegate's to the HydraDataDelegate before its constructor has been called. This happens regardless of the plugin LoadingPhase mentioned in the above post. However, if I remove the HydraPlugin Component from the pawn and leave the generic motion controller components there is no crash and the motion controls work fine in game.

    I wanted to use the Hydra component for calibration and for historical data, though I may try and avoid it and do things using only the generic motion component so I can easily swap in a Vive when we finally get a hold of one.

    Most of my posts here have been about bugs I find, but want to mention again this plugin is awesome and has really helped us prototype and experiment.

    Leave a comment:


  • replied
    getnamo,

    I have solved the issue I replicated in post #279 for both 4.9 and 4.10. To refresh your memory the problem was that if a C++ game mode made reference to a blueprint class that contained the Hydra component errors were thrown during editor startup indicating missing scripts and other errors.

    The fix was as simple as adding the loading phase "PreDefault" to the HydraPlugin module in the .uplugin. e.g.

    Code:
        "Modules" :
    	[
    		{
    			"Name" : "HydraPlugin",
    			"Type" : "Runtime",
                            "LoadingPhase": "PreDefault",
    			"WhitelistPlatforms" : [ "Win64", "Win32" ]
    		}
    	]
    From the documentation:

    LoadingPhase:

    If specified, controls when the plugin is loaded at startup. This is an advanced option that should not normally be required. The valid options are Default (which is used when no LoadingPhase is specified), PreDefault, and PostConfigInit. PostConfigInit allows the module to be loaded before the engine has finished starting up key subsystems. PreDefault loads just before the normal phase. Typically, this is only needed if you expect game modules to depend directly on content within your plugin, or types declared within your plugin's code.
    Since my C++ gamemode's constructor referred to a blueprint class that used your plugin it looks like the PreDefault is required. Everything seems to work the same as before and shutting down and starting up the editor works fine with no errors thrown. If I remove the line the errors return.

    I now have a completely different problem which is my game seems to run fine from PIE, but when I run via visual studio (needed for step debugging my game) everything crashes. This might be related to the packaging bug. Either way I see FHydraPlugin:ataDelegate() is being called before the CreateInputDevice function is being called. I can wrap the return to check for nullptr and this lets things get further along, but the plugin ends up crashing elsewhere. I will dig in if I can.

    Leave a comment:


  • replied
    Originally posted by JPStark View Post
    I'm working on a block stacking puzzle game that's similar to Boom Blox, but I've been stuck for a while on a weird rotation bug. I figured this would be the place to ask for help, so, here's a quick rundown of my setup:

    The camera pivots around a stack of blocks on a spring arm system that's based off the 3rd person templet. You can zoom the FoV in/out and as the camera pan up/down the stack. The "grabbing hand" is motion controlled by the hydra, but its central base coordinate is relative to a point on a spring arm in front of the camera. As the camera pivots around the tower, the Hydra's base coordinate stays in front of your perspective. I've been able to get this system working nicely, and I made a demo to show it:

    https://youtu.be/pvMyJCk5rsI?t=64


    Unfortunately, there is a weird bug that I was trying to hide it in that video. Let's say I grab a block with my hydra and I want to tilt the far side upwards... If I tilt my hydra up, you would expect to see the far side of the block tilt up in a corresponding fashion, but it that doesn't always happen that way. Sometimes the wrong part of the block begins to tilt up and my brain overheats as I try to figure out how my real world hand rotation affects the in-game block rotation. Here's a video of the problem in action:

    https://www.youtube.com/watch?v=6DImCdw3Bno

    As you can see, it doesn't actually matter what angle I'm looking at the block from. When I grab a block, its orientation in relation to the hydra will be determined by that block's rotational yaw at the moment I grab it. I need to get the block's orientation to correspond with my orientation, and I think that means the following:
    + hydra yaw (world)
    - actor yaw(world)

    Anyhow, I've spent about 10 hours trying to figure out how to do this, but the closest I got was to make the block spin to match my orientation when I grab it and that's no good because it knocks stuff over. I'm trying to get this going as a project for the VR development club I started at my college, but there's no point getting other people working on other stuff when I can't even get the basic motion controller and camera system working. Any help would be greatly appreciated!

    Here are my blueprints: http://imgur.com/a/bWAZe
    From your videos it appears as if you're setting the cube rotation in world space but you forget to add the parent actor (pawn) rotation so it will always show as if your hands are 'in front' of the stack. You are using add controller yaw input to pan the camera, which rotates the pawn controller orientation, you need to combine this orientation with the MC orientation to get the expected behavior.

    A couple more things
    -For best tracking, you shouldn't calibrate hydras rotation, only position. Always have the hydra orientated properly (cables facing away from you perpendicular to your screen, can be off-center, but not off-rotation). This is because if you have a hydra near the base when you calibrate orientation it can be significantly off-center (magnetic field lines bending)
    -You shouldn't break rotators and add their floats, instead use the 'combine rotators' or you can end up with a gimbal lock. Combine rotators uses quaternions math, whereas adding doesn't; NB: The order of combine rotators matters, its non-commutative (consider it the difference between the offset affecting the input orientation vs adding a simple offset post input).

    Rotations are some of the toughest things to get right, just remember what you're rotating in what space. Btw good job on the clear images and videos, makes it easier to spot problems.

    Leave a comment:


  • replied
    Hi there,

    does anyone have a working c++ example / tutorial? I noticed the youtube tutorial or the answer #68 are very outdated.

    Thanks,
    Andrei

    Leave a comment:


  • replied
    I'm working on a block stacking puzzle game that's similar to Boom Blox, but I've been stuck for a while on a weird rotation bug. I figured this would be the place to ask for help, so, here's a quick rundown of my setup:

    The camera pivots around a stack of blocks on a spring arm system that's based off the 3rd person templet. You can zoom the FoV in/out and as the camera pan up/down the stack. The "grabbing hand" is motion controlled by the hydra, but its central base coordinate is relative to a point on a spring arm in front of the camera. As the camera pivots around the tower, the Hydra's base coordinate stays in front of your perspective. I've been able to get this system working nicely, and I made a demo to show it:

    https://youtu.be/pvMyJCk5rsI?t=64


    Unfortunately, there is a weird bug that I was trying to hide it in that video. Let's say I grab a block with my hydra and I want to tilt the far side upwards... If I tilt my hydra up, you would expect to see the far side of the block tilt up in a corresponding fashion, but it that doesn't always happen that way. Sometimes the wrong part of the block begins to tilt up and my brain overheats as I try to figure out how my real world hand rotation affects the in-game block rotation. Here's a video of the problem in action:

    https://www.youtube.com/watch?v=6DImCdw3Bno

    As you can see, it doesn't actually matter what angle I'm looking at the block from. When I grab a block, its orientation in relation to the hydra will be determined by that block's rotational yaw at the moment I grab it. I need to get the block's orientation to correspond with my orientation, and I think that means the following:
    + hydra yaw (world)
    - actor yaw(world)

    Anyhow, I've spent about 10 hours trying to figure out how to do this, but the closest I got was to make the block spin to match my orientation when I grab it and that's no good because it knocks stuff over. I'm trying to get this going as a project for the VR development club I started at my college, but there's no point getting other people working on other stuff when I can't even get the basic motion controller and camera system working. Any help would be greatly appreciated!

    Here are my blueprints: http://imgur.com/a/bWAZe
    Attached Files

    Leave a comment:

Working...
X