Over the past few months I have been working with one of our Bentley users, Tapani Talo, modeling a high rise tower using GenerativeComponents and OpenBuildings Designer. Mr. Talo had some very interesting ideas for a tower design and was looking for a way that he could conceptually model the tower without having a defined program or site. He needed a model where he could explore different design ideas, variations and what-if scenarios without endlessly rebuilding the model. A problem tailored made for GenerativeComponents.
He has generously allowed me to share what I learned throughout this process. I have put together a series of YouTube videos showing how I set up the GenerativeComponents model(s). These will be posted on YouTube over the next few weeks. The first in the series is posted today.
Establishing Tower Geometry
For those of you that have taken the GenerativeComponents QuickStart you will recognize many of the same techniques for creating a stacking model that drives the Floor Manager, but you will also see some new concepts like linking one GC model to another in order to use geometry in one model to drive geometry in another model. This turned out to be a very useful technique in working with such a large model.
I hope you enjoy.
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.
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
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::
I hope I've addressed your questions and concerns. As always, please respond if you want additional information.
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.
Jeff Brown said:"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.
Jeff Brown said: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.
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.
Jeff Brown said: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.
> 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 Brown said: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.
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.
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.