Updated IfcOpenShell+pyodide demo app wasm.ifcopenshell.org

Comments

• Moult

  January 12

  This is incredible! Is the biggest change the reduction in filesize to 10MB? (so you aren't waiting ages for IfcOpenShell to load?)
• kurb70

  January 13

  Great to see progress here. Thank you very much. Definitely a very important part to strengthen the use of BIM with IFC.
• aothms

  January 13

  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.

  
• semhustej

  January 13

  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:
  

  
• brunopostle

  January 13

  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):
  
• semhustej

  January 13

  @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.
• aothms

  January 13

  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.
• Moult

  January 13

  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.
• aothms

  January 13

  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.
• brunopostle

  January 13

  @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.

  simple.ifc 242.4K
• aothms

  January 13

  @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

  
• brunopostle

  January 13

  @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.
• aothms

  January 13

  I remember following along those discussions. That's why in the IFC5 hello-wall example we have a Void 'representation' / subprim on the Window :)

  
• brunopostle

  January 13

  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
• Moult

  January 13

  @brunopostle I didn't know that. Is that from something you read in the IFC spec?
• brunopostle

  January 13

  Nope, I probably just assumed it because they are alternative representations (and Bonsai seems to only show one at a time)