ROTSTEP questions

[Roland Melkert]

Hello all, I've been working on ROTSTEP support for LDCad 1.6 but I have some questions regarding the spec / general behavior of these meta's.

First what is the base orientation (the one for step 1) to be used while calculating the step's orientation using the REL option.

I've been using this:
   

Second is it correct to assume the "ROTSTEP 0 0 0 ABS" will turn out an upside down image (as LDraw is y negative orientated).

  abs.png (Size: 39.31 KB / Downloads: 165)


And then there is the REL option should it act like so when rotating an already rotated model using the x axis only.
   

Hope these issues are clear so experienced rotstep users can help me refine the feature.

Also if someone could donate an (semi) large model using lots of rotstep metas with an known expected output would be very useful.

[Milan Vančura]

Hello all, I've been working on ROTSTEP support for LDCad 1.6 but I have some questions regarding the spec / general behavior of these meta's.

That's great, Roland. I'm a volunteer as a tester.

About the spec: for me as a user, it's simple: please agree with the current LPub maintainer so both LDCad and LPub3D shows the model in the same way. That's what matters.

[Roland Melkert]

That's great, Roland. I'm a volunteer as a tester.

About the spec: for me as a user, it's simple: please agree with the current LPub maintainer so both LDCad and LPub3D shows the model in the same way. That's what matters.

Thanks Milan the mpd you mailed me opened a can of worms for me though as it made me realize the step meta is literally used as the "end of step" indication while I was using it more as a "start of next step" one in LDCad thus all the rotations are currently applied one step later . This can be fixed of course, I just can't help feeling it to be a bit illogical though (adding the rotation info AFTER the parts are inserted. But it is inline with the LDraw standard it just didn't matter when using non ROTSTEP ones.

Second issue I uncovered is the REL variant seems to apply <meta param matrix> * <default view matrix> in the LPub generated pdf's while the MLCad specification says it should do the reverse. but as I don't want to break the whole booklet world I will do the same, just curious on where this went wrong

And last: Anyone has the default view orientation matrix as used in Lpub? I'm currently using a approximation but an LDraw type 1 reference line like matrix notation of it would be very handy. I'll make it an option so people can change it if needed.

Also any more MPD's are welcome especially ones using the ADD and ABS variants together with expected output pdf's

[Travis Cobbs]

And last: Anyone has the default view orientation matrix as used in Lpub?

I don't know for sure, but I suspect that it is latitude 30, longitude 45 in lat/long spherical coordinates. Here is my OpenGL-compatible code for initializing the matrix in LDView; I'm pretty sure that's the same as what's in LPub:

Code:

void LDrawModelViewer::setupIsoViewAngle(void)
{
   rotationMatrix[0] = (TCFloat)(sqrt(2.0) / 2.0);
   rotationMatrix[1] = (TCFloat)(sqrt(2.0) / 4.0);
   rotationMatrix[2] = (TCFloat)(-sqrt(1.5) / 2.0);
   rotationMatrix[3] = 0.0f;
   rotationMatrix[4] = 0.0f;
   rotationMatrix[5] = (TCFloat)(sin(M_PI / 3.0));
   rotationMatrix[6] = 0.5f;
   rotationMatrix[7] = 0.0f;
   rotationMatrix[8] = (TCFloat)(sqrt(2.0) / 2.0);
   rotationMatrix[9] = (TCFloat)(-sqrt(2.0) / 4.0);
   rotationMatrix[10] = (TCFloat)(sqrt(1.5) / 2.0);
   rotationMatrix[11] = 0.0f;
   rotationMatrix[12] = 0.0f;
   rotationMatrix[13] = 0.0f;
   rotationMatrix[14] = 0.0f;
   rotationMatrix[15] = 1.0f;
   examineLatitude = 30.0f;
   examineLongitude = 45.0f;
}

[Roland Melkert]

I don't know for sure, but I suspect that it is latitude 30, longitude 45 in lat/long spherical coordinates. Here is my OpenGL-compatible code for initializing the matrix in LDView; I'm pretty sure that's the same as what's in LPub:

Thanks Travis that translates into

0.707 0 0.707 0.354 0.866 -0.354 -0.612 0.5 0.612

Which is the same as the default in LDView (I should have realisded LPub uses LDView to render   )

I just had to correct to LDraw coord system (a 180 rotate around X-axis, or 1, -1, -1 scale) to compensate for the neg y-axis.

which gives.
0.707 0 0.707 -0.354 -0.866 0.354 0.612 -0.5 -0.612

I assume LDView does that somewhere later on?

I'll make the above part of main.cfg so it is adjustable.

[Travis Cobbs]

I assume LDView does that somewhere later on?

I can't remember where LDView does the coordinate flip/rotate to have +X right +Y down, and +Z into the screen when applying an identity matrix as the "rotation", but yes, it does that separately.

[Roland Melkert]

That's great, Roland. I'm a volunteer as a tester.

About the spec: for me as a user, it's simple: please agree with the current LPub maintainer so both LDCad and LPub3D shows the model in the same way. That's what matters.

I've been playing with lpub4 and it seems the "ROTSTEP  ADD" commands are not supported, it reverts back to the default rotation when used. So I'm going to follow the MLCad spec on that one.

I must say it is all very confusing as LPub seems to be working directly with the ldview longitude latitude stuff instead of rotation matrices and on top of that the Y/X axis flips happen somewhere afterwards inside LDView.

So I'm going to count on user feedback to get this stuff 100% "LPub like" in a couple of weeks once I've finished the first 1.6 alpha.

[N. W. Perry]

I know this is a really old thread, but I kind of wonder what come of some of these questions, because I still find that ROTSTEP output isn't always what I'd expect. But maybe I'm expecting the wrong thing.

Basically, as I understand it, the difference between REL and ADD is that REL combines the rotation given in the meta with that of the default view, whereas ADD combines it with the current view. So if you are on the first step of a model and you add either a REL or an ADD statement, you should get the same result because the current view is the default view. (Assuming ASR is enabled and you haven't manually changed the view.)

But that's not what happens. Say I have the default view set at [30 -35 0]. Now let's say I want it to be [35 -35 0] instead. I can get that with a [5 0 0] ADD statement. But if I use [5 0 0] REL, the resulting view ends up being [36 -35 4]. Huh?

[Roland Melkert]

I know this is a really old thread, but I kind of wonder what come of some of these questions, because I still find that ROTSTEP output isn't always what I'd expect. But maybe I'm expecting the wrong thing.

Basically, as I understand it, the difference between REL and ADD is that REL combines the rotation given in the meta with that of the default view, whereas ADD combines it with the current view. So if you are on the first step of a model and you add either a REL or an ADD statement, you should get the same result because the current view is the default view. (Assuming ASR is enabled and you haven't manually changed the view.)

But that's not what happens. Say I have the default view set at [30 -35 0]. Now let's say I want it to be [35 -35 0] instead. I can get that with a [5 0 0] ADD statement. But if I use [5 0 0] REL, the resulting view ends up being [36 -35 4]. Huh?

Where did you get the 36 -35 4 from?

If I (in LDCad) do a abs sample view in a step with add 5 0 0 (after a ABS 30 -35 0 one) it will sample 35 -35 0.

[N. W. Perry]

Where did you get the 36 -35 4 from?

If I (in LDCad) do a abs sample view in a step with add 5 0 0 (after a ABS 30 -35 0 one) it will sample 35 -35 0.

Yeah, same for me. But if I do the same with rel 5 0 0, I get those different values.

Only difference is I'm not doing it after an ABS statement, but on the default matrix in the config, which I've changed to:

Code:

defStepRotOri=0.819 0 -0.574 -0.287 0.866 -0.41 0.497 0.5 0.709

[Roland Melkert]

Yeah, same for me. But if I do the same with rel 5 0 0, I get those different values.

Only difference is I'm not doing it after an ABS statement, but on the default matrix in the config, which I've changed to:

Code:

defStepRotOri=0.819 0 -0.574 -0.287 0.866 -0.41 0.497 0.5 0.709

Reviewing the code and the MLCad spec documentation I'm thinking REL and ADD are currently wrong in LDCad.

But there are comments (on REL) about not following the spec on purpose.

I would need to setup a decent test file using all variants in multiple configurations to compare with LPub (thinking that would be the most important thing).

[N. W. Perry]

Reviewing the code and the MLCad spec documentation I'm thinking REL and ADD are currently wrong in LDCad.

But there are comments (on REL) about not following the spec on purpose.

I would need to setup a decent test file using all variants in multiple configurations to compare with LPub (thinking that would be the most important thing).

Yes, I remember that LDCad's use of REL was adjusted to match LPub3D (this only affects the order of multiplication, I guess?). The tricky bit is, the MLCad spec is the only place I can find the expected output of any ROTSTEP commands; LPub3D's documentation seems to mention only that they support it.

[Roland Melkert]

Yes, I remember that LDCad's use of REL was adjusted to match LPub3D (this only affects the order of multiplication, I guess?). The tricky bit is, the MLCad spec is the only place I can find the expected output of any ROTSTEP commands; LPub3D's documentation seems to mention only that they support it.

I did some checking and REL seems to be ok afterall, as the result is the same in MLCAD and LPUB.

I'm unsure about ADD though, as LPUB seems to do the same as with REL and MLCAD's step preview is empty no matter the value.

So I'm leaving the implementation unchanged for now.

[N. W. Perry]

I did some checking and REL seems to be ok afterall, as the result is the same in MLCAD and LPUB.

I'm unsure about ADD though, as LPUB seems to do the same as with REL and MLCAD's step preview is empty no matter the value.

So I'm leaving the implementation unchanged for now.

No problem. Any insight on how REL is behaving now?

Seems to me it works best when only rotating around one axis. So if I had to guess, I think it does not apply the rotation progressively; in other words it rotates the second axis on the original part space, rather than on the already-rotated part.

[Roland Melkert]

No problem. Any insight on how REL is behaving now?

Seems to me it works best when only rotating around one axis. So if I had to guess, I think it does not apply the rotation progressively; in other words it rotates the second axis on the original part space, rather than on the already-rotated part.

REL seems to be relative against the base rotation, so it's not progressive.

ADD (according the mlcad docs) should be adding to the current xyz angles, but in LDCad I multiply the current rotation with a newly constructed rotation using the given angles.. This because I don't keep track of the angles outside the step meta.

[N. W. Perry]

REL seems to be relative against the base rotation, so it's not progressive.

ADD (according the mlcad docs) should be adding to the current xyz angles, but in LDCad I multiply the current rotation with a newly constructed rotation using the given angles.. This because I don't keep track of the angles outside the step meta.

That seems to make sense. I think this is the intended behavior of ADD, even if it has unintended consequences. It's supposed to add the given rotation to the current view—NOT necessarily the view given in the previous ROTSTEP. (Because you might rotate the view manually, and then you go to the next step…)