GC Update 9 is slow

I have been using GC from Update 4, there has been a performance issue. I just want to share some feedback about the performance in Update 9. The current version I am using is 10.9.1.38. As shown in the video I have a simple script that reads solids from a range and re-creates them based on their distance along the alignment, there is not a lot happening in the file. I have also hidden most of the nodes to improve the speed, however, when I tried to switch the visibility of the final solid node it's taking forever to apply the command. As can be seen from the below video, it's going one by one element to change visibility. For a model with about 10,000 solid elements, it will take days to do this and the file/model will become unusable.

Another issue I found in the latest update is, that I don't see the full list of dot operators when writing it in input fields, it was showing all the operations available for a node. For example, If I have a list of solid and I want to flatten the list I won't see "Flatten()" operator when I write a dot after a solid.

On the positive side, GC is great and I want to thank the development team for their hard work to help users and bringing great functions to GC. On another note, I have seen some graphical programs which work as an Add-in to the main software and it can get the elements by selecting them and we can further use programming to perform modification or data extraction. In GC, we have the Range function which does a similar job but we need to re-create the elements then only we can perform further functions. Doing that, we can't perform functions on the different types of elements. For eg. I have a Solid and Circle in my model and I want to move them using GC, I will need to create a range, create a node "Solid by elements in range" and "Circle by elements in range" and then I can move both types of elements. Is Bentley thinking in this direction where we can directly manipulate objects using programing language rather than re-creating them? Or, would we see a node in GC where it can capture every type of element from the model by using a range node and do common modifications/data extraction for standard properties

  • Hi Jaimin

    I just want to share some feedback about the performance in Update 9. The current version I am using is 10.9.1.38. As shown in the video I have a simple script that reads solids from a range and re-creates them based on their distance along the alignment, there is not a lot happening in the file. I have also hidden most of the nodes to improve the speed, however, when I tried to switch the visibility of the final solid node it's taking forever to apply the command. As can be seen from the below video, it's going one by one element to change visibility. For a model with about 10,000 solid elements, it will take days to do this and the file/model will become unusable.

    We have been able to capture, repeat and fix a few performance issues for the next release. The key being capture and repeat the performance issue, which is often the challenge. Is this one repeatable? It happens every time you try it? If so any chance you could raise this file on a ticket ASAP or even post it here? 

    Another issue I found in the latest update is, that I don't see the full list of dot operators when writing it in input fields, it was showing all the operations available for a node. For example, If I have a list of solid and I want to flatten the list I won't see "Flatten()" operator when I write a dot after a solid.

    That one has been raised and is on the list. In the meantime the Operation Node was designed to take a lot of that syntax work out of it. You will find Flatten there. Just one tip, you can string Operation Nodes together and often a list of objects needs to be sent to a ToList before further operations become available from the dropdown. 

    In GC, we have the Range function which does a similar job but we need to re-create the elements then only we can perform further functions. Doing that, we can't perform functions on the different types of elements. For eg. I have a Solid and Circle in my model and I want to move them using GC, I will need to create a range, create a node "Solid by elements in range" and "Circle by elements in range" and then I can move both types of elements. Is Bentley thinking in this direction where we can directly manipulate objects using programing language rather than re-creating them? Or, would we see a node in GC where it can capture every type of element from the model by using a range node and do common modifications/data extraction for standard properties

    From the beginning, GC was used to create and manipulate objects by a set of rules. Those objects, whilst being standard elements had that link to GC, so further actions and relationships performed by GC were maintained. You can't have GC hooked up to the elements then suddenly use a move tool to move a single object in a series as an example. That would break the rule for a series. What the RangeBox, in addition to the Promote and the ByElement method provide is a way to take non GC geometry, and use it to create a new object which maintains that link to GC. Actions to the non GC object can still use the standard tools without disrupting rules performed by GC. The RangeBox and the ByElementInRange method hasn't specifically been designed to move objects, or change the attributes, or something similar, but instead is used to lever the original geometry to create GC known objects and subsequent actions downstream. 

    I think what you are asking for here is to have an interface, visual scripting, node and wire type, to perform actions on non GC elements. For example, VBA can be used to lever the standard Move tool to move an object, but VBA needs coding experience where the visual scripting interface (what we find in the GC graph) does not which makes it easier to create tools for those who aren't great at coding. Have I understood this correctly? Yes we have discussed but how we do this technically, given the background on the way GC works will take some thought, or maybe its something else all together. 

    Could you definitely raise a ticket for your requirement so its captured as coming as a request from a user and any further detail so it can be taken on board? Feel free to discuss here but formalize in a ticket.  

    Stuart


    This is a test

    Answer Verified By: Jaimin Patel 

  • As can be seen from the below video, it's going one by one element to change visibility.

    Hi Jaimin

    In this particular case, it looks like if you left click on the solid node first, which selects all the solids, then right click to turn the visibility off, it goes a lot slower if you just turn the visibility off, without selecting the objects first. 

    Do you see the same at your end?

    Stuart


    This is a test

    Answer Verified By: Jaimin Patel 

  • Hi Stuart,

    Thanks for the detailed explaination about my feedback/questions. I think you have answered most of my questions.

    I think what you are asking for here is to have an interface, visual scripting, node and wire type, to perform actions on non GC elements. For example, VBA can be used to lever the standard Move tool to move an object, but VBA needs coding experience where the visual scripting interface (what we find in the GC graph) does not which makes it easier to create tools for those who aren't great at coding. Have I understood this correctly? Yes we have discussed but how we do this technically, given the background on the way GC works will take some thought, or maybe its something else all together.

    Yes, you have understood correctly. It would be nice to have feature. As you said, similar can be achieved by VBA coding but it requires coading knowledge, where as GC is easy to use and adding this kind of node/wires will further expand GC's capabilities, and may be it will help performance as well, as object's doesn't need to be re-created. I hope development team can find some solution to this matter.

    Is this one repeatable? It happens every time you try it? If so any chance you could raise this file on a ticket ASAP or even post it here?

    It is fairly big file and lot of solids in it so I would expect it to be heavy, however, switching the visibility perticually taking too long. I'll definitely share the file to test.

    Regards,

    Jaimin Patel

  • It is fairly big file and lot of solids in it so I would expect it to be heavy, however, switching the visibility perticually taking too long. I'll definitely share the file to test.

    Did you try the suggestion I made? Don't select the node first - just turn off the visibility without the node selected. 

    Do you need the node and its its elements included in a selection for this? 


    This is a test