I went back to answering way too many questions in the Revit API discussion forum yesterday.
However, two other interesting topics also cropped up when I finally let go of that pastime, and I just finished a good book:
- The Sellout by Paul Beatty
- IFC Ids and Open Shell
- Forge formats Python script
I struggled a bit initially before getting used to his style, then really deeply enjoyed this unique American satire on racism.
It won the Man Booker Prize, and Beatty is now the first writer from the United States ever to be thus honoured.
It hits hard to caringly and lovingly reach into and explore some pretty deep and subtly hidden everyday truths.
It is sometimes also just funny.
Here is a metaphor I liked describing two men who don't quite fit in: "Like Nazis at a Ku Klux Klan rally, they were comfortable ideologically, but not in terms of corporate culture."
Question: Where can I ask questions about general IFC related stuff?
I would like to hack together something to display IFC models in the browser.
To do that, the server is converting uploaded IFC files first to Collada, then to a JSON format used by three.js.
This conversion process is problematic if the IFC IDs are not unique, which sometimes they are not.
I could burp out an error at the user, but I'd rather try to fix it silently if possible.
I've thought about 'fixing' the IFC file before conversion by simply searching for duplicated IFC IDs and creating new (unique) IDs for those elements.
Since I'm only doing this conversion for 3D display purposes, do you think that could work, or is it fundamentally flawed?
I'm basing this on the assumption that all IFC elements seem to be referred to by line number, not ID, so the specific ID doesn't really matter for my purposes, as long as it's unique.
Answer: I am not an IFC expert by any means, but here is a recent Autodesk University class an [IFC Technical Overview] presented by someone who is :-)
I was heavily involved a long, long time ago.
Yes, the IFC id just has to be unique within the context of the IFC file itself, afaik.
[Q]: Are there any situations where several different IFC files cross reference each other and refer to their respective internal ids?
I recently summarised all I know about
the consistency of IFC GUID and
including links to earlier discussions.
If the answer to [Q] is no, then you can assign any id you like, of course.
Even if the answer is yes, but no such cross-referencing occurs in your situation, you should still be able to go ahead.
Also, if you are getting all your elements from Revit BIM, you can use the Revit element
UniqueId just as it is. It is guaranteed to be unique, and thus enables cross referencing between different files and models... unless the files contain copies of element that occur elsewhere as well, e.g., you copied the BIM and the elements contained within it, of course. That obviously leads to duplication.
Regarding the three.js viewer:
- Are you aware of the VA3C three.js AEC viewer project?
- Are you aware of Forge and its developer resources?
- Are you aware of the Revit IFC importer/exporter open source project?
You might want to discuss your question with the Revit IFC open source community.
Response: I actually currently use IfcOpenShell to convert from IFC to DAE via
After that I segment the DAE files so that each IFC storey/space/etc. gets its own file based on information in the IFC model, parsed using Xbim.
That way, the clients can download only the storey/space they are interested in. Then I convert each storey/space DAE file to JSON, which is smaller and has much less memory requirements due to the browser not needing to parse an XML document (which it has to if loading the DAE file).
Answer: Cool. That sounds like a very useful workflow. Might come in handy in other contexts as well.
People just recently asked how to compress large BIM models for Forge. Your approach might help there too.
Other suggestions include:
- Simplify the BIM model before translation. Reduce geometry complexity, remove overly detailed aspects.
- Split the BIM RVT into separate files, e.g., by level or discipline, before submitting them for Forge translation. You can use the Forge aggregation functionality to put them back together again at need.
I just published the beginning of a new collection of Forge Python scripts, currently with a count of one:
py_forge_formats.py implements a Python wrapper around two basic RESTful Forge web service calls:
- Authenticate an app – forge_authenticate_app
- Query the file formats currently supported by the translation processes – forge_formats
The result is prettified using the jprettyprint helper function.
The mainline ties it all together and presents the final result, which looks like this at the time of writing:
$ ./py_forge_formats.py 9 Forge output formats: dwg: f2d, f3d, rvt fbx: f3d ifc: rvt iges: f3d, fbx, iam, ipt, wire obj: asm, f3d, fbx, iam, ipt, neu, prt, sldasm, sldprt, step, stp, stpz, wire, x_b, x_t, asm.NNN, neu.NNN, prt.NNN step: f3d, fbx, iam, ipt, wire stl: f3d, fbx, iam, ipt, wire svf: 3dm, 3ds, asm, catpart, catproduct, cgr, collaboration, dae, dgn, dlv3, dwf, dwfx, dwg, dwt, dxf, exp, f3d, fbx, g, gbxml, iam, idw, ifc, ige, iges, igs, ipt, jt, max, model, neu, nwc, nwd, obj, pdf, prt, rcp, rvt, sab, sat, session, skp, sldasm, sldprt, smb, smt, ste, step, stl, stla, stlb, stp, stpz, wire, x_b, x_t, xas, xpr, zip, asm.NNN, neu.NNN, prt.NNN thumbnail: 3dm, 3ds, asm, catpart, catproduct, cgr, collaboration, dae, dgn, dlv3, dwf, dwfx, dwg, dwt, dxf, exp, f3d, fbx, g, gbxml, iam, idw, ifc, ige, iges, igs, ipt, jt, max, model, neu, nwc, nwd, obj, pdf, prt, rcp, rvt, sab, sat, session, skp, sldasm, sldprt, smb, smt, ste, step, stl, stla, stlb, stp, stpz, wire, x_b, x_t, xas, xpr, zip, asm.NNN, neu.NNN, prt.NNN
For the sake of completeness, those two scripts have been added to this repository as well.
Two aspects need to be prepared: Forge and Python.
These scripts assume that you have stored these credentials in the environment variables
Regarding the Python components:
Now you should be all set to run as shown above.