LDCad - How do I manage groups?

[Eric Butler]

I'm just starting with LDCad, and so far I'm loving. But I'm having trouble trying to manage groups. I can create them and move them and rotate them, but when I want to group together sub groups, then things get messy. Once I group groups together, I can no longer find a way to select the sub groups. All that I can select is the main top-level group. If I remove the top level group, then I can access the individual groups again. However, I can no longer access the top level group unless I regroup all the groups again. This is not ideal especially when working with large models. Also, if I hover over a group, I can see in the bottom a group name like "Group 1" etc... but cannot find where I can edit that to name the groups. Surely, I must be doing something wrong?

Can someone help me figure out how to manage all these groups?

P.S I know about Group Layers, but this isn't what I'm looking for. If I group together a bunch of groups, I should be able to move / rotate that top level group, then also be able to select a sub group from a list or tree and rotate just that part too. Is there a way to do that?

Thanks!

[Roland Melkert]

I'm just starting with LDCad, and so far I'm loving. But I'm having trouble trying to manage groups.

The behavior you want can be done using layers (groups can be in multiple layers at once) but you don't seem to want that, so that leaves submodels.

Using submodels combined with the source window will give you a more 'gui' like way of doing the things you want.

Groups are, imho, always a last resort, using submodels is usually much more manageable.

The group name can be edited using its property dialog, you open that by pressing ENTER while a group is selected and the mouse is inside the editing area.

[N. W. Perry]

Different question, but since it fits the thread topic…

I'm wondering if this is a bug or if I'm using groups wrong: Let's say I create a group in a submodel, so that subfile is the "top" level for that group. Then I switch to the main model session and go into nested mode. I select the group that's in the submodel, and add some parts from the main model to it. Everything works fine, I can select and manipulate* the group with all of its parts.

But now let's say I've closed LDCad, and I go back to the model another day. Then, selecting the group in nested mode only affects those parts in the submodel—the parts added to it from the main model aren't selected, even though they're still in the group according to the file code. In other words, when LDCad is closed and re-opened, it seems to "forget" any group parts that are not in its top-level subfile.

Now I assume I should just create the group in the main session and then add parts to it from the submodel instead of the other way around. The downside is just that I can't then select the group at all when I'm editing the submodel itself—but I guess, why would I want to be able to select a group if I can't select all of its parts anyway?

---

*Well, not totally fine…the group center shows up in very odd places if I select parts from the non-top-level of the group, and transforming the group leads to unexpected results with these parts…but that's another story!

[Roland Melkert]

I'm wondering if this is a bug or if I'm using groups wrong: Let's say I create a group in a submodel, so that subfile is the "top" level for that group. Then I switch to the main model session and go into nested mode. I select the group that's in the submodel, and add some parts from the main model to it. Everything works fine, I can select and manipulate* the group with all of its parts.

But now let's say I've closed LDCad, and I go back to the model another day. Then, selecting the group in nested mode only affects those parts in the submodel—the parts added to it from the main model aren't selected, even though they're still in the group according to the file code. In other words, when LDCad is closed and re-opened, it seems to "forget" any group parts that are not in its top-level subfile.

I'm not sure what you are describing here, how do you add parts to the group? Because that isn't possible using the gui, are you editing the ldraw files?

Or do you use ctrl+g for that. If so, you are not adding parts you are making a new group which includes the old one and some loose parts. This new group will only be seen at the top level it is made in.

Well, not totally fine…the group center shows up in very odd places if I select parts from the non-top-level of the group, and transforming the group leads to unexpected results with these parts…but that's another story!

This is a known bug, but I'm having troubles replicating it. This makes me think it might also have to do with the recursive groups you are using.

Could you send me the model you are using above?

[N. W. Perry]

I'm not sure what you are describing here, how do you add parts to the group? Because that isn't possible using the gui, are you editing the ldraw files?

Or do you use ctrl+g for that. If so, you are not adding parts you are making a new group which includes the old one and some loose parts. This new group will only be seen at the top level it is made in.

I'm using alt+shift+g or "Add selection to group".

This is a known bug, but I'm having troubles replicating it. This makes me think it might also have to do with the recursive groups you are using.

Could you send me the model you are using above?

Here it is attached. See for example the front tires, which are in the "main" model but grouped with the steering axles in the steering submodel. (Quotation marks because there is actually a higher-level main model used for displaying the primary model at a rotation.)

To replicate this second bug, because of the first bug, you'll have to ungroup the group and re-build it by first grouping the steering axle from within the submodel's session, then moving up one level (chassis.ldr) and adding the tire and hub to the group with alt+shift+g. Then try rotating the group—the tire should end up in some faraway place.

  853 Auto Chassis.ldr (Size: 34.28 KB / Downloads: 3)

Interestingly, when I open my OMR version of this car, the groups all work correctly, for selecting as well as transforming. 

[Roland Melkert]

I'm using alt+shift+g or "Add selection to group".

I totally forgot about that feature

So it is most definitely a bug. I will look into it later this week.

[Roland Melkert]

Different question, but since it fits the thread topic…

I'm wondering if this is a bug or if I'm using groups wrong: Let's say I create a group in a submodel, so that subfile is the "top" level for that group. Then I switch to the main model session and go into nested mode. I select the group that's in the submodel, and add some parts from the main model to it. Everything works fine, I can select and manipulate* the group with all of its parts.

But now let's say I've closed LDCad, and I go back to the model another day. Then, selecting the group in nested mode only affects those parts in the submodel—the parts added to it from the main model aren't selected, even though they're still in the group according to the file code. In other words, when LDCad is closed and re-opened, it seems to "forget" any group parts that are not in its top-level subfile.

I finally manged to 'observe' this behavior, it turns out this is not supposed to be allowed. Higher groups can contain ones from submodels, it shudn't be possible to add parts from an higher model to a group living in a submodel. I will be blocking such additions in Alpha 2.

Well, not totally fine…the group center shows up in very odd places if I select parts from the non-top-level of the group, and transforming the group leads to unexpected results with these parts…but that's another story![/i]

This is actually the same problem, the steering axle group sits in a lower submodel then the hub and wheel.

LDCad should have prevented making such a group in the first place.

The reason is all operations on groups are done in the group's owner world space. The axle is at Z 40 inside the steering model but at -400 on the higher level, so the wheel and hub will receive the higher to lower space corrections while not needing it.

To solve this you should make a new group at the chassis level out of the steering group, hub and wheel.

If it is hard to select things, you can always use the hide feature (or navigate to a lower step where everything is still visible)

I will add extra checks to the "add selection to group" operation, firing a warning if not all is actually added.

[N. W. Perry]

I finally manged to 'observe' this behavior, it turns out this is not supposed to be allowed. Higher groups can contain ones from submodels, it shudn't be possible to add parts from an higher model to a group living in a submodel. I will be blocking such additions in Alpha 2.

I see, so whatever was allowing this behavior operates within the currently running session, but when the file is re-opened, LDCad reads it correctly—that is, ignoring any group items that are in the "wrong" level?

That behavior makes sense and is easier to keep track of. I've already adjusted my workflow accordingly, but it will be useful to have a warning. And it's fine because the mainpart of the group is still allowed to reside in a submodel, as long as the group itself is defined at the highest level.

Is there any chance that version 2 might feature a GUI tool to view and edit all groups and their attributes? It would help when trying to troubleshoot, or just manipulate e.g. an empty group. Perhaps it could be a tab in the session info dialog?

[Roland Melkert]

Is there any chance that version 2 might feature a GUI tool to view and edit all groups and their attributes? It would help when trying to troubleshoot, or just manipulate e.g. an empty group. Perhaps it could be a tab in the session info dialog?

Actually this was planned for 1.x a couple of versions ago.

the plan was to use the source window for this by displaying a group based tree instead of the normal reference line based tree.

The source window' sourcecode is even prepared for this, but I dropped the feature somewhere down the road.

This was mainly because I was planning the 2.0 version, I might revisit it now I'm working on a 1.7 instead.

[N. W. Perry]

I just remembered another odd bug involving groups: sometimes, changing the name of a group will also change its position!

I'm not sure exactly how to recreate it, as it doesn't happen with every group, but it may have to do with using a custom center. Consider the attached file—there are four piston rods that are groups, and if you change their names, the pos values in the matrix will also change. It's just by a few thousandths, but clearly not expected behavior…and for those of us with a perfectionist nature… ;-)

A successful workaround is to change the group name in a text editor, so it probably has to do with the actual dialog in LDCad.

(You'll have some missing submodels that I didn't bother to inline, but that won't affect anything.)

[Roland Melkert]

if you change their names, the pos values in the matrix will also change. It's just by a few thousandths, but clearly not expected behavior…and for those of us with a perfectionist nature… ;-)

That is probably due to the double to string to double conversion of the orientation/positional values.

I'll add a detection so it only does that when you actually changed the position or orientation inside the dialog.