LDraw.org Discussion Forums

Full Version: Thinking about doing a LDCad 1.7 version
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
(2020-04-04, 18:03)N. W. Perry Wrote: [ -> ]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! Wink

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.
(2020-04-04, 21:24)Roland Melkert Wrote: [ -> ]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.
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. Wink

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!)
(2020-04-10, 18:43)N. W. Perry Wrote: [ -> ]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. Wink

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.


(2020-04-10, 18:43)N. W. Perry Wrote: [ -> ]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?
(2020-04-10, 19:05)Roland Melkert Wrote: [ -> ]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. Smile


Quote: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.
(2020-02-24, 18:41)Roland Melkert Wrote: [ -> ]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?
(2020-04-23, 5:34)N. W. Perry Wrote: [ -> ]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.
(2020-04-23, 15:02)Orion Pobursky Wrote: [ -> ]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?
(2020-04-23, 15:02)Orion Pobursky Wrote: [ -> ]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)



(2020-04-23, 16:56)N. W. Perry Wrote: [ -> ]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.
(2020-04-23, 19:07)Roland Melkert Wrote: [ -> ]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?

Quote: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.

Quote: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!)  Tongue
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15