Identical objects w/unique instance visibility of nested objects

Extensions
#1

I’m looking for an extension. Imagine if you had several copies of a component, but you want a slight variation in some of them. So maybe in some of them you want one of the child objects hidden. So I want all the geometry to remain in sync just like a component, but I want to be able to toggle visibility of child objects an a “per instance” basis.

Obviously, not possible with components, but seems like it’s doable using groups, if an extension tracks changes made and syncs the geometry but allows for different visibility.

My use case is I have trusses from an apartment building, and many of the units are identical, but maybe some of them will have a balcony and some won’t. I’d rather not create unique components for each variation of units.

Anybody know of such an extension?

#2

Why would say this? Groups are nothing more than Components with “special” behaviors (ie, their definitions are hidden from the “In Model” component browser and they are automatically made unique if there is more than 1 instance and an edit context is entered manually.)

I don’t see any way around it until perhaps Live Components become authorable.

#3

Why would I say this? Because if you change the visibility of a nested object inside of a component, it changes the visibility for all instances. So it’s impossible to do what I’m saying with components.

What I was suggesting was maybe an extension could track a set of groups as if they were components, meaning, keeping all the geometry in sync. But allowing for various “configurations” of nested visible objects that can be saved almost like their own definitions, which could be updated and propagated through the model.

So maybe I have apartment unit A1 as the main “component”, but based off of that I could have A1 balcony, A1 porch, A1 ADA, that all share the same objects/geometry, I just have different child objects shown or hidden based on the configuration. It would enable me to still have a single “component” to edit, that way if I have a wall I need to change that’s shared by all, it’s one change instead of 4 redundant changes.

(I know groups are “secret” components behind the scenes until one is edited but I don’t see how that’s relevant to my inquiry.)

#4

I told you how it is relevant. Groups are components, and so have the same limitations in addition to their limitations (as mentioned above.)

But … their basic limitation of their definition being hidden from the component manager might be an advantage in this scenario.

And this is the very difficult issue.

I think we have discussed this in the past when talking about the problems with Dynamic Components (and also with what we are seeing with the beta Live Components.) In that discussion (which is probably in the DC category,) I think I also remember myself proposing that perhaps groups could also be used similar to what you have just proposed.

See this old topic …

… and this topic is the one I remember, that both @Anssi and I were proposing that similar but unique DCs be held together in some sort of transparent “collection” …

:thinking:

Currently, with DCs, it’s extension automatically makes instances unique when any nested object is hidden via the “hidden” dynamic attribute. (But, yes, that then breaks the sync’ing of the common geometry.)

And since it is a no-no to modify the proprietary DC code objects, this would mean a whole new component engine. It likely has not yet been done because of the amount of investment (ie, it is a very large code project to create something the feature size of DCs or LCs.)

The Live Components are doing this now, but the instances have unique generated geometry that is not in sync with other instances. We’ve told them we need them to be part of “collections” that can have certain properties (like material) synced and settable across the whole “collection”.

Anyway, … back to existing extensions. There have been some attempts at parametric components extensions, but I have not tried them myself. (So, I don’t know if they’ve tried to crack the hide nested object situation.)

1 Like
#5

Thanks for your input Dan.

1 Like