I'll have a better look... It's a pity that instead of writing nice documentation on how to access and use the API, they chose to write cyptic windows-only C sharp codePatrick Jörg wrote: ↑Wed Jul 10, 2019 6:23 amI have access to the API, but still trying to figure out how it works and what i am allowed to do.
You could have a look too at theyr proof of concept: https://github.com/bimobject/public-api ... of-concept
If i'm right you can upload a kind of filter App to theyr website and then access that one.
It is transferred as string because of the issue I am talking about here : Part.__fromPythonOCC__ issue : Segmentation fault ?yorik wrote: ↑Wed Jul 10, 2019 3:17 pmThe problem of huge IFC files is becoming more and more present...
There are several paths we can follow. One is of course that we need to make IFC import/export in FreeCAD faster. The current bottlenecks are 1) geometry is transferred from IfcOpenShell to FreeCAD as strings, which means extra encoding/decoding operation and 2) creating a lot of document objects in FreeCAD is slow and costly, since objects come with complex series of signal/slot processing.
For HVAC being able to compute an entire system is a very big advantage and honestly I was making fun of software which requiring to split system at each level to be bearable.yorik wrote: ↑Wed Jul 10, 2019 3:17 pmIssue 2) Can be addressed very well with working with partial IFC files and using Arch References. You can save the contents of an IFC file as one FreeCAD file, place all the objects inside a few BuildingParts, and use an Arch Reference to reference those BuildingParts in another file. In the other file, all objects inside the BuildingParts appear as one object. This allows to scale things up petty far. But it requires a bit of planning as how to "compose" a project using different partial IFC files.
I agree but we definitely need an improved version.yorik wrote: ↑Wed Jul 10, 2019 3:17 pmIssue 1) is a bit more complex. Although IfcOpenShell and FreeCAD speak the same geometry language (OpenCasCade's brep format), the data is currently transferred from one to the other as strings.One solution would be to code a new IFC importer in C++, which would be able to manipulate OpenCasCade geometry directly from one app to the other, but there is always the downside of making the importer cryptic for non-C++ coders... The ideal would be to be able to still work in python. We should explore more ways to transfer OCC geometry more "natively" from one to the other, that would work in python (pythonOCC, etc...)
I must agree here.
Let's be fair about this I never compared but Revit also takes ages to import / export. (often ≥ 15 minutes for large models I don't know exactly as I took the habit to do something else and forget it for often 1 hour) And when you think it crashed just wait a little more just in case
It would be cool if there was a parser between .ifc and .fcstd on the server. So when FreeCAD try to download a project it would download as a .fcstd file. I know i am dreaming but that would solve all my problemsyorik wrote: ↑Wed Jul 10, 2019 3:17 pmThere are several paths we can follow. One is of course that we need to make IFC import/export in FreeCAD faster. The current bottlenecks are 1) geometry is transferred from IfcOpenShell to FreeCAD as strings, which means extra encoding/decoding operation and 2) creating a lot of document objects in FreeCAD is slow and costly, since objects come with complex series of signal/slot processing.