Razer Hydra Plugin

Hi, getnamo

Seeing what you’re capable of controlling the hydra, you may be able to create a plugin to control arduino boards?

It would be interesting to create simulators with the new vehicle system.
Thanks in advance.

Not being a programmer myself would some kind person please upgrade this awesome plugin to 4.2. Thanks very much

Hi getnamo,
Please upgrade it, or tell me how to compile it to 4.2.
Would be very kind! :slight_smile:

@Uni Koblenz &

There should be a new version available tomorrow (I’m still trying to fix the Shipping vs Editor issue with the plugin). If you can’t wait, you can follow the steps outlined earlier in the thread about how to update your project.

I’m not familiar at all with arduino boards, if you have some programming knowledge you should be able to change the plugin code with your knowledge of the boards to make your plugin.

Thanks getnamo. Very much appreciate your hard work. Did you get anywhere with adding support for input mapping? It’s not essential as I have most stuff working now but it would just make it a bit neater. Thanks again.

Updated it to 4.2, grab the latest plugin and replace the plugins folder in your project.

Unfortunately I haven’t had the time to fix the Shipping Build compilation (it seems shipping builds absorbs the plugin in some way, and may need conditional compilation) and Input mapping is still on the roadmap. If you can help with either of those, by all means please contribute!

Thank you so much. You get a plug on my new blog :slight_smile:

Awesome project. I remember seeing that avatar video earlier and thinking how you nailed the execution for hydra/rpg controls, especially the bow. Looking forward to your progress :slight_smile:

Thanks getnamo, I’m nearly there using your plugin to get the same system working in UE4. keep an eye on the blog for updates.

very rare crash

Hey gitnamo just had a couple of crashed over the last few days while using your plugin. It is very very rare so no urgency just thought I would post this here just in case it helps you out.

Also thought I would let you know that I now have the arms working as I had them before in unity so thanks very much for the plugin. Will be an update and video on my blog soon.

Care sharing what axis setup was like on your arms and what, if any, conversions you did to the rotational data to get it to work properly? Did you have to play with the order of the axis rotation is applied to? I am having a bit of trouble with this as my hands act strangely when I cross 90 degrees on certain axis. How I ended up solving this was doing rotation in world space and adding an offset.

Yeah had a few problems with rotation on the hands. This is the offsets and rotations applied to each hand. Not sure if it will be the same for you. Hope it helps

@Getnamo (or anyone who knows), does the Sixense library give the position of the controllers back relative to the base station?

If so, how are you transforming them to the game’s worldspace? Or do you make assumptions about where the position is relative to the hand?

I’m trying to figure out how to go about utilizing the positions of the PS Move controllers once I’ve got my plugin for them working (thanks btw Getnamo, I used your plugin as a base :D).

The library reports back the distance from the base in mm for all three axis, Edit: but this is automatically converted in the plugin to UE format (where 1uu = 1cm by default). Typically you would want to use a calibration point to capture the length of a player’s arms/etc to line your model up with any player that uses it. For example I use a T-pose to capture both the height of the shoulders and the arm separation in Skycall, and feed that back to keep the player flapping in sync with the bird model.

I’m unfamiliar with PS Move but the Hydra is pretty unique in that you get true 6-axis position and you derive velocity and acceleration rather than typical inertial motion controllers where the reverse is true (and quickly becomes inaccurate). You may want to look into what gets actually reported by the move controller and what its limitations may be.

Thanks Getnamo, I sort of figured that might be the case.

The Move can indeed support proper position and rotation without having to do derivation and stuff yourself, if it has the tracking camera enabled. I’ve run into some issues getting it all to work on 64bit, but I’m going to keep at it.

In the mean time I’m also trying to pick up a Hydra and use that to get things set up more rapidly for my game.

Any chance you could give an example of your calibration setup for the Hydra in your game?

This is UScript (UDK) I’ve yet to update it but the principle is the same:

 local float xOffset, yOffset;
    //Offsets, take the average Z and X position to set the base offset
    HydraBaseHeightinCM = -1 * (RazerInput.LeftHandPosition.Z + RazerInput.RightHandPosition.Z)/2;
    xOffset = -1 * (RazerInput.LeftHandPosition.X + RazerInput.RightHandPosition.X)/2;
    yOffset = -1 * (RazerInput.LeftHandPosition.Y + RazerInput.RightHandPosition.Y)/2;
    //Player Vector offset (center point)
    HydraPlayerOffset.X = xOffset;
    HydraPlayerOffset.Y = yOffset;
    HydraPlayerOffset.Z = HydraBaseHeightinCM + 40;
    //Wing Separation
    ArmLength = VSize(RazerInput.LeftHandPosition-RazerInput.RightHandPosition);
    ArmLengthFactor = 161/ArmLength;

The function is called when a player is in a T-pose, which captures the base offset, the player center point (shoulders for flight), and the player wing separation.

Looking forward to new version for 4.3 Thanks very much.

I’m looking through this part right now to make the plugin support input mapping, I think I understand the initialization part but I haven’t managed to narrow down what function needs to be called to update the axis value when the value has changed or a button has been pressed. I see no references to FSlateApplication. Could you point out what I need to call to update the mapping values?

If you search the code you’ll find many examples of FSlateApplication::Get() to get you the slate application, from there you can call the appropriate function to route your axis through. I think the best bet is OnControllerAnalog which can take an FKey for the axis and the current AnalogValue. It also takes a ControllerId, which I think, probably makes the most sense to just pass 0 as the first controller.

Yep that did it, but I have to say quite a few of the details are still undocumented and convoluted. E.g. needing to #define LOCTEXT_NAMESPACE “(subcategory)”,
including “Slate.h”, and adding InputCore and Slate to your plugin module build settings. In addition to that any controller id apart from 0 doesn’t work (does it assume a second player?) and the Plugin Actor derived classes can’t seem to forward key Events (I’m guessing this has to do with the input chain as a Controller derived class does forward them).

But hey you learn the standards only once :slight_smile:

Plugin V0.6, UE4.3
Thanks to Marc’s hints, the plugin has now been updated to support Input Mapping!

Example usage in the third person template:

You can find these settings under Edit->Project Settings->Engine->Input. You can use key events in addition to the standard hydra events from a HydraPlayerController derived blueprint. This makes adding hydra support to any project a breeze, but the input mapping events do not include integrated or historical data. If you want to do manual gesture detection or more involved input manipulation I still recommend using blueprint events or the C++ delegate.
Feedback is always welcome, let me know if you find any bugs!

Input Mapping Hints:
-Motion is defined as a -1.0 to 1.0 scale for each axis. The range is capped at 2 meters from the base to provide fuller range, you may need to scale this value if you’re using it as motion input rather than 1:1 world mapping.
-Rotation is scaled to -1.0 to 1.0 in each axis, again to provide snappier input you may need to scale the values.
-Joystick Trigger emits both its axis value and a ‘click’ defined by value >=0.5

Leftover Todo:
-Shipping build fix via conditional build (shipping builds seem to swallow the plugin into project code, unsure of best practices)