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:
I just finished reading The Sellout by Paul Beatty.
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 UniqueId,
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:
You might want to discuss your question with the Revit IFC open source community.
You might also want to contact Jon @jmirtsch Mirtschin, author of the GeomGym IFC library.
The IfcOpenShell project (GitHub) also looks very promising.
Response: I actually currently use IfcOpenShell to convert from IFC to DAE via IfcConvert.
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:
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:
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
This script replaces and improves on the
previous forgeauth
and forgeformats Unix
shell cURL scripts documented in the discussion of
the cURL wrapper scripts to list Forge file formats.
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.
Before you can make any use of the Forge web services, you will need to register an app and request the API client id and client secret for it at developer.autodesk.com > my apps.
These scripts assume that you have stored these credentials in the environment variables FORGE_CLIENT_ID and FORGE_CLIENT_SECRET.
Regarding the Python components:
Now you should be all set to run as shown above.
By Jeremy Tammik.