Working with Solid Shapes or with Meshes?

[vocx-fc]

It is not entirely clear to me whether we need to have "solid" objects or "meshes" to do the thermal calculations.

Arbeitsablauf für schnelles arbeiten mit großen IFC, STEP, IPT, 3D-DXF, 3D DWG und IGES -Dateien

As Bernd says in the thread, the problem with most FreeCAD objects is that they are parametric; they always recompute their Shape depending on the properties that are changed; this is implemented in the execute and onChanged methods of the object's class.

So, when we have a lot of objects, the FreeCAD system needs to keep track of every property in case it changes; that makes working with several thousand objects slow. If we only need the "dumb" geometry, then we should discard the parametric behavior of the object, and just have a solid, or a mesh. This is what Thomas Seemann says in the thread; he converts many big files to STL, DAE, OBJ, etc.

In the FreeCAD preferences (Import-Export, IFC import) we can set to import IFC objects as "Parametric Arch objects", "Non-parametric Arch objects", "Simple Part shapes", or a "Single compound". Each option decreases in complexity from the previous one.

Importing an STL, DAE or OBJ should be faster because the entire thing is a mesh with only points and triangular faces, but it doesn't have solid information like volume, area, length, and things like that.

• https://wiki.freecadweb.org/Shape
• https://wiki.freecadweb.org/Mesh

[haraldg]

Yes, we probably don't need to import parametric objects. However we do need some of the meta data from IFC. So very dumb objects probably won't do. We certainly need to handle a huge number of objects. (One of the bigger models has around 200 space objects and each space has multiple doors, walls, etc. That's easily becoming a lot.) Also we need Shapes not Meshes, because we do lots of geometry processing in our algorithms. This would be hell without proper Shapes.

Also our own objects mostly need to be parametric, because we actually want on the fly recomputes for some things.

[markus2330]

Thank you, very important insight. I also had a similar question. The assumptions on the IFC importer is a very important aspect we need to understand and clarify.

@haraldg did you already try with which import settings your algorithms will fail to work?

[haraldg]

I did neither tests for compatibility nor speed of various options.

I had this far down on the list of priorities. (Prototyping first, optimizations later). But if @vocx-fc thinks we he needs this information to properly decide where on the FreeCAD side to invest his efforts, then we can do such tests any time.

[vocx-fc]

I did neither tests ... speed of various options.

I think I will do this testing. I will create several IFC files, and test how fast they take to import in each IFC setup. However, as Harald says, we probably cannot use the lowest options, because we will still need to have some parametric objects, like Arch Spaces or Walls.

Not choosing parametric objects in the preferences was the reason I experienced the error in #16. So, at least we know that with the current code, some options of the importer will not work.

If some parametric objects created by Arch are too heavy, we also have the possibility of reimplementing them; that is, we make "lighter" Walls and Spaces, without many properties, only the ones we need. In this case we have to think if we want to keep absolute compatibility with the mainline Arch Workbench, or if we are able to have a mini-Arch with lighter objects. As far as I understand, we are mostly interested in data coming from IFC files, so however we represent the information in FreeCAD is a bit secondary.

[haraldg]

I'd try to stick to FreeCAD as much as possible. If something is useful for us, but not really specific to EnVis, it probably is useful for others too and we should contribute it into FreeCAD proper.

One way to go is to call IFCImporter.insert() multiple times with different settings for different kinds of objects. This was actually the main reason, why I contributed the possibility to pass and ifcopenshell object to insert() instead of a filename: To make this possible without having to parse the ifc file several times with ifcopenshell.

[markus2330]

I agree with @haraldg that we should get as much as possible upstream. But first we need to find anyway what is actually making it so slow. Do we know for a fact (with benchmarks) that the fat Arch objects slow it down? (The object creation would turn up as a big cost point if this would be the case.)

We need to do the optimization steps in the right order:

1. to check for the minimal settings which still work. This might bring the biggest speedup. And then we will not profile code paths which are not needed for us anyway. These settings should be the default and see also #20, users should not be able to destroy their EnVis by changing these settings.
2. benchmark and profile to find bottlenecks
3. and then discuss how to get rid of bottlenecks (like "light walls")

[haraldg]

I think I will do this testing. I will create several IFC files, and test how fast they take to import in each IFC setup.

Here are some ifc files, that InPlan probably will use for testing a lot: http://www.ifcwiki.org/index.php?title=KIT_IFC_Examples

[markus2330]

InPlan probably will use for testing a lot:

I doubt that they will test anything, we will have to demonstrate what is working.

I added the files (hopefully with SpaceBoundaries, @haraldg: did you already check them?) in our IFC repo.

[haraldg]

Well, Herbert sent the files around. I guess he had some reason. Even if he doesn't test himself, he probably expects to see them used in demonstrations.

Yes, I checked them and they have space boundaries. They seem to be fairly good examples. Ideally I'd get them working before I demonstrate EnVis on Wednesday.

[markus2330]

Well, Herbert sent the files around. I guess he had some reason.

I asked for more models (because the EFHeinfach is/was broken).

Even if he doesn't test himself, he probably expects to see them used in demonstrations.

Of course.

Yes, I checked them and they have space boundaries. They seem to be fairly good examples. Ideally I'd get them working before I demonstrate EnVis on Wednesday.

Great!

Btw. the institute (AC20-Institute-Var-2.ifc) I could not load at all. If you can reproduce this, please open an issue, then @vocx-fc can take a look.