When zero is not zero


#1

I understand floating point values in computers to be imprecise representations - you know 1.0-1.0=.0000001 : )

That being said.

Take a 16384 x 180 x 16384 M mesh, place it at 8192,(180 / 2),8192 in domain.

Go to 0,0,0 corner with AV and back out a bit so you can sight along axis.

If you’re lucky it’ll line up with the axis bounds, if not you’ll notice it’s off. So you open properties for model and see it is at 8192,90,8192 and it’s size is 16384,180,16384 then you notice the rotations are -0.002, -0,002, -0.002 and think that’s it, over 16KM that’s a fair bit of rotation so you set to 0, 0, 0 and see the model snap into perfect placement with the corners of domain bounds. You relog and wait, it’s askew again! so you open properties and sure enough it’s -0.002… again so you change it to 0, close the dialog and this time it corrects then immediately goes back.

It seems somewhere somehow we’re doing floating point maths and hitting precision/round off errors. Personally I’d just define it all in integers cm or mm, whatever finest resolution needed seems, but that’s just me.

I’m attaching a video showing this anomaly - my capture doesn’t pick up the dialogs but what I’m doing is, looking at mesh out of alignment, open properties, fix, it’s good, open properties again it reverts to something not 0,0,0, for rotation… fix again - this time it only briefly stays then snaps back to offset. I’ve found this to be consistent since starting to rez large mesh objects. If you can get luck and on 0,0,0 rotation it won’t stay as eventually you’ll touch it and it’ll jump to some new slightly off zero set of rotation. Locking doesn’t help as if you open the dialog when it’s correct to lock it messes it up and you have to repeat until you get lucky again.

I also see the size values do this, for example sometimes you end up with 16384.0,180.001,16383.998.

All this will make working with large objects a real pain or, small objects in close proximity!

Video of rotation error in action.