Thinking about doing a LDCad 1.7 version

[Miguel Reizinho]

But this would not be consistent with part bin implementation, and filter allows for example to show all "blue" colors and let you choose.

You are right, the behaviour would be different.

[Roland Melkert]

You are right, the behaviour would be different.

I prefer to make it as much the same as the filter in the part bin. So there will also be a special 'search' group for the color bin which initially shows nothing until you enter a filter.

Only thing I'm still not sure about is the space it takes, as it's not always needed and I kinda liked the minimal sized color window. Making it opitional is kinda tough because the 1.x gui rendering is currently very static (2.0 is basically a html like engine whom handles 'div' sections )

[Miguel Reizinho]

I prefer to make it as much the same as the filter in the part bin. So there will also be a special 'search' group for the color bin which initially shows nothing until you enter a filter.

Only thing I'm still not sure about is the space it takes, as it's not always needed and I kinda liked the minimal sized color window. Making it opitional is kinda tough because the 1.x gui rendering is currently very static (2.0 is basically a html like engine whom handles 'div' sections )

Perhaps a dropdown list for v2.0? I really like the color pallete from stud.io. It's very pratical and I would welcome something similiar in LDCaad. It has ability to filter/search, the colors are sorted alphabetically and by type (solid, metalic, transparent), and has a left vertical toolbar where you can see color groups and click on it to see only colors of that particular hue (in the image, the magenta color group was selected):




In MLCad I used to have the colors on a vertical toolbar to save up some space:

[Milan Vančura]

So I'm thinking to do a 1.7 version instead with a couple of more things I wanted to do in 2.0. But that version is a looooooong way out.
....
If anyone has some additional ideas this is the time to let me know.

This is great message, Roland, thanks a lot.

The top of my wishlist (filtered for features hopefully doable in 1.7, without full code rewrite in 2.0):

* color bin: textual color search - exactly as it is described in this thread
* color bin: "special color bins" similar to special part bins: colors in current (sub)model, colors in all the mpd of current (sub)model - makes model editing much faster
* performance: maintain the list of "open" snap points (objects) so only those snap points "on the model surface" are counted. Typical example: moving more complex submodel in the main model. This makes my computer completely overloaded today.
* UI: avoid that big jump when moving some submodel or part with hotkeys (in coordinate system) and then trying to fine-tune the place with a mouse. For me, this is the most annoying feature of LDCAD, esp. because I need this workflow when my computer is nearly frozen because of the problem in previous point.
* documentation of scripting language: full documentation of LDCAD API plus some howtos or tutorials. This is missing so much!! It should be probably the point on the top.

[Owen Dive]

<snip>
* documentation of scripting language: full documentation of LDCAD API plus some howtos or tutorials. This is missing so much!! It should be probably the point on the top.

Yeah but nobody wants to write documentation when there are fun features to develop!

[Philippe Hurbain]

Yeah but nobody wants to write documentation when there are fun features to develop!

Sure! one thing that could be done while (perhaps) not beeing too tedious would be to provide some simple scripting examples (like a 3 gears geartrain, a 4 bars linkage or a rack and pinion steering). All these exemples are already provided in existing scripts, but are included in overwhelmingly complex models and scripts.

[Philippe Hurbain]

If anyone has some additional ideas this is the time to let me know.

- It would be very nice if the bezier handles were visible during control point move (after duplication with insert). That would greatly help to figure out current orientation.
- I still find that control points arrows are too thin. If they were 3 pixels wide instead of just one they would be more visible and easier to select (so many times I select the part behind...)
- Wondering if an "average" function would make sense. It would orient a control point to follow a smooth path between previous and next control points.

[Roland Melkert]

- Wondering if an "average" function would make sense. It would orient a control point to follow a smooth path between previous and next control points.

I'm not sure what you mean here.

I wrote the LDCad code based on this information:

https://en.wikipedia.org/wiki/B%C3%A9zier_curve

Specifically the first one in the 'Higher-order curves' section.

Or do you mean the "Quadratic curves" one, which only have a single control point.

[Philippe Hurbain]

Here is the idea I have in mind:
   
Sensor, plug and blue brick are fixed, but of course the cable must avoid the brick. When I insert a new control point to get around the brick, I end up in the middle configuration, with a pinch in the cable. The "control point" smoothing function would somehow average (with some weighting depending on distance) the other two control points directions in order to set a "plausible" direction and twist.

[Michael Horvath]

Could you maybe add a special "View" mode, where all controls are for moving the viewpoint and we cannot accidentally touch and alter a part? Thanks.

[Philippe Hurbain]

Could you maybe add a special "View" mode, where all controls are for moving the viewpoint and we cannot accidentally touch and alter a part? Thanks.

The view mode is already there. Click on the name of model on top right of edit window and select "view" tab.

[Orion Pobursky]

I've noticed that sometime when I snap something (especially a bunch of things at once) to grid or reset the orientation that it doesn't snap all the way but instead gets very close (the largest error I've seen is 0.01 on position, the matrix is usually super close like 0.0001)

[CJ H.]

I'd like to see a configurable keyboard shortcut that would open the part bin display filter regardless of where the mouse is.  I'm usually finding parts by entering a part number in the filter, and having to mouse over the parts bin to open the filter feels slow.  Thanks for considering it!

[Johann Eisner]

I don't know if anybody have this wish already,
but a german language package would be nice. ?
Maybe in the 2.0 Version.

[Roland Melkert]

I've noticed that sometime when I snap something (especially a bunch of things at once) to grid or reset the orientation that it doesn't snap all the way but instead gets very close (the largest error I've seen is 0.01 on position, the matrix is usually super close like 0.0001)

Precision has always been an issue even while using all double precision variables.

The main reason is the mutation is applied as a 'difference' to all the parts in the selection.

So if the main part in the selection has been mutated a lot (or is read from low decimal count file) the rounding errors will be amplified.

Alternative might be to use 'snap all to edit grid plane' from the placement menu.

[Roland Melkert]

I'd like to see a configurable keyboard shortcut that would open the part bin display filter regardless of where the mouse is.  I'm usually finding parts by entering a part number in the filter, and having to mouse over the parts bin to open the filter feels slow.  Thanks for considering it!

F3 works while the mouse is inside the bin instead of just the filter text box area.

And if you want a global key you could make that happen by writing a small macro, like:

Code:

function runBinSrc()
  local act=ldc.action('partBinWin_filterOpen');
  act:run()
end

function register()
  local macro=ldc.macro('Global bin src')
  macro:setEvent('run', 'runBinSrc')
  macro:setHint("Open the filter dialog of the last used part bin.")
end

And then assign F3 to that macro using the hotkey configuration dialog (right click on the tool bar).

[Roland Melkert]

I don't know if anybody have this wish already,
but a german language package would be nice. ?
Maybe in the 2.0 Version.

2.0 will be language independent but that version is a long way out.

1.x uses mostly central constants for all non dialog texts so if someone translated that it would be possible to compile a German version. But all the dialogs will still be English.

[SNIPE]

Some ideas:

Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.

The ability to select all parts of a given type or color does exist but only if you assign a keyboard hotkey for 'select working part' or 'select working color' and then holding shift when you want to do 'select working part' / 'select working color' a second time. But shift does not work with the menu item, only a hotkey so maybe add shift support to the menu item and also assign a keyboard shortcut by default for 'select working part/color' because it is used super often.

Also a 'select all connected parts' like in LDD would be cool.

The ability to rotate multiple bricks but where they have their own rotation centers instead of a single rotation center where everything else selected orbits that.

A secondary color ootion like in MSpaint by right clicking on a color square in the color menu and having a second long square telling you the currently selected secondary color.

Also the ability to automatically align another part to a part with a diagonaal edge like a wing plate. example

A new 'node view' editing pane like in the following video for auto generating parametric structures like in grasshoooer/blender: https://youtu.be/8TFrz2eWyB0?t=865

Regards, SNIPE

[N. W. Perry]

Here's an idea I just had (and given our experience with LDCad, I wouldn't be surprised if this isn't already possible and I just don't know it). 

What about being able to modify the "insert" command with arrow keys, in order to place the next part to the immediate left/right/top/bottom of the previous one? This could speed up placement of repetitive parts like floor tiles and so on.

(I know that you can already guide the placement of the next part by pointing your cursor, but you still have to "commit" the placement by clicking; my idea would automatically place and commit the next part.)

[Roland Melkert]

Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.

I'm working on something like this for 1.7, but it will be an animation mode thing.

Originally I wanted to push this back to 2.0 as the 2.0 rendering engine is much better with large scenes as 1.x does only some very basic frustum (near plane) culling.

The ability to select all parts of a given type or color does exist but only if you assign a keyboard hotkey for 'select working part' or 'select working color' and then holding shift when you want to do 'select working part' / 'select working color' a second time. But shift does not work with the menu item, only a hotkey so maybe add shift support to the menu item and also assign a keyboard shortcut by default for 'select working part/color' because it is used super often.

If I understand correctly the main problem is selecting a work part/color without loosing the selection?
Maybe an option to make the 'hot' part the working part/color?

Also a 'select all connected parts' like in LDD would be cool.

That would be very cool indeed, but its very complicated I do have some snapping improvements planned for 2.0 though.

The ability to rotate multiple bricks but where they have their own rotation centers instead of a single rotation center where everything else selected orbits that.

Might be handy, I'll look into it.
Until then there is a sample marcro for this, it applies the orientation of the first selected part to all other parts in the selection. If needed you can adjust it to (also) apply relative rotation.

A secondary color ootion like in MSpaint by right clicking on a color square in the color menu and having a second long square telling you the currently selected secondary color.

I did consider using multiple work part/colors before but I'm afraid it will complicate things too much.

Also the ability to automatically align another part to a part with a diagonaal edge like a wing plate. example

This would need additional information stored in parts (like snapping and mirroring).
Afterwards it would need a way to cycle trough the orientations that information supplies.
Someone has suggested something similar like this before in order to use something other then the parts local 0,0,0 while dragging/snapping.

A new 'node view' editing pane like in the following video for auto generating parametric structures like in grasshoooer/blender: https://youtu.be/8TFrz2eWyB0?t=865

Script would the why to do this in 1.6. An interactive flow chart like that video is something I would like very much at some point but it will get complicated very fast.
My LD4DStudio project had something similar to it, but very little people used it. That's why I decided to go script only in LDCad which basiclly does the same (without the gui) trough the aniTools module.
I might bring back some kind of gui for 2.0 though, but not sure yet.

[Roland Melkert]

What about being able to modify the "insert" command with arrow keys, in order to place the next part to the immediate left/right/top/bottom of the previous one? This could speed up placement of repetitive parts like floor tiles and so on.

(I know that you can already guide the placement of the next part by pointing your cursor, but you still have to "commit" the placement by clicking; my idea would automatically place and commit the next part.)

A macro could do this, might be a fun example I'll look into it.

[N. W. Perry]

This would need additional information stored in parts (like snapping and mirroring).
Afterwards it would need a way to cycle trough the orientations that information supplies.
Someone has suggested something similar like this before in order to use something other then the parts local 0,0,0 while dragging/snapping.

Some parts have this info included in HELP metas—perhaps there's a way to search these metas for possible suggested rotation angles?

For other parts, Selection Info could help figure these angles, if it were possible to select (or snap to) part vertices.

[Michael Horvath]

Eye view - the ability to move the camera as if you're in a first person game, this will make it easier to go into tight spaces such as a room in a  house and inspect building errors etc. The movement could be tied to the grid stepping.

Yes, I wish for this feature too.

...but LDCad already has so many hotkeys, I don't know where you would fit the controls.

[Philippe Hurbain]

Possibility to inline flex parts? That would replace flex part with its fallback code, allowing to access individual elements (eg. change chain links to tread links). Of course that would apply only to discrete element flex.

[Roland Melkert]

Possibility to inline flex parts? That would replace flex part with its fallback code, allowing to access individual elements (eg. change chain links to tread links). Of course that would apply only to discrete element flex.

I like this idea alot.

But I'm afraid the next request would be to change it back later on. So instead of inline it might be better to make it an option of the subfile (disable regens, make it editable) somehow.

[Orion Pobursky]

I like this idea alot.

But I'm afraid the next request would be to change it back later on. So instead of inline it might be better to make it an option of the subfile (disable regens, make it editable) somehow.

Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.

[Roland Melkert]

Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.

Yes, the addFallBack option of the !LDCAD CONTENT meta.

Set it to

never

or

remove

You can do this with any text editor or use the header dialog's path tab's code gen option inside LDCad itself.

[Orion Pobursky]

Yes, the addFallBack option of the !LDCAD CONTENT meta.

Set it to

never

or

remove

You can do this with any text editor or use the header dialog's path tab's code gen option inside LDCad itself.

Ahh, it's called Code Gen. Got it. I was trying to edit the meta itself in the source window.

[Philippe Hurbain]

Is there a way to turn off the generation of fallback code and remove it from within LDCad? 

For what purpose? Create clean templates?

[Orion Pobursky]

For what purpose? Create clean templates?

Couple of reasons:
- For flex extensive models, allows me to distribute a file that isn't huge (e.g. 8448)
- Makes it easier to split the file out with a text editor since all the auto-generated isn't there.

Yes, I know I can make LQ templates but call me a perfectionist.

[Roland Melkert]

For what purpose? Create clean templates?

Templates will automatically exclude fallback, when using "addFallBack=default", given they are stored in a registered template location.

[Philippe Hurbain]

Templates will automatically exclude fallback, when using "addFallBack=default", given they are stored in a registered template location.

Wondered why it worked sometimes... Location!

[N. W. Perry]

Not the same but related:
Is there a way to turn off the generation of fallback code and remove it from within LDCad? If not, can there be? I've been manually editing the META with LDDP because I couldn't find a way to do it inside of LDCad.

Came here to suggest something very similar, yet opposite…

Could it be an option to export only the fallback code, without the !LDCAD metas, specifically as a part (.dat) file with appropriate header? This could be used e.g. to open models with flex elements in other LDraw programs without sacrificing the higher quality of LDCad's generated mesh by using static references. (It's also necessary to view an LDCad-generated spring mesh in an external editor.)

I could see this as a third option when choosing "Duplicate subfile…", and possibly also in "Detach subfile", along with new file and new subfile in the current file.

[Roland Melkert]

Could it be an option to export only the fallback code, without the !LDCAD metas, specifically as a part (.dat) file with appropriate header? This could be used e.g. to open models with flex elements in other LDraw programs without sacrificing the higher quality of LDCad's generated mesh by using static references. (It's also necessary to view an LDCad-generated spring mesh in an external editor.)

I could see this as a third option when choosing "Duplicate subfile…", and possibly also in "Detach subfile", along with new file and new subfile in the current file.

Whenever you drop a template on a model it asks if you want to make it part of the mpd or a separate file.

If you choose to make it a separate file and name it something .dat you should be ok most of the time.

Only possible problem is when a generated part has subparts that .dat would technically be a mpd (this is mandated by LDCad's generator).

All LDCad meta's should be transparent to other tools as they would (MUST) just skip those lines.

That said, I'm planning to make some improvements to the mpd split/joint tools for the 1.7 version.

I'll add an extra option to split generated content (with a warning about loosing the original paramters etc) to that version.

[N. W. Perry]

Whenever you drop a template on a model it asks if you want to make it part of the mpd or a separate file.

If you choose to make it a separate file and name it something .dat you should be ok most of the time.

Only possible problem is when a generated part has subparts that .dat would technically be a mpd (this is mandated by LDCad's generator).

Interesting…how would that be different from a regular .dat file that references primitives and subparts?

All LDCad meta's should be transparent to other tools as they would (MUST) just skip those lines.

That said, I'm planning to make some improvements to the mpd split/joint tools for the 1.7 version.

I'll add an extra option to split generated content (with a warning about loosing the original paramters etc) to that version.

Yeah, I suppose technically I don't need to remove the metas, but for some reason it feels like a "cleaner" part file without them. Also, it removes the risk of the mesh being regenerated accidentally if I open the .dat file in LDCad…

[Roland Melkert]

Interesting…how would that be different from a regular .dat file that references primitives and subparts?

None, as it becomes (to other software whom don't know the meta's) a normal LDraw file. The fact it's secretly a mpd shouldn't really matter to a parser aware of mpd rules.

[Orion Pobursky]

This one is small:

When I use duplicate this file, can the new filename be a derivative of the old filename (ex. Head.dat -> Head-1.dat) instead of "submodel01.dat" (or whatever the default pattern is)

[Philippe Hurbain]

This one is small:

When I use duplicate this file, can the new filename be a derivative of the old filename (ex. Head.dat -> Head-1.dat) instead of "submodel01.dat" (or whatever the default pattern is)

+1 !!!

[N. W. Perry]

Speaking of small (and +1 to the above, by the way!), here's one that may or may not be:

Would it be possible to assign quantities and colors to group references in a .pbg file, the way you can with individual parts? I use these to list composite parts (hinge assemblies, turntables and so forth) within a set inventory, but at the moment I have to create a separate .pbg for each different color of the assembly, and I can't indicate the quantity at all.

Of course, it's quite possible that there's a way to do this already and I just haven't discovered it! 

[Philippe Hurbain]

And similar... it would be nice if current file name was suggested when using "save as". Generally we just create a derivative of the name.

[Roland Melkert]

Would it be possible to assign quantities and colors to group references in a .pbg file, the way you can with individual parts? I use these to list composite parts (hinge assemblies, turntables and so forth) within a set inventory, but at the moment I have to create a separate .pbg for each different color of the assembly, and I can't indicate the quantity at all.

Of course, it's quite possible that there's a way to do this already and I just haven't discovered it! 

Interesting use case, there is no way of doing that at the moment though.

Groups don't have those attributes as you can't really select them, you can only go 'into' them.

the original intent of those numbers and colors was to let people build stuff with a limited inventory, the numbers would then go down when a copy is placed in the model.

But I favored other features instead so it got pushed back again and again.

But even in that setup it would only work on a single group not the whole tree.

I could however introduce a new part bin group kind whom let you display the contents of another one in a different color (for the col16 items in that group).

I'll add it to my 1.7 'maybe' list.

[N. W. Perry]

Interesting use case, there is no way of doing that at the moment though.

Groups don't have those attributes as you can't really select them, you can only go 'into' them.

the original intent of those numbers and colors was to let people build stuff with a limited inventory, the numbers would then go down when a copy is placed in the model.

But I favored other features instead so it got pushed back again and again.

But even in that setup it would only work on a single group not the whole tree.

I could however introduce a new part bin group kind whom let you display the contents of another one in a different color (for the col16 items in that group).

I'll add it to my 1.7 'maybe' list.

Being able to set the color by inheritance would be really useful! I can see the trouble with quantity, though…that's not as important, really, at least until LDCad makes use of this info.

One workaround is to include the full assembly inside the group, with the correct quantity shown there. (I have to include the assembly in the group anyhow, since I want to use it as the mascot.) Only trouble is this gets me back to making separate groups for each different quantity of the same part, which probably isn't worth it.

[N. W. Perry]

Here are two suggested minor tweaks that have occurred to me recently:

1) I would love to be able to configure hot keys for changing the active grouping layer from the main editing window. Or at least the first 9 (plus 0 for "none/disabled"); I probably would never get anywhere close to 32 grouping layers.

2) Small human-readability issue: LDCad adds a newline to the end of a main file (LDR or MPD), as required/permitted by the spec, but not to the end of subfiles inside an MPD. I find that I need to add this whitespace manually, to help when I need to scan the source in a text editor. (I appreciate that LDCad doesn't delete the space after I've added it, though!)

[Roland Melkert]

1) I would love to be able to configure hot keys for changing the active grouping layer from the main editing window. Or at least the first 9 (plus 0 for "none/disabled"); I probably would never get anywhere close to 32 grouping layers.

That reminds me, the whole layer thing is a bit experimental in 1.6. It was supposed to become more dynamic (editable names etc). Linking it to hotkeys is/was part of that clean-up.

2) Small human-readability issue: LDCad adds a newline to the end of a main file (LDR or MPD), as required/permitted by the spec, but not to the end of subfiles inside an MPD. I find that I need to add this whitespace manually, to help when I need to scan the source in a text editor. (I appreciate that LDCad doesn't delete the space after I've added it, though!)

The trailing newline is because internally all lines are without the next line character(s) only at the moment of writing to disk are they added to each string in the list making them lines.

The main problem with empty lines is pollution when appending new lines etc.

Only real solution I see is to truncate (trim) on read and force a single empty line on write. I could make that an option?

[N. W. Perry]

That reminds me, the whole layer thing is a bit experimental in 1.6. It was supposed to become more dynamic (editable names etc). Linking it to hotkeys is/was part of that clean-up.

I didn't know that, but now that you say it, it makes sense. I've also noticed there's no way to see all group information in one place, or move parts from one group to another (including any empty groups, such as if I've ungrouped something and want to put it back together). The recursive grouping is really powerful but can also be a little confusing, especially as it interacts with nested editing and submodels. Being able to view and interact with the entire group "tree" would be very useful, but of course now we're getting much deeper into the weeds.

The trailing newline is because internally all lines are without the next line character(s) only at the moment of writing to disk are they added to each string in the list making them lines.

The main problem with empty lines is pollution when appending new lines etc.

Only real solution I see is to truncate (trim) on read and force a single empty line on write. I could make that an option?

Could it be an option from Clean-up, maybe? Just to add an empty line before each FILE meta (except the first), in the same way that whitespace is added to force official header formatting? Alternatively, I could just train myself to add an empty line to the end of each submodel, as I already do with STEP commands at the end of each step.

[N. W. Perry]

Precision has always been an issue even while using all double precision variables.

The main reason is the mutation is applied as a 'difference' to all the parts in the selection.

So if the main part in the selection has been mutated a lot (or is read from low decimal count file) the rounding errors will be amplified.

Alternative might be to use 'snap all to edit grid plane' from the placement menu.

I've noticed something even stranger…I just spent a bunch of time cleaning up all the rounding errors in a model with lots of rotation in it, and the simple act of closing and then reopening the program seems to have reintroduced them. It's just a .001 difference, but it means that mirrored pairs of parts might have different decimal values, for example. (Note that I'm referring to relative positions here—the file code hasn't changed so the absolute decimal values are all still correct.)

So what causes the change from simply closing and reopening the file?

[Orion Pobursky]

I've noticed something even stranger…I just spent a bunch of time cleaning up all the rounding errors in a model with lots of rotation in it, and the simple act of closing and then reopening the program seems to have reintroduced them. It's just a .001 difference, but it means that mirrored pairs of parts might have different decimal values, for example. (Note that I'm referring to relative positions here—the file code hasn't changed so the absolute decimal values are all still correct.)

So what causes the change from simply closing and reopening the file?

I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.

[N. W. Perry]

I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.

Good, that's what I was guessing as well—that calculating from the coded values gives a different result than applying the series of mutations I make while editing.

As a follow-up, then, it seems I might be doing something backwards. When adding new parts to a rotated assembly, I first snap to grid and reset orientation of the new part (on the relative orientation of course), then move it into place using part snapping. I should probably snap to grid after moving the part into place, huh?

[Roland Melkert]

I think, and Roland can confirm, that LDCad keeps the full precision for each part's position and matrix in memory as long as the file is open. This practice makes sense to me since it will cut down on rounding errors while you are actively editing the model. Once you close the model, the full precision info is lost and LDCad has to rely on the precision written to the LDraw file itself.

Indeed. Internally all matrices are stored using c++'s double variables.

The mesh vectors are stored as single so they can go '1 on 1' to OpenGL. But matrices are only converted to single floating point for use with OpenGL at the very last moment (while keeping the double as the master).

All matrix file io is double too.

I've experimented with re-normalizing the rotation part of matrices during loading but that made thing worse in certain circumstances.

I've also played around with recognizing common matrix values (0.707 etc) to do substitution, but this too isn't fool proof.

The only real solution would be to store more digits or even the whole double precision content as a string (so it would translate back to the same binary content)

Good, that's what I was guessing as well—that calculating from the coded values gives a different result than applying the series of mutations I make while editing.

As a follow-up, then, it seems I might be doing something backwards. When adding new parts to a rotated assembly, I first snap to grid and reset orientation of the new part (on the relative orientation of course), then move it into place using part snapping. I should probably snap to grid after moving the part into place, huh?

If you snap to the global grid after positioning something on a relative one you will get visual errors. Or do you mean snapping to the relative grid? If so that might also introduce rounding errors as the relative grid does some matrix operations of its own.

The best way to keep clean numbers in your files is by avoiding rotated assemblies of loose parts. Instead use submodels so only one reference line will have those nasty digits. This might not be an option in technic models though.

[N. W. Perry]

The only real solution would be to store more digits or even the whole double precision content as a string (so it would translate back to the same binary content)

Which, I assume, would mean storing that string in a meta tag, or maybe as shadow content?

If you snap to the global grid after positioning something on a relative one you will get visual errors. Or do you mean snapping to the relative grid? If so that might also introduce rounding errors as the relative grid does some matrix operations of its own.

I did mean relative, but I see now what you mean. I tried snapping to grid after placing the part, and it does result in more rounding errors. I thought at first it was giving me the same result as closing and re-opening the file, but it actually seems to be even more than that.

The best way to keep clean numbers in your files is by avoiding rotated assemblies of loose parts. Instead use submodels so only one reference line will have those nasty digits. This might not be an option in technic models though.

That's an option indeed. But since I use submodels for organizational reasons, I think for my purposes that's more important than this precision issue. I think as long as I place everything correctly before exiting the file, I'll know that the saved values are as clean and precise as they should be, which will be good enough for me. (I just have to avoid the urge to check the relative positions again after re-opening the file!)