#495 Issues with the 3D-manipulator

[Pete]

Hi.

A couple of things about the 3D manipulator seem a little bit off:

1) On scene view, when the manipulator is set to local mode (press W twice) the N-axis is not pointing to the Z-direction of the of the object as expected. The rotation handle color instead is staying what it was. (See the picture.) On mesh views the N is the normal direction as it should, but the rotation handle colors are not matching there either.

I think this is because the original plan seems to have been that Z should become N for 'normal' or 'local Z'. So XYZ should become PQN, but in the code the order is NPQ. I'd suggest to move the N last (and what ever follows that). This would also take care of the color mismatch with the rotation handle color.

2) In some cases the location of the tool is going "ping-pong". See the attached video. It does not happen always but in the case of a selected triangle at least.

3) The size is not scaled according to magnification in perspective mode. In parallel mode the tool appears the same size on the sceen what ever the scale is. In perspective mode it should be set to be scaled according to the distance frome the camera position (as projected onto the Z-axis of the camera.)

This last one may not be considered a "bug" but rather a feature request as the PolyMesh-one is not following the scaling in perspective viewing either.

[Peter Eastman]

I think #3 is better as it is. The size of the manipulator is based on what's convenient to manipulate with the mouse. Just because some objects are further away than others, that doesn't mean the manipulator should sometimes be too small to use easily and other times fill the whole screen.

[Pete]

Rethinking a bit: I think you are right about keeping the distance effect in the displayed size of the manipulator when it comes to the distance of each object from the viewing point (see the Perspective.jpg). That's where I got it a little bit wrong. Going back to my original concern, I still think, that magnification should be taken to account automatically. See the other pictures, I think you'll get my point. :)

Earlier it was not possible to recalculate the size for the manipulator in perspective viewing, because both of the variables (scale and distToScreen) that affected the scaling had fixed values. Now the new variable distToPlane in perspective corresponds with the scale in parallel. The resizing factor would then be distToPlane/distToScreen.

And I might add #4: Wouldn't it make sense that, when the manipulator is set to rotate objects around their local origins, it would also be placed in the object's origin? -- In the case of only one object selected, that is.

[Peter Eastman]

I think perspective.jpg shows why this would cause problems. In the manipulator at the back, everything is really cramped. The scale and move handles are overlapping, so it will be hard to control which one you click on. The blue and green circles have become very narrow, so it will be hard to control which side of them you click on. And objects can easily be a lot farther away than that.

[Pete]

I think perspective.jpg shows why this would cause problems.

I guess it does, tough in the Mag_high.jpg and Mag_low.jpg it's even worse. In the case of Mag_low, the user can't even resize tool as the handles are outside the screen.

In the Perspective.jpg the problem is not actually very real. The last spehere is too far to do any work on it anyway. I would just move closer and find a viewing angle that works for me. That's what modelers do all the time not even thinking of it but if the tool requires resizing, when the scaling changes (and the scaling can change much more than between tens and tenths of a unit like in the example), that is an extra task, that distracts concentration.

[Pete]

Another issue: When an axis is mostly pointed towards the screen, the 3D-movement along that axis does not keep up with the mouse movement. The on-screen drag-vector of should be projected back onto the 3D-axis that is being used.

[Pete]

And yet another one: (#6 I think) The polygon shape of the rotation feedback is filled only on postive or negative angles. Which one, depens on the viewing direction.

I wonder if the shape shoud be read in reverse order in the invisible cases? At least it can not be a 3D-rendering issue as the pattern is drawn in 2D.

Edit: This is a problem, that occurs with the GLCanvasDrawer.

[Luke S]

Pete, did some of our recently merged PRs take care of most of your concerns here?

[Pete]

At least #1 and #3. Not #2, #4 or #6.

The one mentioned before #6 (not dragged in scale when z-movement is involved) was taken care of but it works with non-perspective rules. In perspective mode there is some error. The gorrect movement, when depth change was inncluded turned out to be pretty complex process ... I tried to map it out on paper but still did not get it quite right.

So a kind of half way done.

Then there are the issues with selected faces and edges (#7), were the local mode orientation is wrong. (=just averaging vertex normals, ingoring teh actual selected element.)

Another, not so visible thing to users is that the 3DManipualtor is forced to the format of Manipulator. Which is which are 2D-manipulators designed to work through "view" coordinates. The 3DManipulator communicates directly with the scene or model coorinates and the unnecessary view transfromation causes all kind of little trouble along the way, including the #2.