Quaternion type? about euclid HOT 12 CLOSED

There are other good more generic math libraries out there with quaternions in them (cgmath, nalgebra, piston-math). Therefore, limiting the scope of euclid to servo needs only makes sense to me, and no quaternions are needed there AFAIK.

from euclid.

I think that it would make sense to have quaternions in euclid. There is at least one place in the w3c specs that mentions quaternions so it's not irrelevant to servo and/or webrender either.

So yeah, I'll be happy to review you PR if you feel like contributing a quaternion type :)

from euclid.

Oops, awkard race condition. Nevermind what I just said until @kvark and I sort this out :)

from euclid.

Ok, after some discussions on irc we concluded that some of the animation and webvr specs (at least) use quaternions (for more than storing a few floats). Gecko has its Quaternion type so there certainly is a use for it in Firefox.

So a quaternion type in euclid sounds good.

from euclid.

In the same vein as euclid's naming TypedTransform3D/Transform3D rather than Matrix4x4 I think that it would make sense to call the type TypedRotation3D/Rotation3D. That is, favor idiot-proof terminology over more math-savy ones.

from euclid.

@nical wouldn't that bring confusion w.r.t. euler angles?

from euclid.

Hopefully not? I was hoping that just like we do for transforms, the internal representation would not matter thanks to an overly explicit api. (transform_point instead of multiply operator, etc.) If we have two constructors ::from_quaternion(q0, q1, q2, q3) and from_euler(row, pitch, raw) rather than new(...) it should be hard to make a mistake. But I don't have a clearly defined picture, do you have specific concerns?

from euclid.

So the API contract of the euclid type would be like: I can be constructed from stuff, I can be interpolated, I can rotate points and vectors, also combine with the likes of myself.

Supposing, servo implements a web standard saying that "this interpolation has to be done via quaternion slerp".

Doesn't then the use of euclid::TypedRotation3D lose the guarantee about the concrete quaternion-like behavior of that opaque type? And if the type guarantees that it quacks exactly like a quat, then maybe it should be called a quaternion in the first place?

from euclid.

that it quacks exactly like a quat

Hihi :)

then maybe it should be called a quaternion in the first place?

Well, we could say the same thing about calling transforms "matrices" instead of "transforms". I feel like Rotation3D is a more beginner-friendly terminology, it fits well in the language currently employed in euclid and I don't expect to have to make it cohabit with an euler angles type.

We can (and should) expose the internals of the quaternion (q0, q1..) an quaternion-oriented things like slerp (just like we expose the members of Transform3D and its determinant) for people who have specific needs to reason about quaternion-ness of it, but I like the idea of the basic api being as idiot-proof and unambiguous as the rest of euclid.

from euclid.

Well, we could say the same thing about calling transforms "matrices" instead of "transforms".

Yes, absolutely, and if you recall - the debate on typed transforms versus plain matrices wasn't one-sided either. It's just that the angle of the problem (no pun intended!) that quaternions bring exposes that potential semantics mismatch with servo expectations that I haven't thought about earlier.

We can (and should) expose the internals of the quaternion (q0, q1..) an quaternion-oriented things like slerp

That's certainly one way to address my concern - just have a plain slerp function, the semantics of which guarantees the behavior of quaternion-like spherical interpolation.

I like the idea of the basic api being as idiot-proof and unambiguous as the rest of euclid

I don't see this issue in the context of idiot-resistance, but rather in the context of the level of abstraction. Hiding the details and providing a stricter API works best when you have lots of clients that would want to use it in different ways. The reality is, euclid is there for servo, so the benefit of hiding things from the servo team is not clear.

All in all, I'm just being grumpy and semantically picky here. If the argument doesn't reach you, please feel free to proceed with TypedRotation3D, I'll be fine with it ;)

from euclid.

Hiding the details and providing a stricter API works best when you have lots of clients that would want to use it in different ways. The reality is, euclid is there for servo, so the benefit of hiding things from the servo team is not clear.

The point is not to hide anything but rather manipulate friendly terminology to avoid confusion. There was some massive head-scratching among servo devs when euclid was talking in terms of matrices and the unfortunate amount of conventions (row/column/pre/post/etc.) that we had to keep in mind. Taking a step back from mathematical objects and saying "all I care about are composable transformations and whenever I need to talk in terms of matrices let's make it super explicit" was welcome improvement for servo in particular.

All in all, I'm just being grumpy and semantically picky here. If the argument doesn't reach you, please feel free to proceed with TypedRotation3D, I'll be fine with it ;)

Thanks, I'm still very much in favor of making euclid's API simple by default while having the mathematical terminology available when explicitly needed like we do with transforms.

I'm going to give this a try, and we'll see what the API looks like when I have the first draft/implementation.

from euclid.

This has landed a little while ago.

from euclid.