All-in-One AEC package

M by mrhe on 11 Jan 2021, edited 20 Feb 2021 # +2 votes

Hello everyone,

first of all - a massive thank you to the community for the enormous work, that has been done towards pushing FLOSS in the AEC industry. You are a huge inspiration!

I have been following the forums for a while now, but since this is the first time I am posting here, I might as well introduce myself. The name is Mariusz, civil engineer/landscape architect by training. Have been working for one of the bigger engineering companies for 10+ years now (approx. 15000 employees internationally, same office as @duncan btw.). I specialize in terrain modelling, water sensitive urban design, bioengineering and BIM for landscape. On top of that, I'm passionate about generative design and am currently writing a PhD on AI applications in landscape architecture. Work with Civil 3D, Revit, Rhino, 3ds Max, Blender, Arc GIS on a daily basis and 2 years ago started developing plugins for Rhino of intermediate complexity.

I've started preliminary talks with our management about their potential involvement in funding osarch's efforts to develop open-source software for the AEC industry. The grand idea would be to convince the biggest players in the field to become patrons of a foundation similar to how Blender is supported by AWS, NVIDIA and the likes. The vision - to have an OS All-in-One package for the entire industry.

And that's precisely what I wanted to ask your opinion on. What do you think of a unified software package, which would cover the entire AEC design process similarly to how Fusion360 addresses product design workflows?

Sketching for ideation,
GIS for context,
Civil/Landscaping tools for site design,
Sculpting/Solid/Polymodelling for initial massing,
Dedicated tools for Architecture, Structure, MEP, Façades etc. modelling,
Dedicated simulation tools for each of these categories (i.e. stormwater flow for terrain modelling, solar energy gains for façades, loads distribution for structure etc.),
2D documentation and paper space layouting,
BIM authoring,
Cost estimates & scheduling,
Construction sequencing and 4D visualizations (time being the fourth dimension),
Facility management,
Decommissioning,
EDIT: Project management tools (thanks @denissoto),
EDIT: Rendering, virtual reality, presentations (thanks @JQL)
others which I forgot/am not aware of the need for...

Users could start at any design stage and use any subset of the above modules for their specific task. These would be grouped in dedicated workspaces similarly to how today we can switch between grease pencil and sculpting tools in Blender or modelling and FME simulation tools in Fusion360.

This certainly wouldn't be the easiest thing to achieve, but would it be feasible at all, given - say - $5 million a year and 5 years of development? Would it be something that you as architects/engineers/urban planners would be interested in using at all?

I'd love to hear your thoughts!

D by denissoto on 11 Jan 2021 # +1 votes

I would love to have such a FOSS tool like that. Something that could be added to the list is the ability to manage the entire project, with Kanban tasks for each stage of the project or some similar Agile methodologies.

J by JQL on 11 Jan 2021, edited 11 Jan 2021 # +1 votes

This would be a massive undertaking but with such kind of financing maybe some of the major developers around here could gather around the idea. I personally love it!

For what I can tell from what I've seen around OSarch, the main purpose here has been to bind together various software for each specific use case into a singler or multiple possible workflows. Having a new software that would have a Blender take would be another story though it would be excellent.

Having said taht, I actually believe Blender could already be the base for a lot of what you describe. I think this could cut down the difficulty of what you propose a lot. Just look at what BlenderBIM and Archipack are aiming at together. If I understood it right, Archipack creates architectural elements that are automatically BIMified and BlenderBIM ready. Dion is trying that Sverchok heads the same way. Elements created with it could become BlenderBIM classified.

So Blender could be the hub of a single or various plugins that would work together to solve every module you want. In Blender:

Sketching is possible, integration with sketching software too. It's even possible to bridge it with an tablet and sketch on that. It just needed better gestures support as it already allows pen support.
Blender has some plugins for GIS context already. It would be a matter of upgrading them.
I don't know of a site modelling specific tool for blender, but addressing that via a plugin could also be possible. I imagine all modeling techniques and calculations via modifiers and booleans to be very possible to streamline.
Dedicated tools for MEP, Façades, Architecture start popping up too. We've seen examples in the forum with object libraries that connect to each other. Those could be improved specifically for this purpose. Archipack is a great example. I also think more accurate as well as intuitive modelling capabilities would be in need. Blender is very intuitive for innacurate work. Not so much for accurate work. There are some plugins but none are really there yet.
Simulation tools. Dion has ported Ladybug tools for blender via Sverchok. I don't see why can't other software, especially opensource be ported too.
2D Layout. I guess this is the main reason why I don't use blender. Dion is doing something about it with BlenderBIM. If he could manage it ...
BIM authoring. BlenderBIM, obviously.
Cost estimates and schedule, could also be BlenderBIM? I think it's on the roadmap.
Construction sequencing via animations in Blender should be doable already. Maybe something could be developed for this specific purpose.
Facility Management, Decomissioning, Construction Sequencing and Project management via Blender nodes would be oh so cool.

I think you also missed:

Rendering, virtual reality, presentations. Blender shines here and it's always improving. It lacks 2D layout. Blender already shines here.

And that's why I think BlenderBIM was such a good idea. Blender is still far from AEC, but with some finetuning and parallel development it can evolve into everything we need. It might only require a boost of the kind you are trying to do.

B by bitacovir on 11 Jan 2021, edited 11 Jan 2021 # +2 votes

All in One... in 5 years. Sure...

You have Blender and FreeCAD that both involve a wide spectrum of applications. Development time for each project?

Blender, 26 years (1995)

FreeCAD, 19 years (2002)

I'll be retired waiting for your "all in one" promise.

(Just recently Blender is getting USD $1,800,000 annually in donations, after many years of development, and after building a solid and proved reputation as 3D software solution).

M by mrhe on 11 Jan 2021 #

Good point @bitacovir.

The idea would obviously be to reuse as much as possible from existing applications. Why not start with Blender as a point of departure and gradually expand its functionality? Also, these products didn't have such generous budgets at the beginning of their respective journeys and still offered meaningful functionality to some users.

I understand, that throwing money at a project doesn't necessarily mean it is going to succeed. But looking at where Fusion360 got within 6 years with proper backing from Autodesk, I'd like to believe that there is a chance to achieve a working package in sooner than 20 years :)

M by mrhe on 11 Jan 2021 #

@JQL said:

Having said taht, I actually believe Blender could already be the base for a lot of what you describe.

Appreciate your comprehensive answer @JQL! I didn't mention using Blender as a base to start with specifically, but that was what I had in mind when posting the initial question. It's great to see, that there are so many existing initiatives, which cover a lot of the scope already. Having BlenderBIM as a coordination platform and "engine" to develop against could increase interoperability between these plugins. Also, a commonly agreed upon UI/UX design would make life simpler for all users.

Another question to more experienced developers out here - how easy it is to find skilled people, who know how to code AEC features for Blender? Is money the only bottleneck, or developer availability would be a much bigger constrain even if we had Elon Musk's net worth at our disposal?

S by stephen_l on 11 Jan 2021 # +1 votes

The main bottleneck are blender's core limitations. A shared automated build infrastructure may overcome current addons limitations and probably allow to "bend" blender so it does fit with broader needs and close to core c/c+ implementations as python to blender communication is painfully slow and not enough for huge projects.

Historical attempts to create forks show many "near dead" projects like mechanical blender due to lack of interrest / visibility (and even counter-measures from blender fundation itself like removing all comments in code).

A huge contribution could be to dev an addon api for c/c+ right in blender and push to blender fundation as a first step to further enhancements.

M by mrhe on 11 Jan 2021 #

@stephen_l said:

A huge contribution could be to dev an addon api for c/c+ right in blender and push to blender fundation as a first step to further enhancements.

That's a very interesting idea @stephen_l! Being relatively new to the Blender world and having zero dev experience with this platform I was surprised to find out, that there is no C/C++ API available to developers. Rhino's C# API, which I'm more familiar with, is so much more capable than it's Python counterpart. For performance reasons and scalability it is a must for some plugins.

Interesting note about the abandoned forks and the Blender Foundation not giving them support. Could you please shed more light on why this was the case?

M by Meetlat on 11 Jan 2021, edited 11 Jan 2021 # +2 votes

Wouldn't Freecad be a better approach for this? As it uses vectors and there are already a lot of AEC workbenches and add-ons

J by Jesusbill on 11 Jan 2021 # +4 votes

Hi @mrhe, I think the future does not lie in a All-In-One solution but in a ... One-in-All solution ... or maybe both :D

And with 5 million / year you can definitely achieve a lot if spent wisely.

Let me explain what I mean. We can say that a piece of software consists of 3 fundamental parts that we can think of as separate components:

data, that is the type of information/data-schema that the software handles
methods, that is the workflows/processes (the back-end) that the software can execute, given specific types of input and output data for each workflow
UI (the front-end), the means for a user to use the methods on the data.

With this in mind, the UI is just an abstract and modular component so we should not aim to create a new software with "a commonly agreed upon UI/UX design", nor should we choose between FreeCAD or Blender to develop such a solution.

What I believe we need is:

agreed data-schemas to operate on for each type of workflow (IFC is at the moment one of them for various AEC workflows)
modular, reliable and validated back-end workflows the industry needs that can be integrated in multiple platforms (IfcOpenShell development has already taken this direction with tools shared in BlenderBIM Add-on and FreeCAD)
substantial financial support to Blender, FreeCAD and any other platform with a modular architecture that can host modules to execute the various workflows, or even stand-alone UI apps that can implement specific types of workflows
financial support for a web-based platform solution for the most important workflows (IFC.js could be a great asset in this)

With this roadmap we will be developing: (1) a number of back-end workflows with specified data-schemas and (2) different UI applications that in some cases may over-lap, as long as they use the same back-end components.

Then, I believe there is only one last part missing ... the One-In-All component ... that should be non other than a Data Content Management System. We can imagine it as a simple "add-on" in any software of the ecosystem, or as a stand-alone App, with a dedicated, configurable, back-end. The user can use it to handle and manage his data inside the ecosystem or even run workflows that need minimal UI interaction. Users or companies should be also able to define their own "back-end-compatible" data-model for internal use and communicate with other companies in the agreed data-schemas.

It is funny because since the beginning of the year we have started developing in Aether Engineering (a small engineering company I am director of) such a piece of software, a CMS for organization of our data and for application of workflows. The idea is that at some point we will not have to manually create folders for projects, copying relevant files, applying workflows manually, etc. but we will be able to manage our data (for example projects, material or other dbs, etc) and any applicable workflows with a dedicated back-end and with a simple UI, and hopefully in the future connecting the back-end in Blender and FreeCAD to directly control data management. It is still in very early stage but I can certainly share more information with whoever is interested.

I by iosvarms on 11 Jan 2021 #

@stephen_l said:

Historical attempts to create forks show many "near dead" projects like mechanical blender due to lack of interrest / visibility (and even counter-measures from blender fundation itself like removing all comments in code).

This is shocking to me. Why would Blender remove comments from code. Seems "counter-open source".

M by mrhe on 11 Jan 2021 #

Thanks @Jesusbill, that's an interesting take on the subject.

If I understood you correctly, you're advocating a more robust interchange format between various applications which would all focus on their core functionality while allowing for content creation and data authoring in the respective applications. How would it be different from the workflows that exist today?

I don't know about other disciplines, but landscape architects are somewhat forced to jump between multiple software packages to deliver our designs. A typical workflow in our office would look roughly like this:

Site analysis in ArcGIS
Ideation stage (sketching) in Photoshop and Illustrator
Concept design in 2D Autocad
Stormwater simulations and system dimensioning in EPA SWMM
Swept path analysis in Vehicle Tracking
Visualizations in 3ds Max/Lumion
3D softscape/hardscape in Civil 3D
3D objects in Rhino
BIM authoring in Revit
Clash detection in Navisworks
Costs and tendering in Orca Ava
Project management in MS Project

At each of the above steps, there are data losses and interoperability issues. Constant switching between applications brakes the flow and takes time to readjust the muscle memory related to viewport navigation. Also, each of these pieces of software require additional training to use, and there are hardly any graduates, who know their way around even 1/3 of them.

One of my hopes for an All-in-One solution would be to flatten the learning curve for practitioners and eliminate data losses between design stages.

PS I'd definitely be interested in finding out more about the project you are working on.

S by stephen_l on 11 Jan 2021 #

In earlyer blender's days, funding was an issue and in such context any concurrent branch may be a threat for the long term survival of the project.

D by duncan on 11 Jan 2021, edited 11 Jan 2021 # +3 votes

I eat my dinner with a knife, a fork and a spoon. Sure I can buy an all-in-one knife/fork/spoon but it doesn't work as well. And sometimes I want a tea spoon or a steak knife.

All-in-one always sounds like it would be great, but it usually isn't.

But it's a good exercise writing the list of functions and thinking about what we have and what we're missing.

J by Jesusbill on 11 Jan 2021 #

@mrhe said:

If I understood you correctly, you're advocating a more robust interchange format between various applications which would all focus on their core functionality while allowing for content creation and data authoring in the respective applications. How would it be different from the workflows that exist today?

Well, not exactly. I am advocating for a modular and flexible architecture and for more than 1 application/platform in the ecosystem and for that, yes, I think we need agreed data-formats to operate on.

Your argument, fair to a certain point, is that with an "All-In-One" package you can perform all your needed tasks in a single application that takes care of all the inter-operability issues. But this will be a system difficult to develop and maintain and difficult to modify by individual users or companies for any reason (this comes down to the monolithic vs micro-services architecture argument). If instead we can have applications that can work on predefined schemas and separate back-ends, there will be freedom to use any that can accomplish your intended task.

One of my hopes for an All-in-One solution would be to flatten the learning curve for practitioners and eliminate data losses between design stages.

I think it will be difficult to come down to a single solution for each workflow. People are different by nature and need different implementations

The last point on the CMS gives a small twist, which I can explain perhaps better with an example based on your typical workflow.

Let's say that you have different applications that you use to do the tasks and that you use 5 different open-data files to inter-operate between them. For example, you initially create a dxf file, then you import it in Blender and you enrich it to get an ifc, which you further enrich with class detection and get a json for your report and eventually a txt document for the project.

Now in the CMS app, you define your project as a list of these 5 filenames that should eventually be in a given project folder. Ideally, if you have a good control of the applications you can assign a current project in the CMS app and you can directly start each application with the correct file loaded and with predefined names for any output files to be exported in your current project folder. Or/and you have an "add-on" for each application, where again you can read your CMS data and manage the correct files for the current project. So, in a way it would be like operating on a "All-In-One" app but within different platforms and with the possibility to easily modify the data between tasks, for example for a custom implementation, without problems in the pipeline execution or in the inter-operability with others.

J by JQL on 11 Jan 2021, edited 11 Jan 2021 #

One in all like a file that serves all purposes? A base that is common to all modules. Or a file with many subfiles connected to it? A 3d model with attached schedules and docs? All parts of which should be readable in each module that needs it? And each module edits that part while reading the all other parts?

If we had this file that binds all files parts we could have something.

Each module could then edit the corresponding part of the file. A module could be a bare bone and it could adapt to blender as a plugin, FreeCAD as a workbench or to any software that would be fit to deal with that subject.

An ifc alike file where parts of it could be edited independently of the main file. An ifc folder instead of a file. An .ifc as ifc zip. A part of the ifc would work like a xref of a DWG file.

J by jtm2020hyo on 12 Jan 2021, edited 12 Jan 2021 # +2 votes

Wouldn't Freecad be a better approach for this? As it uses vectors and there are already a lot of AEC workbenches and add-ons

1+. FreeCAD is already very close to being an All-in-one software, just need some fixes and add more tool to their Dodo Workbench for MEP design ... for Circuits, KiCAD could do a fusion with QElectroTech but I did not receive answers by both parts... and well some more tools for 2D and plumbing and mechanical design.

... I agree with @mrhe , literally, each different software to Blender and FreeCAD is reinventing the Wheel and the worst part is than not all FOSS are support for import-export since others FOSS, what we really are work together, and if not possible, at least promote the interconnection between FOSS.

...but IMHO is already possible, I think is already not a problem with code or developers, I think we need a consensus or merge projects.

... maybe the real problem is donations or do profitable software.

J by Jesusbill on 12 Jan 2021, edited 12 Jan 2021 #

JQL: The idea would be to have a way to personalize without great effort how you want to handle your projects and your data within the use of the open-source tools. If we can assume that you will have open-data files as reference for the workflows in your projects (dxf, ifc, xml, json, etc) you could create for example your own project data-model to manage these files and to associate them with the specific use of tools you want.

J by JQL on 12 Jan 2021, edited 12 Jan 2021 # +1 votes

But how is that different of what we do already? We already have the files and software to handle them inside a folder. They are just impossible to perfectly roundtrip between packages. What I thought this meant was that these modules for editing parts of files, for BIM, 2D Layout, Energy analysis, Scheduling, etc, could be written as barebones, then plugged into master software like Blender, FreeCAD, LibreOffice, etc and would be able to work on parts of the master file/folder, while keeping the rest of the files related but edited only with other modules.

Like you wouldn't be able to edit the model with LibreOffice, but could read it and fill data into the cells, using the module. You couldn't edit data in Cells with FreeCAD, but could edit the base Sketch with the FreeCAD module. This sketch could be read by LibreOffice to retrieve areas though. You could then send the file to Blender, the Blender Module would read it, and you could use Sketches or Extrusions along with Blender's Modifiers to create subdivision meshes or you could sculpt them or apply textures and materials. Then you couldn't change sketches or materials on FreeCAD but you could seamlessly read them and modify sketches again adapting modifiers back in Blender's Module.

Would this ever be possible or there are too many things that couldn't happen?

For instance sculpting is not a modifier, so I guess it would be hard to adapt it to a new face generated by those new sketch extrusions. However, if the sculpting could be kept there in the model as a static mesh and the user could figure out what to do with it later.

Does this make any sense?

J by Jesusbill on 12 Jan 2021 #

But how is that different of what we do already? We already have the files and software to handle them inside a folder.

Yes but each time you have to manually load your relevant project file, define any export files you are creating, etc.

The least gain from what I am proposing would be automating in some way these actions.

What you describe below could be done but my idea is that it would be done in an abstraction level above the input/output formats of the open-source tools and for your needs only, while inter-operation and collaboration with others would be done through the agreed data-schemas.

You would create your "JQL" data-model where for your example it could be a "project.jql" file that contains key-value items associating tools with specific file paths of your project. Let's also say that this jql file with all the related files would be in the same project folder, then you have a way to manage your data as you want

J by JQL on 12 Jan 2021 #

I think I understand the idea a bit better. Would you envision collaboration on the cloud or on the hardrive for a file like that? Maybe both? Or maybe it's irrelevant as it's a file, and it can fly around or be available in the network. But if it does fly around, how do you make it fast. Sending a specific .ods file is very fast. Sending the whole project file is crazy.

M by mrhe on 12 Jan 2021 # +3 votes

I appreciate the lively exchange in this thread!

It seems, that everyone agrees that aiming for the highest level of interoperability between disciplines and various design stages is a desirable goal. This would require a comprehensive (modular?) file format and generalized data-schemas to be adopted. Rather than importing/exporting files between applications, all pieces of software could read/write from the same file (database?).

If the above is achievable, why wouldn't it then be a good idea to adopt a modular approach to the tools we are using to manipulate the underlying data? There could be a toolbox for sketching, sculpting, BIM authoring, rendering etc. All grouped into a few predefined workspaces, while still allowing users to create their custom workspaces and custom tools. Similarly to how Blender add-ons are handled today.

Then, as developers, we wouldn't be writing plugins for Blender or FreeCAD, we would be writing code for, say, precision drawing of primitives, which could be executed from both applications or from a completely new AEC software package. Essentially, we'd have a unified UI API to render all the buttons and menus, which would call methods residing in various packages. Everything could still be customized to individual needs, but we could focus development efforts and maximize code reusability.

Is that feasible at all?

J by jtm2020hyo on 12 Jan 2021, edited 12 Jan 2021 # +1 votes

CSV for data base, or similars, is the only way.

S by stephen_l on 12 Jan 2021 #

Extendable formats like obj approach may be a solution.

In .obj you may store geometry, and when a material is defined it use another file beside (.mtl)

Such approach may allow independant data storage for each target domain, so file formats are kept as simple as possible.

D by duncan on 12 Jan 2021, edited 12 Jan 2021 # +2 votes

@mrhe said:

If the above is achievable, why wouldn't it then be a good idea to adopt a modular approach to the tools we are using to manipulate the underlying data? There could be a toolbox for sketching, sculpting, BIM authoring, rendering etc. All grouped into a few predefined workspaces, while still allowing users to create their custom workspaces and custom tools. Similarly to how Blender add-ons are handled today.

Then, as developers, we wouldn't be writing plugins for Blender or FreeCAD, we would be writing code for, say, precision drawing of primitives, which could be executed from both applications or from a completely new AEC software package. Essentially, we'd have a unified UI API to render all the buttons and menus, which would call methods residing in various packages. Everything could still be customized to individual needs, but we could focus development efforts and maximize code reusability.

This is what I think is exciting with FreeCAD / Blender. We have two quite capable and powerful - but VERY different software packages. Both with a robust extensible framework. No one solution is ever going to fit everyone needs. Watching these two solutions learn from and happily compete for the best solution is fantastic. It's like a sand castle competition, yes there's competition, but that's because competition can be fun, motivating and done in the open gives a way to quickly iterate solutions and see what works best.

What's critical is that both projects commit solidly to supporting open formats so data can move from a suitable FreeCAD workbench over to Blender with an add-on and back to FreeCAD and back and forth and sideways through all sorts of solutions. But that commitment to open standards is baked into our community already.

What we're watching may well just be the first generation of FOSS AEC authoring software. Look how quickly Krita has grown - I assume only possible because of the hard work done by Inkscape and BIMP before them. Maybe they show what a new generation looks like being built on the experience of so many other tools.