.ldr files are created with redundant floatpoint garbage

[ghost]

considering that the pieces are usually snapped into a kind of grid, the resulting coordinates from .ldr are often coming with floatpoint garbage like 59.999547 or -10.000054, instead of 60 or -10 - the toilsome part of this is that i always need to fix them by hand on a text editor

(i guess that floatpoint makes sense on rotated parts and alike, but it looks totally nonsense on snapped parts)

is there some way to get these coordinates rounded into integers somehow?

[nathaneltitane]

I second this ticket as I had (a while back) mentioned this to Leo. I really hope something can be done about this.

[rsbx]

The LDraw Library standard specifies 3 decimal places for parts and non-scaled primitives. However, they don't seem to enforce it. E.g. s/15535s02.dat

[nathaneltitane]

The LDraw Library standard specifies 3 decimal places for parts and non-scaled primitives. However, they don't seem to enforce it. E.g. s/15535s02.dat

Oh my god, I was about to write about this issue to update and see what was up!

Was experiencing weird decimal FP decimals yesterday while updating an old model.

Also, something to note is that when manually overriding coordinates and angles with a 0, sometimes it never goes back to actual 0 but gives 0.007 or similar, or even -0.

[rsbx]

I've run into that alot with a couple of my models with matching oddly angled parts. My work around, which has become second nature at this point, is use a value 1.0 off of the intended value and then correct it to the intended value. My working theory is that the issue is that the new value is too close, by some measure, to the old and floating point rounding error makes it the same. There could also/instead be an epsilon check. Either way it hasn't bother me enough yet to look for it.

…

On 3/18/21 11:47 AM, Nathanel Titane wrote: The LDraw Library standard specifies 3 decimal places for parts and non-scaled primitives. However, they don't seem to enforce it. E.g. |s/15535s02.dat| Oh my god, I was about to write about this issue to update and see what was up! Was experiencing weird decimal FP decimals yesterday while updating an old model. Also, something to note is that when manually overriding coordinates and angles with a 0, sometimes it never goes back to actual 0 but gives 0.007 or similar, or even -0. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAECJNC7C5JR5D4F2QCPXH3TEIOBXANCNFSM4DUFJKSA>.

[j6t]

Also, something to note is that when manually overriding coordinates and angles with a 0, sometimes it never goes back to actual 0 but gives 0.007 or similar, or even -0.

Note that a change must be larger than some limit, otherwise it is ignored. For this reason, you cannot change a position of 0.007 to 0 (the limit is 0.0316). But you would be able to change 1.007 to 0.

[nathaneltitane]

and here we have another example with the latest continuous windows build of the issue persisting:

I have to manually input an integer for the fp garbage to disappear and the reste the value to 0 manually to have a complete, non decimal number...

copying over portion of the model results in these coordinates and rotation vectors being kept - trying to modifiy the rotation vectors to procceed the same way a translation vector would get corrected results in a f***ing mess of compensated values...

[nathaneltitane]

Ref. #80 and merge #81 ??

[nathaneltitane]

@leozide @j6t
I have created a brand new multipart model, without using any external existing 'old' model reference. Everything was built from scratch and assembled in that same mpd file from start to finish. All the orientations we fine and there were no decimals for parts oriented according to the selected grid or when angles were multiples of 90 degree (for side placment) - upon finishing the model, closing the file and reopening it to examine parts for bricklink purchase validity, i now see that parts have decimals and precision is lost, again.

[nathaneltitane]

@leozide here is yet another instance of a brand new model file built from scratch - upon editing a group in this submodel, i selected the parts that needed to be adjusted and arbitrarily used a plate for coordinate reference, i then punched 0 0 0 in the properties panel for the selected plat to realign everything to the grid.

Upon selecting each individual element in the group, they now show decimals when in fact they should have kept their alignment...

[nathaneltitane]

@leozide follow up to this issue which happens still with brand new files using the latest continuous build:

items that are squared off to the grid, when duplicated or rotated start appending FP garbage to coordinates.

see comparative screenshots of submodel with left and right mirrored parts, left being squared and right having the FP stuff added post-operation.

@j6t thoughts?

[j6t]

Can I have a look at the model file? You can send it to my github address if you do not want to publish the file. Also, it would be good to have exact instructions (UI interaction) how you get the odd numbers from the rounded numbers.

[nathaneltitane]

Can I have a look at the model file? You can send it to my github address if you do not want to publish the file. Also, it would be good to have exact instructions (UI interaction) how you get the odd numbers from the rounded numbers.

Sent!

Here are the details, for reference, as per the email I just sent:

_First off, a sfar as method goes, when I set parts in place in the model space, I ensure that all the coordinates are squared off and show round numbers.

I tend to use the duplicate function more often than not, combined with the use of the properties widget panel to toggle the part to the new part i would like to change for that position: this is due to often determining complex positions, and the in-place duplication of parts that are already appropriately positioned is far easier than having to go through insertion and repositioning.

As far as the last follow up image is concerned, said model has been verified for consistency, and to my dismay, after moving that submodel out of a bigger assembly into it's own submodel reference, I noticed the FP starting to appear even though I had removed all transformations and 'zero'd the assembly into it'S new reference for proper editing.

I even went as far as correcting each and every FP position manually to a proper rounded integer value as per the normal LDU position... and after starting to edit (duplicate, rotate, translate, etc) to achieve the symmetric aspect that the little wings convey, the FP had appeared once again on the right (copied) side of the model.

one thing to note is that when manually forcing the position on either x y or z to correct the value, there seems to be some kind of override that prevents manual input if the designated override is too close to the rounding that is being shown (i.e: if value is -11.99997 and i manually edit it to -12, it does not take it and toggles back to -11.9997: i have to first set a greater or smaller rounded number, like -14 first, then set it to -12 for it to stick).

You will find the submodel shown in the latest images under '07-04-orbiter.ldr' in the models list._

Feel free to reach out if you need help or clarifications with my process.

[j6t]

Here is a reproduction recipe. Write this in a file fp-inaccuracy.ldr:

1 0 -100 20 0 0 1 0 0 0 1 1 0 0 2340.dat
1 36 -86 70 -28 0 -1 0 0 0 -1 1 0 0 3024.dat

After loading the file, do the following:

1. Set rotation snap to enabled and 45 degrees.
2. Click the red piece.
3. Ctrl-Click the black piece (this makes a group selection with the black piece as master).
4. Rotate around the red axis by 180 degrees (4 steps).
5. Rotate around the blue axis by 180 degrees (4 steps).
6. Click outside any pieces to remove the selection, then click the red piece.

Observe in the properties that the red piece now has Z position -70.0001. The problem does not occur if 30 degree rotation snap is enabled (rotating by 180 degrees then needs 6 steps, of course).

BTW, it is sufficient to rotate around the red axis in step 4 by 360 degrees to see the rounding error. However, since a 360 is an irrelevant operation in practice, I consider it of the kind "if it hurts, don't do it". But it still stands that the more practical operation with 2 different rotations does show the problem even though neither rotation alone leads to rounding errors.