Plugin

Development Programming & Scripting C++
, , ,
80

[=spire8989;123626]
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 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?
[/]

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) is now handled by the plugin internally.

[=]
is incredibly awesome.

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

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