Libraries & objects
About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

Become a registered object developer

Anonymous
Not applicable
This is a spin off of the topic Custom GDL objects for FREE.
ztaskai wrote:
Master wrote:

Zsolt: no problem, I think it is better that GS takes care of its own library, than there is more time for developing ArchiCAD. I do think though, that a little more stimulation for independent object developers would be good for ArchiCAD. You need to understand that objects and GDL are one of the most powerful assets of ArchiCAD. There are a lot of topics on this forum, demanding more action on the GDL front, like this one on Updating the Object Depository.
Maybe this might be a good idea: A reward for the best object uploaded to the Object depository each month (picked at random or by vote), it could fill up the depository rapidly. Or the possibility to become a registered object developer (I know you can become a registered API developer), would make it saver for ArchiCAD users to approach developers.
I like your ideas a lot. Renewing Object Depository into something more social is one of my favorite topics. Unfortunately, I don't have the momentum to set up such a multidisciplinary project like that - yet. I will try harder next year.
Then is a good time to discuss what we can do about it. Updating the Object Depository discussion here.
I have got some more ideas. When you make object developers register, GS can enforce rules about how to set up objects. For instance every object must have Parameters for Listing, or a detail level. It can give more constency to objects.

But are object developers interested in becoming registered?
35 REPLIES 35
Rob
Graphisoft
Graphisoft
The fundamental problem is that GDL has been developed as programming language which brings implicit issues in regards to graphic editing such as:
1. it is fairly difficult to capture any non-geometric or control statements,
2. although geometric entities are identifiable by a command name the syntax itself is strongly script oriented which is almost impossible to mount on chassis of any GUI
3. Translating from geometric to script representation is tricky because a computer produces the optimised version of a script as opposed to a readable script that could be understood by an user.

I do not think that GDL will ever be able to provide space for a fully fledged GUI. Simply because of its nature.
::rk
ztaskai
Graphisoft Alumni
Graphisoft Alumni
owen wrote:
Apologies for that Masterscript .. a necessary diversion IMO but we're getting back on track.
I agree.

Thanks for the explanation. I think we're on the same platform now. A graphical interface as an extra would be useful - you convinced me absolutely. (I don't even want to add buts or side notes!) The problem is that it is an awful lot of work. I'm sure such an interface won't come soon 😞

Regards,
Zsolt Táskai
ArchiCAD Development - GDL Team
AC13, AC14 and upwards...
owen
Newcomer
I will leave aside the recent posts for the moment and address some of the ideas prior - all good but i will just pick out a few and try to avoid those dealing with a GUI (or sorts) for later:
Master wrote:
-code snippets (examples!!)
Yes .. there are some basic examples in the GDL Manual but they are often in total isolation which can make them difficult to understand - both how the function actually works, and what it could be used for. So 'code snippets' could be some very basic combinations of code to produce simple working elements which could then be used as working examples and to construct more complicated structures from. One very basic example could be 2D or 3D geometric shapes adjustable via moving hotspots. Simple i know but you get the idea. This would also tie into something to do with 'automated/assisted' parameter creation i will get to at some point in this thread (something i think Masterscript may be aluding to as well) ...
Master wrote:
-What about combining a few ideas here. One developer does an upload in the depository, somebody (an architect 😉 ) likes it but needs some adjusting. He/she can post a question if somebody can modify it. Somebody does it and posts an update.
Pitfalls: the code has to be clear, readable and made by standard, because otherwise you are spending more time reading and understanding than coding. This requires an update of GDL script.
Pitfalls: I think ArchiCAD has a strong community, but . . . money makes the world go round.
A bit like making the repository an open-source development project (well lots of little ones). An interesting idea - it does have its problems, but also many advantages. You're right money makes the world go round, but i'm sure everyone who works on open source projects also does that stuff for a living. You would have your public and private projects, it would be up to each to decide what they can contribute - as many already do, just not centrally organized as we are talking about.
Master wrote:
-The code that the autoscripting creates must be more pure code and less baggage.
EXACTLY! Why is this so?? Why does an object you create at 1m x 1m x 1m (typing the values) not come into GDL with those values (1.0,1.0,1.0) but instead has some ridiculous decimal values? Is there a problem with accuracy of ArchiCAD input, or is it an autoscript creation problem?

Why can my 1m3 slab not just drag into the 3D script as a pure 1m3 PRISM or whatever .. no funny numbers, no other garbage?
Master wrote:
-Autocompleting code, just like visual basic, you begin to type an element and the GDL editor completes it or gives possible other commands
...
-Colorcoding, hyperlinks to go to GOSUBs, expanding and contracting bits of code, etcetera.
Long standing wishlist items i think .. and for good reason (i mean the wish, not the length of time it has been there). This would really, really help in working with GDL. Color coding various types of commands, automatic formatting, indents, returns, etc. Automatically create correctly formatted function calls so i do not have to worry about the command itself, just the input and output of the command is valid ... this also leads into automated /assisted parameters (later).
Master wrote:
-Visual Userinterface creation, dragging fields and pull-down menus, resizing images.
Yes please, although if the UI coding can be done (2D) graphically ... (will have to leave that for tomorrow)
Erich wrote:
The ability to copy/paste parameters in the parameter table!
Yet another really basic, but longstanding wish. The UI needs an update which would include further improvements like being able to select multiple parameters together and move them by dragging anywhere, not just these little black arrows one by one.
cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5
Anonymous
Not applicable
Hi Folks,

Thank you all for your insights. This thread is becoming a very good resource of ideas for improving GDL.

So let me contribute...

How about a graphic interface for UI (User interface)? I have to confess that scripting UI is a real pain. I guess a more easy UI with embedded images would lead to more quality objects.

My 2 cents.
owen
Newcomer
Rob/Zsolt,

I don't dispute it is probably a very difficult task ... I doubt impossible unless there is something fundamental to GDL scripting that would stop it dead. If that were the case then you could say maybe GDL was the wrong choice, but pragmatically there is nothing you can do now short of throwing it and all the work built on it away ... i.e its not going to happen.

So for the moment i will lower my expectations as to what could be achievable.

Lets completely forget about back-and-forth 3D drawing (with tools) of GDL entities. Leave it one-way for the moment - as it is now, where you can draw something in ArchiCAD and drag that into the script - but clean it up a bit like we said earlier.

Lets go back to the Grasshopper interface - i think this is very much a 2D GUI for automatically formatted code blocks some of us have been talking about (or close to). Lets pretend each Component represents a GDL command including a number of parameters requiring input (from other GDL Components) which are then used to create the output parameters or entities (which can also then be passed on to further GDL Components that can make use of it). The code of the actual command is hidden - after all the only thing we care about is the input parameters and the output right? There is absolutely no need for us to type or even see the command ourselves.

Once you leave this dual-mode editing out of the picture and think of these Components as simply a 2D graphical representation of any number of lines of code forming a GDL command i think it becomes totally realistic. These GDL Components are not just 3D geometry commands - they can be mathematical equations, lists, UI Interface elements (e.g Parameter input dialogs), etc

I hope this is clear enough?

Now one last thing i mentioned in the previous post - automated / assisted parameter creation. All these GDL components obviously require input parameters and may create output parameters. With the current system if the input parameter is missing the whole script breaks down (output if unused does not complain - it just waits to be used). But with the system as shown by Grasshopper if a Component has no input it does not complain .. it just is inoperable. Much like commenting out lines of script in GDL. These input parameters are also highly flexible - say you had 10 components each of which has 3 required input parameters. Now that is potentially 30 unique parameters .. or only 3. But you do not need to decide when you add (write) the component - the input parameters are automatically adjusted on the fly depending on what you connect to them.

So by assisted I mean you do not need to worry about predefining all your parameters and then renaming them or adjusting them all through your scripts if things change. They are handled dynamically as you link, relink, rearrange, etc

(Masterscript - i think these links are also somewhat like visual hyperlinks we would like in a text-only editor? You can clearly see what is linked to what in a flow-chart fashion. Potentially much more easy to understand that text)

i think this is not quite finished but i'm almost out of battery - so more later perhaps (but maybe i should just shut up?)

cheers,

os
cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5
vistasp
Advisor
Braza wrote:
How about a graphic interface for UI (User interface)? I have to confess that scripting UI is a real pain. I guess a more easy UI with embedded images would lead to more quality objects.
Totally agree. The ability to drag UI elements around instead of calculating their positions would be wonderful.

And I've said this before - can we at least have line numbers when we look at scripts in the GDL editior?
= v i s t a s p =
bT Square Peg
https://archicadstuff.blogspot.com
https://www.btsquarepeg.com
| AC INT | Win11 | Ryzen 5700 | 32 GB | RTX 3050 |
owen
Newcomer
[Disclaimer]: Please have a salt shaker or two at hand when reading this post. It is (unfortunately) not serious.

Discussion has come to a standstill for the moment (as all GDL development threads seem to do) but just thought i would have a bit of fun with Search & Replace on a quote from the McNeel site regarding 'that' scripting interface previously discussed:



"Aimed at the emerging generative shape designers, GDL 2™ is tightly integrated into ArchiCAD™ and allows the user to interactively drive geometry via a plug and play interface, removing the need for learning the GDL Script language.

Viktor Varkonyi said that GDL 2™ was developed as an attempt to make scripting more accessible to users that wanted generative modelling tools. “During the design process, designers set-up sophisticated relationships between the parts of the design problem. Before GDL 2™, GDL Scripting or C++ code was the only way to do that in ArchiCAD™. Writing code is not something designers really want to get their head into. It seemed like most bigger firms have a few ‘scripting geeks’ that could not keep up with the designers’ demands. So more and more designers were asking for scripting training... but then they hated it once they figured out how tedious coding was.

“GDL 2™ is a way for designers to look at design problems as a set of sophisticated relationships and to map those relationships graphically and programmatically into a system that allows them to interactively play with alternatives. At first GDL 2™ was very simple but, based on user feedback, it now allows for very complete systems, including the ability for expert users to extend the system with C# and Visual Basic components.”

GDL 2™ works within ArchiCAD™ and uses standard ArchiCAD™ geometry but has its own slick interface window. Algorithms and manipulators are dragged, dropped and connected, as if they were being wired together like effects pedals. It is about as easy as it gets to use but still requires a methodology and understanding of geometry to get a desired result."



cheers,

Owen Sharp

Design Technology Manager
fjmt | francis-jones morehen thorp

iMac 27" i7 2.93Ghz | 32GB RAM | OS 10.10 | Since AC5
Anonymous
Not applicable
I agree, GDL 2™ is highly accessible and easy to use, thanks to its friendly interface. I used to be the scripting geek of the office, now everybody does it. With the previous GDL environment it took days to finish an object, now only hours. Objects are so easy to make and edit, the BIM-value of our projects skyrocketed!
Anonymous
Not applicable
Hello,
What is this GDL 2™ and where does one get it ?
Thank you,
Peter Devlin
Anonymous
Not applicable
Just popped in and I saw the GDL 2 post as well and had to go back and read the whole thread to realize it was not real. Might want to edit the post with a clearer disclaimer to that effect, lest the internets start crawling with rumors of a long awaited GDL 2 (Had my hopes up for a minute!)