PARAM-O development roadmap? (with Survey)

[Anonymous]

[Note by Moderator: Please make sure to fill out the Development Survey. Link to the Survey can be found in the 3rd post of this topic.]


Since PARAM-O is described as a technology demo of sorts, what is the development roadmap for this plugin?

There are a number of GDL elements that are not implemented yet and I am curious what is the development outlook for such a useful tool as PARAM-O?

[Christophe Fortineau]

Hello Anton,

The first step would be to integrate macOS users.

[Viktor Kovacs]

The highest priority issue on the backlog is definitely the MacOS version. We are happy to announce that it is ready for release, so it will be available for the upcoming update of Archicad 24 (Update 3).

We already have a backlog for PARAM-O development, but we need your feedback to make it more relevant to your needs. If you want to participate in the backlog forming process, please fill out this short survey: https://forms.office.com/Pages/ResponsePage.aspx?id=tjJzke5fkkudBYEsfwi5uXn3O7NJqk5Aqpxslw9QXYxUNEIzQzVFTlAwQ1RENkVYUlc4UjBJNzc0Qy4u.

[B_E_A_T_]

Great news that you are releasing the MacOS version! Planning on integrating this in our BIM-oriented Parametric Design course!

[rm]

Viktor wrote:
The highest priority issue on the backlog is definitely the MacOS version. We are happy to announce that it is ready for release, so it will be available for the upcoming update of Archicad 24 (Update 3).

We already have a backlog for PARAM-O development, but we need your feedback to make it more relevant to your needs. If you want to participate in the backlog forming process, please fill out this short survey: https://forms.office.com/Pages/ResponsePage.aspx?id=tjJzke5fkkudBYEsfwi5uXn3O7NJqk5Aqpxslw9QXYxUNEIzQzVFTlAwQ1RENkVYUlc4UjBJNzc0Qy4u.

Viktor -
Could you be much more specific when stating "backlog is definitely the Mac OS version." With all due respect, that sounds extremely vague to me. We too often hear from GS, "this is a priority" with no follow up or commitment to finalization of a "commitment".

[James B]

The Mac version of Param-O has basically finished development internally. But needs to go through more testing and processes before release. So should be available early next year, in an upcoming Update for AC24.
I say should, just incase any last minute issues occur in the process

Also, here's proof.

[A_ Smith]

Where I can find some info (~comparison table) on what is better to do in Param-O and what he does worse or can't comparing to gdl scripting?

[Mjules]

Hi,

Will it be possible to use PARAM-O for contouring models like that of the contouring command in Rhino? Contouring is a method of approximating mass and curvature through the use of rectilinear materials. For example, often we will see architecture site models that are made out of simple sheet materials, such as museum board, but they are representing the mass and curvature associated with topography.

I enclose some examples of the eggcrate models realized from the contouring method. That method is most important for digital fabrication in both fields of design and architecture.

[4hotshoes]

James wrote:
The Mac version of Param-O has basically finished development internally. But needs to go through more testing and processes before release. So should be available early next year, in an upcoming Update for AC24.
I say should, just incase any last minute issues occur in the process

Also, here's proof.

That is great! It looks a lot like Grasshopper. Such a cool way to model. This will put AC in the lead or desirable apps among the new generation of architects.

[leceta]

Mjules wrote:
Hi,

Will it be possible to use PARAM-O for contouring models like that of the contouring command in Rhino? Contouring is a method of approximating mass and curvature through the use of rectilinear materials. For example, often we will see architecture site models that are made out of simple sheet materials, such as museum board, but they are representing the mass and curvature associated with topography.

I enclose some examples of the eggcrate models realized from the contouring method. That method is most important for digital fabrication in both fields of design and architecture.

This work is better done in Rhino (which happens to be super cheap software that nicely complements Archicad)

[rm]

leceta wrote:

This work is better done in Rhino (which happens to be super cheap software that nicely complements Archicad)

I have no experience with Rhino, so I will take your word as truth with regard to being "better done" in Rhino. However, my presumption, right or wrong is the Param-o will create native GDL objects to use in ArchiCAD.

Maybe my presumption is wrong here...someone with more knowledge on the matter could possibly clarify.

As a side note, Rhino looks like it has a very steep learning curve, aside from learning it in colleges as most seem to do now, I can't imagine any firm letting an employee learn Rhino on company time.

[Mjules]

Rhino is very helpful for digital fabrication. We use it a lot to design physical models in Canada during any ideation processes in architecture. If Graphisoft wants ArchiCAD to become a smart software, the company must think about it this way as well.

[Bricklyne Clarence]

rm wrote:

leceta wrote:

This work is better done in Rhino (which happens to be super cheap software that nicely complements Archicad)

I have no experience with Rhino, so I will take your word as truth with regard to being "better done" in Rhino. However, my presumption, right or wrong is the Param-o will create native GDL objects to use in ArchiCAD.

Maybe my presumption is wrong here...someone with more knowledge on the matter could possibly clarify.

As a side note, Rhino looks like it has a very steep learning curve, aside from learning it in colleges as most seem to do now, I can't imagine any firm letting an employee learn Rhino on company time.

Maybe not wrong, but certainly not exactly accurate or precise.

From my understanding from people who are GDL fluent, the current Param-O iteration is,....how shall we say......still very raw.
Meaning that it's missing a lot of GDL commands and functionalities and in it's current implementation it can't (yet) be considered a GDL custom object creation alternative that is the holy grail that a lot of users have been clamoring for.

But perhaps after some development iterations it will eventually get there.
They certainly have a steep hill to climb at the moment to get there, not entirely unlike Rhino's Grasshopper did when it was first developed and released (way back in 2007).
Let's just hope that Graphisoft took the important lessons from McNeel / David Rutten that helped them along the way to making it the foremost visual coding tool it is today.

Also, Rhino is not that particularly hard to learn.
It just happens to have a lot of functionality that is likely not that useful for probably 70-80% of architects - or at least for 70-80% of the type of work and design that architects tend to do.
(Architects are not their primary marketbase as it's widely used in product design, Nautical (ship) design and even aeronautical design).
It's unlikely that you'd have to be spending anything to get your staff to learn it as it's probably easier just to hire graduates straight out of school who know how to use it, because as you've noted, it's popular and ubiquitous in most schools nowadays and most people graduate knowing how to use it pretty well these days.

A lot of architects are finding it a useful tool to have some fluency with in their toolbox nowadays mainly because of how digital fabrication (CNC milling, laser cutting, 3d printing, vacuforming etc) is proliferating more and more into our industry and the line from digital model to fabrication is becoming more and more blurred.

Rhino is a useful, if not important tool in this process since it's been in the digital fabrication arena since the inception of the craft.

Even for something as simple as 3D printing ArchiCAD models (a process that a lot of architecture offices can now comfortable handle in-house with easily available 3D printers and 3D printing technology) it's helpful having a Rhino copy and Rhino knowledge in-house because it's useful in cleaning up and plugging up notoriously "un-water-tight" ArchiCAD models and preparing them for printing.

[Mjules]

Why Graphisoft doesn’t develop PARAM-O this way?

Bricklyne wrote:

rm wrote:

leceta wrote:

This work is better done in Rhino (which happens to be super cheap software that nicely complements Archicad)

I have no experience with Rhino, so I will take your word as truth with regard to being "better done" in Rhino. However, my presumption, right or wrong is the Param-o will create native GDL objects to use in ArchiCAD.

Maybe my presumption is wrong here...someone with more knowledge on the matter could possibly clarify.

As a side note, Rhino looks like it has a very steep learning curve, aside from learning it in colleges as most seem to do now, I can't imagine any firm letting an employee learn Rhino on company time.

Maybe not wrong, but certainly not exactly accurate or precise.

From my understanding from people who are GDL fluent, the current Param-O iteration is,....how shall we say......still very raw.
Meaning that it's missing a lot of GDL commands and functionalities and in it's current implementation it can't (yet) be considered a GDL custom object creation alternative that is the holy grail that a lot of users have been clamoring for.

But perhaps after some development iterations it will eventually get there.
They certainly have a steep hill to climb at the moment to get there, not entirely unlike Rhino's Grasshopper did when it was first developed and released (way back in 2007).
Let's just hope that Graphisoft took the important lessons from McNeel / David Rutten that helped them along the way to making it the foremost visual coding tool it is today.

Also, Rhino is not that particularly hard to learn.
It just happens to have a lot of functionality that is likely not that useful for probably 70-80% of architects - or at least for 70-80% of the type of work and design that architects tend to do.
(Architects are not their primary marketbase as it's widely used in product design, Nautical (ship) design and even aeronautical design).
It's unlikely that you'd have to be spending anything to get your staff to learn it as it's probably easier just to hire graduates straight out of school who know how to use it, because as you've noted, it's popular and ubiquitous in most schools nowadays and most people graduate knowing how to use it pretty well these days.

A lot of architects are finding it a useful tool to have some fluency with in their toolbox nowadays mainly because of how digital fabrication (CNC milling, laser cutting, 3d printing, vacuforming etc) is proliferating more and more into our industry and the line from digital model to fabrication is becoming more and more blurred.

Rhino is a useful, if not important tool in this process since it's been in the digital fabrication arena since the inception of the craft.

Even for something as simple as 3D printing ArchiCAD models (a process that a lot of architecture offices can now comfortable handle in-house with easily available 3D printers and 3D printing technology) it's helpful having a Rhino copy and Rhino knowledge in-house because it's useful in cleaning up and plugging up notoriously "un-water-tight" ArchiCAD models and preparing them for printing.

[Bricklyne Clarence]

Mjules wrote:
Why Graphisoft doesn’t develop PARAM-O this way?

[........

Good question.

[leceta]

Well, take into account that trying to mimmic Rhino's geometry library would be a really huge task.
McNeel's product is centered mainly on this particular task, i.e. solving geometrical operations. They have been working on this for decades. The open NURB library that graphisoft has adopted present only the basis, a fraction of what Rhino offers. Grasshopper is a nice UI with a brilliant UX build on top of Rhinocommon (Rhino's already existing API)

So far, GDL API exposes a very limited geometry operation in the form Add-on (polygon operation). The rest is up to the user and it's knowledge of Linear Algebra.

I find much more realistic (and interesting) that Graphisfot develops param-O as the place where all it's API can merge together, and at the same time, offer a commonplace for all novice and veterated developers, being them "graphic programmers" or "coders". I suspect that this was a key ingredient in the "secret sauce" of Grasshopper, to be a place where everybody feels comfortable, working at any level of literacy. The worst think that can happen to param-O, IMO, is to become, JUST, a simplified version of GDL.

Hope that in the roadmap of Param-O there is place for more flexible GDL scripting components, python scripting components (which would give easy access to the work done/to be done for the JSON API) , tutorials and VS templates to develop custom param-O components (I asume it would be C++), and of course more components for people that just has not enough time to learn coding, but still wants to build algorithms. But in relation to that last comment (more components), if ww have a more robust GDL scripting component and generous user community and a platform/system to share components, a broad ecosystem would arguably emerge.

[Mjules]

Architects should design and draw their own furniture. Developing PARAM-O just to make GDL capabilities easier will not resolve the main ARCHICAD issues.

As designers, we need a parametric architectural software with great parametric tools like those of Rhino. Graphisoft has started working on Archicad since 1980. It supposes to be the leader in terms of parametric architectural software. Unfortunately, Archicad still updates drawing anytime. When working on projects from 12 to 30 stories, ARCHICAD becomes very annoying, disappointing and time-consuming. Graphisoft must resolve this fundamental issue first. The vision should be to make ArchiCad easier for its users. As professionals in the field of design, we don't have time to waste. We need a software capable of developing great concepts during the iteration process. Ideation is most important in the field. That's why architectural tools should help for aggregation, contouring, morphing, conceptualizing, etc. BIM is usually for construction management. Think about architecture first since Archicad has been designed by architects for architects.

[leceta]

I'm agree with, but the topic here was related to Param-O roadmap, that's why I have focused on the topic, rather than Archicad's more general issues.

BIM is usually for construction management

sure and coding IMO is the best tool for information management, wich happens to be a task that an architect (or at leas an architectural studio), today more than ever, need to undertake.

[Mjules]

We need to help Graphisoft find the best way to develop PARAM-O. This new development should be at the service of architectural thoughts first instead of focusing on BIM. What good is it to use some tools from a software to draw objects if we are unable to find in them rapid fabrication techniques to realize physical models allowing us to improve spatial experience in architecture?

[brayan henrique]

What good is it to use some tools from a software to draw objects if we are unable to find in them rapid fabrication techniques

I also really miss ways to extract information (from BIM's "I"). I managed to program furniture models at Param-o, but there is no way to extract cutting plans or quantitative parts or cutting angles from MDF panels. In other words, it is useful but does not help at all when building the models developed within Param-o. This takes away much of the Param-o's usefulness, as it ends up serving for a graphical representation (which is not worth it due to the complexity of creating a parametric object), and is outside the production process. (Param-o would have the ability to exclude the "promob" from the workflow, and make life easier for the projectites in my office, it just doesn't do it because of this awkwardness)

(I speak Portuguese so sorry for any Google translation errors)