theeth wrote:-efbie- wrote:That thing annoyed me a lot.
when you select different axis the object disapear somewhere to go somewhere else with absolutely no relation with what you do with your mouse.
Which version are you talking about here? The code in tuhopuu or bf-blender?
How it is right now in bf-blender, it is quite the contrary as it preview directly what the resulting constraint will do.
I just saw that in bf. I found it even more confusing because the objects flickers as you are choosing the different axis. Because i don't see the path between two different constrained states I lost my sense of space and i can't determine anymore where my object is. I even prefered when it was just following the mouse, it was smoother to the eye.
I don't agree with your reasoning at some points.
* You discard the previous system because it was assuming things that the user wouldn't know. But yours do exactly the same ! You are asuming that the users know where is mouse cursor is before making any constraint. The users look at his object, not at his cursor !!! The hands follow the eye, this is common behaviour, you are doing the opposite. You are asking the eye to track where is the hand.
* You say that you aren't sure that the user would know the orientation of the global axis in 3Dview. Ok. For beginners that can be hard. That's why I
purpose tho show the axes whenever someone is transforming an object. and highlighting the axis that would be constrained. First problem solved.
* You say that the user wouldn't know what axis would be used for constraining. This is solved in the previous point.
* If you say it is sometimes difficult to constrain to an axis, i totally agree with you, but it is not because of the old method, it is because the algorithm to determine wich axis is to be used has sometimes a strange behaviour in 3D space, and i think i know why.
From what i observed i think that they compare the motion in 3D space. Since the users thinks he is moving his object on screen it leads to misleading. We should compare the axis orientation on the screen space.
Sounds complicated but it's not :
Let's set us in in the problematic case :
the users moves his object. if he moves it to direction A, he would expect it to be constrained to the X axis, if he moves it to C, he would expect it to be constrained to the Y axis. Until that point, blender don't disappoint the users and effectively does what's expected.
Now what happens if he is moving to the b case ? He should expect it to be constrained to the Z axis. But because the view is slightly more downwards, blender discard this axis and uses on of the two others.
this is what would be expected :
this is my proposal. Use the angles between the axis to determine the correct direction. And an axis would be discarded only in problematic cases such has beeing too perpendicular to the screen.
I totally disagree about your idea for constraining rotations (using the plane defined by the two nearest axis). It is much easier to identify a rotation by the axis it is rotating around then by its plane. Also relying on the user remembering the color code for the axis (no doing any constraint preview) will lead to a methodology of trial/error for a good proportion of them.
I admit that for rotations, your method would be the best as there is no simple way to determine wich direction the user wants to constraint.
but for planar constraints this is my proposal :
or something like that...
The users constraints to a plane by moving his object in that plane direction. It sounds much more intuitive than moving the object in the direction where you don't want to go....
The plane would be highlighted, no need to remember any axis.
I first tought that this system could work for rotation but it wouldn't.
The drawback of all this is that we would have a different method for planes, translations/scales, and rotations constraints. 3 different methods. But more pleasant to use I hope.
).
. stupid me... )
