I am not sure, if this was already asked, but in Live Components it would be good to be able to define named sets of parameters.
As live components may have many parameters that can be set, the possibility to define a predefined set of parameter values and give them a name would help.
The user then can quickly select one of the “standard” configurations.
Additionally, there should be a possibility to quickly cycle through the list of predefined sets.
If the LiveComponent is imported in a sketchup model, this would allow to change the LC configuration with a click like with the DCs.
(I use DCs often to model interiors and check, when doors, windows,drawers are opened or reclinable chairs extended, that there is still enough space.)
This (now) is called “configuring” a Live Component, and the name part would be to assign a name to the instance as we do now in the Entity Info panel. If you need more of this, you copy using the MoveTool.
It would interesting to know what happens when you save out this preconfigured instance as a component file.
Not sure, if my idea came across properly. What I mean with named parameter value sets would be for instance a drop down at the top of the configuration page, where I can choose between options.
DropDown example based on the LC toilet:
Italian Standard Toilet
Swiss Standard Toilet
Custom configuration
If I choose “Italian Standard”, I would get all parameters in the configuration set to a predefined value, same when I select “Swiss Standard”.
If I choose custom configuration, I can set the individual parameters myself.
It DID. I just made the point that currently we have to manually name the instance (as we always have) with it a currently configured.
Bryce made the point that LC instances can be transported just as components can be transported as component files.
Now back to what you are proposing. From a programmer’s point of view, your idea has challenges.
The “named configurations” are subjective per end user “property sets”.
(Thinking out loud here.) Where are they saved ? They wouldn’t normally be encapsulated within the library component, would they?
Or maybe, they would be and the top level of the LC as downloaded from the 3DW library has an empty “named configurations” dictionary, that the end user can populate as they use it.
This also implies the need for a better local LC library cache (then the DCs have) so that “named configurations” in a model file can be propagated “up” to the library cache so that subsequent insertions in other model files (perhaps by other design team members using the same library cache,) can leverage the latest set of “named configurations” for the LC.
This update of “named configurations” both up and down from the cache could occur when the LC Configurator dialog is opened for a LC instance within a model.
Sure. Agree. In many cases there is likely a basic set of configurations that a company might use, so they’d set these up ahead of time so that users don’t need to.
I think they should be saved in the LiveComponent.
I understood Bryce that there are two kind of skp files. The LC skp with all its config definitions (I call it master LC) and the skp file of a component generated for one configuration of the LC.
If a generated LiveComponent is inserted into a model, then the link to the master LC should be kept and if I want to change the configuration of the generated LC in my model, then Sketchup loads the Master LC, lets me change the parameters and when I press OK, it replaces the generated LC with the new generated component in my model.
If the link to the master LC points to the 3D Warehouse or a file stored locally, should be transparent to this process.
Issue of broken links? The easiest solution to prevent broken links would be to store the master LC as well in the model, but I would prefer that the master LC is stored outside the model, so that the issues you described regarding cache update between models do not pop up. A small screen showing all links in a model would help here as well. Similar like VRay does it.
Should there be different list of predefined sets? Yes, probably one for the author and one for the user.
Currently the configuration is saved within a special attribute dictionary attached to the component definition (instead of the instance.)
This means (currently) we must do a Make unique command on any instance(s) that we wish to configure differently than the “norm”.
An example might be interior doors. Most of them in a dwelling model would be the same width.
But then you’d have closet doors not as wide. Also depending upon location (proximity to walls, etc.,) some doors will be hinged on the left others on the right.
So (again, currently) after bringing a LC into our model, we may need to do a Make unique command several times to create unique definitions for the different scenarios of instances that are needed.
This means that modelers will need to set the main “common” options on the first instance’s definition (material, finish, etc.) and then do the uniquifying as needed.
But we hope that this changes in the future. Modelers would rather have a “common” definition in which common options could be changed modelwide for “related” instances. (Again using door paint and hardware finishes as an example.)
Imagine an entire condominium building model with many many door instances. Then the customer decides they want all the door finishes to change from walnut with black hardware, to oak with stainless hardware. It could be a tedious task to change them.
And then there is the scenario where you want to have different styling for walkthrough animations. Having to have multiple sets of doors assigned to tags(layers) bloats the model size.
LCs by design will not work this way. The “Live” in LC means that the component changes as you make edits to configuration options. There is no OK or Apply button as there is with DCs.
I see, good point regarding the two kind of parameters/options: Model level and Instance level.
If the options could be set on both levels, then the issue would be solved. If an option is not set on instance level, it would pick the value from the model level.
The other posibility would be to sovle it with the named parameter sets. My current project has 15 doors and only three parameter sets would do the trick. So changing the door paint would require to change the color only in the three parameter sets instead of all doors.
Yes, as soon as the “LC master” is stored locally and not in the Sketchup Cloud, this would be the case I assume. But if the LC component is configured in the 3DWH application, as it is now, you see the configuration changes immediately, but still have to
press the button to download the generated component and then re-import it into your model, no?
See the SketchUp 2021.0 release notes section “Live Component Configuration” that explains that LC configuration is native to SketchUp 2021 and higher.
So the quick answers to your question:
Yes with SU2020 you must configure in 3DW.
No, with SU2021+ you can d/l and configure within SketchUp
and re-configure anytime by double-clicking LCs.
Live Components are still a cloud-driven feature. You need a “live” internet connection to drive the configuration dialog. Viz:
The way to save a particular configuration is to save that component definition somewhere. That could be your in-model set of components in the component browser, a local folder, upload back to 3DW or trimble connect…
Note that we do have some limitations in this area. Namely it’s not easy to add custom definition names which persist after config changes. Also Component thumbnails for LCs are not updating in the component browser.
After having downloaded, installed and tested SU2021, it is clear so far what is possible and I like it. The requirement to make as many unique components of an LC as I need different configurations in the model displayed, is fine for me.
But that I have to make a unique component also for each “parameter set” I want to store and use “replace selected” to apply a different “parameter set” to a LC component, is a bit a heavy workflow.
Assume I have a house with three type of doors like bathroom, living/bed room and cellar. I create therefor three unique components for the LC door. Now I want to for each door type two or three alternative configs. As it is now, I would have to create another 6 to 9 unique LC components.
This is a bit a lot and switching between the alternatives is also not done with a single click.
Having a list of all different parameter sets that exist for an LC in my model would help a lot. In the element information, I then could simply select a parameter set from this list to be applied to a LC component.
A possible implementation could be: Add a field “name” in the LC configuration screen where I can name the parameter set. This name along with the parameter values would then be stored in the component definition. In the LC component definition, multiple such named sets could be stored and presented in the element information dialog to select from and apply.
I think the introduction of LC’s could be a chance to enrich the objects with a new form of ‘parents’.
Not nested as with DC now in a single model, but “alive” in models of the same “project” or “owner”
Some settings are related to size, others could be related to “owner” or “availability” or “Kitchen”
(Ikea has a nice kitchen planner where one could configure each individual cabinet, but also choose the type of handle or front color for all)
Since all Configuration are unique and are configured, you could have a blockchain added, too.
It would be kind of like a bitcoin, where you can trace certain things like owner, changes, etc.
I suggest to call them “Assembly”, but “Family” could do, too
Jack, I was thinking the same thing! Something like a LiveConfigurationSet class in the API.
The LC dictionary for multiple “related” LCs could have an attribute that points to an instance of this class. It would likely be a data object similar to (or perhaps a subclass of) the AttributeDictionary class.
Any LC in the model that points to this data object could read option overrides from it’s attributes. And when the LC Configurator dialog opens it can get a list of configuration sets or overrides from this data object, so Uwe could choose one from a droplist.
Also there could be a right-click context menu command that could open another dialog to change overrides for the whole set of “child” LCs. (Like perhaps changing the trim color for all windows, or the material for all interior doors.)
The native “Make unique” command could be expanded to ask the user if they wish the new LC to be part of a “family”. If the user agrees, the LC’s configuration is also saved in the “parent” data object and becomes one of the choices (for a “named configuration set”.)
The common options in the “parent” data object are used to set values for each LC “child”. The end user should be able to control what the “parent” common override options are. (Ie, a list of options with checkboxes, perhaps in a 2nd tab panel of the configuration dialog.)
@Bryceosaurus
I would also like property inheritance natively.
But the named parameter sets to be able to switch quickly between user definable variants should also be done
