Tuhopuu3 / Windows (2005/03/04)

User-contributed CVS development builds. Please test and give feedback!

Moderators: jesterKing, stiv

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- »

theeth wrote:Oh, I see why you're all asking for the "don't move object" thing. The development of the new transform code is no longer done in tuhopuu, so it lags a lot behind feature-wise as it's only synched once a week. I'd appreciate (and so will you probably) if the testing on that was done on bf-blender builds as this would much more reflect the up to date work (and the bug/to do list in the wiki ;) ).

Back to the first point, when selecting a constraint, it now activates the constraint which is highlighted, so you have an instant preview before releasing MMB. I think that is even better than not moving the object at all (and was suggested by slikdigit).

Martin
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. Its really unintuitve, especially for roations.

the old system was great because you only had to do one mouse move to constrain and go in a direction.

the current system requires moving to select the axis, and then changing the direction to move the object. It's one thing too much. it's not annoying in the beginning, but when you use it for production and you must constrain every 0.2sec, it become really annoying. This part of interface is really capital and we should find something : fast,intuitive, elegant, and easy to extend for new transforms. the current system is elegant, but not fast and intuitive.

I would keep the old system and improve it by :
* displaying the axis when your move and highlight the one that will be constrained if you press MMB, a sort of 'preview"
keeping alt pressed would highlight the planes instead of the axis.

* the axis is chosen with the smallest relative angle between the motion and the axis direction.

Why wouldn't that work ?

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

-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.
Its really unintuitve, especially for roations.
Before saying it's unintuitive, did you even try it in bf-blender?

I've explained my reasoning at length in the tuhopuu-devel mailing list, feel free to read: http://projects.blender.org/pipermail/t ... 01081.html

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.

Zsolt: Bolder axis and drawing planes are on the todo.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

SamAdam
Posts: 0
Joined: Thu Mar 04, 2004 1:28 pm
Contact:

Post by SamAdam »

okay.

i noticed that the first version of the easy grab tool is different from this one.

I used to be able to click and hold to drag, and then release.

now i click and drag once to grab and then lmb again to release.

i liked the first one much better...
i thought it was the best tool yet!

is there a way to switch the modes?

Bellorum
Posts: 0
Joined: Wed Jan 21, 2004 3:27 pm

Post by Bellorum »

I used to be able to click and hold to drag, and then release.

now i click and drag once to grab and then lmb again to release.

i liked the first one much better...
I agree fully. An option, please.
There's no such thing as democracy. There's only the tyranny of one, and the tyranny of many.

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- »

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've explained my reasoning at length in the tuhopuu-devel mailing list, feel free to read: http://projects.blender.org/pipermail/t ... 01081.html
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 :
Image
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 :
Image
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 :
Image
or something like that...
Image

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.

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

-efbie- wrote: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.
I never said the current system was perfect (heck no). I tried pretty much all the alternatives (using the delta vector like you suggest, using the transformed center, ...). Using the cursor was the less ambiguous in the majority of the cases (feel free to disagree).
-efbie- wrote:* 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.
And I know exactly why, having spent hours analysing/working on/breaking the old system.
-efbie- wrote:We should compare the axis orientation on the screen space.Sounds complicated but it's not :
<snip>
this is what would be expected :
Image
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.
You do realise that this is what the new system is doing, right?
-efbie- wrote:but for planar constraints this is my proposal :
Image
or something like that...
Image
C is practicly what I'm already doing except that you only use one side of the axis (X, Y, -Z). The funny bit would be determining which to use depending on the orientation.
-efbie- wrote: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....
Not if you think of it as "locking" that axis. Which is exactly what is displayed in the headerprint: "along global Z axis" and "locking global Z axis"
-efbie- wrote:The plane would be highlighted, no need to remember any axis.
Agreed, the current drawing method has definite place for improvements (thicker axis, drawing planes, ...)


Also, you mentioned skew (shear I guess) in another post. This would require a specific 2 axis constraint (not a plane) to know the affecting and affected axis. Warp would probably work with a single axis constraint, but it would require some changes to how the wrapping is done (probably not much though).

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- »

theeth wrote:
-efbie- wrote: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.
I never said the current system was perfect (heck no). I tried pretty much all the alternatives (using the delta vector like you suggest, using the transformed center, ...). Using the cursor was the less ambiguous in the majority of the cases (feel free to disagree).
Maybe you tried many things but since the beginning of the refactoring it has always been mouse cursor location oriented, and it is in my opinion a bad choice. I want to be able to move the object on the top left of the screen with my mouse cursor in the bottom right.

* why ? let's do a scale, extrude, scale, extrude in a row. After each scale, your mouse cursor isn't anymore near the object center, it is located near a random axis with a very small chance that it would be the good one for your next action.

* Let's do really small grabs, or adjustements, a few pixel high. it is nearly impossible to choose the right axis in thoses cases without making big useless moves. It is really annoying when you must adjust your verts like when you are modelling a face.

* having to choose an axis each time is just too slow. When everyone say that the huge advantage of blender is it's speed the current method goes agianst all that.
-efbie- wrote:We should compare the axis orientation on the screen space.Sounds complicated but it's not :
<snip>
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.
You do realise that this is what the new system is doing, right?
This is what we are doing with the mouse pointer absolute position. I want that with the mouse pointer relative position.

at least for grab and scale.

(now that i think of it, i could have said that since the beginning, it would have avoided me lots of stupid mockups :D. stupid me... )

C is practicly what I'm already doing except that you only use one side of the axis (X, Y, -Z). The funny bit would be determining which to use depending on the orientation.
the D is easy : you project the axis on screen, pick the two who are surrounding the pointer (relative position) and theses axis determine the plane.
the C is effectively a little less easy. it would involve computing the camera coordinates in the space with an origin centered on the object, and axis determined by the constraining axes. the signs of the coordinates determines the three axis directions to use. then you use the plane determined by the two axis surrounding the relative cursor position.
-efbie- wrote: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....
Not if you think of it as "locking" that axis. Which is exactly what is displayed in the headerprint: "along global Z axis" and "locking global Z axis"
I agree it is intuitive for my head, but not for my hand. It requires time and a mental gymnastic to get used. Maybe it is worth it, i don't know.
Also, you mentioned skew (shear I guess) in another post. This would require a specific 2 axis constraint (not a plane) to know the affecting and affected axis. Warp would probably work with a single axis constraint, but it would require some changes to how the wrapping is done (probably not much though).
this will be a hard thing to do. Maybe we should find a totally different approach like a "working plane" that would define defacto the plane where such transformations would happen.
Last edited by -efbie- on Fri Mar 11, 2005 11:16 pm, edited 1 time in total.

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

Ah yes, while I remember, I have plans for a "Reuse last constraint" fonction. Maybe with the user option to always have it turned on.

Could cause some problems for some specific case, but nothing too hard.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- »

would it be like remembering the last axis chosen ? or remembering the last transform performed ? because i don't think i'm understanding it well ?!? :?

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

The last axis chosen.
Life is what happens to you when you're busy making other plans.
- John Lennon

Post Reply