DCs have been with us for some years now but have never been updated since. Some people persist with them but my impression is that they have not delivered on their promise. That is probably in large part due to the clunky UI.
The attributes table that controls DCs is effectively a spreadsheet with a few commands that are specific to the software. I was wondering whether there is any clever way of using a standard spreadsheet to input a lot of the formulae that could then be imported into a DC attribute table? I realize this would mean writing some code.
A lot of the formulae are often relative. Conventional spreadsheets make relative operations very easy because you can simply use a cell reference instead of having to name everything. So the width of an element can simply be an absolute cell reference such as C:1 without having to continually tell the software its hierarchical name. That can all get very long-winded and easy to get wrong.
No one is going to use DCs if it takes longer to set them up and then make use of them than it does to reinvent the wheel each time. My feeling is that DCs were a great idea in principle but were let down by poor implementation. The idea remains good so what about improving the implementation?
DC-s were implemented as a spreadsheet which is 2-dimensional , in a sense. We need to add a third dimension , more databased or SQL way of managing DC’s.
Dynamic Components are not a SketchUp feature (in the sense of the .skp file format) but an extension. Under the pre-condition that the DC extension is installed, dynamic components appear to most users like a native feature because they “work” out of the box (but only in those SketchUp versions which support extensions). They neither work in mobile versions of SketchUp nor in 3rd-party softwares that implement .skp support.
However, they have been a big selling point (powerful way to create parametric behavior without programming knowledge) and a lot of content exists on 3D Warehouse.
They are some kind of legacy.
I agree that references (or relative paths etc.) are better than hard-coding names (or using absolute paths). But unnamed spreadsheet references (C:1) are not a good habit because they lead to hardly understandable and hardly maintainable formulas the more complex the spreadsheet grows. Errors happen more often the harder they are to spot.
The DC extension has quite some size and complexity because it implements e.g. an expression parser and an API of formulas/math functions. The original, genius developer is not among the company and probably no person is in charge of further developing Dynamic Components (since they are no native feature). I agree with your suggestion that relying on existing well-proven technologies (spreadsheets as a back-end, or functions) could make it more lightweight.
But major changes to the attributes that are used by dynamic components mean a change to the “Dynamic Component format” and would be incompatible with the existing SketchUp files out there. The current format (and the need to support attributes in all these existing SketchUp files) make it not a light legacy.
Do you think? I have been meaning to get to grips with PF3 for some time and your post made me take the plunge. I probably don’t know enough about it yet but if you’re trying to make something like the chair in the Bricscad example or a window, say, I think you’d struggle using PF3. Or maybe you can prove me wrong? (I’d like you to!)
The geometry of that chair could be easily enough manipulated with the native SketchUp tools.
The auto assembly feature of PB3 is more about the specific elements once build.
We do not see the chair modelled in the first place, if you started with a face (of one of the leg) and made it a profile at the beginning, set 3 copies of them, drew another face for the seat and back, you would have parametrized, meaningful parts of a chair.
I will have to investigate further…
Meanwhile, check the latest tutorials of PB3 and have a blast in your workflow!
Sure. And you could make a DC but it would take a lot of input time.
The principle is easy enough but the practice is hard. PB seems to be mainly for making things that follow a path, either with a consistent cross section or with a series of components. Once you have components that are in many different places (like the various parts of a DC window) and whose position varies according to the overall size, it all becomes quite complex. I’m not (yet) convinced you can do it with PB. But I’ll have fun trying.
Many companies have invested large sums in building DCs of their products.
Some of these product DCs are public at the 3DWH.
However, many more are considered company intellectual property.
Those DCs are solely for internal use or for sales demonstration purposes.
If the legacy DCs were to break due to changes in the DC Format, then there would be many large companies understandably upset (read, furious) over the loss.
Not quite sure of the point you are making. Is it that one dare not “improve” anything for fear of trashing backward compatibility? If so, sure, but isn’t that the standard headache for all software updates? Otherwise nothing would ever move forward.
The thrust here is to make a good idea badly implemented into one that can be used more easily and universally.
Software updates are usually never designed to break anything (therefore versioned file formats etc.).
The issue is that the requirement to support all existing dynamic components (including all features) make any tiny change/improvement/evolvement of the extension a heavy effort.
The problem I see here discussed is that we haven’t noticed changes for maintenance over a long time. While it’s often said “never change a running system”, some continuous maintenance is a good thing. And also consider that DC is only “running” in the desktop version. The future is unknown.
This refers to a versioned implementation of DCs which is “1.0” currently.
(It is a hidden attribute named "_format_version".)
To implement a newer version, the DC code will need to subclass the DynamicComponentsV1 class as DynamicComponentsV2 class and make changes to the subclass as needed.
The version lookup (get_latest_class method) uses a hash that points at the DC class to use.
If a newer v2 is implemented, … older v1.0 DCs should still use the DynamicComponentsV1 class so as not to “break” all the DCs out “in the wild”.
ADD: But users will start to see error messageboxes “Your version of Dynamic Components does not support DC format version 2.0. Please update the Dynamic Components extension.” when trying to use a newer DC if they haven’t updated in awhile.
At the time Scott wrote DCs, Google owned SketchUp and he purposefully implemented functions that were compatible with Google Docs Sheets. Perhaps they had ideas of integrating SketchUp DCs and Google Docs ? (If they had this idea,) that all never got done, and likely will not now that SketchUp and Google have gone their separate ways.
Hi. Yes it took AutoCAD entry with parametrised drawing to develop SU dynamic component ideas. IMHO I blame that on Trimble for not releasing dynamic component creation tools to free (fremium) users. Generally speaking DC creations are not put into the public domain by architects because of proprietary issues and thus development of useful models has been stunted. I have published a few hundred DCs which you can view by searching #propcollection with “dynamic component”. These DCs are very basic with just two positions for a prop, and yet look how well they serve camper props. If DC creation was opened up to fremium users I guarantee a revolution in 3D drawing. I have an application that will stun the 3D world but I’m waiting for these things to change before showing my hand.
Truest talk Sir, I would like to improve on my structural capabilities on DC. With me spending my time to put what is needed for my clients.
I really hope for an improvement on DCs.
It is extremely important that the dynamic components are further developed in the near future!
The current options are very limited for this time. Especially if you look at other CAD systems such as Tekla, BricsCAD or Revit. In the construction sector, we will design parametrically in a 3D (BIM) model more often. We also put more information in 3D objects and models that we share in an IFC file. Dynamic components are important links in this.
As a Content Developer, I notice that manufacturers who make products with many variables (such as angles, etc.), often ignore SketchUp. The reason is that it is too “complicated” to develop user-friendly components.
It is important to:
Being able to edit geometry based on more parameters.
For example a beam that can be chamfered on both sides with parameters.
Make the interface more user-friendly.
The current one looks outdated and has limited options.
Have more control over the display of all parameters.
Now they are displayed in alphabetical order in the Component Options. But this can also be shown in a much more user-friendly way. Just think of grouping parameters in a property set. This also offers opportunities for IFC export.
Smarter handling of nested dynamic components.
If a component contains geometric options, certain sub-components are now often hidden. In my view, it would be much more efficient not to load it directly. But only when this option is chosen and then regenerating the component.
More intelligence to process into components.
Perhaps components can respond to the environment. For example, a window opening in a wall. If the wall becomes thicker, the window opening must also become this.
, more databased or SQL way of managing DC’s.
