Razer Hydra Plugin

great work getnamo. Thanks very much for this. The Input mapping is a great addition.

Yeah, I would definitely agree that some of this stuff is a little too obscure, particularly getting modules set up correctly. I really wish that dependencies would be forwarded along so that if you had Engine you would have gotten InputCore and Slate automatically, but others are concerned that unnecessary module dependency forwarding would increase compile times.

Couple of clarifying points for you.

You could avoid define the LOCTEXT_NAMESPACE to use LOCTEXT macro and use NSLOCTEXT instead which includes a parameter for the namespace. Don’t forget to #undef LOCTEXT_NAMESPACE once you’re done with it. We often run in to duplicate definitions of the macro error when compiling with unity builds due to someone forgetting to have undefined it.

Controller ID does map to players. By default player 1 is index 0, player 2 index 1 and so on, though you can change the controller ID of a LocalPlayer (for example the exec command SSSwapControllers is often used for testing different players in splitscreen with).

I’m not entirely sure what you mean by controllers/actors being able to forward key events?

Thanks for the clarification!

Good catch on #undef, I’ll make sure to patch that in the next version.

What I mean by key events is that if you register an axis or a key press for input mapping, it will also emit a blueprint event for the changes in the value/key presses which you can subscribe to (available in a global context). These events fire when you use a blueprint derived from a convenience class included in this plugin called HydraPlayerController. However if you use a blueprint derived class from HydraPluginActor these events will not fire. The only reasoning I can think of is that the actor isn’t registered somewhere in the input chain, possibly because it is not the player actor and so will not receive the input intended for player 1. Both convenience classes use the same delegate so they correctly forward the controller’s motions and axis to Input Mapping, they just differ in the availability of the key/gamepad blueprint events due to where each is attached to the game (controller to the player, actor free floating). This isn’t a big issue in usability though because the plugin provides its own set of events which get emitted correctly for both classes, albeit not at a global context.

You may ask what’s the point of a convenience actor in this case, the reasoning is that the Hydra Plugin Actor is meant as a convenient way to get hydra functionality without changing your controller classes. Just place it in your scene and use it for the input mapping, or use it to pre-process input and output change to some global variable sets elsewhere allowing for a level of input indirection.

Ah yes, that makes sense. There is a bit of documentation on the input stack here: Input | Unreal Engine Documentation

The key is that if an actor isn’t the player controller, the level script, or the possessed pawn we don’t forward the input by default (each of those can have it disabled too). To push another actor in to the input stack you need to call EnableInput on it.

Great work on the plugin updates getnamo! Love the input mapping support.

Unfortunately I’m getting some strange results on the Pitch values on both hydra controllers, while Yaw and Roll are working as expected. I’m using blueprints to get the values and print them to the screen.
When I turn the hydra 90 degrees on the Yaw and the Roll it translates in a 0.5f change, when its turned 180 degrees a 1f change, as far as I can judge, this is correct and expected behaviour.
The Pitch is a whole other story, when I hold it flat it returns value 0 as expected, but when I turn it the values seem to go up to ~0.8f after a 90 degrees turn and returns to 0 at the 210 degrees mark, after that it turns negative but the negative part turns in the last 150 degrees.

Is this something I might be doing wrong or is the input not correctly mapped? And does anyone else has this problem?

This appears correct. You have to remember that Yaw/Roll is -180-180 degrees and pitch is -90-90 degrees. These are obtained from the raw quaternions that the hydra spits out and converted then scaled to -1-1 for input mapping for each axis.

Watch this gif, in it I start off with undocking the hydra and drawing a debug box, then I rotate it around Yaw, then Roll, and finally Pitch, that time all the way through.

Raw Hydra Rotations Gif

You should notice that when the pitch passes being pointed straight up, the yaw and roll change to maintain a correct vector direction and the pitch approaches, but never truly hits 90degrees. From the game perspective it is giving you the correct vector direction and your rotations will work as seen by the box being able to pass that point correctly.

Thanks for your quick reply! I’ve got it working with blueprints but I’d like to use the c++ version now and I’ve followed the tutorial video and the info on the wiki but I keep getting a linker error on FKey from InputCore on the HydraDelegate.h:
Error 2 error LNK2001: unresolved external symbol “public: static struct FKey const EKeysHydra::HydraLeftJoystickX” (?HydraLeftJoystickX@EKeysHydra@@2UFKey@@B) D:\Unreal Projects\HydraC\Intermediate\ProjectFiles\HydraDelegate.cpp.obj HydraC

In my build I’ve declared the following public DependencyModules: “Core”, “CoreUObject”, “Engine”, “InputCore”, “HydraPlugin”. With this I still got a missing DLL error which I resolved by adding the “Slate” Private Dependency.

I’ve done the following:

  1. Include HydraDelegate.h and IHydraPlugin.h in my Hydrapawn class
  2. Added above dependencyModules to my build
  3. Hydrapawn.h inherrits from the HydraDelegate
  4. Copied HydraDelegate.cpp and changed the header to my project
  5. Set the Delegate in BeginPlay
  6. Set the Tick and made the class tickable
  7. overrided the HydraUndockedEvent

When I build it keeps giving me the linker error. Can you point me in the right direction?
If you want I can supply you the source code.

Thanks in advance!

This problem made me take a look at the source again and I found that I declared the FKeys inside the delegate when I added input mapping to the source, which means they needed a link to the const values implemented in the plugin. Since the project is a different build target this would bring the link errors you got. I tried to find a reason why FKeys would be useful to have outside of the plugin and found none, so I moved that whole section into the plugin which will allow you to compile again as before and this also removed the Slate dependency from project code extensions.

Decided to also update some of the C++ interface so that extending your own class will require less filler code:

  • most plugin functionality has moved to inside the plugin, less likely to need an updated HydraDelegate copied over with plugin updates.
  • no need to write an implementation in your subclasses for the hydra events, only declare them in the header for blueprint use (you will need to implement them if you wish to extend that event for C++ and all functions need an implementation to compile)
  • Call HydraStartup() and HydraTick() in your initialization and tick instead of

	if (IHydraPlugin::IsAvailable())

and IHydraPlugin::Get().HydraTick(DeltaTime), this also removed the need to have IHydraPlugin.h included in your subclass.

  • Events are declared with Hydra namespace in the delegate, may need to update your bind code if you relied on EventHydra** in C++, no change needed in blueprints.

Example HydraPawn code:

#pragma once

#include "GameFramework/Pawn.h"
#include "HydraDelegate.h"
#include "HydraPawn.generated.h"

class AHydraPawn : public APawn, public HydraDelegate

	virtual void HydraB1Pressed(int32 controller) override;
	//Required for delegate to function
	virtual void BeginPlay() override;
	virtual void Tick(float DeltaTime) override;


#include "HydraTest.h"	//project header
#include "HydraPawn.h"

AHydraPawn::AHydraPawn(const class FPostConstructInitializeProperties& PCIP)
	: Super(PCIP)


void AHydraPawn::HydraB1Pressed(int32 controller)
	GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Yellow, TEXT("B1 Pressed"));

void AHydraPawn::BeginPlay()

void AHydraPawn::Tick(float DeltaTime)

With only “HydraPlugin” needed to be added to your project build.cs.

Also added support for angular velocity for convenience which is integrated from controller orientation (emitted on controller moved and available through polling) and some misc updates (historical data handling moved to plugin, HydraActor now is now linked to the input chain by default allowing it to receive input mapping events) and bugfixes (loctext undef)

The updates are available as v0.6.2 at github or at the usual, start of this thread.

Thanks for the, again, fast response and even a new release! Kudos.
I’ve got it working without a hitch now.

Keep up the awesome work!

Hello again getnamo,

I’ve got everything working now from the editor but when I make a build the game won’t start and I’m presented with the following error:
LogModuleManager:Warning: ModuleManager: Module ‘HydraPlugin’ not found - it’s StaticallyLinkedModuleInitializers function is null.

When I look at the Unreal Engine documentation at (FModuleManager::LoadModuleWithFailureReason | Unreal Engine Documentation) I can see that the reason it’s failing is EModuleLoadResult::FileNotFound.
As far as I can see the dll’s from the plugin aren’t built with the project. Do I need to tell Unreal Engine to package extra DLL’s?

When I try to run it from the Editor or launch it directly from the project folder (right click the .uproject and select launch) it works without a hitch. (I guess because the library’s are available in the engine)

Can you point me in the right direction again?

I haven’t built for shipping yet but it seems that right now the plugins get absorbed into the build and they don’t generate the module .dlls. Still unsure of how to solve this properly but it may need some conditional build.

See https://answers.unrealengine.com/questions/72781/unable-to-run-community-plugins-when-packaged.html and https://answers.unrealengine.com/questions/48257/hydra-plugin-only-works-in-editor-pie.html for people looking to solve the same issue.

So I took a look at the packaging process and what if anything needs to be done to support the shipping build. The answer is not much, just copy the plugins folder into your packaged build! Ideally the dll should be automatically copied in the packaging process; paging any epic staff who could help me with adding additional shipping build instructions to copy specified files into the packaged directory, but for now this is the best I could come up with.

Considering only the sixense dll is required for shipping, I updated the plugin with a slimmed-down convenience version and some more verbose logging for when it can’t find the DLL. This update is completely optional as it doesn’t change any functionality, only convenience and shipping instructions.

The steps look like this:

  1. As of UE4.3, your project needs code. Even if you’re using blueprint only, add code to your project and compile (it doesn’t need to do anything).
  2. Package your game
  3. Copy the ‘Plugins’ folder (either the full one you have with any of the plugin versions or the slimmed down one found in v0.6.3) into your packaged build ‘ProjectName’ folder. E.g. if I packaged a project called ‘HydraTest’ in my packaged directory (typically called WindowsNoEditor) find the HydraTest folder and place the Plugins folder there.

  1. Confirm its working by launching your packaged game from the ‘Binaries’ subfolder where you placed your ‘Plugins’ folder.

FAQ Troublshooting with Shipping Builds:


Your project runtime also continues working, but your hydra does not respond.

Fix: This means that you have no code added to your project, as of 4.3 your project needs code to run a plugin. Add any code (e.g. new pawn that doesn’t do anything extra) and compile to fix.


also if you search your logs (v0.6.3) and find

Fix: This error means the sixense dll file is missing. Copy the Plugins folder from ShippingBuildOnly into your {packaged root}/{Project Name}

Hope this helps!

Thanks again for the fast response and great support! You’re awesome!
Ill be checking this out tomorrow.

Updated to UE4.4

and a little sneak peak at an upcoming IK based VRMotionInput plugin:
Gfygur Gallery 1

Gfygur Gallery 2

Gfygur Gallery 2

This is incredibly awesome.

I mentioned this on Reddit (Titus there) as well, but I’ll say again, if you’re interested in help at all, I’m down!

With the 4.4.1 preview fixing DK2 compatibility, I decided to try to update my Hydra project. Seems to work fine EXCEPT that the movement linked to my IK is way off. Last version of UE4 for the project was 4.3

Rotation works fine, but when I move the controllers the arms BARELY move instead of having the 1:1 motion they had before updating.

Any idea why this is? Could it be related to the “FRotator angularVelocity” added to “HydraControllerMoved” ? Or if the scale was somehow changed since 0.5.2, the last version I used.

Edit: For some reason I used to have to divide the position by 10 for it to be 1:1, now I don’t anymore. That fixed it. Did the scale change from cm to mm or something?

I wonder if this is why I couldn’t get the hydra positions to work (for hand IK) in my 4.2.1 build. I’m really going for something like Getnamo is doing in the gifs he put up, but I’ve put that on hold for the moment while I work on other stuff that’s not so fiddly and I know I can complete faster.

The Hydra reports the controller positions from the base in mm, in UE4 the scale is defaulted to 1cm = 1uu. As you discovered dividing by 10 would do the conversion, since v0.6 (UE 4.3) this is now handled by the plugin internally.

That’s great. I am currently still working on IMU based integration, but there are a couple of things that I need help on:

  1. How to swap from IK(direct position input e.g. hydra) to FK (IMU derived input e.g. smartphone/Myo) type input in the cleanest way possible.
  2. Template or plugin? (template might have to be code based, whereas plugin may come with a pre-compiled dll due to hmd look separation code)
  3. VR Head model blending for true first person perspective. Do we create a separate head model or do we use a masked material and vertex paint away vertices we do not want to see? Which is a better approach for ease of asset creation?
  4. What is the most convenient class to contain the IK? Controller? Pawn/Character? a mix of the two? Can we turn this into an interface? Currently most of the code is in the Character, due to forwarding values to the animation template, but I wonder if it would be better from a use case to have in the controller.
  5. From a plugin consumer point of view, what other conveniences would you want? keep it simple or simplify some other common vr input tasks?

For now a lot of these are design choices (important, they define ease of use), but once a first code release is made, any blueprint or code additions are very welcome; you may wish to try some of the problems in isolation before then.


Swapping from IK - you can set up a simple blend in out in the event graph for the anim blueprint - I use this for making single frame poses into cheapo animations - like raising or lowering an arm for holding a torch up. With the layered blend per bone or whatever it’s called, you can blend only certain bones against a different pose, and also control it via the alpha.

What I do there is just have it so that I have a variable for how long to blend in/out in seconds, then in the tick I add the delta time and then scale it from 0-X seconds blend time to 0-1.0, and feed that value into the alpha for the bone based blend. The result is a fairly smooth interpolation between whatever types of animation you’re using over a configuration blend time. If you need it kick it in suddenly and just have it off all other times, a 0 alpha works fine, or a branch

[li]Template or plugin? (template might have to be code based, whereas plugin may come with a pre-compiled dll due to hmd look separation code)[/li][/quote]

This is a tricky one right now because of the issue with plugins not working in a packaged content-only game (have to recompile with a dummy class, turning it into a source project basically). Once that’s fixed up, my vote would be for a plugin, but a template gives a lot of other benefits that might be useful.

[li]VR Head model blending for true first person perspective. Do we create a separate head model or do we use a masked material and vertex paint away vertices we do not want to see? Which is a better approach for ease of asset creation?[/li][/quote]

My vote goes to masking the existing head, because often times editing the art with a new head isn’t a great option, whereas vertex painting is very doable even by non-artists.

[li]What is the most convenient class to contain the IK? Controller? Pawn/Character? a mix of the two? Can we turn this into an interface? Currently most of the code is in the Character, due to forwarding values to the animation template, but I wonder if it would be better from a use case to have in the controller.[/li][/quote]

Not sure I have any real opinion on this one - I think having it in the Character would be more similar to current example setups and what people typically do, though.

[li]From a plugin consumer point of view, what other conveniences would you want? keep it simple or simplify some other common vr input tasks?[/li][/quote]

I think keeping it focused, at least early, is the way to go. Hand and head tracking combined into the avatar in a very solid way, such that it can be set up with minimal fuss, then other convenience features can be added afterwards.

Oh man that is awesome. Any idea when you’ll be ready to release an update?