Plugin

JPStark · November 30, 2015, 4:52am

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 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 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 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…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 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

ionbordura · November 30, 2015, 11:18am

Hi there,

does anyone have a working c++ example / tutorial? I noticed the tutorial or the answer #68](Plugin - C++ - Epic Developer Community Forums) are very outdated.

Thanks,
Andrei

getnamo · November 30, 2015, 2:20pm

[=JPStark;428648]
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 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 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 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…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 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 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). 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.

astonish · December 1, 2015, 9:31pm

,

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.



    "Modules" :
	
		{
			"Name" : "HydraPlugin",
			"Type" : "Runtime",
                        "LoadingPhase": "PreDefault",
			"WhitelistPlatforms" :  "Win64", "Win32" ]
		}
	]

From the documentation:

[]

LoadingPhase:

If specified, controls when the plugin is loaded at startup. 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, 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. might be related to the packaging bug. Either way I see FHydraPlugin::DataDelegate() is being called before the CreateInputDevice function is being called. I can wrap the return to check for nullptr and lets things get further along, but the plugin ends up crashing elsewhere. I will dig in if I can.

astonish · December 2, 2015, 4:47pm

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 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. happens regardless of the plugin LoadingPhase mentioned in the above post. However, if I remove the HydraPlugin Component from the pawn and leave the 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 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 plugin is awesome and has really helped us prototype and experiment.

astonish · December 2, 2015, 10:22pm

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.

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

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

getnamo · December 3, 2015, 1:36am

[=astonish;430548]
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.

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

https://github.com//hydra-ue4/pull/6
[/]

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 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.

[=ionbordura;428765]
Hi there,

does anyone have a working c++ example / tutorial? I noticed the tutorial or the answer #68](Plugin - C++ - Epic Developer Community Forums) 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 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.


Add()	Adds a function delegate to multi-cast delegate's invocation list.

astonish · December 3, 2015, 6:59pm

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). fix handles components created both before and after the CreateInputDevice call.

Github

anonymous_user_6c1dc6d9 · December 7, 2015, 1:44pm

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 issue?

astonish · December 8, 2015, 4:09pm

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?

kent.oster · December 8, 2015, 6:46pm

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.

JPStark · December 9, 2015, 8:16am

Thank you for responding to my block game problem, . 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.

[=;428856]
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 orientation with the MC orientation to get the expected behavior.

[/]

I don’t quite understand what you mean. The way I interpreted was to add the pawn’s world rotation to the physics handle’s rotation on every Event Tick. 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 (Motion Controller Game Blueprints - Album on Imgur) 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 scale with the hydra from the outset, but I have no idea what it should be. Any advice would be appreciated.

anonymous_user_afa9edf11 · December 14, 2015, 12:56am

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//hydra-ue4

and

Epic docs:
https://docs.unrealengine.com/latest/INT/Platforms/VR/MotionController/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 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 plugin.

anonymous_user_afa9edf11 · December 14, 2015, 2:30am

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

Unity with plugin works without any issues, and plugin was from January 2015. Unity Asset Store - The Best Assets for Game Making

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

getnamo · December 15, 2015, 12:30pm

[=dmorgan;436924]
I was up and running in Unity with in seconds. I already spent hours with Unreal and no results. What gives.

Unity with plugin works without any issues, and plugin was from January 2015. Unity Asset Store - The Best Assets for Game Making

Why isn’t there better controller support, tutorials, demos, and info on VR for Unreal?
[/]

is an unofficial, community plugin. Sixense doesn’t currently provide any official plugins for the hydra.

The current architecture for 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 step by step tutorial video series by Weevilman:

Part 1

https://www…com/watch?v=CtWH8pgD-7Y

Part 2
https://.com/watch?v=Vevt7f_sRgM

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

anonymous_user_afa9edf11 · December 17, 2015, 2:04am

I followed the first video with no good results. At 6:33 he does something to fix? the situation but it goes too fast and I am unable to see what he does to fix the issue, something with auto possess? I tried modifying those settings, and/or deleting it. If i disable auto possess i simply see the axis mesh in front of me, and the controllers do nothing. I copied the plugins folder. Used left and right hand motion controllers. The setup otherswise seems identical. I am using 4.10 and your latest update. Any idea? Not sure why I am having issue.

Thanks

getnamo · December 17, 2015, 10:50am

[=dmorgan;439024]
I followed the first video with no good results. At 6:33 he does something to fix? the situation but it goes too fast and I am unable to see what he does to fix the issue, something with auto possess? I tried modifying those settings, and/or deleting it. If i disable auto possess i simply see the axis mesh in front of me, and the controllers do nothing. I copied the plugins folder. Used left and right hand motion controllers. The setup otherswise seems identical. I am using 4.10 and your latest update. Any idea? Not sure why I am having issue.

Thanks
[/]

At 6:33 it appears he deletes the third person character so that your custom game mode character is used.

Some sanity checks:

You’ve dragged and dropped the plugin in the root of your project folder?
You’re using windows? from your earlier post seems like yes
The hydra works in other games/engines? again seems like it does

Try to eject from your character (F10) and move your camera back and see if your hydra are moving the mesh component at all.

Once you’ve established you’re getting movement, step back and see that you’re matching the tutorial setup.

anonymous_user_afa9edf11 · December 18, 2015, 1:34am

I tried deleting the character and there is no difference.

Yes. and the plugin shows up under Edit->Plugins as enabled under Project->Input.Controller
I am using windows 10 pro
The hdyra device configurator recognizes my device and allows me to set options and bindings for games and i can use my hydra controllers and buttons in the game mount & blade

I pressed eject (F8 on my system?) and my meshes are not moving.

My Hydra version is Driver 1.01, Firmware 1.00

The file version on the HydraPlugin for Ue4 says 4.10 in the file and product versions

I have the hydra plugin inside my Hydra_CharacterTest exactly like the tutorial, motion controller left and right, and the meshes under them, and both parented under his HandRoot scene object. Auto Activate on.

World settings has my HydraGM to be the game mode override, and Default pawn class set to my Hydra Character test just like tutorial

Is there anyway to get log and/or debug this?

Something so simple yet there must be a checkbox, a setting, or something very minor not properly set? Is my hydra driver version compatible with this?

Thanks

getnamo · December 18, 2015, 10:18am

[=dmorgan;439570]
I tried deleting the character and there is no difference.

Yes. and the plugin shows up under Edit->Plugins as enabled under Project->Input.Controller
I am using windows 10 pro
The hdyra device configurator recognizes my device and allows me to set options and bindings for games and i can use my hydra controllers and buttons in the game mount & blade

I pressed eject (F8 on my system?) and my meshes are not moving.

My Hydra version is Driver 1.01, Firmware 1.00

The file version on the HydraPlugin for Ue4 says 4.10 in the file and product versions

I have the hydra plugin inside my Hydra_CharacterTest exactly like the tutorial, motion controller left and right, and the meshes under them, and both parented under his HandRoot scene object. Auto Activate on.

World settings has my HydraGM to be the game mode override, and Default pawn class set to my Hydra Character test just like tutorial

Is there anyway to get log and/or debug this?

Something so simple yet there must be a checkbox, a setting, or something very minor not properly set? Is my hydra driver version compatible with this?

Thanks
[/]

Everything seems to be in order. Zip up a minimum example project of your setup and I’ll try it on my setup, also find your logs in {Project Root Directory}/Saved/Logs and pm me them.

As for drivers, you shouldn’t need any drivers for the hydra, the .dll included in the plugin will handle the inputs without additional software.

anonymous_user_afa9edf11 · December 19, 2015, 12:21am

I was able to get input in the right controller working after figuring something out with docking. It seems it needed to be reset. dock/undock. I am not very familiar with the hydra.

However the left controller is not detecting any movement. If I print out the Hydra Left Motion X for the left controller, it is 0, while the Right controller appears to be updating. Same for ControllerMoved event.

The button press appear to show input, but it always thinks its the right controller

So I am having the same issue as originally described with input only appearing to be coming from the right controller. For button events the left controller triggers an event it seems, but it thinks its the right controller the triggered the event. Motion for the left controller is not registering anything at all.

If I print out Hydra Left and Right Bumper from gamepad input key, clicking the bumper on both controllers triggers the right bumper input key. So all buttons trigger the right button events, and motion only registering for the right controller.

Any ideas?