Open Source GDL library project

[Podolsky]

Hi there,

After long thinking on this subject I would like to hit the new Open Source GDL programming project on this forum. The idea to involve GDL developers worldwide to start building new, independent, international, non-commercial library for all. GDL technology has very strong potential and that is very important part why ArchiCAD as a CAD and BIM system is so unique.

Please read the initial statements of this project:

1. The project is running under the GNU GPL licence. It is based on GDL technology, but not limited by it. Any further translations to different programming languages or use in different CAD systems apart of ArchiCAD are welcomed. Additional C++ programming to improve use of the library parts by making special Add-Ons are welcomed too.
2. Anyone, who is taking part of the project, doing it by their free will and free of charge just following the desire to make BIM world better. Donations, investments and grants for developers are discussible and acceptable.
3. The objects must follow all official GDL standards (like GDL white paper) and Graphisoft recommendations. For example - I like to use uppercase in my GDL script for commands (because GDL manual shows all of them in uppercase). But as soon as GS recommends to use lowercase - my opinion or preferences are not valid.
4. Developed library parts must use standard GS variables names to have full compatibility with standard libraries, distributed with official ArchiCAD releases. As well - to use standard GDL subtypes, as soon as introducing new one is not necessary.
5. All library elements must be compatible with Grasshopper - means that most of calculations (that usually happens in Parameter script) shall happens in Master Script, because Grasshopper is not reading Parameter script.
6. Completed library element must be uploaded to BIMcomponents.com web-site for free access of ArchiCAD users worldwide.
7. Any modification to the library part code must be reflected into the versions text file (or log file), provided with the library element.
8. Library part must be truly international - means that they must have multi-language support.
9. Library objects must be not manufacturer-oriented but building element class-oriented with manufacturer support. For example - instead of having ACO drain element - to have rainwater drain element with possibility to choose ACO from manufacturers list.
10. There is no discussions about leadership of the project. Everyone is equal and differs only by experience - strongest are supporting weakest. I will try to manage this project as long as I can, also I'm willing to open some of my personal developments, but I do not pretend to be head of the project (even if this is my idea).
11. Anyone can be involved into any stage of library part development - starting from conceptual graphical schemes and algorithms ending by writing and re-writing actual scripts.
12. Any object must have textual / graphical description how to use it and YouTube video. The links to the manual must be implemented into the object User Interface.
13. Each object must have User Interface.
14. Common global variables names as for example from Add-Ons or MVO objects - matter of community decisions and consultancy with Graphisoft. After the decision is made - this subject is not discussable without serious technical reason.
15. Every GDL object must be written on as lowest ArchiCAD/GDL version as possible - as soon as needed features allowed to use the version.
16. Developing of the new object is starting by introducing your ideas in the post plus hand-drawn (or CAD drawn) sketches and logical (drawn) schemes.
17. This is not PARAM-O project. PARAM-O can be used as a temporary tool, but because of nature of scripts, generated by program automatically, must be reviewed and rewritten by human to achieve better performance and smaller size of script.

Any comments are welcomed.

[Podolsky]

The last artwork - it's just an artwork. Can be used in 'about' section of UI - with the list of developers names. Or in documentation. Also as a logo in preview.
I mentioned before - I have quite a lot of ideas to share. Currently I'm busy with some project but will come back, as soon as will have more free time.
For now I just give more time for users to think about and come with fresh ideas. Why I'm constantly asking about sketches - because I realise might exist people who have some ideas for the objects and interface - but not so good with GDL, when another person can be more advanced with programming - just take an idea and start implementing it into the code. Something like that...

[SenecaDesignLLC]

Things are already getting fractured, is this a thread for logos or code or what?
if we are to follow a specific order of operations that we all dictate should that not be the first item to tackle?
if we cant all focus on what is the task at hand then this isnt going to go anywhere.

I do agree that sketches of ideas are needed to make sure everyone understands an idea, but we are far from needing logos?

or graphics unless they directly relate to the current equation trying to be solved.

I am all in on contribution but we still have not actual starting point.

I think like others have said, we need to vote on whats most needed. not to complicated. but useful to all and maybe interesting enough yet simple enough to get others involved.

and maybe even a complicated object for things suggested before. i use toggle hotspots everywhere just like cadswift, maybe the users who are more knowledgeable start working on some basic macros?

im not going to sketch ideas for something that doesnt have a chance at happening. lets be smart with time.

[SenecaDesignLLC]

we need ground rules and a moderator to help hold us all to them. so there is no bias and the threads stay clean.

[Anonymous]

Ok. Here is my suggestion: Road Design Object.
It is an object based in the Dynamic Polyline Object (developed by SinceV6, Seneca and Heimo) that help placing interpolated point for road design. Here is a sketch:

Please be gentle.
Cheers,

[vistasp]

Braza wrote:
Ok. Here is my suggestion: Road Design Object.

A road object that can branch (or connect cleanly with others) is much needed! Not sure if that's possible... It may be necessary for intersections to be separate objects.

[Hmooslechner]

Braza wrote:

Ok. Here is my suggestion: Road Design Object.
It is an object based in the Dynamic Polyline Object (developed by SinceV6, Seneca and Heimo) that help placing interpolated point for road design.

This seems to be a good idea - but not nescessary with the Polyline - it could (should) get a fixed number of editabel hotspots what would make it much simpler to control.


All about this task: We should not only deposit GDL-splits for everyone-solutiions. We should also post ideas about needed objects ordered in the same categories as the normal Archicad-library does as extra task here - some sort of GDL-wishlist - also for GDL-Script-splits..

Personally - i now try to solve some problems with the ability of GDL to find its own insertion-Level-nr. for the use of library-parts which should cross several project-levels like my new stairway through the whole project.
like this:

What i think of GDL-library-parts which are usesing external scripts: I personally dont like this. In my opinion, every part should hold evering it needs in itself.

[Anonymous]

Hey Heimo, (Sorry for the pun )

Hmooslechner wrote:
This seems to be a good idea - but not nescessary with the Polyline - it could (should) get a fixed number of editabel hotspots what would make it much simpler to control.

I suggested the Polyline because left and right "Curbs" are not always a straight single segment. It also can have arcs and assume a very complex shape. IMO the Dynamic Polyline is perfect for this.

Hmooslechner wrote:
All about this task: We should not only deposit GDL-splits for everyone-solutiions. We should also post ideas about needed objects ordered in the same categories as the normal Archicad-library does as extra task here - some sort of GDL-wishlist - also for GDL-Script-splits..

Agreed. This Open Source Project Section would need a dedicated Wish Section to check the real need of an Open Source Project. BTW I see this Open Source Project Section not only for GDL objects and Macros. It can (and should) be used for Property Expressions, Surface Textures, Fills, etc.

Hmooslechner wrote:
Personally - i now try to solve some problems with the ability of GDL to find its own insertion-Level-nr. for the use of library-parts which should cross several project-levels like my new stairway through the whole project.

Your stair object looks amazing. Try to get some help/insights from Peter Baksa from the GDL Library Department.

Hmooslechner wrote:
What i think of GDL-library-parts which are usesing external scripts: I personally dont like this. In my opinion, every part should hold evering it needs in itself.

Well... It depends in the kind of object/tool you are trying to develop. If it is a single object with a simple purpose then yes its good to have it all in a single package. But it is a set of GDL objects that may do different tasks but share some scripts/routines then it is good to have a shared Macro for this packaged in an .lcf file.

Anyway... Lets wait for some other suggestions to define which will be the Pilot Project.

Take care and be safe you all. This pandemic is still lurking in the shadows.

Cheers,

[Podolsky]

Hi guys.
I would like to make some notes. Because it's open source project with no financial support - that means anyone who is reading or writhing posts here - is potential moderator, owner, developer, designer, client etc. There is no centre, no big brother who is watching you - you are centre. Anyone who wants to do any implementation - just do it, not just write about it - 'it needs to be done this and this'. I might understand when person requesting something from Graphisoft, because he is a client, who paid to Graphisoft, but here - completely different situation.

Road is very good idea. I also had some thoughts about it. My idea was - that road shall have kerb stones and paving - as part of itself. It shall have composite fill structure in section (to represent real layers of the road structure). It probably must be controlled with several hotspots and automatically calculate right slope, following road slope regulations. As you know - Road has minimum and maximum slopes. Would be good to search for professional engineering literature about road design.
Connections between road parts shall happen as in toy railway - straight part, bended part, branch, cross...
Also road shall have manholes and drainage.

Anyone knows where to get road design learning book for civil engineers?

[Anonymous]

Hi Podolsky,

Regarding the Moderator thing, suggested by Seneca, I think it is a good idea. Not to be the "Big Brother", but to draw some focus or broad vision when needed. But yes... Everyone is allowed to join as long as he/she has somethin useful to say or do/script for the project. I mean all Pro Bono.

About Road Object: I think we have to deliver a simple object for a difficult task. The main problem for road modeling, is not the curb, manhole or paving. We have the Railing tool for curbs, Existent Library Parts for manholes and Meshes (With the Composite Mesh Object ). The real problem is to get the correct node heights of the mesh to get the correct road slope according to the surveyor drawing or the Construction Codes, right? And yes. Some feedback from users doing real life road design would be very appreciated. But for now, and before getting into the details of it (We still don't know if its a priority for the most of us), I think we should wait for other suggestions. IMO.

Cheers,

[sinceV6]

Hi,

I understand the wish, but not what it would solve, in the sense that assuming you get the scripted object... You model the 3 road polylines based on (maybe tracing) the surveyors drawing just to get node heights that you then export to xyz and bring back as a mesh to basically complete the surface of the road? If the surveyor drawing already has node height, why not ask for the xyz data?

While I like the suggestion, I think it would be a complex object for a task that can be solved (granted, to a certain extent) with the current tool set. It has been asked before. A proposed solution using mesh here. So if you are tracing with the polylines, why not trace directly with the mesh, which would be the end result anyway.

I don't think AC is the right tool for complex road design. There are other capable software solutions for that.

When I say I like the suggestion is because I remember the object shown by Fender Katsalidis in the Building Together conference last year (?). I thought it was great. The elevator object they showed also gave me some new ideas for mine.

Braza wrote:
I think we should wait for other suggestions. IMO.
Cheers,

Agreed, and the way Braza suggested, simple explanation of the desired outcome or use and an image works great.

Best regards.