Make converting positions to points easier

[ndarilek]

I often find myself doing something like:

let p1: Point<f32> = position.position.translation.vector.into();

if I want to get the distance between entities. This gets verbose quickly, especially with multiple entities.

I wonder if it makes sense to add the conversions higher up in the chain:

let p1: Point<f32> = position.position.translation.into();

Most straight-forward, since I'm working directly on the translation.

let p1: Point<f32> = position.position.into();

Unless there's some other, more meaningful point that can be derived from the isometry, this would be preferable since distance between positions seems common enough.

let p1: Point<f32> = position.into();

In general, if someone isn't interested in the next position, I'd argue that current should be the default assumption without having to be explicit about it every time. This makes calculating distances between two entities a whole lot cleaner:

let distance = na::distance(position1.into(), position2.into());

Thanks.

[MiniaczQ]

Stumbled here randomly,
while the first few are still every long,
the later ones start getting non-obvious as to what they actually return.

You should consider making a trait extension to get the point directly from position, probably with a more accurate name.
as_point() perhaps?
Maybe something more descriptive.
Let me know what you think.

[ndarilek]

It should be obvious what all these things return given that most have type annotations--often a requirement when using into().

I know I can make an extension trait, but I don't think I should have to. Rapier already has lots of conversions, so running up against the lack of them here is a bit jarring.

[sebcrozet]

Adding (to nalgebra) a conversion from Translation to Point sounds legitimate (especially since we already have a Point -> Translation conversion). Anything higher up the hierarchy start being too ambiguous since some information (the rotation part of the isometry) is lost in the process.

[ndarilek]

Sure, but what relevant part of the position is lost when calculating distance between two points? Since rotation isn't relevant there anyway, what's the harm in dropping it if explicitly requested to do so?

[sebcrozet]

if explicitly requested to do so

Yes, so writing isometry.translation.into() would be the explicit way to request only the translational part as a point. Writing isometry.into() to extract only the translational part on the other hand doesn’t look explicit.

[ndarilek]

I can respect that if it's your ultimate decision. But I'd counter that, if the type-checker wants a thing that behaves like it's idea of how a Point should, that .into() translating directly into that is as explicit as it needs to be, regardless of how high on the type hierarchy Point is.

Either way, I'll be glad to see this get a bit easier to accomplish. Thanks.