Become a registered object developer

[Anonymous]

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?

[ztaskai]

I'll post 2 answers to all which has been written in this topic before me. This one is about graphical GDL scripting (which is slightly off-topic here).

I just tell you how I see this topic. My point of view can change - you may change it 😉

Let's start from the target groups: there are architects (A) and developers (B).

(A) For architects, a graphical GDL interface is an overkill. As Master Script already wrote they need efficient parametric objects and some good custom content creation. The first one should be suitable for generic recurring jobs. The second one would stand mainly for project specific objects. Of course, it could be parametric too - sure it would be useful. Consequently, I truly doubt that Rhino is a good tool for architectural purposes. Furthermore, ArchiCAD isn't a modeling tool - it's for architectural design and it can use the models generated by modeling software (3DS, Sketchup, Autocad, etc.).

(B) For programmers & content developers a graphical interface is pain. In the first 1 minute I was amazed by the Grasshopper videos but then my stomach started to hurt watching the struggle of the demo person (just like watching a Ben Stiller movie). All those repetitions, hovering, mousing aren't the attributes of an efficient development tool. GDL should develop into a programming language producing better maintainable scripts and GS could provide a better text/script editor for it. A real programming language will always outperform graphical interfaces in professional usage and well-scripted objects will outperform generated content.

A few words about Graphisoft priorities - at least the public part. GDL integration and customizability is a priority for us. You mentioned curtain wall which can contain custom GDL elements for each component - brilliant example. All ongoing developments aim for about the same level of integration with GDL. Unfortunately, custom profiles are a good example for the opposite - I can see that. There are plans to take custom profiles to the next level but all ideas have to fit into "the big plan" 🙂

[ztaskai]

Now I get to the actual topic 🙂

I don't really believe in the "registered" part either. I don't think anyone can tell that a specific developer follows GS recommendations unless they work together. We could test whether the developer knows the methods but I don't think we should waste resources on that.

I believe more in a tightly organized community which can rate products and providers. Naturally, I want to display some technical quality information too which is set by GS or by GS tools. I don't even see how it should work theoretically let alone in practice.

This could be the forum where we discuss how a correct rating system should work.

What do you think?

Regards,

[Erich]

Zsolt, I really appreciate your frequent presence on the forum recently. It is nice to get a Graphisoft perspective on things.

I don't completely agree with your point A above (For architects, a graphical GDL interface is an overkill). I think is it nearly impossible for Graphisoft, or anyone else for that matter, to provide content appropriate to all conditions. In fact this is the very reason I first learned GDL. But similarly I would hazard a guess that most architects will not even attempt the most basic GDL because it is outside of their comfort zone and realm of experience. By providing a graphic interface you would be speaking to your clientele in a language they better understand. I have done some GDL instruction for my local users group and by and large everyone's face goes kind of glossy when looking at pages of code in a scripting window. That said, I would hate to loose the scripted interface we have now as I do agree that is is more effective once understood.

I think the idea of registering GDL developers, while perhaps providing better content, will almost certainly reduce the amount of content available which will not be beneficial to the community. We do not yet seem to have the issues seen in the Revit community where junk content abounds. Right now I think we need to get more of the community involved in content creation.

The idea of a community driven rating system might help control the quality. The problem I see with rating systems is that when a user first acquires an object, you have not idea if it is good or not. Therefore any rating the user may provide initially can not be based on any real criteria. By the time a user has used a part and formed an opinion based on that experience he/she is probably nowhere near the forum and has no means to submit a rating. Then when on the forum later, the object is long forgotten and while the opportunity for providing a rating might existing the inclination is gone. Perhaps such a rating system could be tied into the Archicad interface so such ratings could be provided from within the program. But if so it would need to be elegantly done so as not to affect the daily use.

[owen]

ztaskai wrote:
I'll post 2 answers to all which has been written in this topic before me. This one is about graphical GDL scripting (which is slightly off-topic here).

Apologies for that Masterscript .. a necessary diversion IMO but we're getting back on track.

ztaskai wrote:
Let's start from the target groups: there are architects (A) and developers (B).

(A) For architects, a graphical GDL interface is an overkill. As Master Script already wrote they need efficient parametric objects and some good custom content creation. The first one should be suitable for generic recurring jobs. The second one would stand mainly for project specific objects. Of course, it could be parametric too - sure it would be useful.

This conception of who GDL should be geared towards is where our disagreement over its interface lies. I actually think Parametric Scripting (GDL in this instance) should be viewed as part of the design tools available to Architects working in ArchiCAD just like the Wall tool is. Now in theory it is now, but due to implementation it essentially gets ignored by most design architects.

I am an architect who also happens to be a bit techy. 6+ years back working for a big firm we could see the benefit of making our own custom objects - both general office standards and project-specific. However no-one really knew how to do it .. not even a handful. We (the design team) wanted to apply a series of modular facade panels to a series of 'spline' planform facades. Given the alignments etc were still in flux, as were the proportions of facade panels, we wanted to do it parametrically so we did not have to manually replace/resize each panel whenever we wanted to test things out. So I bit off a bit more than i could chew and threw myself in the deep end - the GDL Cookbook and these forums were the only help you could get. It was rewarding but extremely frustrating at times. We got about 80% of what we wanted - parametric modular panels all good, but couldn't get an array of different panels along a spline which was editable. Could probably do it now but that was the first real GDL i had done so ..

Now GDL is not that difficult if you are that way inclined, but for someone who has no programming background (or desire to) it is totally off-putting. After 5 years of working for the same firm there was still only a handfull of us who could do any GDL. Even creating the simplest of objects were beyond 95% of the office because no-one wanted to 'program' in a text editor. Fair enough, we are architects.

Now i know for a fact if there was some sort of 3D graphical interface - even in combination with a 2D editor window - we would have learnt faster and there would have been more than just a handful of us. Architects love to design systems based on relationships, proportions etc and we love do it graphically. Yeah let people dig into the code under the graphical interface, or in parallel - but let us design parametric systems in 3D. Its how we work, and why many of us love working in ArchiCAD versus AutoCAD (efficiencies aside).

We do not however want to manually type lines of code in a text editor, check it for typos, hope we understood the sometimes cryptic GDL Manual explanations, etc, etc

From an architects perspective (and we are your target, not programmers) drawing two cubes in 3D, dimensioning between their faces and saying 'make this Parameter A' beats writing:

CPRISM_ mat, mat, mat,
    n, h, 
    x1, y1, 15,
    x2, y2, 15,
    x3, y3, 15,
    x4, y4, 15,
    x1, y1, -1

ADDX ParamA

CPRISM_ mat, mat, mat,
    n, h, 
    x1, y1, 15,
    x2, y2, 15,
    x3, y3, 15,
    x4, y4, 15,
    x1, y1, -1

DEL 1

ztaskai wrote:
Consequently, I truly doubt that Rhino is a good tool for architectural purposes.

There are many that would disagree. I think it has its place for design, but to actually produce ConDocs you would most probably go with ArchiCAD. They are working on their documentation side of things though, and with digital models driving fabrication who knows how long the status quo will remain. ArchiCAD is very much geared towards production of traditional 'paper' drawings (something it does very well too).

ztaskai wrote:
Furthermore, ArchiCAD isn't a modeling tool - it's for architectural design and it can use the models generated by modeling software (3DS, Sketchup, Autocad, etc.).

Agreed - modelling is just one part of the design process, but a very important part. I just think there are a lot of features of 'generic' modellers which could be applied to the modelling side of ArchiCAD, still with all the other architectural specific functions on top. As for the 'can use models..' bit - yes and no. Technically true but there are a lot of issues and often the results leave a lot to be desired. If it were possible to model complex forms in other applications and get them into ArchiCAD in a usable way then perhaps this whole subject would be redundant.

ztaskai wrote:
(B) For programmers & content developers a graphical interface is pain. In the first 1 minute I was amazed by the Grasshopper videos but then my stomach started to hurt watching the struggle of the demo person (just like watching a Ben Stiller movie). All those repetitions, hovering, mousing aren't the attributes of an efficient development tool.

Assume you're refering to the second 'high-rise' video? There were a few hiccups but this was a recording of a live webcast tutorial AFAIK. It was a pretty simple exercise which should probably have been covered much quicker but for all the talking (and the small 'how does this work' bit at the end ...)

The first video showed the extremely rapid construction of a triangulated complex curve structure - 7 minutes which i'm sure would have been quicker if it wasn't being paced so people could actually comprehend what was going on. Can anyone seriously tell me they could code that form in GDL in 7 minutes? I don't even think it is actually possible given the current GDL functions available - and you would certainly need a maths degree.

I don't know .. maybe you need to be an architect to see how much better that method (draw in 3D as well as drag 'n drop preformed code snippets) looks to the current GDL.

ztaskai wrote:
GDL should develop into a programming language producing better maintainable scripts and GS could provide a better text/script editor for it. A real programming language will always outperform graphical interfaces in professional usage and well-scripted objects will outperform generated content.

I agree Graphisoft should at the very least provide a much better script editor - there have been many suggestions going back well over 5 years now. I also agree that for programmers a text-based interface is probably far more efficient. However why does it have to be one or the other. Can the programmers not just code directly, while others can draw in 3D or code as they feel comfortable? Its similar in Rhino ... the programmers can stick with RhinoScript if they want but now there is a GUI wrapper (Grasshopper) providing a designer-friendly interface to it. This is the reason it is really starting to take off both in schools and practice.

I would propose is actually a side-by-side GDL editor option where you could see both code and 3D, along with the effects of editing each on the other.

ztaskai wrote:
A few words about Graphisoft priorities - at least the public part. GDL integration and customizability is a priority for us. You mentioned curtain wall which can contain custom GDL elements for each component - brilliant example. All ongoing developments aim for about the same level of integration with GDL. Unfortunately, custom profiles are a good example for the opposite - I can see that. There are plans to take custom profiles to the next level but all ideas have to fit into "the big plan"

Yes the Curtain Wall tool is a good start - you can create your own custom components to call into the system. Good stuff.

However I am talking about being able to create your own systems such as this via scripting - such as define a plane, deform it, subdivide and extrude profiles along joints, infil panels etc - similar to the video i was talking about. I do realise this then gets into issues of how you represent these things in plan when the plan view is not a 'real' 3D cut view like Sections/Elevations, etc.

That is a can of worms that has been opened before so better leave it there.

glad we can exchange perspectives

[owen]

Whoa ... that was longer than i thought

ztaskai wrote:
Now I get to the actual topic

quite

I think some sort of quality assurance of developers by Graphisoft (which is what a registered developer program would imply to many) would be unworkable from Graphisofts perspective ... its just too big a job. I certainly don't want their GDL dept spending time on it.

What they can do is provide better resources for developers - and anyone who uses ArchiCAD can be a developer. Some quick things that come to mind:

• - Better GDL Manual - its not terrible, but it is hard to understand how things work in places which is why books like the GDL Cookbook and GDL Handbook are so important.
  
  - Better training material - including guidelines on how to structure objects, common parameter names (maybe this ties into the documentation of Graphisofts own Library standards)
  
  - Better ArchiCAD Library + Standards Documentation - anyone who has opened up one the incredibly complicated GS objects will understand. It is often quicker to start your own from scratch than modify something that almost does what you want due to the fact it is so damn hard to find your way around.
  
  - A code library / exchange - people could share all kinds of code snippets, just drop it in your script and correct the parameter names as required. Graphisoft could even include their library of code components to kick things off .. that would be really useful if documented.

[Erich]

owen wrote:
A code library / exchange - people could share all kinds of code snippets, just drop it in your script and correct the parameter names as required. Graphisoft could even include their library of code components to kick things off .. that would be really useful if documented.

This is an interesting idea, if the snippets can be kept simple enough to be useful. I am working on setting up a personal database in Filemaker currently for just this purpose for my own coding. If this idea could effectively be broadened and shared it could spur better code development and more complete solutions.

[Anonymous]

I don't mind being off-topic here

I think there are some pretty good ideas:
-Better GDL Manual
-we love do it graphically
-code snippets (examples!!)

Rating system:
-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.

GDL interface
I think there is a wide range between the GDL editor now and a graphical editor. Some examples to tighten the gap.
-I think everybody in ArchiCAD has made his own objects by using Save 3D model as. Lets make this just a little better. There are already some small examples: Like using Wallhole in the ID to create a custom wallhole, or General as Material to make the material parametric.
-The code that the autoscripting creates must be more pure code and less baggage.
-Special elements just for autoscripting. For instance an element that defines Parameter A. Something similair is already in the complex profiles (horizontal stretch/vertical stretch)
-Autocompleting code, just like visual basic, you begin to type an element and the GDL editor completes it or gives possible other commands.
-Better error handling: OK, I have an error in the POLY or PRISM, but where!!!
-Colorcoding, hyperlinks to go to GOSUBs, expanding and contracting bits of code, etcetera.
-Visual Userinterface creation, dragging fields and pull-down menus, resizing images.

[Anonymous]

Words from a newbie.
As a absolute newbie to a tiny, tiny bit of playing with the simplest of simplest aspects of a simple object, I'd like to second the comment that Erich
has made:
"..most architects will not even attempt the most basic GDL because it is outside of their comfort zone and realm of experience. By providing a graphic interface you would be speaking to your clientele in a language they better understand."

Architects are in my opinion are; visualizers first, structural minded second and programing code minded last.

I especially like the general concept presented that a duel GDL Object opportunity makes far more sense, than going either way on it's own.

Anyway, now back to listening to the masters speak.

More on how a graphical and code based connection might work?
How would a simple version of this begin/look?
lec

[Erich]

Masterscript,

You missed a big one. The ability to copy/paste parameters in the parameter table! It wouldn't hurt to be able to have a newly added parameter added to the line above/below the currently selected parameter. It is such a pain in the *** to have to drag parameters to a logical position in the table when dealing with a complex object with lots of parameters. While this will not help the masses it sure would make object making less painful.

[Rod Jurich]

Erich wrote:
You missed a big one. The ability to copy/paste parameters in the parameter table!/.

Erich, I am with you on this one.
With parts becoming more complex, this wish would really help if GS obliged.