Same here, I use them as both. It's also a way to simply organize and keep track of what you're building (when I have a hierarchical view.) I nest groups. If I have sub-models that deserve to be in their own project for reuse elsewhere, then it would be handy to link files into a project. Those linked "external sub-models" wouldn't be editable in the project (to keep it simple) but you could double click them to launch an additional instance of LeoCAD to edit the source sub-model file. Right now I merge external sub-models into the project and immediately assign them to a group for that sub-model. When I fixed the file merge, I almost added the ability to automatically group the whole imported model for this very reason. One design I have was for a functional train track bumper (for the older 4.5V/12V systems.) It had a stationary base and tie, and a moveable bumper that was spring loaded by a rubber band. These two parts must be independent of each other and so everything I did with these two groups/sub-models/selections was separate. Part of my attraction to the hierarchical group management is because that's how I have done things for so long. I create a lot of diagrams and graphics which can involve lots of hierarchical layering to get the masking effects you want, or just to stay organized, so it comes natural to me. I never thought of saving selections. I can't think of any scenarios where I always want to go back to a certain selection that is more complex than just clicking or control-clicking on a few things. - Rod
Date: Wed, 8 Jan 2014 11:00:56 -0800 From: [email protected] Subject: Re: Patch: Group Toolbar To: [email protected] CC: [email protected]; [email protected] It's been awhile since I built that BI, but as I recall, I used groups for both purposes: sub-assemblies and selection sets. I recall thinking at the time that I could REALLY use sub-assembly support in LeoCAD. I would end up creating entirely new files for each sub-assembly so I could show sub-assembly steps in a callout. Most of what I wanted would require that LeoCAD head more in a desktop-publishing direction than a CAD program, however. I thought it would be especially neat if I could define sub-assemblies in the main assembly, go into a display mode that showed ONLY the steps of the sub-assembly (while I was working on those steps), and also the ability to define the first main step that the sub-assembly showed up as an "explode" step, so the sub-assembly (as a group) would have a different position than it normally maintained in the model. [At all times, I was happy to use InDesign to add arrows to the final product, I never saw it necessary to have LeoCAD do that job, and in fact I was using LDView as my renderer as well, rather than rely on LeoCAD to output the BI] Having to specifically load and save selection sets sounds like extra steps that would be annoying. Saving them as part of the file (as groups are now) is definitely better, IMHO. -- joshua From: Leonardo Zide <[email protected]> To: Joshua Delahunty <[email protected]> Cc: Rodney Rushing <[email protected]>; "[email protected]" <[email protected]> Sent: Wednesday, January 8, 2014 11:46 AM Subject: Re: Patch: Group Toolbar I was rewriting groups way but this conversation is making me rethink their purpose. So what do you (and others) use groups for?Would you use groups if you had sub-models? Do you need groups to be nested?Would it be better to save selection sets instead? On Tue, Jan 7, 2014 at 11:36 AM, Joshua Delahunty <[email protected]> wrote: For what it's worth, I used groups extensively when building the BI mentioned here: http://www.technicbricks.com/2011/08/building-instructions-for-nathanael.html So they definitely have their use, in the current incarnation (at least, in the pre-Qt version of LeoCAD). -- joshua From: Leonardo Zide <[email protected]> To: Rodney Rushing <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Tuesday, January 7, 2014 12:23 PM Subject: Re: Patch: Group Toolbar The original idea was just to make it easier to select pieces that are always locked together (like a tire and wheel) and be a replacement for sub-models. Maybe groups should have been selection sets instead and have sub-models be used for complex groups. And that's why I don't like the current groups, it doesn't replace sub-models and doesn't help with selection either because it tries to keep all objects selected at the same time. I don't like changing things that aren't visible so you end up being inconsistent one way or another. Maybe drawing a faded version of the invisible pieces in the group is enough to show what's going on. On the code side groups are a terrible hack also. On Tue, Jan 7, 2014 at 8:27 AM, Rodney Rushing <[email protected]> wrote: > Groups are something that I never finished implementing What was your original goal for groups? I don't think there is a problem with groups as they are (perhaps some additional internal structure to make it more efficient to isolate groups instead of scanning the whole piece list - but I also like the coherence of having just one list.) All that seems to be lacking are (1) information to make the user aware of how the operations are applied, and (2) consistency in how operations are applied. If I knew render view operations would always apply to invisible pieces of a group, and there was something to tip me off that there are invisible pieces in my selection, I'd be satisfied. I do sometimes wish I could position a sub-group. The group toolbar is a way to do the selection, but the core logic that I didn't want to change is not aware of how to operate at a specific group level. That seems like an easy change. Also, multiple views of the data are a big help in understanding your model and manipulating pieces within the group irrespective of how they are represented in some other view. - Rod ________________________________ > Date: Mon, 6 Jan 2014 17:04:24 -0800 > Subject: Re: Patch: Group Toolbar > From: [email protected] > To: [email protected] > CC: [email protected] > > I was on vacation and I'm just catching up with my emails. > > The reason why there are steps and frames is because LeoCAD used to > have an animation mode where you could create simple animations using > key frames and you could create animations and instructions in the same > file. I've decided to remove it because it's not the main focus of the > application (building instructions) so it adds to confusion and feature > bloat. > > Groups are something that I never finished implementing, it's weird to > have objects that are not visible be part of a group because it's not > clear what should happen when you move the group. If you don't move the > hidden objects the group will be wrong later but if you move them then > you're moving something that's not visible. > > To be honest I think groups shouldn't exist in their current form, > having a parenting system could be a better way solve the problem > because pieces would always be relative to their parent so moving the > parent automatically moves its children, even if they are hidden and > more complicated groups that need multiple steps would be sub-models > instead. I was actually implementing this system in my current work > branch > (svn.leocad.org/branches/model<http://svn.leocad.org/branches/model>). > > BTW, I usually develop new features in a separate branch so please post > something if you plan on writing big features so we can try to avoid > conflicts. > > _______________________________________________ Leocad mailing list [email protected] https://list.gerf.org/listinfo/leocad
_______________________________________________ Leocad mailing list [email protected] https://list.gerf.org/listinfo/leocad
