New file format - dotbim

Hey :wink:

Few days ago we released some new file format (not file format, but a schema!) for BIM. It is not strictly related to GH itself (even though there is a GH plugin for export and import already in f4r: dotbimGH | Food4Rhino), that’s why I post it here on Meta. The main repo with documentation and C# library is here: GitHub - paireks/dotbim: Minimalist file format for BIM.

Basically I wanted to make it a bit easier to work with geometry and data attached to it. IFC in many case is great, but also it is really difficult to work with from the development point of view. So there is some sort of extremely minimalistic alternative.

I get many different reactions regarding it, so if you also have any comments about it: let me know :wink:

Video: https://www.youtube.com/watch?v=-bpWEdWcHvw

4 Likes

Interesting. Have you looked into the rhino3dm project? It’s also designed to be a simple way to handle geometry + data. It already handles all the geometry types that Rhino supports.

We agree that there is a need for clean data + geometry interop in this space, and that an open-source foundation for such a thing is necessary. I’m curious what you think is missing from rhino3dm to solve the problems you’re trying to solve?

4 Likes

I like rhino3dm project as well and love the fact I can use 3dms in browser. I used it e.g. in https://3dviewer.net/ :slight_smile:

I had a bit different approach as we cannot accept that many geometry types as rhino3dm provides. The idea was to contain only triangulated meshes. The thing is that (IMO) it is the most reliable form of geometry (most AEC software can at least import it). Other types of geometries for many software are problematic. Also having only one type makes it easier for creating importer. Obviously it is extremely limiting in some cases, but I’d say that in AEC in most of the cases it is enough to have reference geometries discretized that way. In Rhino world most of the time you need NURBS geometries, you need this sort of precise surfaces. In AEC if a bolt, beam, reinforcement, is a mesh or NURBS surface doesn’t change that much :wink:

1 Like

You’re right about easy, but easy doesn’t always mean effective. A mesh is the least accurate, most generic form of geometry representation. If fabricating the model doesn’t matter, then meshes are sometimes adequate. But once you get serious about doing LOD 400 models in BIM, meshes aren’t enough. I think an effective data interoperability layer needs to support all the geometry and data that people need in order to design, iterate, and fabricate their projects.

Is there something about rhino3dm that doesn’t work for the data side of your BIM schema?

As for being able to support complex geometry, that’s something we should talk about. Most serious BIM products can support all the geometry in the rhino3dm file format. If you have a target application that doesn’t support rhino3dm geometry types, perhaps having ways to downgrade the geometry to simpler types makes sense.

While meshes have limits, so might rhino3dm. I think if we all work together to make a library that can actually solve the problems of data interop in AEC, we all win. If we all start the same way (lines, meshes, simple data - there are many of these in each of the AEC firms in the world, and they don’t solve the problem) then the project never gets useful.

What are your thoughts?

3 Likes

Yeah, it is not like we can compete in terms of efficiency. You either go with efficiency or simplicity, and this one goes for simplicity.

Regarding LOD 400 accuracy in models in BIM - yes, meshes won’t be enough. But (controvertial opinion is going ;)) in most of the cases it is not necessary to have a LOD 400 accuracy. They market it that way that it is the future, but it doesn’t affect the real workflow of engineers that much in most of the cases. That is my private opinion obviously.

There is nothing wrong with rhino3dm. But if you’d tell me that I will have to write the reliable importer for it for e.g. Tekla or Revit, it will take some time. It should be much less time that it is for IFC I guess, but still. And also not all features will be covered, like I cannot transfer materials to many BIM software for example. With our format we try to make it in a way that you can write the importer within hours even without any additional library and you will get probably 100% of features. So it is basically different approach to a problem. If it actually be like this - we will see :wink: For the web viewer and Rhino importer it was like that, it was like few hours of work, but we’re testing other platforms right now.

I don’t expect to be huge to be honest, or replace something, this is only some alternative for test. It is just a schema, it cannot be sold, many things depends on how community reacts and so on.

1 Like

I wonder if there is a middle ground. Sure, simplifying to mesh very early in the process is, well, easy to write. And then as more features get requested you can add that geometry.

As for materials, that also is in rhino3dm. Fully supporting PBR materials is on the roadmap. We’d love to work together with you on this problem.

4 Likes

Just an update, thanks to Seghier Mohamed Abdelaziz, there is Rhino plugin for import.

2023-09-13_22h03_08

It works really fast with file loading :slight_smile:

Plugin itself is there: GitHub - seghier/dotbimRH: https://github.com/paireks/dotbim

3 Likes

Update of a plugin from Seghier here: GitHub - seghier/DotBimRHImportExport: Import Export Dotbim plugin for Rhino

Right now there is also export from Rhino to .bim :slight_smile:

1 Like

Thank you for sharing…Every year Rhino becomes more and more interesting with its ability to support such valuable plugins! Especially those related to BIM!!
I thinkthat Seghier is no longer on this forum. How can I contact him?

1 Like

I think probably by adding a Github issue here :slight_smile: : Issues · seghier/DotBimRHImportExport · GitHub

1 Like

Bonne idée…Merci ! :+1: :ok_hand:

1 Like