yep, still a problem in the latest release. Screenshots:

1. Insert the part. Note integral position and rotation

   

2. Rotate 180 degrees. Note that the angles are no longer integers

   

3. Translate along some axis that isn't the rotation axis. Now the positions aren't integers either.

   

There is related video "LeoCAD fine positioning problem"

• https://www.youtube.com/watch?v=3U6lPXjr3Os

That looks like an unrelated problem to do with projecting mouse movements to me. It's also 10 years old - is that bug still present?

I cannot reproduce this with version 21.03. I think this report can be closed.

I cannot reproduce this with version 21.03. I think this report can be closed.

But there still is decimal garbage on part translation/rotation

Although infinitely small, the reported coordinates are never perfectly rounded.

I am very curious how you do that. Can you please show an example created with version 21.03?

The only case that I observe oftentimes is that the Properties show 360 instead of 0 degrees. But I can usually correct this by changing it to 1 degree and then back to 0. I even use rotational snapping at the default of 30 degrees (although I basically only need 90 degrees), and the values round nicely to 0/90/180/270. After such rotations, shifting the pieces using the arrows always show nicely rounded position values.

I should add that I only ever use the pick tool, not the drag or rotate tools. I move and rotate using the red/green/blue arrows. Just in case it makes a difference.

Note that the original reproduction I gave has been fixed by correcting the definition of pi in leocad to be the most faithful 32-bit float definition. The issue almost certainly remains, but likely is harder to reproduce than it used to be

I am very curious how you do that. Can you please show an example created with version 21.03?

The only case that I observe oftentimes is that the Properties show 360 instead of 0 degrees. But I can usually correct this by changing it to 1 degree and then back to 0. I even use rotational snapping at the default of 30 degrees (although I basically only need 90 degrees), and the values round nicely to 0/90/180/270. After such rotations, shifting the pieces using the arrows always show nicely rounded position values.

I should add that I only ever use the pick tool, not the drag or rotate tools. I move and rotate using the red/green/blue arrows. Just in case it makes a difference.

This happens with models loaded from previous versions or that have been built with different editors - I had referenced a similar note regarding FP garbage in another issue entry but cannot find it.

Idea is that if one wants to move or return the part or submodel to a rounded angle position or to a normal LDU position setting, there alsways seems to be the need to override the x/y/z and angle with manual integer input to rid the input of the decimal 'garabage' before being able to (again) input coordinates or angles and obtain the rounded, non polluted entry (0, 90, 360, etc)

P.s.: I always use the latest continuous dev builds

This happens with models loaded from previous versions or that have been built with different editors

What do you expect? When the numbers are in the LDR file, then they tell the truth. It does not matter that old versions of LeoCAD were sloppy. What is in the file, has to be preserved as close as possible, regardless of whether it is "garbage" or not. As far as I am concerned, I would not like a tool that does not round-trip its files faithfully.

Of course, you have to touch every number manually. What you can do is go to the LDR file in a text editor and search-and-replace the ugly values. (I have done that in the past.) As long as all your pieces are on integral positions and multiples of 90 degrees, this should be straight forward.

The problem that I faced in the past is that LeoCAD has a lower limit of a change: if the change, even when it is by typing a value in the Properties, is too small, it is ignored. That's why I said that I had to change angles to 1 degree and back to 0; replacing 360 by 0 amounts to a change that is too tiny. Some time ago, I had a look what could be done, but couldn't get a grip on it.

Modern LeoCAD does not place pieces on "ugly" angles or positions anymore. The problem addressed by this issue has been resolved.

running latest build... -0 (wtf?)

Latest windows continuous build - brand new model, brand new parts inserted in main model, then cut/paste into new submodel entry for editing...

I cannot reproduce with your instructions. (But I do not know what you mean by "for editing", though.) Can you please be a bit more precise.

I see 9 Objects selected in your screenshot and Group number 1 is also mentioned. Are you sure you are looking at the properties of a single piece?

I cannot reproduce with your instructions. (But I do not know what you mean by "for editing", though.) Can you please be a bit more precise.

I see 9 Objects selected in your screenshot and Group number 1 is also mentioned. Are you sure you are looking at the properties of a single piece?

that group was initially creatied as an inline within the main model and oriented to test the fit.
I cut the group out, created a new submodel entry for it and pasted it in there
I then selected the part (IN BLUE) to use its properties and line the group up with normal coordiantes/orientation:
manually overrride the position and rotation input boxes with 0s)

And yes, I am sure i was looking at one part'S properties since the properties listed in the capture are the part i selected that is highlighted in blue.

Do you use Leocad enough to understand how it functions?

EDIT:

and here'S more evidence of FP garbage...

The ``-0'' is most likely rounding in the printf-like code for a negative floating point number with a very small magnitude that should be 0 except that some floating point approximation/rounding occured.

The FP garbage is due to the limits of the float type precision and the approximations inherent in the trigonometry code. Using double instead of float everywhere would make it less noticeable but at with a significant performance impact on some platforms.

Affine transformation matrices using fixed sized values have a precision limit and conversion from the transform matrix to Euler angles for the display can only decrease precision.

The FP garbage is due to the limits of the float type precision and the approximations inherent in the trigonometry code. Using double instead of float everywhere would make it less noticeable but at with a significant performance impact on some platforms.

Affine transformation matrices using fixed sized values have a precision limit and conversion from the transform matrix to Euler angles for the display can only decrease precision.

but if the math is based off LDU which is a fixed precision finite number to work off of, besides infinite precision rotation angles, translations should always be able to give you a round number, no?

In general, no. The rotation angles don't have infinite precision and they are "merged" into the affine transformation matrix using the sin/cos value approximations from those angles.

@nathaneltitane As long as you start your argument from an existing model, it is easy to dismiss your complaint: You are just starting off from a model that already has the garbage values. It is impossible to reproduce your problem if you do not provide exact description what to do and if you do not make the model available.

In general, no. The rotation angles don't have infinite precision and they are "merged" into the affine transformation matrix using the sin/cos value approximations from those angles.

However, as long as rotations are only by multiples of 90°, the resulting transformation matrix consists only of 0 and +-1, and LeoCAD gets it right in the models that I make. With one exception, as I already said: I observed 360° when the result should be 0° after the rotation.

@nathaneltitane As long as you start your argument from an existing model, it is easy to dismiss your complaint: You are just starting off from a model that already has the garbage values. It is impossible to reproduce your problem if you do not provide exact description what to do and if you do not make the model available.

this latest post is a fresh model...

this latest post is a fresh model...

It would be helpful if you could post instructions. The screenshot does not show in which order you assembled the parts. Also, the snap options could make a difference, and whether you placed the items by dragging with the mouse (and where) or by hitting the Ins button on the keyboard.

this latest post is a fresh model...

It would be helpful if you could post instructions. The screenshot does not show in which order you assembled the parts. Also, the snap options could make a difference, and whether you placed the items by dragging with the mouse (and where) or by hitting the Ins button on the keyboard.

I always place my first part by dragging it out of the parts list then I manually set its position to 0,0,0

As a habit I then duplicate that part and switch the duplicate using the properties part entry to whatever I need.

my snap options are default and use regular ldu connections that obey part/stud placement by either rotating a duplicate then translating it into place or by dragging a new part to the corresponding stud placement while the previous part is on blue.

I fail to see how the steps could help in understanding the issue since all part insertion methods and translation/rotation steps should bare the same and result when positioning parts relative to one another according to where their studs are...

Thank you for the details. The workflow that you have described should not introduce rounding errors ("garbage in the decimals") with modern LeoCAD (except for the 0°/360° error I've described earlier). If you find a case, you would have to recite the exact procedure, starting from an empty project (or a given LDR file that does not already have any rounding errors).

Thank you for the details. The workflow that you have described should not introduce rounding errors ("garbage in the decimals") with modern LeoCAD (except for the 0°/360° error I've described earlier). If you find a case, you would have to recite the exact procedure, starting from an empty project (or a given LDR file that does not already have any rounding errors).

well the latest screen caps I introduced 2 days ago were from a fresh build using a new model file without any precedent....

Let me do this:

• Start LeoCAD.
• Click Plate 1 x 2 with Handle Type 2 and drag it near the origin.
• In Properties, set all of X, Y, Z to 0.
• Click the Z (blue) rotation handle and rotate by 180°.

Since this is the position that you want to have this piece in (see first screenshot), I'm stopping here. At this point, all of X, Y, Z are still zero. I do not have -0 anywhere. Also, I have angles X and Y at 0, not 360. Please repeat this procedure with your installation and let us know which values you observe.