A quick update that I have updated the WASM/pyodide demo and wheels:
https://wasm.ifcopenshell.org/
https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.8.0/src/pyodide/demo-app
The app itself is just a teaser, but I'm really excited about the possibilities this brings to using the full ifcopenshell ecosystem in the browser.
This is incredible! Is the biggest change the reduction in filesize to 10MB? (so you aren't waiting ages for IfcOpenShell to load?)
Great to see progress here. Thank you very much. Definitely a very important part to strengthen the use of BIM with IFC.
Is the biggest change the reduction in filesize to 10MB? (so you aren't waiting ages for IfcOpenShell to load?)
Probably? But I've also noticed (didn't measure) that the WASM performance overhead appears lower for CGAL than OpenCASCADE. Pyodide got a little bit more stable. We can import shapebuilder now, which is 90% of the demo I guess. All in all, I'm ready to say this is beginning to look like something usable.
Very neat!
I was able to load a sample file:
Created a wall with window and door, saved the new file and open it in BIMVision, where it looks all good:
Cool, editing seems to work ok here, though it failed to load a larger IFC model with a lot of geometry. There is a glitch on firefox where the 3d viewport seems to be drawn in the wrong position and/or the 'loading..' notification is never removed (also non-cuboid opening representations are drawn instead of voiding):
@brunopostle said:
There is a glitch on firefox where the 3d viewport seems to be drawn in the wrong position and/or the 'loading..' notification is never removed (also non-cuboid opening representations are drawn instead of voiding):
I had the same problem with one model in chromium-based browser. It seems model-dependent to me.
Yes it's probably an exception in the load process, please share one of these where it fails.
The wrongfully applied openings is a bit alarming though, because that is ultimately C++ code.
I suspect the demo code could be simplified quite a bit to use the shape builder and API more. Is that OK if I go ahead and do that?
I haven't investigated but right now ThatOpen's viewer crashes when trying to load models produced from this.
Is that OK if I go ahead and do that?
Don't need to ask ;) context.py has a python main entry point as well, so you should be able to just use it outside of wasm as well.
ThatOpen's viewer crashes when trying to load models produced from this.
Hm, probably that also goes away when you improve API usage.
@aothms said:
Yes it's probably an exception in the load process, please share one of these where it fails.
The wrongfully applied openings is a bit alarming though, because that is ultimately C++ code.
Attached a simple model shat shows the viewport/loading dialog messed-up on Firefox. It also shows the openings issue - note that the openings that fail are manifold meshes, the extrusion based openings are ok, but all of them work ok in Bonsai.
@brunopostle I got the file to work with the following javascript changes:
--- a/src/pyodide/demo-app/index.html
+++ b/src/pyodide/demo-app/index.html
@@ -285,7 +285,7 @@
let it = ifcopenshell_geom.iterator.callKwargs({
'settings': s,
'file_or_filename': ifc,
- 'exclude': ['IfcSpace', 'IfcOpeningElement'],
+ 'exclude': ['IfcSpace', 'IfcOpeningElement', 'IfcStructuralItem'],
'geometry_library': 'hybrid-cgal-simple-opencascade'
});
@@ -297,7 +297,9 @@
// obj.type appears to be overwritten by pyodide, returning the typename of the C++ class?
let ty = ifc.by_id(obj.id).is_a()
- generateMesh(last_mesh_id, obj);
+ if (obj.context !== 'Clearance') {
+ generateMesh(last_mesh_id, obj);
+ }
if (!it.next()) {
break;
I know where this fails, but I don't know why. The structural items have a face topology representation that is not supported well by cgal and throws an exception, but under normal usage this is happily caught, but not in wasm somehow. It seems the old behaviour from before still prevails that some caught exceptions seemingly arbitrarily cause pyodide to fail :(
The geometry you see near the windows is just the clearance context though, other viewers will give you a similar view.
@semhustej Your file loads for me in firefox, but crashes chrome.
All in all, I'm ready to say this is beginning to look like something usable.
I guess this stability still needs some work and a better understanding of the exception handling in wasm. But we'll get there over time
@aothms said:
@brunopostle I got the file to work with the following javascript changes:
The geometry you see near the windows is just the clearance context though, other viewers will give you a similar view.
Ah, I thought I was being clever stashing this complex opening geometry in the Window Type definition as an invisible Clearance representation, then copying it into Openings to cut walls.
I remember following along those discussions. That's why in the IFC5 hello-wall example we have a Void 'representation' / subprim on the Window :)
I was under the impression that applications were only supposed to show one representation at a time, ie. not show a 3d door and it's 2d swing at the same time
@brunopostle I didn't know that. Is that from something you read in the IFC spec?
Nope, I probably just assumed it because they are alternative representations (and Bonsai seems to only show one at a time)
Login or Register to reply.