DO *NOT* use Snap To Grid with Local Axis on!

Im not sure if this has been posted before, but having snap to grid with local axis enabled messes up the axis-drag constraint set by the former option.

The object I was building with had its axis parrellel to the global axis. (Its X-rotation was set a -90 degreres, Y and Z were 0.)

I set a grid unit of 0.125 meters. With local axis disabled, when I dragged an axis arrow, the object snapped to multiples of 0.125 (1.0, 1.125, 1.25, etc).

With local axis enabled, when I dragged the object up (along -y axis), it snapped to a position of 1.118 from 1.0. I dragged the object up again, and it snapeed to 1.243.

Obviously, this is not the intended behavior (espicially with axis parallel to the globals.)

==Chris

I think the behavior is that, with Local Axis on, the grid rotates around the object's center, and the 0,0 ref point of the grid becomes the same point. With Local Axis off, the sim's 0,0,0 point becomes the center.

So even with the target object at ZERO_ROTATION, the grid snap points WILL be different with Local Axis on.

Christopher and Tiger,

May I quote you both on this in the Ivory Tower building tutorial? Very good information here.

Lumi

** deleted **

Lemme see if I understand what you said:
Your basicly stating that, with local axis on, snap to grid adds the grid unit to the object's current position, instead of snapping to multiples of the grid unit.

So, with local axis on, a grid unit set to 0.125, and an object at 1.001 Z, snapping the object up one unit, will position it at 1.126, not 1.125. That's a viable explanation, but Im afraid it still doesnt explain the quirk.

In my case, the object's axis (axes? What is axis plural?) were parallel with the world's axis, and the object was at 1.0 exactly when I started the test, so, when I move the object up one snap, theoreticly it should be at 1.125. Your explanation doesnt explain why the object snapped to 1.118 from 1.0, and then 1.243 from 1.118.

It actually looks like some sort of rounding error, since 1.118 is quite near to 1.125, and 1.243 is very near to 1.25.

Maxx, snap to grid is actually quite accurate, you just have to constantly check that it is. I would have never caught this inconsistancy had I not checked the edit window numbers after snapping. I havent found any problems with using snap2grid without local axis on.

==Chris

:blush:
Im honored, sure!

==Chris

** deleted **

I almost always link before rotating things. Of course, this can be a problem if parts were already linked together, and need to be again when I'm done rotating.

But I've had unlinked groups rotate themselves into spaghetti on me! Sometimes it's just an update issue, and nudging them or relogging puts them back as they should be, other times only a control-Z will recover... And sometimes, not event that will work. (But I think the undo bugs are mostly gone now.)

Thanks so much!

Personally I don't use the grid or snap to grid at all...but so many fine builders do, and they've recommended that I include an exhibit on it in the Ivory Tower. So....I'm going to try to cover it in my own, exhaustive way.

So many people to interview...so little time, but my gosh I'm loving this project!

Lumi

Had something very odd happen last night. I was practicing building large domes and got a bit extravagant. I wound up with a module that was 126 linked pieces something like 30X30X30 meters in size. I copied this and rotated the modules into new positions to make something quite large and baroque looking, but when I was done, two of the modules had come completely unlinked. The positions of all the elements were correct, but they were no longer linked.

Struck me as very odd.

I deleted the thing, as it caused a lot of lag in the sim, but I'll experiment with this more later.

Lumi

Rotating without linking will inherently introduce floating point error into your offsets, due to the actual value (calculated as a function of sine or cosine for example) being placed into a floating point variable (which has finite precision).