Hi,
I was thinking that orientation feature in Preform could use a bit more flexibility, especially now after 1.9. software release. My problem is it only has global rotation as a way to manually rotate an object. Often I would like a local rotation (with object’s xyz axis), this would be useful if an object has a distinct features, let’s say one dimension is much larger than other two and rotating in global axes would be counter intuitive.
Also, relative degrees displayed in orientation box is a good idea but still a global units would be useful sometimes. Let’s say I have couple of different models with support structures that I oriented to fit the build platform and then realized one of the models has a problem and need’s repairs in 3D software. I fix, load it back in Preform and getting it’s rotation back to where original model was is a bit of a hassle. Copying rotation from a first model would make things easier. Position is not a big problem since it needs just two axes to get it back to where I want it. Also, to round it all up, I am used to global and local rotations from my 3D software and trust most modelers are so IMO this is over simplistic approach. Maybe a switch between global relative, global absolute and local absolute would be my preferred choice.
Thanks for the well-thought-out and detailed feedback.
The main reason that we got rid of persistently visible global rotation angles is that their behavior is confusing. For one thing, the order in which the rotations are applied affects the final orientation of the model. Furthermore, because the rotations are applied one after the other, modifications in one of the fields can seem to behave incorrectly – for instance, changing the X angle value could seem to rotate the model in the Z axis, or some other difficult to visualize axis, depending on what is in Y and Z. One result of this was that some users (very understandably) complained when the tool behaved counter-intuitively.
Allowing only relative rotations in the fixed, global X, Y, and Z axes resolves this confusion, but introduces a different problem, namely that it can be hard to reproduce an orientation exactly. We are working on ways to improve this aspect of orienting a model. For now, the simplest workaround that I can think of is: If you have two models that you want to be oriented approximately the same way, you can reset both of their orientations, select both models at the same time, and apply the same sequence of transformations to them.
Any ideas about how to quantify a model’s global orientation using a persistent coordinate system are welcome.
I’ll make a mental note about your suggestion that we allow rotations in the local coordinate system of the model. It’s an interesting idea and technically no problem – the main questions would be whether it’s worth adding the complexity to the interface, and where in the UI such a feature would fit.
thanks for your reply!
I agree that absolute global rotations are not an elegant solution and there are too few cases it is really needed. I appreciate the effort to keep things as simple as possible on the UI but nevertheless I think orientation is the second most important option (right after support’s). Most modeling software usually have multiple options to rotate the object (global, local, normal, view, etc…) and of course this is not an option here. Of all I have written in a first post I think my vote would go to local rotation as a most needed one, especially for technically designed models (opposed to organic models).
My suggestion is to add a rotation manipulator on selected object (when orientation box is active), something like a fixed gimbal circles (not really a gimbal but I used it to describe my point). It wouldn’t even need any numerical counter for this, it’s just an easier way to manipulate an object around it’s axes.
I don´t like the orientation in the new Preform 1.9. I can´t copy the orientation of an
older part, so I must do the whole work of orientation again. :-(((((
Also I missing the absolute values of orientation in the window.
So I am back to version 1.8.2, this runs fine for me with the orientation.
Yes, something like that, although arrows here probably indicate translation so not really a need for them but rather something like the red line to indicate rotation.
The idea to include manipulators as seen in other CAD software is one that we’ve thrown around for some time, and they would indeed make the UI of multiple-coordinate-system rotation options much simpler. We’ll keep this in mind for the future!
I think I have to disagree with you on this one, but maybe we’re on the same page with global relative…
If the build space is thought of as a single orientation space (as it actually is in physical reality), then the angular orientation of objects within that space should be relative to that space. Why does each object fail to retain its’ set angular values? No idea. That seems like it may be a bug or implementation inadequacy to me.
Global angular orientation (not position) is the simplest and most logical orientation method in a non-editing environment. It matches exactly the reality of the build environment. I have not upgraded to 1.9 myself, so I have yet to actually experience the change, but from what I’m reading there appears to be a conflating of two behaviors that may not need to be exactly related, e.g. using a global xyz space, and saving the configured orientation of a specific object (or not resetting it to zero). Keep in mind we’re only concerned with the object’s angles relative to the fixed global axes - not positions in 3space.
So, to be more clear, the axes need to be fixed in orientation relative to the build platform, e.g. do not angle with the part, yet are still relative to each part, e.g. 0,0,0 (part pivot point) per part is always at part center of mass. Orientation then is really an angular translation about the part’s center of mass - we’re actually moving the part, not moving the view of the part. Again, this matches the reality of what we’re really doing physically, so makes the most sense.
Another, semi-related issue is that X and Y in Preform are oriented backwards compared to literally every CAD program in the world. This may make understanding the part’s orientation counter-intuitive if you are thinking about its’ orientation as it was in the space where you created the object.
The issue with retaining the displayed X,Y,Z rotations relative to the global coordinate system is most easily demonstrated by example, using PreForm 1.9.
The behavior of the orientation tool in 1.9 is that it lets you apply rotations to your part about the fixed global coordinate axes. So, for instance, you can apply a 90 degree rotation about the X axis, and then to the resulting part apply a 90 degree rotation about the fixed, global Y axis. You could also apply these two rotations in the opposite order. I encourage you to try this: you should see a different resulting orientation.
(To get nice visual feedback about what the rotation tool is doing, you can hover your mouse cursor over one of the X,Y,Z boxes, and move your mouse wheel up and down.)
The important point is that because the resulting orientations are different, there is ambiguity about which of these two orientations a display of X: 90, Y: 90, Z: 0 would refer to. I believe that this is the source of a lot of the confusion about the 1.8 orientation tool.
You are right that there are two, mostly separate issues being discussed:
how to store and recreate a given part orientation – this was possible with 1.8, for example – and
what axes the orientation tool rotates around when you change its values, or input values. (In 1.9, inputs rotate parts about the fixed, global X,Y,Z, axes. In 1.8, part rotations were also applied about the fixed, global X, Y, Z axes, but in a fixed order, so the tool appeared not to behave this way because of the issue I described above.)