Efficient Dynamic Component Design


#1

Wondering if there was any value in discussing the most efficient way to structure variables and references between main and sub-components contained within them? I have been writing a bit of code to make doors and windows that are dynamic, and wondering if there were any guidelines on structuring my equations efficiently, or what the most efficient way to reference variables, etc. are.

For example, if doing window casing - should I have both my outer and my inner casing be calculated based on the width of the window/2+correction factor or should I do that calculation for one of them, and then reference that calculated value for the second one? Does it really make a difference? Or more correctly, at what point does efficient code become noticeable and valuable to pursue?

Any pointers from SU gurus or coders is welcome. Thanks!


#2

Also wondering if it’s more efficient to calculate these type of things at the main component level, then simply pass that variable to the sub-component and keep all my calculations as ‘high up’ the chain as possible. Is there any use in trying to structure models this way?

Perhaps some tests are in order - could we design some basic Dynamic Components that would help test these different hypothesis?


#3

Axis is probably the first thing to consider,
For doors, windows
I suggest the face width be on the X axis and the height on the blue axis. the depth running back along the Y. the insertion point on the lower left.

For beams, profiles…similar
the section width be on the X axis and the height on the blue axis. the length running back along the Y. the insertion point on the lower left. (option to place / move center or right)

components need to have the ability to be swapped whilst still retaining some overall sizes, This can be achieved by wrapping the component contents in another component and exposing the size attributes, then use a fixed or current option to pass the size values to the geometry. This wrap can be used for the collective starting point for other operations such as explode, outer-shell and even follow-me to simplify the complex and make smaller files after purge.

So a simple window would be a fixed glass with a frame, as an example
fixed window.skp (71.4 KB)


#4

Standard axis directions for windows and doors that cut a hole in a face are red for width, green for height and blue for thickness.

Recently I have started to prefer to use groups instead of components for DC parts, especially to avoid the proliferation of all those duplicate component definitions that clutter the component browser.

Anssi


#5

Fairly new here and to SketchUp, but I dove into component creation fast. I 2nd the preference for groups within components as it does, indeed, declutter the component list.

However, last night I started looking into typing schemas - used for reporting and for integration with other platforms (like building information managers). For proper information transfer (at least as I read things), you’ll likely need to have nested components, as only components have a “type” - which is the field used to contain the schema information. So go ahead and use groups - unless you need this type of integration!

Disclaimer: My reading on typing was brief, so my understanding may well be flawed - I just hope it’s not fatally flawed! Thus, take what I’ve said with a few grains of salt!


#6

the warehouse is full of doors and windows with various orientation and insert points, so if I had a drawing contain these and I need to swap them, I can use the fixed window example above with the scale option set to true, saved in my components folder. First right click the component and select “change axis”, to orientate to same if required. Then select size (add all) in the DC attribute (Pro only) to expose the lengths (LenX,…) then swap. Basically any geometry can be made into a component and swapped, like a line to a beam.
@Anssi
Yes, openings and cuts (gluing planes) are XY. However I prefer to use a separate opening cutter (that can have complexity to cut a rough opening of various sizes through multiple walls or surfaces) , The window or door component set to scale, can be embedded for the ride.and exposed after exploding the cutters, other wise placement is made afterwards.
Agreed, for the subs, groups are best at memory cleanup, but I have found that a group type cutter tends to misbehave occasionally, so I use components for these; and of course, the swap works with the double component.
@sjdorst
I believe you can add schema type to a group, though reporting maybe the problem for subs


#7

@pcmoor I have no clue whether or not your right! As I said, I’m really new to this and, as far as typing goes, I only have the barest minimum of surface knowledge based on one quick read. I haven’t worked with them, haven’t (yet) needed to coordinate with another software system (and likely never will need to). I just wanted to raise the possibility that there might be a use case where it’s better to have components (instead of groups) inside components.


#8

You can add a Type to a Group via the Entity Info window while the Group is selected. The only difference from a Component is that there is a dialog that opens when creating a component and that dialog also offers a field to choose a Type.


#9

I have some minor insights to share on the coding-end of the DC design. I hesitate to share them because they are quite unscientific indeed, but useful as they may get others thinking about the code structure of DCs, for which I haven’t seen any documents (correct me if I’m wrong) about efficient code within the DC. If someone knows of a resource like this any help is much appreciated.

I set up the following test using 12" cubes as the base component:

A container component to make copies in the X-direction of this initial cube, based on cube copies=parent!LenX/LenX

A container component for that to make copies in the Y-direction, based on similar copies=parent!LenY/LenY

A final container for Z, direction, same approach.

So I have a set of nested components, based on the initial cube. The first one makes a line of cubes, the next one makes columns of these lines of cubes, the last makes stacks of these layers. Pretty simple, right?

Things get bogged down when you get to about a 20x20x20 stack of cubes. Perfect. Just what I’m looking for - some real lag time that I can measure and make sense of - something measured in seconds or minutes, not milliseconds. Something I can time on my iPhone while it works.

So I time it, and the test I did was to take a 20x20x3 stack, put in a construction line @ 20 out, hit the scale tool and just when I clicked, hit the start on the stopwatch. Took about 1:05 to complete the operation.

Next I thought, OK what if I have the main component calculate how many copies to make in each direction based on LenX/Y/Z, then pass that down through the sub components. That way, each sub-component won’t have to do its own calculation - it can just reference the variable passed to it. Seems like it should save time, right? So I created xCopies, yCopies, zCopies and created corresponding hooks in the sub-components referencing zCopies=parent!zCopies, etc.

Stretching this box again gave me a second test. This operation took about 1:35 to turn into the 20x20x20 cube.

So from this very, very basic and cursory view, I can’t say that the results produced anything of statistical significance. I was hoping that the component with the pre-calculated values would preform better, but maybe the calcs are so simple that it doesn’t matter. Simple division is quick, and maybe easier for the computer to do than passing variables down the line over and over. Maybe the calculation time doesn’t even factor into the component creation, and it’s the geometry creation itself that is what the processor wrestles with the most.