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.

[Anonymous]

sinceV6 wrote:
Display order should only exist for 2D elements, not 3D elements or their projections.

Yes. This makes a lot of sense. I have the same opinion with Pen Weights. IMO they are, together with Layers, a relic of the CAD 80's. If we have each elements elevation and a FPCP. Then why not define general Pen weights for: External Cut, Skin Cut, Foreground View, Background View, and then AC would interpolate the two values for foreground and background and automatically apply Pen weights in between.

sinceV6 wrote:
Thinking about all the things road design means, I would say it is a better job for a tool(set).

Sure it is. But how long will we have to wait for a tool like this.

[Podolsky]

Here is an idea. Complete room tool. It can work on it's on or as zone accessory - picking up room geometry from the model. In 3D it shown as complete finish layer of walls, ceiling and floor. Windows and doors are included. Data sent to Embedded library for exchange. Might be that GDL macro generated from main object to produce schedules. Exchange data contains all information about all rooms in the building. Layout object - that works in this mode only if placed on layout, reads layout number and ID. Has title block as set as company standard, that supports various CAD standard and draw all interior elevation with all necessary information, dimensions and generated legend and notes. Because it is an object, placed in layout - hotspots able to edit actually everything - like size of ventilation grills, position of light, electrical sockets. That becoming good mark-up tool - when possible to edit the project just on ready layouts.
Interior Elevation marker is part of the floor plan representation and can be switched on or off. Because layout object knows, where it placed - it translates layout number to the IE marker.
All correct data collected from the room for quantity take off. Here can work simple Python script that collect all data into spreadsheet.
Varios level of details let to control complicity of 3D model to the level of simple surfaces. This surfaces might have built-in (pluged-in) function of dividing surfaces into mesh for future simulation algorithms as radiocity, that can produce low poligon, fast models for BIMx and another web platforms complete building interior model for real estate virtual building visiting sets.
It can include varios smart tools: painting tools, floor and ceiling division, adding node and line bending tools. For example adding node and bending tools can be just plus and bracket, floating on the floor plan near the object with hotspot. Moving plus that it would touch the line will produce editable hotspot of new node. Deleting the node by overlay another hotspot. Bending tool working the same principle after touching the line with bracket appearing hotspot on the middle of the line, that let to change bending radius. It also can include biarc line as an option - to draw cool shapes of the room.
Scheduling tool can be another object, placed to layout. Windows and doors schedules can be populated to perfect state. If company standard require small page format, it populates the pages and showing on each page total amount of pages.
All that can be done with nice simple interface with big buttons - to support touchscreen computers. It's necessary to take a look on the last interface of Apple and Windows 11 and do something it their style, that overall use of the whole OS UI would be based on the same principles.
Ready pre-set catalogues in the object and automatically generated libraries by master GDL of used hatches and photo fills. It needs to work on Photoshop principle. This way possible to have photo fills on interior elevation layouts - showing for example decorative brick on the walls.
Room must cover all parts of construction, with no exception - all MEP, fire safety, pictures on the wall, light, all decor, Windows sills, thresholds. Furniture can be included too - by reference to another library objects. Actually it can be any object. Windows and doors must have custom profiles access from profile manager (that detect lowest version of ArchiCAD, where this tool can work).
Such an object placed to the model can be easily labeled in sections.
Because this object totally by itself with all data access - different standards can be applied to IE - like problem with showing N, W, E instead of numbers. Tool can detect position of the building in regards of North and show orientation as required. It also can pass information about windows orientation. Windows can have additional tools like Facade maker - where it it possible to set the whole facade - especially if it's a big building, applying different patterns to windows.
So then such an object need to be placed to Structural model with empty openings.
Room can include different layouts of kitchens and toilets. Especially can be useful for disabled toilets - where every bit can be pre-set.
MEP hotspots needs to be available for piping, ducting and wiring. These elements are not included - because they are connecting different rooms and have their own routs independent of room geometry.

So the main philosophy - you are placing room tool and getting ready drawings. The drawing generation does not include ArchiCAD IE engines or scheduling engine. This drawings you can then modify and change the model.
Because usually rooms have simple geometry - drawing, generated from 2D primitives can be populated, avoiding using Project2 command as much as possible. I think it can be faster this way. Embedded library (or project library folder) contains total data of the room, that can be extracted for different purposes.

See logical scheme attached

[Podolsky]

I think very important part of such a structure is that vertical elements such windows and doors then can editable via editable hotspots interface, that simplified input of window and door geometry using UI elements only - doing that directly on layout. Also location of sockets, size of ventilation grilles input happens more simplified way without usual 3D space included. It also can be edited in 3D space, but it's just faster to do everything on the drawing - similar way how it happens on floor plan. Then workflow mimics classical 2D CAD drafting and pre-CAD time. That can be highly beneficial for old generation designers and it is excellent tool for interior design.

[Anonymous]

No doubt it would be very useful, but IMO this object, like already said about the Road Object, would be far better handled as an AC tool rather than a GDL project.

[Podolsky]

Yes, I understand that. But the whole point is start to populate and develop (!) tools. This why it's not commercial and open source - all non traditional principles of the workflow can be tested here.
In programming is important algorithm, main principle, idea. To develop algorithm is like to do architectural project.
To write the code itself then it's just technical issue. You can give to write the code to any experienced programmer, if you developed an algorithm already, and he can do it quickly. I think even experienced programmer can learn GDL in few weeks.
Later, when you have object already - if it's working - you can re-write it, improve it, translate to another language. Look how new Stair is created - they using only part of built in ArchiCAD functionality - rest it just GDL. And new stair and curtain wall initially was possible to write on GDL only.

Seriously guys, let's do already something. Otherwise it doesn't make sense to speak about it only all the time.

[Anonymous]

I don't want to spoil the party Podolsky, but my (GDL) guts say that there will be a lot of dead ends in this road.
Perhaps somethin more simple.

[SenecaDesignLLC]

I think this is actually a good idea. It's actually what I've been working towards with my wall accessories. And if we got it working right it could make interior design and finishes fast.
We already have a room accessory object to get some of the basic code needed to start.
But really I think it's quite doable. And not as complex as it might seem.

[Podolsky]

This is my last thoughts about GDL programming. I took a look to the libraries that making Kristian (Swift and Infinity). This is absolutely incredible to which level he is pushing GDL and what cool methods he is discovering in editing elements using hotspots. It's totally amazing what editing mode he introduced in his ceiling tool. What Kristian is showing - that with right mind set and mathematical thinking everything is possible. I might argue, that his UI is overcomplicated and I don't see myself going through all pages of settings and variables in his tools - it's too mathematical, but still - it's a question of time - to improve interface.
So if someone able to do complex and good working tools, why then it's impossible or not worth to do something that can really save the day of many users? In my idea of room tool I collected many requests I did read on this forum with interior elevations, room finishes etc. Rooms - it's an essence of the architecture and the same time weak point of ArchiCAD. I mean all architecture and construction is about how to create space. We are building walls to separate space - not because of the wall itself. The initial planning is starting from defining spaces first and after adding walls and slabs between. I think it's clear.
If talk about dead paths where development can go. Of cause it can go nowhere. Especially if jump straight forward into writing code without realising the overall structure of the system. It's necessary to design the system first, make schemes, information dependencies, main algorithms - from simple to more complex. Then if idea is good and algorithms are clear - it will work.
I want to repeat again: because it's open source - developing ideas into detailed algorithmic level is like making good detailed wish of future function of ArchiCAD. If idea is good and it's working - then it can be adopted by GS later, some parts, that working poor just because of nature of GDL, can be replaced by C++.

This is how I see it. Maybe different from many users, but many users are just buying software and then complaining - or, GS, please fix this, fix this - we paid money to you. Look how it's working here and there... But if look technically to the system possibilities - ArchiCAD can be much much better with what it had now - without even waiting for new version. Technology already give plenty of possibilities - it just necessary to understand how it's working.

[Podolsky]

Actually I was recently working on one project, where I had part of topographic survey and part just a map screenshot from Google. I just needed to show the road on plan - simple linework. I also knew exact shape of the road on short distance. I just tried biarc object published here before. And it's working very well for that. I was able quickly to draw the road, following bending shown on Google map. The next step I think is to have triple biarc tool - to quickly draw such a shape (currently I used polylines too - exploding object, connecting into polyline, use offset, then draw on top of polyline with biarc). Polygon Add-on needs to be involved to perform offset and get right radiuses for all three curves. After creating simple, I might say primitive 2d road tool then possible to add 3d part. Then add more features...
This is how the road can be created.

[SenecaDesignLLC]

The way Kristian uses hotspots is a very simple loop, either a toggle on or off or you can make.a node rotate through options like my wall accessories.