I’ve used and developed “Dynamic Components” or their equivalent in other CAD systems.
They all have different names for these, like “Parametric Objects” or “Smart Objects”.
Here’s what they do that SketchUp’s implementation doesn’t (as far as I can tell??) and what SketchUp would have to do to keep up:
Allow a dynamic component to call a Ruby Script as one of its functions.
Allow any element type to be dynamic, not just components.
Allow a DC to respond to its relationships with other objects (ie what it is glued to or connected to or inside of, or pointing to.)
Even with these capabilities, however, experience has shown.
Developing effective parametic objects is too complex for most users, even spreadsheet experts.
Parametrics can work where there is a linear causal relationship: A determines B which determines C. However most design processes are not that fixed. Many times a designer may decide that he wants a certain C, so what would A have to be to give me that C? Parametrics therefore has a deserved reputation for being too rigid.
Most simple parametric objects (simple doors and windows) should be included in the box anyway. Even so, if you look at the examples that SketchUp provides, impossible results are easy to create because many factors have not been considered. (eg: SketchUp’s parametric bench can be stretched to any length??)
More complex parametric physical objects (eg: all the actual subparts of a double hung window) can only be realistically built and published and maintained gratis by the actual manufacturers as an incentive to spec their products.
The most fruitful area of use is actually in parametric symbols, labels, custom types of dimensions and other notational (ie non physical) objects. These are essential in producing a multi disciplinary set of construction drawings, for example. But SketchUp’s implementation doesn’t allow a DC to see the attributes of what it’s connected to. And DC’s don’t work in Layout.
There are issues with implementing a “foreign code call.”.
If the extension that defines the method called has not been loaded, this will result in some kind of exception (NameError or NoMethodError.) If a require call is allowed from the DC, then this can result in a LoadError. This then means the DC code must be a error handler for any kind of foreign code. Not something anyone in their right minds will want to tackle.
Security is another issue. Some coders have asked to actually embed Ruby code into the DC dictionary. This raises the possibility of malicious components.
It is just a “Pandora’s box.”
Smarter to just add standard functions that everyone can use to the base DC code.
Otherwise, SketchUp would have to implement code signing for DCs, like they have done for extensions.
This is not doable currently. Only groups and components can have a transformation property. (So it would mean wrapping even a single “dynamic edge” within a component.)
I’m not suggesting that what I would like is easy to do, or doable within the current SketchUp object model. But other systems have achieved these abilities because they had better object models (at least for this purpose.) So in the broader sense (that an end user should understand) all of what I describe is “doable”.
Like all CAD software, SketchUp suffers from the failing to think outside the (in this case SketchUp) Box.
But yes, there can be good improvements in DCs, like translation to C code for speed and deployment across all SketchUp applications (ie, viewers, etc.)
The idea you’ve proposed, with the most immediate merit (IMO), (which has also been previously proposed,) is the “extended object interaction” (#3) idea.
I’d love to “connect” components with “connection points” and “connection orientation” instead of just surface gluing. Think, plug and socket type fittings.
I also agree that LayOut would be great if it got DCs, which also goes along with what I’ve been asking for LayOut all along. That is attribute dictionaries for objects.
BTW, there is nothing to prevent some talented coder, from creating another parametric objects extension (for SketchUp.) It just should not interfere with the native DC extension.
There have been a number of threads on DCs which appear to be in their infancy in SU. I have tried making some myself and have found the biggest stumbling block is how long it all takes, mainly because there are no obvious shortcuts. The inability to nest sub-components is another major limitation. For the end user, it is usually quicker to create a new component for every new instance, which rather defeats the object.
I don’t know that “infancy” is the correct word. They debuted with version 7.0, (17-NOV-2008,) and so are now in their 8th year. I don’t think SketchUp can be said to still be in it’s infancy, either.
They are what they were designed to be. Either dynamic in the sense they can be driven by an options dialog, or respond dynamically to some user transformation (scaling, etc.)
But, I agree the workflow and build dialog is cumbersome.
Not true. Examine some of the samples.
Look at the “Bench Wood Highback”. It employs nested dynamic sub-components, that react based upon the outer most component’s scaling.
Also, take for example some of the bi-folding closet doors that fold up onClick. (There is a thread here about them.) They must have dynamic sub-components. One of the panels must follow the other and rotate as the whole thing folds.
You can have formula refer to other components in the same context by name followed by a exclamation symbol, or refer to the parent like “Parent!attribute_name”.
“So is this the old argument that SketchUp (which was invented to be the “UN-CAD”,) needs to be overhauled to be another CAD-like clone ?”
It has nothing to do with that. Parametric concepts transcend CAD.
And my purpose is certainly not to suggest ideas which I think are new. All of these ideas had been successfully implemented almost a decade before release 1.0 of SketchUp in the first 2D “UNCAD” called Visio. Back then AutoCad (still the ugliest piece of graphic software ever written) was 2D. (Visio also allowed (allows) the definition of custom handles: also an important feature which I should have also mentioned.)
At the time of SketchUp’s first release, it was reviewed as “Visio on steroids”.
Visio could perhaps have evolved to 3D but was smothered when it was bought by Microsoft.
So my purpose is to advise as follows:
If you are a developer planning to reinvent a wheel please at least look at previous models.
If you are a SketchUp user trying to create Dynamic Components keep you hopes very modest.
My FR would be to keep all iterations of the DC within a single component definition. Now they tend to populate the In Model component browser with endless copies of the original definition, which makes the browser quickly unusable, and changes you make to the workings of the component only apply to the instance you happen to be editing.
Yikes I hadn’t noticed that.
I was considering DCs as part of a new extension, which led to my realizations on how limited they were.
But now I see what you are talking about. This is a deal breaker, as my extension would have created dozens of new definitions. Again, Visio avoided this problem 25 years ago.
But it is not really a solution. Change one of the nested DCs, and it is made unique. Same as always. This is the nature of the component object model of SketchUp. IE, definitions “own” an entities collection. Instances do not. (There is a lengthy discussion thread on this already. Maybe more than one.)
Yes. The problem doesn’t lie with identical instances but with different ones. In a BIM application I can create all the different sizes of, for instance, a door and they still retain the connection to their common definition, so I can later edit a common property (colour, for instance) and it gets updated on all the “children” even if they have unique size parameter values.
It might be possible, if the differed instances had “dynamic group” definitions (which would be hidden in the component browser,) but had a “_parent_guid” attribute to lead the code back to the original component definition.