Designing a Skyscraper using GenerativeComponents

RE: Designing a Skyscraper using GenerativeComponents

Jeff Brown — Tue, 28 Jan 2020 20:07:09 GMT

Hmm, you're right. I see that IGCMs need more versatility than what I had originally designed. I'll add that to the list, as well.

Thanks, as always, for your feedback! It's very valuable and very appreciated.

RE: Designing a Skyscraper using GenerativeComponents

dominic SEAH — Tue, 28 Jan 2020 19:34:20 GMT

Awesome!

[quote userid="3632" url="~/products/products_generativecomponents/f/generativecomponents---forum/186373/designing-a-skyscraper-using-generativecomponents/566220"]The user of a tier-2 destination model is not be able to directly refresh from the original source model, nor should they be allowed to, since such a refresh might disrupt the intervening tier-1 destination model. [/quote]

OK, take your point. But, I think that in practice a lot of designers will want to avoid having to hop back and forth when updating a model assembly. Imagine Drive Train<Axle<Wheel<Hub<Bolts and the Bolt has changed.

The way I see it, since all of the code behind the IGCM's have been copied into the destination model, any disruption should be localised to the destination model... initially, anyway?

User re-imports Bolt from Drive Train. If all goes well, user re-imports Hub. Check. Problems? Oh no, open up Hub, import Bolt into Hub*. Flex and debug. Switch back to Drive Train. Re-import Wheel... all the way back up to Axle.

*Hub may be used in another assembly that may not need that particular Bolt as a component, so won't have Bolt as an IGCM.

Initially, there may be a lot of miss-fires, but eventually as the graph matures, it would be good to give the user the option to refresh the whole chain / tree from the destination model. Most MCAD modelers have some kind of 'controlled' auto-update function and do not force the user to re-visit each component model.

RE: Designing a Skyscraper using GenerativeComponents

Jeff Brown — Tue, 28 Jan 2020 15:14:53 GMT

Hi Dominic,

> Would I be correct in saying that there can only be one GMIP and GMOP in each 'source' model?

No, there can be any number of each. The example I showed in my previous message had two GMIPs in the same source model. Meanwhile, any or all of the nodes in that model could have served as GMOPs.

> So, the user should still be able to daisy chain IGCM nodes in the 'destination' model? User A works on panelising a surface for a facade grid. User B works on a facade panel. User C inserts both GC_A.dgn as an IGCM (which has input/output ports) and GC_B.dgn; and wires the wires the output ports from GC_A.dgn to the input ports in GC_B.dgn. This should still work?

Yes, that should work.

> But designs do not start and end between the left and right side of one model. There needs to be a way of linking / nesting the GC models across multiple files... It seems like we should be able to do this as long as each model has its GMIP and GMOP defined? I assume that the destination file will copy the IGCM script (and any other input) so there is no dynamic 'late binding' stuff necessary?

That should work; IGCMs can be chained/nested. Any destination model that includes an IGCM node may mark that node as a GMOP (along with any other nodes it wants to mark as GMIP/GMOP). Thus, that IGCM will be exposed to each "tier 2" destination model (which, in turn, will include its own IGCM node that's linked to the tier-1 destination model).

> As mentioned above, it would be useful to expose the nested IGCM's on import. This would then allow the user to synch the nested IGCM's on demand from the 'destination' model.

The user of a tier-2 destination model is not be able to directly refresh from the original source model, nor should they be allowed to, since such a refresh might disrupt the intervening tier-1 destination model. (Remember that these links are not live; they're simply pulling information from a file that was saved at some previous time.)

> IGCM's work so similarly to GNT's I wonder if there should not be a 're-import as GNT' function. User plays around with graph until its relatively stable... or the project transitions from scheme to detailed design. User converts IGCM to GNT in the destination model. Bear in mind, there will be a lot of different destination / consumer models at the 'periphery'.

That's an interesting idea. I'll add that to the list of requested features. Thanks.

Jeff

RE: Designing a Skyscraper using GenerativeComponents

dominic SEAH — Tue, 28 Jan 2020 08:20:25 GMT

Hi Jeff,

Thanks for pointing out the GMIP function or step in the process of generating a 'source' GC_*.dgn for use as a ImportedGCModel node in a 'destination' model.

Would I be correct in saying that there can only be one GMIP and GMOP in each 'source' model?

[quote userid="3632" url="~/products/products_generativecomponents/f/generativecomponents---forum/186373/designing-a-skyscraper-using-generativecomponents/566086"]"a GMIP must be a root node, that is, a node that doesn't have inputs from any other nodes" means within the source model, only.[/quote]

Great. So, the user should still be able to daisy chain IGCM nodes in the 'destination' model? User A works on panelising a surface for a facade grid. User B works on a facade panel. User C inserts both GC_A.dgn as an IGCM (which has input/output ports) and GC_B.dgn; and wires the wires the output ports from GC_A.dgn to the input ports in GC_B.dgn. This should still work?

[quote userid="3632" url="~/products/products_generativecomponents/f/generativecomponents---forum/186373/designing-a-skyscraper-using-generativecomponents/566086"]the ImportedGCModel node to designed to appear only once in the destination model, typically near the beginning (left side) of that model. In other words, the destination model uses the source model as a starting point.[/quote]

OK. But designs do not start and end between the left and right side of one model. There needs to be a way of linking / nesting the GC models across multiple files... It seems like we should be able to do this as long as each model has its GMIP and GMOP defined? I assume that the destination file will copy the IGCM script (and any other input) so there is no dynamic 'late binding' stuff necessary?

As mentioned above, it would be useful to expose the nested IGCM's on import. This would then allow the user to synch the nested IGCM's on demand from the 'destination' model.

[quote userid="3632" url="~/products/products_generativecomponents/f/generativecomponents---forum/186373/designing-a-skyscraper-using-generativecomponents/566086"]A GNT cannot be redefined after its initial creation .The best you can do is delete its definition and then re-create it from scratch.[/quote]

IGCM's work so similarly to GNT's I wonder if there should not be a 're-import as GNT' function. User plays around with graph until its relatively stable... or the project transitions from scheme to detailed design. User converts IGCM to GNT in the destination model. Bear in mind, there will be a lot of different destination / consumer models at the 'periphery'.

RE: Designing a Skyscraper using GenerativeComponents

Jeff Brown — Mon, 27 Jan 2020 17:16:01 GMT

Hi Dominic,

Firstly, let's define "source model" as the GC model in which the GC model properties are defined; this could also be called the "core" or "producer" model. And let's define "destination model" as the GC model that contains the ImportedGCModel node; this could also be called the "extension" or "consumer" model.

The terms GMIP (GC model input property) and GMOP (GC model output property) are relevant only in the context of the source model. The destination model doesn't have any GMIPs or GMOPs.

So, then, my statement "a GMIP must be a root node, that is, a node that doesn't have inputs from any other nodes" means within the source model, only. That statement has no bearing on the destination model because, again, the destination model doesn't have GMIPs.

A source model may have any number of GMIPs, as long as each of those GMIPs is a node that doesn't have any inputs (within the source model). In the following small source model, I've indicated the two nodes that could be GMIPs:

And then if I actually designate both of those nodes as GMIPs...

then, in the destination model, both of those nodes will manifest as input ports on the ImportedGCModel node:

The person who works on the destination model can't choose which of the ImportedGCModel's inputs they want to provide; they must provide values for all of them. Just as with any type of node having required inputs, you must provide values for all those inputs before the node can operate.

The types of nodes given to the ImportedGCModel's inputs must match the corresponding types of the GCIP nodes in the source model; for example, CoordinateSystem for CoordinateSystem and Slider for Slider. The popup "tooltip" indicates this for each input port of the ImportedGCModel.

(As you probably know, the Control Panel lets you choose which specific sliders and other controls appear within it.)

Regarding the differences between GNTs and ImportedGCModel nodes, here are the main differences::

A GNT is a self-contained component that can be used in any model, any number of times, independent of any other model or DGN file.
An ImportedGCModel is intended for team collaboration; it's a link to another model in another DGN file. Its intended scenario is that the source model represents the core architecture of the project, while the destination model represents extension or peripheral architecture. Thus, the ImportedGCModel node to designed to appear only once in the destination model, typically near the beginning (left side) of that model. In other words, the destination model uses the source model as a starting point.
A GNT cannot be redefined after its initial creation .The best you can do is delete its definition and then re-create it from scratch.
An ImportedGCModel's definition can change frequently, at the whim of whoever is in charge of the source model. Whenever that person saves their changes to a file, the person who works on the destination model can click the "Reimport" button on their ImportedGCModel node to get those latest changes.

I hope I've addressed your questions and concerns. As always, please respond if you want additional information.

Jeff

RE: Designing a Skyscraper using GenerativeComponents

dominic SEAH — Sat, 25 Jan 2020 12:32:22 GMT

Hi Jeff,

Thanks for the explanation.

Presumably, you mean any other nodes in the 'outer client' or 'source' graph. In Mary's case, the GC_TowerGeom.dgn has a lot of output properties that can be connected to other nodes in the 'importing' or 'client' GC model / graph. Not shown in the vid, but I presume that the input properties will also be available in the client model.

OK. I assume that when you say the GIMP must be a root node, you mean the 'source' graph can not have another GMIP stored separately?

So, if the GC_TowerGeom.dgn provides the base curve for setting out the facades, and the user has another GMIP for the facade panels, this second GMIP could to be imported into the 'client' graph separately and hooked up?

If there are nested 'downstream' GMIP's in the imported node, they could be imported as separate GMIP's in the 'client' model to avoid forcing the user to re-wire the nodes? Once imported, the re-import function would be specific to each GMIP node to keep things as 'root' and replaceable / managable as possible?

[quote userid="3632" url="~/products/products_generativecomponents/f/generativecomponents---forum/186373/designing-a-skyscraper-using-generativecomponents/550722"]it's expected that most nodes in the client model will be connected, either directly or indirectly, to the outputs of the ImportedGCModel, rather than to its inputs.[/quote]

Not being able to feed inputs into the GMIP is a problem. The inputs presumably can already be exposed as Sliders? It would make sense to have these at Node level and not overload the active model's Control Panel, I think.

Is this the main difference between GMIP and GNT? It would be great to narrow the gap.

RE: Designing a Skyscraper using GenerativeComponents

Wayne Dickerson — Mon, 04 Nov 2019 10:24:47 GMT

Hi Jeff,

Sorry for the late reply.

That makes sense. I have been working through some workflows with the ImportGCModel and I can see where it is useful but as you say the GNT workflow is better adapted for the approach I was thinking of.

The main reason we were looking for a different approach is we have struggled in a team environment with GNT updates not flowing through once they have been replaced. I thought the ImportedGCModel might simplify this situation.

All good

Thanks

Wayne

RE: Designing a Skyscraper using GenerativeComponents

Jeff Brown — Thu, 24 Oct 2019 14:17:34 GMT

Whether a node can serve as a GC model input property (GMIP) is not based on the node's type, but rather on its relative position within the source GC model. Specifically, a GMIP must be a root node, that is, a node that doesn't have inputs from any other nodes.

The ImportedGCModel mechanism works by effectively replacing the source model's GMIPs with nodes from the outer, client model. Of course, only source-model nodes that are independent from the rest of the source model can be replaced in that way. (You can't replace a node in the middle of a model 'A' with a node from model 'B'; that doesn't make any sense.)

An ImportedGCModel is not designed to serve as a generic multi-node component in the same way as a GNT. Rather, it's designed to serve as an "anchor" for additional geometry. In other words, it's expected that most nodes in the client model will be connected, either directly or indirectly, to the outputs of the ImportedGCModel, rather than to its inputs.

HTH

RE: Designing a Skyscraper using GenerativeComponents

Mary Chib — Thu, 24 Oct 2019 12:58:57 GMT

Hi Wayne, Thanks, I am glad you enjoyed the videos.

To be honest, I had not really paid much attention to the "GC model input properties" as I was primarily looking to drive the other models from the Tower Geometry model. However, your question made me go back and take a look...and that starts to open up all kinds of other possibilities.

It does seem that the "GC model input properties" are limited to expressions. sliders, guages, etc. The thought of using the imported GC model instead of a GNT is an interesting thought and then does suggest the need for geometry inputs.

I need to do some more investigating...I'll let you know what I find.

Mary

RE: Designing a Skyscraper using GenerativeComponents

Wayne Dickerson — Wed, 23 Oct 2019 00:20:40 GMT

Hi Mary,

Great videos. I hadn't fully utilized the imported GC model until you showed it in your examples. Typically we have used the include GC script.

As Dominic mentioned in another thread this could be a real game changer in workflows. I can see it as a real world node grouping method, that is a easy way to manage than the GNT workflow. Just need to re-run the script or save etc.

Just wondering if I could ask a questions about the IGCM "GC model input property"?

In testing I could only set nodes like expressions, sliders, gauges etc as inputs. Do you know if that is intentional? Maybe I missed a step?

To really open up the functionality it would be great to be able to set points, polygons or other geometry as inputs giving the ability to for teams to develop scripts that others can reference in and use. Thinking out loud it is probably the same as creating a GNT but it has a bit more flexibility I think when sharing scripts with other team members.

Thanks again for the videos.

Look forward to the next series

Thanks

Wayne

RE: Designing a Skyscraper using GenerativeComponents

Mary Chib — Tue, 08 Oct 2019 13:44:51 GMT

Thanks Brendan, Just wanted to add that a playlist has been added to YouTube. The first three videos have been posted, final two will be posted by next week.

RE: Designing a Skyscraper using GenerativeComponents

Brenden Roche — Fri, 04 Oct 2019 13:53:55 GMT

NIce work Mary