Web based world building tool based on IFC, with support for creating, editing, saving IFC elements.

edited March 2021 in General

Hi folks!
As part of an ongoing WebXR "slow hack", we're attempting to create a collaborative world building experience, inspired by this modern classic:

I'm currently investigating if it would be feasible to use IFC to create and manipulate primitive shapes, i.e. walls, slabs, and openings (doors/windos) to begin with. IFC.js looks like an interesting starting point, but as far as I can tell it does not currently support entity creation, editing or serialization? I'd be very interested to hear your thoughts on the best way forward here!
Cheers,

Anders & team "WeBuildXR" at the WebXR slow hack.
https://www.eventbrite.com/e/retro-xr-hackathon-remix-the-classics-tickets-141906505177

Tagged:
duncanDADA_universepaulleewalpa

Comments

  • edited March 2021

    sounds like fun @anders - and a bit of work. You question if it's feasible with IFC as th data structure (?), well it's what blenderbim addon does now, so yea, it's feasible.

  • @anders, I've been mulling on this sort of thing as well. Logically, it should be possible, but you'll most likely have to handle your own tooling, and it won't be trivial. Hope you figure something out!

  • @DADA_universe said:
    @anders, I've been mulling on this sort of thing as well. Logically, it should be possible, but you'll most likely have to handle your own tooling, and it won't be trivial. Hope you figure something out!

    IFC.js might however be a good place to start from.

  • @anders said:
    Hi folks!
    As part of an ongoing WebXR "slow hack", we're attempting to create a collaborative world building experience, inspired by this modern classic:

    Such an amazing film by the way.

  • Wow! Looks like an aspiring project @anders !
    I am wondering if a "lean" option, given time limitation, could be having mini ifc templates for predefined types of structures and use IFC.js to create and dump the objects in the scene.

    paullee
  • Would require client-server interaction, where
    On client side you have ifc.js to display data.
    On server side there is open cascade to handle geometric operations like booleans.
    And maybe an ember like in the between to handle ui and transactions.

  • @stephen_l I believe the WASM based web-ifc project that IFC.js uses is implementing their own geometry operations, including booleans, so client-server interaction is not required.

    stephen_l
  • edited March 2021

    Thanks for all comments!
    @duncan indeed I consider IFC as a data format more than capable enough, with BlenderBIM as one of the surprisingly few examples. Looking forward to being able to do proper round-tripping using IFC in more tools soon. The objective in this case is to build a PoC WebXR experience where all functionality exists in the browser so as you say @DADA_universe & @Moult, IFC.js is what we're currently looking at. For shapes that can be created with booleans I think that should be enough and that way we only need to produce basic shape data ie IfcExtrudedAreaSolid and IfcLocalPlacement etc, that IFC.js can then use for the actual geometry generation. Finally, as you say @Jesusbill to simplify the project but also to introduce creative constraints that we think might actually strengthen the experience, we're thinking of only implementing some 10-20-50 basic shapes ie wall modules, doors, windows etc. Most likely we're also adding a snapping system to emulate the basics from a building code standard like OC24/CC60 etc.

  • Another example that we're looking at for inspiration (Swedish only unfortunately, but click the button "Rita din byggnad" to launch a 3D design tool in the browser:
    https://www.lundqvisttravaru.se/

  • edited March 2021

    Hey there! The project is very interesting! I'm looking forward to seeing how it progresses.

    From what I understand, the project is about a web-based modeller where several people can collaborate, isn't it? If so, I wouldn't choose IFC.js as a starting point.

    The main reason is that, as far as I know, the raison d'être of IFC is the communication between programs from different vendors in order to be able to use the information of one in another (for example, so that a pillar defined in Revit becomes a native pillar of a structural calculation software). Therefore, unless you want to take advantage of building models defined in other software (e.g. BlenderBIM) and their information, I think that using IFC as a format can bring you more difficulties than advantages. Note that the IFC is intended as a persistence structure, not as an efficient data structure to keep in memory in runtime.

    Using something like Three.js or Babylon.js you would have it much easier using glTF objects for persisting models such as doors, windows, etc, and using JSON to serialise and reconstruct the geometry of the scenes between sessions. In my opinion, this will make your life easier, as you can create a data schema that suits your project and not worry about having to adapt your structure to the IFC schema, which is already a major effort. For example, if you decide to work in IFC and a user creates a window, when saving the scene you will have to make sure that the relative coordinate system of all the geometric entities that build that window follows is adapted to the IFC schema. On the other hand, if you use JSON, you can simply do something like:
    {
    "buildingName": "Building_01",
    "buildingOpenings": [
    { "windowModel": "...", "openingPosition": "...", "openingSize": "..." }
    ]
    }
    Anyway, this is just my opinion, so if you decide to try IFC.js, I will help you as much as I can!

    c4rlosdias
  • edited March 2021

    Good points @agviegas and we may just end up building a simplified editor with a fixed set of glTF/glb objects. My idea behind using IFC and IFC.js is two-fold; first, I would want our users to be able to perform (basic) boolean operations, ie add a window to a wall, that would then know that it should add an opening element of the same size to that wall. Second, and possibly more importantly, one of our team members is an architect and we're envisioning an easy-to-use, rapid design tool that enables multi user collaboration during design. Being able to export the result as a proper IFC for continued work in another tool i.e. BlenderBIM or possibly Revit/ArchiCAD etc would be a great advantage. I'm thinking that by having the user start from a limited set of template "IFC fragments" containing just one element, and by limiting dynamic editing to resizing and creating openings and doors/windows, we should be able to get away with creating a fairly basic IFC authoring (geometry data, opening element, and door/window element), along the lines of this example:
    http://academy.ifcopenshell.org/creating-a-simple-wall-with-property-set-and-quantity-information/
    Let me know what you think, we don't have extensive amounts of time for this hackathon so of course we have to contain ourselves a bit :)

  • Offering my two cents on this, I would agree that using IFC as the authoring data model is generally quite a complex task, perhaps not something to be accomplished meaningfully within a hackathon. It would be definitely easier to create your own set of data models and just run with it. However, the moment you go past your own scope and if you ever want your model to collaborate across disciplines and have reliable automation across the BIM ecosystem, IFC is the only data model which has ever attempted this, and with all of its faults and complexity, I see no alternative and in fact praise its ambition. The guys behind Hypar have also seemed realised this and are stepping up their IFC game.

    The good news is that the barrier to entry to doing native IFC authoring is becoming lower and lower. The BlenderBIM Add-on code is largely agnostic of the Blender environment, and has distilled the common operations to native IFC authoring into agnostic functions that can be called by anyone. As a result, we are soon entering territory where it no longer requires extensive IFC documentation knowledge to build apps that author correct IFCs in-memory (what the BlenderBIM Add-on does) natively. The tutorial you linked to is very low level, but there are now high level functions to make it easier. Examples include operations like "assigning representations", or "deleting objects", or "changing materials" - which previously would require a solid understanding of the many IFC relationships ... now can be distilled to a few function calls - with all of the dirty work (e.g. recursive tree purging, maintaining correct relationships, updating ownership histories) all being automatically taken care of.

    Of course all of this is reliant on IfcOpenShell exposed to the web, perhaps through WASM. If someone embarks on this, I believe this can open up a world of potential and collaboration. Ping @aothms.

    brunopostle
  • Of course all of this is reliant on IfcOpenShell exposed to the web, perhaps through WASM. If someone embarks on this, I believe this can open up a world of potential and collaboration. Ping @aothms.

    I see this is the path IFC.js now follows, they've decoupled their code base so there is the base that deals with parsing IFC to WASM and there is the THREE.js wrapper as a separate implementation for interacting with the base. I started poking around to see about creating a Babylon.js implementation and it does not seem like an impossible task, save for finding the time, and limitations to my own coding abilities.

    What you say about BlenderBIM being agnostic of the Blender environment is also quite interesting. Godot is another tool that really should be able to handle IFC files. Godot _ IFC would open a whole world of interactive apps being built around IFC models, due to the low barrier to entry. Initially I thought creating such a toolchain in Godot would need it being written from the ground up, however, if like you say BlenderBIM is agnostic of the Blender environment........Godot does have python support (though it might be clunky in some instances).....or at the very least, GDscript is very python like, and maybe a BlenderBIM port to GDscript is feasible?

    anders
  • We ended up going for BabylonJS and IFC.js, with the objective of creating usable IFC:s during the collaborative design sessions in the app. I've gotten a basic loader working in BabylonJS for WebXR using the loader from three.js as reference just like you proposed @DADA_universe. It works, but there are some minor issues wrt rendering since Babylon uses a left handed, Y up coordinate system. There are also some possible bugs / issues with our test files, I've joined the IFC.js discord and maybe I could put the test files somewhere @agviegas? I'm using the default test files from Building Smart and the "Wall with opening and window" does not load correctly in vanilla web-ifc either :
    https://technical.buildingsmart.org/standards/ifc/ifc-examples/

    DADA_universeagviegas
  • @anders said:
    We ended up going for BabylonJS and IFC.js, with the objective of creating usable IFC:s during the collaborative design sessions in the app. I've gotten a basic loader working in BabylonJS for WebXR using the loader from three.js as reference just like you proposed @DADA_universe. It works, but there are some minor issues wrt rendering since Babylon uses a left handed, Y up coordinate system.

    Great news! Would love to see how you did it.
    About the coordinate system, I read somehow about how to fix that but can't remember where. Will share if I find it again.

  • It works, but there are some minor issues wrt rendering since Babylon uses a left handed, Y up coordinate system

    In three.js one should define the camera.up vector to 0,0,1 instead of 0,1,0

Sign In or Register to comment.