Primitives

[peteihis]

Resolves #126

Creating primitives with a 0 for a dimension is still possible, but it will not break the ObjectInfo. Property dialogs and pose keyframe editors can handle 0-dimensions too.

Using undo at creation time to prevent creating entirely flat objects would not have worked as the undo would still be redoable.

[peteihis]

I just noticed something: The orientation of the created object is not affected at all by which way you draw it. The calculations always produce the exact same outcome (except for the div/0 case). The orientations could just be copied from the view coordinates without need to worry about dividing by zero.

@peastman: Has it been the original intention to change the orientation of the object by how you draw? I believe it has been for a long time as it is now and this would be at least my expectation as a user.

Either which way, I'll rewrite this PR.

Also 'expand from center' function might be a nice addition. Possibly holding ctrl down? Lights have a different function for ctrl-drag but would that be a problem?

Edit: Typos patched.

[peastman]

When you say "which way you draw it," do you mean which corner you start dragging from? Yes, that shouldn't make a difference.

[peteihis]

@peastman:

• By "...by how you draw" I meant "which direction you draw to" or if you like "which corner you start dragging from".
• By "Either which way" I meant: Whether the orientation of the object was supposed to depend on the drawing direction or not, I would rewrite the PR. In the first mentioned case to make the orientation change actually happen and in the latter to remove the unnecessary calculations.

.. And so the case is the latter one. :)

[peteihis]

Ok, I think I'm done with this one.

It went a bit further than just fixing the occasional views going blank. As it turned out the calculation, that caused that had no other effect than the occasional uncaught /0 error.

The changes are not very visible but:

• The possibility of /0 was removed.
• Orientation vectors are taken directly from view camera (z direction inverted).
• Centerpoint and orientation along with object dimensions are recalculated at every MouseDragged event as before.
• Ctrl-down at MousePressed expands from center.
• Shift as before.
• Both keys togethter, produce combined effect.

[peteihis]

@i said earlier

orientations could just be copied from the view coordinates

But to be exact I ended up with:

    ydir.set(cam.getCameraCoordinates().getUpDirection());
    zdir.set(cam.getCameraCoordinates().getZDirection());
    zdir.scale(-1.0);

Y does not need any calculations and z only it's elements' signs flipped. This does not produce new vectors thrown to garbage.

In CreatePolygonTool, there is:

    ydir = cam.getViewToWorld().timesDirection(Vec3.vy());
    zdir = cam.getViewToWorld().timesDirection(new Vec3(0.0, 0.0, -1.0));

Logically the result is exactly the same but (in the Polygon tool) with a longer route to calculate it: When the user rotates the view, the conversion matrix is recalculated based on the position and orientation of the Camera. What happens, when you throw a [0,1,0] into the machine is that, the information travels to the opposite direction and the result actually is the Y-direction of the Camera....

Can anyone find something wrong with this thinking?