So far I do not see a big difference between Live Components (LCs) and Dynamic components (DC). DCs can react on a click event, so that when clicked on them, an action is performed on the component and they can be scaled. But other than that the functionality looks to me the same.
What I see as a strong plus in LCs is the nice user interface and that you see the effect of a parameter change immediately in the 3D component.
Therefor I would prefer, if the LC would be implemented as an extension of DCs instead of a completely new and independent concept.
DCs are already pretty powerful, but not so straight forward to configure. For instance changing an axis of a sub component has a huge impact and all formulas need to be manually adjusted. Also a function to place subcomponents (e.g. chairs) in a predefined way relative to another component (floor of a room) would be a nice enhancement. If such things could be made easier to setup and the user interface of the LCs would be used on top, this would be great.
I am not familiar with lc but can you set custom attributes as you wish?
So far LCs can only be viewed in 3d wrehouse. No editing possibilities for SketchupUsers. Thez said this comes only next year.
@Bryceosaurus is probably the best person to answer this.
From my personal perspective I’d like to say DC is a brilliant concept but has technical problems that makes it difficult to maintain. It’s one of the oldest SketchUp Ruby extensions ever, developed before the best practices for SketchUp extensions had been figured out. A fresh start built on a more solid foundation will hopefully allow for a whole different level of development with frequent improvements.
Let’s hope that this is a promise.
One important difference is that LCs are supported directly in the Sketchup core rather than an extension. This allows them to be used online. Since DCs are implemented as a ruby extension it was ‘not possible’ to port them to the web.
Or that’s my assumption anyway based on the fact that the LC’s are currently configurable in the 3D warehouse (Web app), along with this statement from Bryce.
I can see how LC’s could be useful, but their dependence to 3DWH as source puts me off, rather build in the functionality into the program core.
DC’s can be tricky, but become magic in the hands of people like the @Yoni FlexTools team and the interface they’ve constructed. If their team could be expanded to support and build more and different kinds of DC’s it would be a win/win situation in my books.
Have patience…
Do we have to understand that DC will be abandoned?
In this case, investing time and work in SketchUp is a waste.
As a reminder, for a developper, technically DC is quite simple, it’s parameter setting on the bounding box of groups/components.
The main problem with DC is the internal SketchUp problem confusion between group and component.
I love DCs - and their immense configurability. I really hope LCs will be at least as versatile?
Presumably DCs will continue to work alongside LCs? I have spent many years of my life developing a large library of DCs that I share with my colleagues via Component Finder linked into Dropbox. It works really well. It would be such a shame if after all these years we had to start again from scratch!
Of course. They do now (work side-byside,) and do not interfere with each other.
DC extension code acts upon only components (instances and definitions) and group instances that specifically have an attached attribute dictionary named "dynamic_attributes".
Live Components have their own specifically named attribute dictionary.
So, “never the twain shall meet”. 
The Dynamic Components extension has not had any new features for many many years, and will (most likely) not get any more. SketchUp team has said this before. There are too many extensions (some Trimble) that now rely upon the DCs to remain as they are.
It has also been like “pulling teeth” to get errors in the Dynamic Components extension fixed. I do hope (and politic) for all existing easily fixed errors in DC code to be fixed, before it is “retired” to an optional extension.
So, it is most likely [speculating] that the Dynamic Components extension would be “frozen” at some version, and thereafter remain as such in the Extension Warehouse as an optional extension. (Ie, it may no longer be distributed as a “default” extension with the SketchUp installer. But [speculating] this is not likely to happen for several major cycles until after Live Components is mature enough.)
We are hoping that a conversion utility will be fielded that would make adoption “less painful”.
The LC interface allows much better and a larger set of controls for the end users (sliders, etc.)
@DanRathbun the concept look nice ,tidy.
The only think that troubles me is if the extentions would work on the same ruby rules. And would be possible to use them on LC.
Hey Everyone
There’s not a huge difference between the basic notions behind Dynamic Components and Live Components. We simply wanted to offer a platform for making configurable objects to aid in design workflows.
The big differences are under the hood. Live Components were developed to resolve some key limitations with Dynamic Components. These are things like: easier and more approachable authoring; protecting author’s intellectual property; more efficient modeling capabilities, more efficient files from a consumer perspective; better unit support… We believe that these differences will allow us to better serve the community well into the future.
As far as conversion utilities is concerned, we are not planning on having a way to convert Dynamic Components into Live Components. There are too many subtleties in the way spreadsheet formulas are used within Dynamic Components to make them work seamlessly as Live Components. In many conversion situations, we expect that there would be a “fix it” step needed to correct the logic. Another thing is that geometry is handled differently for Live Components. (Dynamic Components only support scaling/stretching and visibility.) As a result there will be some key advantages with modeling geometry in Live Components which are worth leveraging from the beginning. I realize that might seem like a painful decision but it will usually be better in the long run to author a Live Component from scratch. It’s also better for us from a development perspective - we can focus on building new features to support Live Components instead of spending time playing whack-a-mole on conversion problems.
thanks for sharing this Information. It sounds promising.
I have two questions:
-
How are live components stored: Can I assume that a live component is in the end as well stored as a .skp file, which I can import as a component into an existing Sketchup model? Or do I always have to generate first a skp file from a live component before it can be used in a Sketchup model?
-
Efficient files: Will it be possible to instruct the live component to generate the skp file with a reduced poly count? Assume I model an inflatable chair which I offer from a mini size of 50cm up to 2m in width.
Then the model generated with 50cm size should have far less quads than the big chair. Will this be possible?
Live Components are essentially components and can be transported in the same ways. Or to put in another way the geometry for a Live Component is effectively cached as a component inside your files. When dowloading from 3DW before configuring, there is a “static” version of the geometry available as a component. Once inside sketchUp, Live components can be copied or saved as just like normal components. You’ll even be able to email a configured live component as a file attachment. It’s only when you go to reconfigure that the contents are changed.
This is definitely possible. Much like how you make choices that affect the polygon count while modeling manually, you can make the same choices when authoring Live Components. Parameters can be linked in various ways to control the LOD of model assets. For example you could have sliders that affect something like the number circle sides for an extruded pipe. Or you could set up enums like: High poly & Low poly which then affect your model assets. I’ll see if we can publish some examples with LOD controls soon.
@Bryceosaurus
Looking forward to seeing the LOD working.
Another question came up:
Reducing Sketchup model file size with Live Components:
I assume that a live component uses much more space than the generated component. Will it be possible to import a generated (leightweight) component into a model, but keep the link to the (heavier) live component? So that the live component is stored outside the main model, but I can still change the configuration of the generated component from within the main model?
Do you still have to have an internet connection to (re)configure, once you inserted a static version from your local component library?
I don’t think a live component takes up any more space than any other component. The “liveness” is stored in the cloud and SketchUp file contains normal geometry and an ID.
Yes, that is the case, if the master LC is in the cloud and the generated component is downloaded. But I still assume or hope that the master LC file (containing the liveness) can also be stored locally and imported to a sketchup model in the future.
Yes you will need an internet connection to reconfigure even if you already have the .skp file stored locally.