OpenVrController -> getWorldTransform() doesn't return world coords

[Anonymous]

Hello,

I have some trouble understanding VReds Transformation Matrix usage. My assumption always was, that the Vred TM are the simple standard Transformation matrices, so that I can move, scale,rotate, shear around Objects in space from my world coordinate system. 

Now I retrieve the TM's from my ViveControllers, which works simply by .getWorldTransform().

From my understanding index 3 7 11 should return my absolute coordinates, at least if index 15 is 1.

However if I turn my Headset, and I track my unmoved controllers again these values change. That's really weird. Is that a bug, is my file corrupt or am I missing something important here (still using Vred 2017.2, being afraid to break my script when upgrading 🙂 )? Doing the same for my Headset works as expected. It seems to me, that the vive controllers are living in completely different coordinate systems, somehow in relation to the vive camera.

What I'm basically like to do is to create a Viewpoint as an calibrated starting view, because in real worId I start in a mobile carseat, and now I want to adjust that to my virtual room. What I used to do was to move and rotate everything in the scene to match up, but that's impractical for further processing. Instead I like to define a calibrated viewpoint.

Placing the vivehead to the scenes headobject works as expected, however we like to define the angles with both controllers (or vivetracker), by exactly placing them on predefined locations at the seat. I only need to get the world coordinates and calculate the angle inbetween the vector from both controllers and the worlds x-axis (and y axis to determine left or right). But not having the controllers world coordinates is a problem, and questions the whole concept.

I would be very glad for any help

[michael_nikelsky]

Take a look at the OpenVRExample.vpb that ships with VRED. There we take the worldMatrix of a controller and apply it to another object by calling:

targetNode.setTransformMatrix( controller.getWorldMatrix(), false)

It is important to do it exactly this way, otherwise you will not get the correct matrix since the tracking space is HMD related and the HMD matrix is not part of the cameras transform matrix but of a special HMD matrix. Only the getWorldMatrix takes this into account.

Which brings me to the next point: If you are doing roomscale tracking you should never set a viewpoint for the HMD. The viewpoint works for 1 person holding his hat a exactly 1 position. Someone who is 10cm smaller will be floating, someone larger will feel like being pushed to the ground. Things get really bad if the viewpoint is at an angle, then many people will get sick immediately.

You should only set the position on the floor, I posted a script for teleporting that does this here: https://forums.autodesk.com/t5/vred-forum/htc-vive-teleport/td-p/6795910

Kind regards

Michael

[Anonymous]

Thank you Michael,

I completely forgot about this example at first. Thank you.

Well I actually haven't encountered problems with moving the viewpoint yet. I once implement an own line-plane intersection algorithm and

moved the viewport always in to the right location. This works quite well. This is the reason I like to implement that approach to the interior.

Of course you cannot directly place the viewpoint, but you can move it in relation of hmd and object. This way you can exactly place the cam to a desired location. I think it is hard to describe. I attached the problem in an isolated file. You need to press twice the trigger of controller 0 in order to jump the green sphere, which is a placeholder. I only need to rotate the viewpoint and save that values. The only problem is, that the controllers world coords are  no real worldcoords but hmd related. So the calculated angles always change when the hmd rotates. If you have a vive around, than simply have look.

Best regards

Tom J

[Anonymous]

Okay, no answer...

The problem here is still unsolved and for my purposes it is a big deal if there is no way in getting coordinates of the controller in relation to the actual scene world coordinate system. I mean I can move any object in sync with the controllers position, by writing someNode.setTransformMatrix(CONTROLLER0.getWorldTransform(), false ), but that is not what I want. I only want the absolute coordinates of my controller in order to build on from that information, but I always get wrong values. No matter what I try, they all change when the hmd rotates (and that's even when I'm just using checking childnodes of a controller-synchronised node in the Transform Window).

I can't help myself but from a mathematical point of view, there is definitely a way in walking it from the vive local coordinate system to my worlds absolute system. Isn't it simple ChangeBasis?I only need that vive to vred transform matrix to walk the way backwards. I found a field called "trackingMatrix" in my camnode, but I couldn't retrieve it because I cannot map from SFMATRIX to list of floats. getMReal32,and similar methods don't work. 

Forgive me for being persistent. My company has bought multiple vred pro licenses inclusive a very high monthly support fee. That is why it would at least nice to get a feedback like:" I don't know what you want from us, or I don't know a solution to that problem, or there is no solution". But saying do it exactly like in example xy is not really helpful, because a lot of your examples do not fit others practical needs. 

[michael_nikelsky]

Hi,

first of all: If you have an urgent matter you should contact support, this forum is a community forum and not the official support channel.

As far as your question goes: I can´t reproduce it. I just tried it out, placed the controller at a spot on the floor and moved the HMD around while printing out the matrix of a controller every second. There were changes in the matrix of about 10mm at most which are caused by the accuracy of the tracking system but except for that the controller matrix is fixed to the tracking space (which should match your worldspace if everything was setup properly). 

And the OpenVRExample we ship should also be prove that the matrices are correct since the node we set the matrix to is located directly under the root node and therefore its position must be in world coordinates, otherwise the results would be very strange.

So it has to be something with your setup or calculation but I did not yet find the time to take a look at it. One thing that might cause issues are different layouts, so matrices might be in column first or in row first. If I recall correctly there was a difference in the way VRED handles these and what we get from OpenVR, so you might need to check the transpose parameter when setting new matrices.

Kind regards

Michael

[Anonymous · Accepted solution]

I solved it,

the error was very hard to find but I found the solution when I was going to produce screenshots of the problem this morning. Therefore I even reduced the script to 7 lines but then the error disappeared. You were right, by isolating the problem you can't reproduce it.

The problem was due to the viewpoint moving. For some reason this made the getWorldTransform() to return wrong values. So what I did, I simply swaped the steps in the calibration method. Now, I first rotate and then move the viewpoint. I'm sorry for being a bit rude in my last post, but this issue really made me crazy. I think the worst errors are if there are no error messages but wrong values only. Python scripts are tending to produce a lot of these errors, and I should consider to become a even more defensive coder when using non-static typed languages. But you know, the good thing about this thread, it at least made me find the error.   So, Thank you and sorry

[michael_nikelsky]

Glad you found the solution 🙂