File format change recommendations

[kovacsv]

I like the idea to have a new BIM file format that is easy to read and write. I also understand that the file format is intended to be really simple, but I think it has some limitations that should be addressed to make it more usable. I've collected my thoughts.

Recommendations for version 1.1.0

These are backward compatible changes.

1. Introduce a name attribute for elements. It would be a big help in an application that lists all elements. Now only the type parameter can be used, so for example you will see "Wall, Wall, Wall, Slab, Wall, ...".

Recommendations for version 2.0.0

These are incompatible changes, but I think they would make a big difference in usability.

2. One color per element is a big limitation. Just think about a window element. You probably would like to use different colors for the frame, glass, and handle. I would assign the color to the mesh object, and would allow multiple meshes for one element.
3. There is no need for mesh_id in the mesh object. Meshes could be referenced by their index in the meshes array. Now an importer should build up a map to access meshes, because the mesh id can be any number. You can't be sure that the n th mesh has the id n.
4. String info types are easy to handle, but doesn't allow real collaboration. For example if an exporter uses fractional inches, it will write a value like 2′–6″. If I would like to display it in meters I have to detect the unit, and then do the conversion during import, which is not a trivial thing to do.
5. Hierarchical elements are missing. For example a stair can have multiple subelements (maybe with different metadata), but sometimes you would like to handle them all together. It would make harder to write an importer, but easier to use the end result.
6. Normal vectors are missing. For curved elements it would be great to have normal vectors optionally.
7. I would rename vector to position. 🙂

Hope that helps, keep up the good work.

[ibober]

Just a notice, except the point 4 these changes will make the format more similar to glTF. It has a hierarchy of nodes, meshes are referenced by index and allow many materials on one mesh.

[elzahaby]

I would also like to know why the mesh is separated from the element? I would regard the geometry as part of the I of an object so i would put the mesh as a child property of a element which should be optional so that it can be possible to store information in the tree that doesn't have any kind of geometry

also, i would like to introduce a child property, to capture the relation between objects, for example, a building, could be a meta element with children, which could be all the elements the building is composed of. Same Goes for Windows or Walls. With this type of "Relationchip" Every Part of a Window can be described as a Child/Children, And thus, Every Part can have a single color.

I would suggest to take inspiration fron how nosql databases are structured (firestore)

Add the id of every element as a key for easier computation

elements:{ "76e051c1-1bd7-44fc-8e2e-db2b64055068" : {…}}

[Evil-Spirit]

6. I can second this. This should be pervertex normal vectors. The point should be considered: it can't be calculated since pervertex normals defines smoothing groups which can't be detected since it is created by intension of the 3d model creator / CAD application. Sharp edges can be detected by using this kind of normals, then, combined with silhouette, 2d drawing of part can be easily visualized. 

7. The same for pervertex UV. It can be omitted, but if necessary, it should be ability to store them.

[paireks]

Hello all. Thank you for all these ideas :)

I just wanted to clarify one thing regarding changes and updates. Generally I've made some sort of the statement that I won't change the core schema and I won't increase it's number of features in the future. I know it might sound ridiculous, because most of the formats / programming languages / software constantly update, so why not doing it with this file format as well?

The idea comes from the Markdown language which is I'd say is the biggest inspiration. Latest release was in 2004 and nothing has changed since then. So if someone created an Markdown editor in 2005 - it should still work to this day perfectly fine. And it also doesn't require any updates to increase the number of features, because the number of it's features is still the same.

Dotbim file format was meant to be Markdown language for AEC in some way. It's limited, it's minimalistic, it's reliable, you can build tools for that really easily and extremely fast. Obviously - for more complex and more demanding forms of communication other solutions may be a better option. Just like it is with Markdown.

Still there is a place to extend dotbim capabilities: by creating extensions. That idea was also taken from Markdown, but also from CityJSON. The example of Multicolor extension for dotbim is here: https://github.com/paireks/dotbim-extensions-multicolor In the extensions you can provide optional tags that are necessary for your workflows. If anyone publish one I can add it on the repository and website, so it will be visible for everyone.

I know some would say that it would be better to change core schema, not to provide extensions, but well. That would require that after every little update I would have to contact every developer of every exporter/importer or library or converter and everytime I'd have to require update. I tried it already for a test, and it's not easy - different developers move to different projects, they don't have time to go back to it and so on. That would end up with the result that some exporters support version 1.2.0, some 1.1.0, some 1.0.0 and so on. That would also end up with no longer minimalistic schema, because we would continue adding different features to try to satisfy everyone.

I understand that some aspects of it could sound controversial or weird :) If you have any questions or comments just DM me or comment it there ;)

[Evil-Spirit]

I understand that some aspects of it could sound controversial or weird 

The idea comes from the Markdown language

Before "fixing version" you would have invent something ideal and not needed in additional improvements, something like thing with almost no ability to improve. Obviously, your format isn't something like this, so, you need just close this project and start one more. At the moment, your file format is not better even than STL, just because STL already supported and much more simplier.

[paireks]

There is no such thing as ideal, or without ability to improve. You can always say you can add something, improve something, in Markdown as well :) So it's creator choice if he wants to keep improving it and add functionalities or not. Dotbim is mesh-only minimalist file format. It literally stores mesh + dictionary, and it was made to do just that. Personally I've been using it for a while in practice, and it works great for me for that purpose. At first I was worried that maybe something is missing, that's why there is schema_version inside, but the more I use it, it seems to fit well enough its purpose. For more complex workflows, when you want to e.g. create 2D drawings from it, or you want to get quantities from it, etc. - other exisiting solutions might be better: IFC, Speckle, Hypar Elements. These are the much more complex schemas, but in return you will find much more features.

STL is cool, but as far as I know it stores only meshes, so I missed metadata. GLTF is great, I was using it at first for these workflows, but it contains much more features than it's necessary for AEC (camera, light, animations, textures etc.) + it's not that popular to store metadata there. So writing importer was a challange then. That's why decision was to release .bim.

I know that people would love to add to it thousands different features, but then it won't be minimalist anymore. For instance you can see in another issue that there is proposal for BREP or NURBS support. I've heard also some ideas to add textures. These are all cool ideas, but not for that project, where limitation > variety :)