Hip tracking that doesn't need additional tracked devices

[bddckr]

[fight4dream]

How would this work? Is there any paper or reference to follow?

[thestonefox]

We had this in vrtk v3

https://github.com/ExtendRealityLtd/VRTK/blob/3.3.0/Assets/VRTK/Source/Scripts/Presence/VRTK_HipTracking.cs

[fight4dream]

        [Tooltip("Distance underneath Player Head for hips to reside.")]
        public float HeadOffset = -0.35f;

        [Header("Optional")]
        [Tooltip("Optional Transform to use as the Head Object for calculating hip position. If none is given one will try to be found in the scene.")]
        public Transform headOverride;
        [Tooltip("Optional Transform to use for calculating which way is 'Up' relative to the player for hip positioning.")]
        public Transform ReferenceUp;

these were the exposed fields, if we are to port into v4. what would you suggest the new names for the class as well as these fields?

[thestonefox]

we'd probably stick more with the terminology we use now like source, target, target offset, etc

I'm thinking too maybe this sort of script would belong in the pseudobody package?

[fight4dream]

The original v3 scripts only works on Transforms, so it doesn't seem to belong to pseudobody. Unless it alters some aspect of the current pseudobody such as splitting our body into (head, torso, leg) colliders, and the hip is the point between torso and leg. This script can be attached to any camera rigs. so it may not belongs to Tracked Alias neither. i feel like it shall remain zinnia so that we can add this to all camera rigs.

[thestonefox]

i didn't mean it would be on the psuedo body prefab, but just as like an extra script within that repo that could be the place for it.

it feels far too specific to be a zinnia script to me

[fight4dream]

i think it is also very different than the pseudobody repo to be living in there.

in that case, may be it should be its own package.

the v3 code uses Vector3 add, multiply, extract forward, set y, normalize, dot, lerp and float clamp, and then make a quaternion rotation from forward, up

i'm checking which operation we missing from zinnia

[fight4dream]

missing add = Vector3Adder multiply = Vector3Multiplier extract position (from transform) = TransformPositionExtractor extract forward (from transform) = TransformDirectionExtractor set y = Vector3Restrictor normalize = Vector3MagnitudeSetter missing dot = Vector3DotFinder missing lerp or can use formula a*(1-t) + b*t but still missing the Vector3Adder missing quaternion rotation from two vector3 = Vector3ToQuaternion or a kind of TransformDirectionMutator

propose for Vector3ToQuaternion:

public class Vector3ToQuaternion
{
    public Vector3 Forward;
    public Vector3 Up;
    
    public Quaternion DoTransform()
    {
        return Quaternion.LookRotation(Forward, Up);
    }
}

if it is TransformDirectionMutator , it would do transform.(local)rotation = Quaternion.LookRotation(Forward, Up)

[thestonefox]

The only reason I'm thinking pseudo body is because the pseudo body is all about providing a kind of fake tracking to your real body

and hip tracking is kind of that too, it's providing a fake tracking of your body hips.

perhaps a separate repo is the solution too though.

lol i wonder why there's a Vector3Subtractor but not a Vector3Adder. looks like we're also missing Vector2 Subtractor/Adder as well (then also maybe Vector2MagnitudeSetter and Vector2Restricter?).

(side note, when i look at Zinnia I always wonder whether these could be separate packages too or are we doing too much abstraction then?)

Vector3ToQuaternion isn't really converting a Vector3 to a Quaternion, it's relying on you providing two directional Vector3 data parts...

Maybe Vector3DirectionsToQuaterionRotation?

[fight4dream]

back in the days you were making the v4 farm scene working. Vector3Subtractor is one of the component to compare hand distance or something like that. And it was okay to not chase the completeness because it was a prototype. If we are doing it now, we would instead have adder, multiplier, negator, and inverter.

for the “directions to quaternion”, we have something similar in the combined actions. they are called “axes blah blah”. i think Axes is more suit to the purpose of constructing Rotation. and rotation alone is enough to convey it is quaternion. other scripts that uses euler angles do not have “rotation”.

also, we have euler angles in the Data and Transform related. but we might as well have Quaternion/Rotation to directly get/set from the (local)Rotation property.

Zinnia is very close to a node/graph based system. that’s why i like it even in non xr projects. mainly because of these data conversions and actions. to spin off some more packages depend on what is the purpose or future zinnia is going.

Back to this feature, I’d say a separate package with the logic in its own script(s) is fastest to roll out to the public yet can then be dissembled and made its way back into zinnia if see fit.