@Miwarre i think most users do not want to talk about this because they don't see this as a problem, users make balls and balls need a full 360 degree rotation in all directions, are they perfect nope but that's more to do with the ends of the beams been flat then not been able to get the angle needed oO , ive not posted the steeps needed because i really don't think about it that much i just do it lol but i guess as @Deirdre said they cant do half of degree and that could cause a slight problem but not one that's a big deal. but in saying this the way it works can cause problems sometimes you get in a angle you seem to have fun trying to get out of and flipping and rotating does not seem to help till out of the blue you get there lol so the rotation could be improved oO
Oh well, this is going to be long and boring; please bear with me... I have warned you If nothing else, if you care, please read at least the final comments. Thanks!
Thanks to @Deirdre for the steps she provided. I had a look at them, re-played them locally and I learned a few interesting things.
Step 0: a beam (0.5m wide, 3 m long, if you care) at default, un-rotated orientation. This is how it looks along the Z axis (I tried to take the screen shot as orthogonally as I could and I overlaid the axis names for added clarity):
So far nothing strange.
Step 1: 3 x UP arrow (according to Deirdre list). This should mean +45° around the X axis (currently, as the beam is not rotated, the axes of the object and of the world coincide). View along the Z axis:
and along the X axis:
Everything as expected!
Step 2: 3 x PgDn arrow: this should mean -45° around the Z axis. View along the Z axis:
And along the X axis:
and also along the Y axis (looking down):
Now things start to look strange. From the screen shots a sharp eye may be needed, but while viewing the rotation on the screen, it is rather clear that this rotation is neither around the object Z axis or the world Z axis; it looks like around some undefined axis which presumably depends on the previous rotations.
Step 3: 4 x Left arrow: which should be -60° along the Y axis. This is rather clearly the world Y axis, not the object axis (or any variable axis resulting from 'obscure' calculations). View along the Z axis:
View along the X axis:
And view along the Y axis, showing that the object is not actually parallel to the XY plane::
Finally, a detail showing that the 'tilting' of the beam around ITS OWN Y axis is far from being 45°:
1) The implementation, instead of the X, Y, Z axes (as described in the F1 help screen), rotates the object around axes largely counter-intuitive and very hard to visualize; they are surely the result of internal calculations, but from the user perspective look arbitrary.
For what is worth (and from some @red51 comments above), I suspect that the implementation simply alters the X, Y or Z value of an internal representation in Euler angles, rather that implementing rotations consistently intrinsic or extrinsic. A hint might be the suspect of gimbal lock shown in OP [II], as an Euler angle representation may suffer from it.
2) By small (non-intuitive) corrections, the intended orientation might perhaps be obtained (still not sure, though). Each correction will however affect the orientation of the object around all the 3 axes and will require further corrections. It is not a matter of having half degrees available, it is a potentially never ending chase of corrections after corrections.
3) JME directly supports consistent intrinsic rotations and one could wonder which reason is strong enough to ignore this easy support. If Euler angles are preferred to persistently store the rotation data of an object, as they are the most compact representation (sparing one floating-point value over quaternions and 6 f.-p. values over matrices), the conversion could happen when writing the data to a file.
4) I am still not sure that implementation is logically complete (the suspect of gimbal lock is a strong hint that some orientation cannot be reached); right now, it definitely looks operatively incomplete, as a simple case like the one I pursued in this thread is proving very hard to reach, possibly impossible to reach with the needed precision.
5) I am glad that all of this seems not to affect many users (those looking for 'balls', as @yahgiggle says ); still the eventual lack of precision does affect architectural realisations.
6) I am aware that angles, quaternions, Euler angles and so on are not glamour nor make for a popular update; still, the building capabilities of RW will remain as one of its strong points and I feel that this matter should be raised a bit in priority.
think most users do not want to talk about this because they don't see this as a problem,
I think many users don't build in these dimensions. They are not so familiar with the matter.
@Miwarre Your explanations are very complicated for me. I'm a builder, no mathematician, no architect, I'm only
playing with one, and trying to translate it in my language and in my understanding, but I'm trying to help as well as I can do. When I see the pictures
I can imagine it better.
I have the wish for more precision, more measurements, bigger glass size for instance. Who really needs 0,5° differents, if he wants to build no ogival or
@Miwarre Your explanations are very complicated for me. I'm a builder, no mathematician, no architect, I'm only playing with one, and trying to translate it in my language and in my understanding, but I'm trying to help as well as I can do. When I see the pictures I can imagine it better.
I have the wish for more precision, more measurements, bigger glass size for instance. Who really needs 0,5° differents, if he wants to build no ogival or absolutely accurate.
Thanks for the reply @Deirdre. I fully understand you; the whole matter was much like black magic for me too, when I started. So, I'll try to elaborate on the final comments of my previous post.
1) Precision is not optional: if you don't need it and it is there, it does no harm; but if you need it and it is not there, you are out of business. Also please note that I am not speaking of residual approximations: the beam shown in my previous post is several degrees off, both along its own Y axis (as shown in the final detail screen shot) and along the world Y axis (as shown in the penultimate picture). I'll make a few examples, not theoretical but from my actual experience with RW:
1a) The beam we are mistreating all along this thread might be the corner beam of a, say, 4-sided roof as in:
Once I needed to use it, rather than in "square section" as shown here (with its edges two above and two below), in "diamond section" (i.e. with its edges on top, middle left, middle right and bottom, i.e. rotated by 45° around its length (Y) axis): I had to give up because the intended orientation was practically impossible to obtain without it being visibly off the mark.
1b) Another time I was working with dormer-windows:
but the junction between the roof side slope and the dormer-window roof slope was impossible to reach decently; so I had to 'cheat' make both as larger rectangle and close the access to the inside of it, as it was a mess of intersecting rectangles:
1c) Then, I tried with 'Gothic' tracery windows, just a simple one; I hoped to use beam again in "diamond section", but again the result was a mess of mismatching beams, so I gave up again and resorted to "square section":
This are all practical cases, involving a limited number of pieces and not really in complex relationships to each other (at least easy to visualise).
2) Counter-intuitiveness: In the current implementation, the rotation commands rotate the object around non-evident -- and in several cases counter-intuitive -- axes: in general, neither the object OWN axes or the world 'global' axes, which are the reference systems that a user can visualise more easily.
3) Incomplete?: I am not 100% sure of this, so I still add a question mark. However, the fact that nobody was able to solve the relatively simple problem I posed at the start of this thread makes quite serious the hypothesis that the current implementation is incomplete and does not allow to reach all the possible orientations a solid body can assume.
I also ask to try the example I describe in section [II] of my first post: it shows a case when one rotation around one of the possible axes is lost, as this also is a serious hint about the potential incompleteness of the current implementation.
4) Unnecessary: Above anything else, all of this is unnecessary, as far as I can tell. Object-relative reference systems are very common and relatively easy to implement; they allow to add rotations which are really and precisely around the object OWN axes (also called intrinsic rotations), which are much easier to visualise, as you have the object before your eyes. They can also be implemented in a way which is really complete (demonstrably).
They would allow to easily (at least much more easily than now) and precisely reach any orientation you can visualise. Under these context, the 1° degree precision now available would be enough for most objects, surely for the 3 smallish objects I show in the pictures above.
Now, jMonkey (the framework RW is developed upon) comes with built-in support for them and I cannot think of a reason strong enough for NOT using it, as RW apparently does now.
Finally, while I am aware that the attentions of users is currently toward other aspects of the game, the building system is and will remain one of the RW strong points and dragging along the (unnecessary) weak points I describe above does not seem to me 100% wise. So, I feel the priority of this aspect should be raised.
Thanks for reading another over-long post! If I made errors or arbitrary assumptions, I will be glad to learn more!
At this point, I think to be ready to formalise my
1) Given a reference line
1a) parallel to one of the coordinate planes (XY, YX or ZX; the example shows a green beam parallel to the XY plane)
2) and slanted of 45° (the two blue beams of equal length show that the green beam is indeed slanted of 45°)
the goal is to place
3) one single (solid) beam rotated of 45° around the reference line (here outlined with red beams);
The 45° rotation requirement is considered satisfied when the middle vertices of the beam start and end sides are horizontal:
4) The beam shall be at least 4 blocks long and of the maximum width a beam can have.
5) The positioning and rotations shall look precise at visual inspection when seen from a distance of at least 4 blocks from any of the beam points (visible precision at super close inspection distance is not required)
6) Proof of solution shall be the list of rotation commands issued to achieve the requested orientation from the default upright orientation of a beam (as set by pressing [Backspace]).
7) The prizes for anyone solving the problem will be:
- my ever-lasting gratitude
- the satisfaction to be proven "Master of Rising World Construction"!
Note: in the pictures above, the red beams outlining the goal beam are not correct and the start and end 'squares' are actually rhombi. This is because I am currently unable to achieve the request orientation and I believe it cannot be obtained with the current RW implementation.
I hope to be proven wrong!
Long topic... where to start? In general: As mentioned, all rotations are basically intrinsic rotations, but they don't work exactly as you may expect. Basically a construction element keeps all information it needs to reconstruct the rotation from an empty quaternion. When rotating a construction element (while placing it), you basically just increment (or decrement) the particular rotation values (rotation around x, y and z axis).
When converting these euler angles to a quaternion, the rotation values will be applied in the order y, z, x, i.e. yaw, roll, pitch, or in other words, heading, attitude and bank (when thinking of an airplane).
However, since we're going to rework the construction system in the future anyway, we will check out if there is a more convenient way for the rotations
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°.
Getting fully accurate angels is not that easy. There is always a loss in precision when it comes to the conversion of euler angles to quaternions, this is unavoidable. Especially since the game just uses floats, which have a limited precision (but even when using double values, there is always a precision loss when converting euler angles to quaternions). But usually the precision is sufficient, as long as we don't want to create some CAD software
Precision is not optional: if you don't need it and it is there, it does no harm
It depends, at least when we're talking about precision in general. For example, the translation of every element has a limited precision (since we want to keep the amount of data the game has to store per element as low as possible). When it comes to the rotation, there is still some room for a higher precision (i.e. 0.5 degree steps), we just thought it wouldn't be necessary at all (that's why at least the stetr command does not accept values lower than 1).
Now, jMonkey (the framework RW is developed upon) comes with built-in support for them and I cannot think of a reason strong enough for NOT using it, as RW apparently does now.
Basically the JME implementation of euler-to-quaternion conversion is based on this: http://www.euclideanspace.com/…lerToQuaternion/index.htm
Nevertheless, RW mainly uses JME for rendering and scene management (and JME does an awesome job when it comes to these things). But everything that goes a little bit more into detail requires specific solutions (best example: water. Actually the RW water has absolutely nothing in common with the JME water, although JME offers great looking water "out-of-the-box", but that implementation isn't compatible with dynamic worlds, or more precisely, voxel based worlds).
When it comes to the translation or rotation of objects or constructions, we have to do our own math (basically a construction element isn't just a single object, it's baked into a mesh with all other contructions in the same chunks (same applies to objects, like furniture). When it's necessary to transform a single element (e.g. opening a door), the particular vertices are just rotated around a certain point (since the game doesn't know anything about the door except its offset in the vertex buffer).
Achieving this is tricky when it's necessary to have a precise rotation. Getting appropriate screenshots is even more difficult, since it highly depends on the camera view (having a parallel projection would be more helpful in this case^^). However, here is a beam which should meet these requirements. It's necessary to use a rotation precision (setr) of 1 (indeed this is a situation where 0.5 degree steps would be helpful). To get exactly this angle, you have to experiment with the x and z rotation a little bit.
@red51, WOW! I am very grateful that, in the midst of releasing an update, you found the time to look into this matter!
I am aware that any floating point operation involves roundings and that this kind of things requires several steps often with trigonometric functions and so on. One more reason for finding a way which requires as few steps as possible to reach the intended result!
Also, I think the level of "required" precision is visual more than instrumental: luckily, RW does not have (nor does it requires) goniometers! If it looks precise, it is precise enough. As an example, the orientation of your beam is precise enough, while the final orientation of the beam in my post near the top of this page is visibly non-precise.
your example shows that the test orientation I though impossible to reach can be reached indeed! This, for me at least, is great new, as it falsifies a hint that the current implementation might be incomplete (and, again, thanks for finding the time to work on it!!!).
However (there was a "however" coming... ), at the moment your example cannot be properly replicated, without a list of steps. As you say: "you have to experiment with the x and z rotation a little bit". I may easily be wrong and I will try (for sure you know RW much more than I do!), but I have the feeling that the list of steps would be rather long for something which ultimately can be described at the sum of two rotations.
I believe this raises some concerns of actual usability (and of user experience, to quote a term now fashionable) for a wide range of projects (three of them I have described above).
Couple of details:
all rotations are basically intrinsic rotations, but they don't work exactly as you may expect. [...] When rotating a construction element (while placing it), you basically just increment (or decrement) the particular rotation values (rotation around x, y and z axis).
When converting these euler angles to a quaternion,...
Sorry, but I beg to dissent. When increasing / decreasing one of the three values of an Euler (or Tait-Bryan) representation, in general the rotation applied is not an equivalent intrinsic rotation around the corresponding object axis.
This might be true, occasionally, for instance if the other two values are 0, but not in general; I think this to be clearly shown in this my previous post of this same thread. In other words, if <a, b, c> represents a rotation in Tait-Bryan angles, <a+n, b, c> does not necessarily correspond to adding a rotation of an angle n around the object X axis (and similarly for the other axes).
since we're going to rework the construction system in the future anyway, we will check out if there is a more convenient way for the rotations
I am sure the dev team has all the required expertise, but if it can be of any help, I can try to work out the math involved in adding a real intrinsic rotation to a Tait-Bryan representation.
.... but you all know that RW is a building/survival game not a CAD programm?