This is very cool. I just talked with another engine tech and he’s going to bring in his Hydra from home to check this out with. We’re trying to get together an entire VR rig with whatever hardware we can find to see if it’s achievable (also it’s fun).
A very cool plugin, but I get some error when loading it.
**Plugin ‘HydraPlugin’ failed to load because module ‘HydraPlugin’ could not be found. **
I’ve placed the Plugin folder in my project folder. The warning comes up after I enable the plugin just after the engine restarts.
I’m using Windows but I have the same problem as the Mac user above.
That would be very helpfull, I’m making my own implementation right now for simulating hands for a future VR game. Still a bit buggy so I’m wondering what you have made!
I’ve also noticed the mixing up of the rotation’s pitch, roll and yaw for the rotation, would be nice if they could be converted in the plugin to UE4’s yaw, roll and pitch.
Great work on the plugin. I have brought in a Hydra I had at home that wasn’t being used and it didn’t take long to get some basic gameplay working with it. I look forward to seeing how you are able to keep improving on this.
I moved this thread to Engine Source & Github section.
Make sure you are using the correct version of the plugin for your engine version (0.5.1 for 4.1 and 0.5 for 4.0.x). Also is the engine being used in 64bit mode?
This will hopefully be fixed in the next version, it’s on the todo list.
Glad to see Unreal taking a strong interest in VR! If you have any suggestions on how to improve the plugin to fit epic style better, I’m all ears
I have not had an opportunity to look at the source code you have available with your plugin, but it would be a good idea to make sure your source code matches the coding standards used at Epic (if you have already done this, then please disregard ). You can see our current standards here](Coding Standard | Unreal Engine Documentation).
Thanks for the help. I forgot to download the source code for 4.1 and ended up not being able to compile the project. It’s all fixed but I can’t run your plugin in 4.1.1.
I am very new in this kind of stuff could you please tell me the process of updating a plugin so it can work for the newer version? Does it only involves re-compiling the plugin?
I am not much of a programmer but I am going to make a VR project. I already have the first oculus the second version is coming :P.
I am thinking of making a Virtual reality horror game where the player hold a flashlight/gun with razer hydra. Could you please tell me if the plugin provide the necessary functions to achieve it?
I also noticed that one of the axis (Yaw I think) is going from 90 to -90 so I can never get the full rotation, it just switches from 90 to -90 or vica versa. Good stuff that you are actively working on the plugin!
Just a suggestion also, dont know if you want to keep the plugin closed source but it would be nice if this would be available via github or something so we can suggest or help with the plugin (even though im not so much into c++ but still)
You do realize that the source is included in the download, right?
Oops my bad, gonna look into it now!
Just checked, the 0.5.1 plugin version works on ue 4.1.1 so just make sure you have the latest plugin downloaded replacing the old one located in your project’s Plugins folder.
Plugin binds the Hydra to UE4, what you do with it is up to you, there are really no limitations.
That’s the data you get from the hydra API. To track rotations you will need to manually check for large changes in rotation (e.g. yaw going from -89 to +88 in one frame) and add/subtract full rotations to your input. This is how I solved the problem for my own project.
I might add this capability to the plugin, but I generally prefer to keep plugins clean without extra convenience code.
Also as Kashaar mentioned, source is included, but for your convenience, here’s a github:
I got a warning that the module is not compatible and recompiling may be necessary. How can I recompile the plugin?
The plugin header etc is not really linked in my solution. What is the actual process to re-compile the plugin?
Edit : Recompiled successfully following the step above. Thanks a lot
Alright so lets start off that I HATE angles and lots of math in general (despite being a programmer), but what I hate even more is adding hacks to solve a problem that gets created elsewhere. So bear with me while we go on a short journey here…
So I dug around in the source code and since I write C# on a daily basis everything I tried for converting the rotation matrix to a quat failed, so that was fun. I decided to google some more for whacky rotation from the sdk and see if there were other people having the same problem and some have had problems with it as well, but not in the same kind!
When I reached the end of the thread I was starting to think there is nothing we can do since they did not have a solution for the problem.
Then in the following thread a thing called gimbal lock was mentioned:
So ok still bad luck I guess?, nope. The problem occurs because we break up the rotator to fix incorrect rotation, we lose the original rotator and so we get a gimbal lock on an axis because from there on out we are working with euler angles which have this problem.
Since I can switch out params in C++ I did a bit of guessing and within 4 tries I fixed the rotator.
converted.rotation = FQuat(data->rot_quat, -data->rot_quat, -data->rot_quat, data->rot_quat);
Woop woop, pretty happy it works now and I can focus on my game!
So in general guys, dont break up rotators, they dont like you if you do so!
Edit: I just tried breaking up and making the rot again but not changing anything, that works so this confirms my HATE for doing math with angles
Well, maybe this will help… For reference, here’s how I translated the rotation from the Hydra to UE’s rotation system in Blueprints:
It’s just a different source coordinate system, it seems. Where in UE, X is forward, Y is sideways, and Z is up, the Hydra seems to use a different system where Y is upwards, Z is forwards, and X is sideways… unless I’ve got that mixed up. Edit: At least for rotation.
I actually think it would be good if the plugin handled this coordinate system translation… it seems to work alright for positional tracking, at least.
Read my post I fixed the plugin so the UE4 engine gets the correct rotator cause now you probably have the same problem: when you rotate the hydra in a way you it freaks out and rotates in a weird or opposite way.
I’ve proposed the change I made in code on github, if you want to try it out for yourself you can edit the “Plugins/HydraPlugin/Source/HydraPlugin/Private/FHydraPlugin.cpp” file with the rotator fix.
Hm, are you sure? Because I don’t have that problem. But might it be related to what actor/component rotation function you use, maybe? I know that there is one rotation node in BP that is basically like FPS rotation (pitch is clamped to -90 to 90), and another that isn’t, which gives you free rotation. Can’t check right now which is which since I’m not near a computer, though.
I’m sure, getnamo had this same problem but was calculating new data with history data and by doing so avoiding the real problem.
Anyway the rotation should be correct from the plugin to use with UE4, its crazy to constantly have 2 or more nodes in blueprint to convert the rotation. There is not a single use case I can imagine for using the inverted/wrong rotation, you will always have to convert it.
Try rotating every axis of the hydra controller to over 90 degrees, im quite positive you will see the same gimbal lock. I’m using a gun mesh that rotates accordingly to the rotation of the hydra controller.
Kashaar brought this up earlier, but this solution is what made me dig in and update my quaternion knowledge. TIL you can change quat coordinate system by effectively ignoring the W component and just swapping x,y,z around.
In general UnrealX = - SixenseZ UnrealY = SixenseX UnrealZ = SixenseY. I had this fixed for position, but because of (fearing) the quaternion, left the rotation for a later day. The caveat is that the values coming from hydra rotation are inverted, which means you have invert each axis and this is why your solution is correct.
Thanks for this and I’ve patched it into v0.5.2 of the plugin.
Please note that the rotation count issue is separate from the gimbal lock and if you want to count revolutions you will still need to check for big rotation changes.
Maybe we should start a club for people in fear of quaternions!