Hi,
I have lots of small utility type User Functions I use across several projects.
What is the best way to simply incorporate them into new projects (perhaps as a node) / or across all projects (as part of the general interface).
RegardsRobert
Hi Robert,
The simplest method is to collect all these functions in a single GCT file and include that GCT file at the start of each script via an Include-File transaction. That way those functions will show in the Functions dialog and also in auto-completion.
The less simple method is to use the C# sample solution which contains a template how to wrap functions so they can be included in GC as a loaded DLL.
The first method allows easier correction of functions, if needed. The latter is more resilient against accidental modifications.
Regards,
Volker
would this be able to help the user generate GNT's with non-geometric nodes?
Hi Dominic,
GNTs can include some non-geometric nodes like Expression and FunctionCall nodes starting with Update 3 (or even earlier).
Future extension of this capability of including utility node types would have to be considered on a case-by-case basis.
Hi Volker,
Good to hear that Expression and FunctionCall nodes will be honoured. Is there a list of non-compilable nodes?
Ideally, all the nodes should be compilable... Isn:t GC written in C# anyway?
Geometry nodes and "Utility" nodes are different and before making them more similar we have bridged the gap for some of the utility nodes. For other utility nodes there would be an issue with their specialized user interfaces or specific behaviors which at the current state we cannot integrate into a GNT. Without disrupting my development colleagues, I'll just posit that the major challenges are at an architectural/logical level. (Yes, GC is written in C# but even that leaves plenty of challenges...)
I'll look for a list which identifies Utility node types that can be included in GNTs, or vice versa, whichever is the shorter list.
Many thanks for looking into the list.
it will be very useful. Most users will try to GNT as much of the graph as possible... as they develop it, for speed and usability reasons. It would be good to know which nodes to avoid, or make provision to bypass on GNT creation. Presumably the GNT tool will also warn and point out which nodes can not be digested?
C#: I was hoping that if GC's nodes were written in C# then it should be possible access the node as a loaded dll / assembly... In a so called 'zero touch' way. http://www.hksinc.com/hksline/2017/07/12/dynamo-components-part-2a-zero-touch/
Presumably, the GNT tool uses VS Express under the hood to generate the dll. Would having a pro version enable this?
Thank you for your suggestions.
For speed, the recommendation would be to use GC's Sample Solution to code a class library (a node type or series of node types) analogous to what's described in the "zero touch" blog entry. The November GC SIG workshop will be about the Sample Solution. As development environment, Visual Studio or Visual Studio Express are working well.
GNTs are compiled with GC's built in parser/compiler, which is also used to create the code that will be executed when users write functions directly in GC. Note that the GNT Library concept now makes GNTs more portable between users, projects, and versions (upward compatibility). We introduced the GNT Library concept because it seems that there are increasing challenges for DLLs' portability because of security concerns and versioning requirements. GNTs; however, are for encapsulation, not for improving speed of execution.
True "no-touch" linking of DLLs to automatically create GC node types is an interesting notion; however, because GC's concept of how nodes and their techniques are organized, this may be a challenge.
Thanks for the clarification.
YII 2018 was very interesting... in particular the new initiative to open source imodel.js. I suppose that the target crowd for this API will be much larger than the 'design'-oriented users of GC/OBD... and plugs into the nascent 'smartcities' big data movement. where consumer-centric providers of data and not the producers are king.
The funny thing is that API will be JavaScript-based, via TypeScript.
First, I wondered if GCScript would go JavaScript... ala Microstation/JS ! :-) But I was told that Mstn was too wedded to dotNet. I suppose GC would be in the same boat. Then, I thought maybe GC should go opensource as well? Looking at Dyn*o, it doesn't look like it is very active. No doubt, infrastructure will have a much better chance of 'terraforming' a profitable ecosystem for Bentley. FME must be feeling a bit out-flanked at the moment. Acquisition announcement for YII2019?
ESRI's and Cesium seem to be a lot more successful, here. I guess, these days everyone wants/needs to be 'everywhere' like Google or Amazon. Mstn/J was aimed at getting things to run 'everywhere' as well... two decades ago.
ZT: I hope that some of this will be possible in future... espcially if GNT's are not the way to speed things up (news to me!).
I suppose if/when imodel.js takes off, then there might be a business case to provide a Java/TypeScript API for GC. It might even be the excuse to develop a scalable cloud/GPU-based VM?