Save geometry after transaction or run multiple transactions

Hi,

Coming from Revit- Dynamo( Building Design) background, i am new to Bentley generative Components & exploring it currently. In revit dynamo, once we run a script & close dynamo , the geometry/process still is saved or present in model. we can run another script post that without worrying about the geometry or any element in revit being affected with respect to the task being automated .
when i try the same in generative components say create points from excel or place cell based on coordinates, only one transaction is available at a time , how can i save the placed geometry/cell or points? So that i can run another transaction or scripts do further automation later on as & when the team needs to modify anything.  i tried switching to modeling or aecosim from dropdown after i ran transaction , it did save geometry the next time i opened generative components, but it seems to crash most of the time. any help would be appreciated.
Thanks

Parents
  • Hi Sachin,

    Any GC changes made through nodes will be preserved as a new Transaction. Before closing out we should hit the save button to account for the latest change in form of a Transaction. 

    After each step, we can save the changes as a new Transaction in the transaction window.

    Or, you can turn on Auto-Transaction where each transaction will be saved automatically. 

    If you find too many changes under one single Transaction we can split it into multiple Transactions by using the following option.

    If you see too many transactions considering every little changes, we can make it cleaner and compact by using the following option. 

    I hope this information is helpful.

    but it seems to crash most of the time

    It is unusual, might be file specific. Which application version you using? You might share your file

    I hope you have a great time using GenerativeComponents. Feel free to contact us with any doubts or questions. 

    Thanks,

    Anik

  • Hi Anik,

    Thanks for quick reply. but that is not exactly my question, apologies if it was confusing. let me rephrase it again so as to make it more clear.

    for example in Revit dynamo, let say i ran a script to place some families/objects or elements using excel(script 1). The project team might make some changes manual or otherwise with respect to design/coordination. Post that i might have to run another script to say update attributes or property set values based on another excel data set. so there are two scripts running one after another not as a combined workflow or single script, can the same be applied to GC.  i mean lets say i do one set of transactions , saved them as GCT -01. later on i want to run GCT-02 which is totally different module or workflow. is that possible? while still maintaining the original geometry or elements in the file

    The main reason being as my job is to just develop scripts dynamo or otherwise & provide them to project teams to run them on respective models. So wondering how the geometry can be saved after the transactions have been run & also can multiple transaction be run that are not relative to each other.

  • HI Sachin,

    This made me a little clear. I do not see any reason why it should not work. 

    what i have seen here is that if i add in new transaction say from another gct file or script,

    Are you editing the existing transaction script? How exactly are you adding these new transactions? As far as I know, if you add new transactions it should not turn of the previous transactions.

    i dont want to loose any geometry that was created earlier. 

    I do not think that you are losing the geometries. You just have to replay the transaction again in your case. 

    Thanks,

    Anik

  • Hi Anik,

    Basically after i save the DGN say with some cells placed using the script/transaction. i then save the transaction( save current doc to transaction as GCT file option) .

    i open building designer place some cells manually etc & save the file again. After that i open the GC , i can see the manually added content , but my previous cells are not visible, if i run the transaction script again  it will appear. isn't there a way to make them independent. so that i don't have to run transaction every time to bring in the elements. basically they be part of the model once saved!!

    i go to edit entire transaction option & basically do replace current transaction option , incase i want to run another script. 

    is there a way that i can have two separate scripts run one after another or add to transaction list. 

    not sure if i am doing it the wrong way or am i missing something.??

    Thanks

    Regards

    Sachin

  • if i add in new transaction say from another gct file or script, the cells from earlier transaction go off.

    This should be possible, using the various tools:

    Include File (.gct) Transaction

    Import Node

    Function Call Node

    Packager Node

    ...?

    Which are you using?

    You can use the same file(the one used by the design team) again in GC or you can reference it in GC. We can further discuss a standardised workflow once we have more information about your project requirement.

    As Anik mentioned earlier there are various ways to incorporate GC objects into the general OBD .dgn models... so, it would be good to get the GC team to review. The old paradigmn was based on keeping the GC script and processing in separate models that are referenced or inserted as Cells in the general OBD models. This federated 'divide and conqure' approach leverages Mstn's very good Ref attachment functionality and has a lot of advantages... but will probably feel alien and clumsy to Dynamo users.

    GC users tend to use GC as a front-end form finding tool that generates a model that is handed off to the general team using OBD. In contrast, Dynamo seems to be very popular as a general visual programming tool that has in-depth access to the R*vit database... so more parallel / embeded working. I think that GC is also moving slowly in this direction...

    Let's take a common task that Dynamo would be used for: automated labeling of geometry inside a model. In GC, the GC generated text elements would typically be generated in a separate model. Using Mstn's Ref attach tools, the annotation would simply be 'Xref'd' in where / when needed. Multiple annotation models can be processed using the same .gct etc. The smart text elements would remain part of the GC graph, which prevents editing by Mstn/OBD tools. No need to get into a heavy centralised model.

    OTOH, Dynamo users would expect the smart text generated by GC to be inside the OBD model. This is possible, but currently, the resultant smart text elements would not be editable by the non-GC user.

    What happens when the smart text inside the model needs to be updated?

    The simple way around this would be use GC Export Node in combination with a Mstn Delete Element command function call..? The GC script would delete the existing smart text elements and add the new elements at the end of the script run?

    This way, the smart text would be editable by the general team. Moving text around as the non-GC users add more stuff is inevitable and there would be no need to manage the GC scripts etc in the dgn.

    Basically after i save the DGN say with some cells placed using the script/transaction. i then save the transaction( save current doc to transaction as GCT file option)

    Not sure, but you may have better luck saving as dgn?

    i don't want to rewind or continue the same transaction.

    Also, there is a tick box to always play the transactions...

  • Mstn's very good Ref attachment functionality and has a lot of advantages... but will probably feel alien and clumsy to Dynamo users.

    You have hit the nail on the head there Dominic. 

    We GC users are very comfortable in taking geometry (dgn, dwg, ifc, etc) or information (excel, etc) as referenced information and re-creating geometry based on the rules we apply in GC using the input geometry or information. It in essence creates a copy of that information within the file containing the script, and can replace the original information when needed or if needed, as oppose to writing directly to, and making change to existing geometry. 

    An example of that is here. https://youtu.be/Yw1uWFoMitI

    The 2D survey is referenced data from some one else. It could be constantly changing. What we are doing here is taking the data we require from that, and creating "new" geometry without altering the existing.

    However the author of the 2D survey may continue to make change. After change we can run our GC script again, and recreate that geometry based on change made to the 2D survey. 

    Making change to geometry manually created in a DGN would require a "utility" created in say VBA or other coding based techniques. We have discussed using GC as a simplified way of creating "utilities" without the need to "always" dive into code. Its certainly on the table.  


    This is a test

  • We GC users are very comfortable

    Yah... maybe too comfortable for too long Stuck out tongue winking eye

    The 2D survey example illustrates the problem. Once the info is processed and part of the general OBD model it is difficult to manage / retrieve for further processing by GC. Advantage: Dynamo.

    It would be good to discuss further and clarify the options available now and maybe what is in the pipeline. Future SIG-o-rama?

    A 'Range Processor' Node might be something that should be on the near term roadmap.

    1. User writes script in model A.

    2. User Ref attaches elements to be processed in Model B or uses a Ref attach Node.

    3. User uses Range Node to suck in elements to process.

    4. New option in Range Node to lock the elements in the Ref attachment using the same mechanism that spits this cheerful message out 'The originating application (22877) has intentionally restricted changes to this element.'?

    5. User wires results to a Range Processor Node that exports the results back into the Ref attachment. Inputs include the Range Node (to get the keys to find, unlock and delete the input elements; as well as the dgn file and model path etc).

Reply
  • We GC users are very comfortable

    Yah... maybe too comfortable for too long Stuck out tongue winking eye

    The 2D survey example illustrates the problem. Once the info is processed and part of the general OBD model it is difficult to manage / retrieve for further processing by GC. Advantage: Dynamo.

    It would be good to discuss further and clarify the options available now and maybe what is in the pipeline. Future SIG-o-rama?

    A 'Range Processor' Node might be something that should be on the near term roadmap.

    1. User writes script in model A.

    2. User Ref attaches elements to be processed in Model B or uses a Ref attach Node.

    3. User uses Range Node to suck in elements to process.

    4. New option in Range Node to lock the elements in the Ref attachment using the same mechanism that spits this cheerful message out 'The originating application (22877) has intentionally restricted changes to this element.'?

    5. User wires results to a Range Processor Node that exports the results back into the Ref attachment. Inputs include the Range Node (to get the keys to find, unlock and delete the input elements; as well as the dgn file and model path etc).

Children