Plank & beam rotation axes?

  • Either I am overlooking something too obvious to find it mentioned or there something strange in how planks and beam rotate with the New Construction System.


    It seems to me that:


    A) With the [Up] and [Down] arrows, the element rotates around its own X axis


    B) With the [PgUp] and [PgDn] arrows, the element rotates around its own Z axis


    C) With the [Left] and [Right] arrows, the element rotates around the World Y axis


    _______________________________


    [ I ] Steps to reproduce B) and C):


    1) Start with a beam at reset rotation ([BackSpace]) and default setr
    2) Rotate it of 45° around the Y axis (3 x [Left]): the element rotates around the World vertical, with coincides with the element Y axis (no other rotation yet)
    3) Rotate it with the [PgUp] or [PgDn] (Z axis): the element rotates around its own Z axis
    4) Reset the rotation ([BackSpace])
    5) Rotate the element of 45° around the Z axis (3 x [PgDn])
    6) Rotate it with the [Left] or [Right] arrows (Y axis): the element still rotates around the World vertical (World Y axis) as in 2), and not around its own Y axis.


    By replacing [PdUp]/[PgDn] (Z axis) with [Up]/[Down] (X axis), one can see that also A) above is true.
    ________________________________


    [ II ] Another example:


    1) Start with a beam at reset rotation ([BackSpace]) and default setr
    2) Rotate it of 90° around the Z axis (6 x [PgDn])
    3) Rotating it with either [Up]/[Down] (X axis) or [Left]/[Right] (Y axis) rotates around the same axis: the object X axis and World Y axis.


    Now, rotation around two different axes should not be the same, should it?


    My mistake or an inconsistency in the code?

  • Just try to reproduce that and all work like intended (tested few times with changing position too)

    Not sure to understand.


    1) What should I reproduce to have everything working as intended?


    OR


    2) You reproduced my description and your results match mines? In that case, I doubt, the difference between A) and B) on one side and C) on the other side was "intended"; to me seems a structural inconsistency, which makes some orientations impossible (or very hard) to obtain.

  • @botchikii: selon le forum, tu es français (ou quand même en France); tu peux écrire en français aussi, si tu préfères; je croix que j'irai répondre en anglais, parce que mon orthographe française n'est pas grand chose...


    "the final orientation of the beam is the same": exactly, this is the problem! It should not be the same. Rotations are not (should not be) commutative; if they are, something is going wrong. What I suspect is that X and Z rotations are applied to one coordinate system, Y rotation to another.

  • Oh, when a topic is flagged as "solved" it doesn't necessarily mean the issue is fixed ^^ Topics will be marked as "solved" automatically if there are no new replies in a given time.
    About the issue: It is actually true, basically only the Y rotation is around the world axis. It's not exactly a bug, it's more about how the rotations are applied to the element: The game uses euler angles, and they will be applied to the element in the order y -> z -> x (yaw, roll, pitch).
    As a result, the yaw (Y) is always around the world axis, while roll and pitch are around the object axis.


    The implementation of the construction system is already a long time ago, but actually it was the most convenient way. I guess. At least having a X, Y and Z rotation around the world axis lead to some awkward situations (and I had the impression that it was more complicated to align construction elements properly then). However, since it's anyway our intention to rework the construction system, we will have a look at the way how rotations work (and maybe find a better solution for that) ;)

  • @red51: Thanks for the reply, I appreciate you spending time on commenting on this topic. I am not very familiar with the terminology used in game field, so I may fail to understand some detail, but I still believe there is a bug somewhere, rather than the choice of a given implementation over another.


    Your description seems to imply that intrinsic rotations (i.e. relative to the reference frame being rotated, or "object coordinates") are used rather extrinsic ones (i.e. relative to the global, fixed reference frame, or "world coordinates"). I'll assume this to be true.


    (Side note: as you quote three rotations around three different axes, while the "classical" Euler formalism only uses two, the first and the third rotation being around the same axis, it seems to me we are actually dealing with Tait-Bryan angles, but I'll assume them as just a variant of the Euler formalism).
    ______________________________


    A) Euler angles should be able to represent any orientation with three appropriate elemental rotations. However, I have been unable to achieve the object orientation which can be described as:


    0) the object is initially aligned with the world reference frame (grey outline)
    1) rotate the object around its Z axis by, say, 45° (black outline)
    2) rotate the object around its Y axis by, say, 45° (red outline)


    as depicted by:

    This orientation seems impossible to achieve with the current implementation. Possibly, I didn't try hard enough and I would be glad if somebody could find a way to do it, but so far this does not seem to be a complete implementation.
    _____________________________


    B) If intrinsic rotations are used, they should be used all over the place and, as they are "played back" in a specific order (Y - Z - X), generally different form the order in which they are created (in my example above they are created in the order Z - Y), the latter order should be converted into the former.


    I'll try to explain myself elaborating on the example above.


    0) Step 0 (initial rotation) can be described with the Tait-Bryan Y-Z-X angles as y = 0, z = 0, x = 0.


    1) Step 1 (rotation around the object Z axis) can be described as y = 0, z = 45°, x = 0.


    2) Step 2 (another, second, rotation around the object Y axis) cannot be represented as y = 45°, z = 45°, x = 0, because this represents a different final orientation in which the Y rotation is applied first, as per your description.


    The actual representation of step 2 as a yaw - roll - pitch (Y-Z-X) sequence of elemental rotations should be derived by applying step 2 to step 1 obtaining a cumulative rotation matrix (or quaternion) from which to work out the individual Euler (or Tait-Bryan) angles in the chosen sequence (Y-Z-X).


    I hope this might explain a bit more the issue I am facing.

  • FOLLOW-UP


    @red51: I just made a little jMonkey project to play with 3D rotation calculations and this is a summary of my findings. I hope it further explains my point of view. All values are taken from jMonkey own calculations and getters.
    _____________________


    1) An initial rotation of 45° around the Z object axis is expressed by:


    1a) the rotation matrix
    | 0.71 -0.71 0.00 |
    | 0.71 0.71 0.00 |
    | 0.00 0.00 1.00 |


    1b) the quaternion <0.00 0.00 0.38 0.92>


    1c) the 'Euler' angles 0.00X 0.00Y 0.79Z
    _______________________


    2) An additional rotation of 45° around the object Y axis yields:


    2a) the rotation matrix:
    | 0.50 -0.71 0.50 |
    | 0.50 0.71 0.50 |
    | -0.71 0.00 0.71 |


    2b) the quaternion <-0.15 0.35 0.35 0.85>


    2c) The 'Euler' angles -0.62X 0.96Y 0.52Z


    It is clear that adding a second rotation around an axis does not simply add to one of the 'Euler' angles, but affects all of them.
    _________________________


    Just for reference, a single rotation of 45° around the object Y axis yields:


    *) the rotation matrix
    | 0.71 0.00 0.71 |
    | 0.00 1.00 0.00 |
    | -0.71 0.00 0.71 |


    *) the quaternion <0.00 0.38 0.00 0.92>


    *) the 'Euler' angles 0.00X 0.79Y 0.00Z


  • as depicted by:

    This orientation seems impossible to achieve with the current implementation. Possibly, I didn't try hard enough and I would be glad if somebody could find a way to do it, but so far this does not seem to be a complete implementation.
    _____________________________

    i know some angles do seem impossible but with some time you get used to how this has been implemented and can achieve any angle oO

    Yahgiggle Steam Signature, real name Deon Hamilton :thumbsup: Server @ ip 139.99.136.76:4255 Name (The Federation of territory) Unity :thumbsup:

    If at first your code does not work call it version 0.1 with the odd bug :thinking:

    My Own Website




    31245-logo-png
  • @yahgiggle: thanks for the reply and for the time spent on this.


    From your screen shot it is not easy to appreciate angles, so I may be wrong, but the rotation around the beam Y axis does not look as it be precisely 45°.


    If you could list the individual rotations you did to reach the shown orientation (I don't think they are covered by some kind of intellectual property ;) ), I could reproduce and tell if we are speaking of the same thing or not.

  • You can use Setr veryhigh this gives you a 1 degree turn so you can do a full 360 degree rotation at 1 degree intervals setr high is 5 degrees and i think the default is 10 or 15 the angle of rotataion on my image was used with the default setting so its not 100% 45 degrees but its what you can do with the default setting

    Yahgiggle Steam Signature, real name Deon Hamilton :thumbsup: Server @ ip 139.99.136.76:4255 Name (The Federation of territory) Unity :thumbsup:

    If at first your code does not work call it version 0.1 with the odd bug :thinking:

    My Own Website




    31245-logo-png
  • You can use "setr 1" to "setr 90". This is much quicker than typing setr high, veryhigh and so on.Default is "setr 15".

    See this just proves there is always something you don't know lol cheers Deirdre :-D

    Yahgiggle Steam Signature, real name Deon Hamilton :thumbsup: Server @ ip 139.99.136.76:4255 Name (The Federation of territory) Unity :thumbsup:

    If at first your code does not work call it version 0.1 with the odd bug :thinking:

    My Own Website




    31245-logo-png
  • @yahgiggle ^^


    I tried to make a test by myself, if I understand it right. What @Miwarre wants.


    I used a woodbeam 1 m long, setr 15, and turned it 3 times to the left side (I used a block as background). Arrow key up at my position.
    Then 3 times page down, 4 times arrow key left, then I used setr 1 to move the beam. As I think its not really possible to get an
    exact position without having half degrees.
    If I have understood the problem correctly. :)

  • @yahgiggle & @Deirdre: I appreciate the time spent by those (few) who seem to care about this point which, if true, would be a serious flaw in a fundamental part of RW.


    However, I am forced to note that so far nobody posted a list of steps to reach the test orientation I described above; this by itself would show that I am wrong to worry (and would teach me something I could not discover by myself).


    And sorry but an approximation is not enough; even with the default setting of 15°, it should not be a problem to achieve angles which are integer multiples of it, as 45° is (yes, there might be internal floating point rounding errors, but if they show through in a process that, in the optimal implementation, is made of just TWO steps as my test orientation does, then something else is seriously screwed).


    I am also surprised that nobody seems to care about the case I describe in part [II] of my original post. In my point of view, this alone shows that here something is not working as it should.


    So as far as I am concerned, the issue is still pending (and incidentally, I know how to use str/l/p as it can be seen in the summary of their functioning I posted a little while ago).


    Of course, thanks again for all contributions!


    EDIT: Cross-posting!!! Deidre posted a step list while I was writing this post. I'll check it ASAP! Thanks!

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!