I got it to a point where I see no other changes to make.
EulerBase<AngleT>
Template
I made use of AngleRadian<T>
inside EulerBase
so that we could make it templated if we wanted…
BevPoint
have this orientation coming out of get_curve_points_from_idx
. So I think it is a pretty safe assumption to make.
If another basis was used (chosen?) for geometry node curves it…
AngleRadian
for future proofing
I would think it was more for ease of use, discoverability and documentation purpose. But it can be removed if not wanted.
Looking at the use of math::from_orthonormal_axes in fill_mesh_positions in curve_to_mesh_convert.cc (which I'd say would be the canonical example at this point?) it's hard to tell if this is…
I just want to write down one core design principle:
All rotation types should convert to other rotation types by conserving orientation. The data should never be re-interpreted during a…
Following up on this. It seems like just doing this is even doing better.
void compatible_eul(float eul[3], const float oldrot[3])
{
for (uint i = 0; i < 3; i++) {
eul[i] =…
What's the reason to go for such a "this alias"? What's the added value of using eul.x() over this->x() or just x()?
This is in a conversion operator. Using this
hides the…
While a lot of cleanup is necessary, #104941 is a great start. We can start arguing about naming an other stuffs.
I went to the bottom of the pit to understand and comment all the code inside…
rotate
by transform_point