The AEC community must rely heavily on the features of proprietary modeling programs to coordinate a vast amount of both geometric and parametric data for every project. The tools are amazing, but regardless of the feature-set of the modeling program, the ability to innovate becomes completely coupled with the ability for the software vendors to progressively add features. Vendors are forced to either have to work within the limitations of the software or build add-ons via the program’s SDK, which simply become faster automated ways of running the modeling programs user interface and do little to fully address the inherent limitations. These problems become particularly painful at the interface between describing the design intent to trying to extract enough manufacturing data to actually construct. The BIM model is inherently a generalist tool and the lack of a common modeling language makes it difficult to use this data in a way that can then be useful for digital fabrication. Creating a framework that allowed building component manufacturers to enforce the required parameters necessary to drive their products could remove a lot of the need for design churn with secondary and more specialized modeling applications.
There are many similarities between crafting a user interface and modeling the built environment. On the web, for example, an application consists of a nested hierarchy of components. These components are generally reusable concepts from application to application, but vary widely from project to project. Just like two buildings may not have the exact same window style--there exists the idea of a window in a building and these components need to be customized to fit the nearly infinite needs of the building program. This is very similar to how a web component may be styled from application to application (or instance to instance). Components must also respond to changes in a building program. Often during construction, building elevations, wall lengths and the overall parameters can often change. Smart building design allows for these components to be driven by these top level parameters. This is very similar to how a responsive web application may reorder and scale components based on the browser or device size
What it does
Our program displays a simple web based user interface which then generates an XML model of the configured building. This XML has all of the instructions to configure and place the resulting part families into a building assembly. The XML file is then read in by an add in for Revit and also Inventor--which has the task of configuring and placing the parts. The idea is that the add ins can be fairly 'stupid' and all of the logic can be pre-determined by the react syntax.
How I built it
The user interface and the XML generation is all done in react. We created a simple building component framework in react that allows a developer to write the logic of the building component layout just like they would if they were writing a web page.
Challenges I ran into
We decided early on that Forge would be an ideal environment for this. However, Forge was new to everyone on the team and we had some problems completing this integration.
Accomplishments that I'm proud of
Proud of how everyone worked together to try and complete. All of the individual pieces work great--the ui and XML generation work well. The add ons for revit and inventor also work really well.
What I learned
Learned a lot about Forge and very excited to learn more.
What's next for REACT-BIM
Lots of ideas on how to make this a viable framework. Need to create a library of standard building parts and a way of registering any parametric CAD part with the framework. Also looking at adding a geometric constraint solver and part numbering service capabilities. Also planning to starting using this to help model the VIFAB's stair system. The framework is barely even an embryo now, but with industry help this could be a powerful and useful tool.