Submodel naming and organization

[Orion Pobursky]

I'm starting to rethink my design philosophy regarding how I put together a model for the OMR. Currently I name things by step number (e.g. step45.ldr) or an appropriate noun name and step if there are multiple sections that start with step one (e.g. book1-step5.ldr). Since I've now run into multiple instruction sets where even LEGO can't keep the step numbers consistent, I'm thinking about abandoning the step numbering system and instead focus on submodeling to make positioning movable elements easier. Maybe not even include steps at all?

How does everyone else go about organizing their submodels? Do you put instruction steps in?

[Lasse Deleuran]

A popular convention seems to be naming the sub assemblies, such as "wing", "windscreen", etc. but this obviously becomes a challenge once sub models do not resemble anything. When that happens, I start numerating on the assembly that they are part of. As an example, windscreen.ldr might have sub assemblies windscreen1.ldr and windscreen2.ldr.

[Orion Pobursky]

A popular convention seems to be naming the sub assemblies, such as "wing", "windscreen", etc. but this obviously becomes a challenge once sub models do not resemble anything. When that happens, I start numerating on the assembly that they are part of. As an example, windscreen.ldr might have sub assemblies windscreen1.ldr and windscreen2.ldr.

That's kinda what I used to do. Then I switched to the step thing. Now I'm thinking about doing away with all of that (at least for some models, Technic especially) and focusing on assmblies that improve the "posability" or animation potantial regardless of how the steps are laid out.

[Roland Melkert]

That's kinda what I used to do. Then I switched to the step thing. Now I'm thinking about doing away with all of that (at least for some models, Technic especially) and focusing on assmblies that improve the "posability" or animation potantial regardless of how the steps are laid out.

You could use UUID's

[Lasse Deleuran]

You could use UUID's

That is the approach I use when you add new sub models using Part Editor in buildinginstructions.js It makes the construction of building instructions faster when you don't ask the user to name each child. In order to reduce the file size, new sub models are named "a", "b", c", ... "aa", "ab", ...

According to the OMR specification, all approaches are acceptable.

[N. W. Perry]

I'm starting to rethink my design philosophy regarding how I put together a model for the OMR. Currently I name things by step number (e.g. step45.ldr) or an appropriate noun name and step if there are multiple sections that start with step one (e.g. book1-step5.ldr). Since I've now run into multiple instruction sets where even LEGO can't keep the step numbers consistent, I'm thinking about abandoning the step numbering system and instead focus on submodeling to make positioning movable elements easier. Maybe not even include steps at all?

How does everyone else go about organizing their submodels? Do you put instruction steps in?

I use submodels almost exclusively to align with sub-builds in the official instructions. I name them for what they actually represent: a crankshaft assembly, a roof, an architectural element such as a pediment, a fire truck, and so on. I can almost always find an appropriate noun or phrase to represent the object, although this sometimes leads into extensive Googling to figure out what the proper name of certain things actually is (I guess that's part of the fun for me).

Occasionally I'll have to resort to something more esoteric: components of a tower assembly might be towerA, towerB, towerC and so on; or maybe just a purely functional name like mount, core, base, hinge, etc.

Additionally, I have a basic hierarchy for naming the assemblies (in the Description field, not the filename), viz.:

• A "submodel" is a major, largely independent part of the whole, like an entire floor of a modular building, or the separate vehicles in a Town set. Not all models have these.
  
• An "assembly" is the basic subdivision of a model. The majority of first-level sub-builds are assemblies. If they're part of a submodel, the name will be based on that submodel (like "1F Window assy").
  
• A "sub-assembly" is basically an assembly inside an assembly; so, a second-level sub-build.
  

Pretty much any sub-build in the instructions with more than 3 steps or so gets a submodel/assembly. Occasionally I'll make a submodel for a repeated assembly that's not a separate sub-build, but in most cases I'll just copy/paste the parts.

For positioning/rotating/animating purposes, I use LDCad's groups instead, because they can nest inside and across submodels. This is because sub-builds often contain both parts of a hinge or turntable, not just the part that actually rotates, and often have more parts added to them after they're placed in the main model. Groups are very powerful so they work well for this.

[Orion Pobursky]

That is the approach I use when you add new sub models using Part Editor in buildinginstructions.js It makes the construction of building instructions faster when you don't ask the user to name each child. In order to reduce the file size, new sub models are named "a", "b", c", ... "aa", "ab", ...

According to the OMR specification, all approaches are acceptable.

Yup. The OMR doesn't care. It does mention steps being as close to the instructions as possible. This consideration is kind of outdated since I wrote this before the electronic distribution of BIs by LEGO themselves. This is primarily why I'm considering dropping the practice of adding BI steps to my OMR models and switching to something more sensible for model organization.

[N. W. Perry]

Yup. The OMR doesn't care. It does mention steps being as close to the instructions as possible. This consideration is kind of outdated since I wrote this before the electronic distribution of BIs by LEGO themselves. This is primarily why I'm considering dropping the practice of adding BI steps to my OMR models and switching to something more sensible for model organization.

For a more direct answer to your question than what I gave below…yes, my submodels are based on actual building steps, but not named for them. Instead, all the steps in my model are based on the official instructions. If a sub-build appears at a step in the instructions, then I'll include it at the same step in my model. And if the sub-build has its own steps in the instructions, I'll have the same steps in my model (so sometimes there's a blank step, if the instruction doesn't add any parts but only rotates the view, e.g.).

[Orion Pobursky]

For positioning/rotating/animating purposes, I use LDCad's groups instead, because they can nest inside and across submodels. This is because sub-builds often contain both parts of a hinge or turntable, not just the part that actually rotates, and often have more parts added to them after they're placed in the main model. Groups are very powerful so they work well for this.

Your approach is the overkill version of what I'm doing currently.

I've been resistant to use groups. No real reason why. I guess if I'm changing things I might as well start using them.

[N. W. Perry]

Your approach is the overkill version of what I'm doing currently.

I've been resistant to use groups. No real reason why. I guess if I'm changing things I might as well start using them.

I was too, at first. I started using them so that, in the event I become more adept at scripting and animation (or it becomes more interactive from within LDCad), I'm already set up for that, and don't have to go back and re-think my use of submodels, which works for me as it is.

More broadly, as I discover new capabilities of LDraw programs, I find that I want to make full use of them, which sometimes means going back and making sure I've implemented them correctly. That's also why, for example, I'm always looking for precise ways to figure angles and such, because I know the system is capable of it. But back in my Bricksmith days, successive approximation was as close as I could get, so it was good enough for me.

[Orion Pobursky]

I'm always looking for precise ways to figure angles and such, because I know the system is capable of it. But back in my Bricksmith days, successive approximation was as close as I could get, so it was good enough for me.

This is why I made this spreadsheet:
https://docs.google.com/spreadsheets/d/1...sp=sharing

Most of this isn't needed anymore since LDCad does triangles fine. However, it doesn't have rotational snap. This means I still need to calculate circle-circle and circle-line intersections on occasion.

[N. W. Perry]

This is why I made this spreadsheet:
https://docs.google.com/spreadsheets/d/1...sp=sharing

Most of this isn't needed anymore since LDCad does triangles fine. However, it doesn't have rotational snap. This means I still need to calculate circle-circle and circle-line intersections on occasion.

Oh yes, I've seen this around a few times! I haven't run into the use cases for most of these yet, but I certainly use Law of Cosines all the time, usually when I need to find the "collision" point between a rotating and a stationary part. I just keep an online triangle calculator handy and plug in my 3 known values.

[Jaco van der Molen]

I'm starting to rethink my design philosophy regarding how I put together a model for the OMR. Currently I name things by step number (e.g. step45.ldr) or an appropriate noun name and step if there are multiple sections that start with step one (e.g. book1-step5.ldr). Since I've now run into multiple instruction sets where even LEGO can't keep the step numbers consistent, I'm thinking about abandoning the step numbering system and instead focus on submodeling to make positioning movable elements easier. Maybe not even include steps at all?

How does everyone else go about organizing their submodels? Do you put instruction steps in?

I do it with step numbers too, but only numbers.
See attached example (I need to OMR it a bit more before I post it in the Official models SW thread)

So, page 9 of the original LEGO instructions step 6 has a subassembly in a call-out. I name this one 6.

If the subassembly is numbered sequentially like from page 25 where you start building the stand, I name that submodel starting with the step number it starts to the last with a dash. In this case 33-52. There is a submodel in this subassembly in step 34, so that one gets the name 34.

If submodels go nesting, I add a dot/point. See page 69, step 112. That one gets the name 112. But in step 4 of this submodel is another submodel in step 4. So that one is named 112.4.

My 2 cents