Geometry Computation in the Browser
This article explores the motivations for developing a low-level geometry library / kernel that can run in the browser and demonstrates how it could benefit both AEC (Architecture, Engineering, and Construction) and geospatial user workflows.
Introduction
WebGL frameworks like Three.JS and Babylon.JS make it easy to use JavaScript and TypeScript to create useful and engaging 3D applications in the browser. The geometry libraries used within these frameworks are similar to those used in game engines: they are optimized for efficient high-quality real-time rendering of static assets. This is different than the geometry libraries that are created for the creation of 3D digital assets (like in 3ds Max, Maya, Blender, etc.) or those used in CAD and BIM applications. In the latter cases geometry is represented differently to facilitate algorithms that can modify and generate geometry easily.
There are some use cases important for AEC and GIS work-flows, which involve the procedural creation or manipulation of geometry. The geometry libraries in Three.JS and Babylon.JS are inadequate for these purposes, they are missing many of the operations we need in a modeling application or a procedural geometry creation app.?
Use Case - Procedural Generation of Pedestrian Bridges
An example use case I encountered recently at the AEC Hackathon hosted in Copenhagen at BLOXHUB last week was the challenge put forth by Ramboll . They proposed a procedural pedestrian-bridge building tool. I was lucky to be part of a team of four Ramboll employees with additional onsite support from Ramboll.
Our team decided to try and build a tool for preconcept design of bridges. The primary use case were municipalities who needed to a tool for affordable and rapid early stage visualization and estimation of possible bridge locations.
Building on top off Rhino/Grasshopper the team built a tool, where the user could choose two points on a map and get metrics on the effectiveness and carbon impact of a bridge while also seeing it in 3D.
??
Experiments with Cesium
I branched off of the team's main project, and used my time to experiment a bit with Cesium JS to see if we could generate the bridge geometry in real-time within a geospatial context of (roads, buildings, and terrain).
As part of the challenge Ramboll provided us with terrain data, street map data, and building object data. The team brought this into Grasshopper directly, but using Cesium it would have been possible with just a few lines of JavaScript code to access this data live and from anywhere in the world.
I was able to bring in a bridge as a static object into Cesium via the Cesium ION geometry loader but I didn't get it positioned correctly. The workflow was extremely manual.
If I had more time I would have liked to have tried to recreate the Grasshopper parametric bridge in plain old JavaScript, and integrated it directly in Cesium, and read the points from the Grasshopper script. However putting it together is a non-trivial amount of work.
From Grasshopper to the Web
Having a tool working in Rhino 3D / Grasshopper is great for prototypes, proof of concepts, or in-house tools where your users already have Rhino licenses. Many successful hackathon projects are built using them. Transforming these into an application usable from web-browsers requires more effort. The following tools and services can be used to execute Grasshopper scripts on the web: ??
These all require back-end infrastructure, with its accompanying costs, to perform the compute, but can leverage directly from your grasshopper definitions.?
Performing Compute in the Browser
Performing geometry computation on the client-side has a number of advantages.?
Some examples of tools for AEC professional do the geometry or BIM computations entirely in the browser are:
If you want to port all of the algorithms that are used in a typical Grasshopper procedural geometry tool to the browser it would require a very significant engineering effort. You would need to start with a library that can work with meshes, NURBs, solids/volumes, curves, polygons, and that has an extended set of geometry creation and manipulation tools.
Perhaps a good starting point would be Rhino3DM.JS. Beyond that library, there are still a lot of additional requirements which are usually found in custom Grasshopper nodes and plug-ins.
A Case Study in Browser Geometry Requirements - Reading IFC Files
Reading IFC files in a browser requires some significant geometric heavy lifting. Both the Conway Geometry and Engine Web-IFC for example have to connect a number of different libraries to accomplish the different sub-tasks required in creating a mesh from the IFC files: Mesh Booleans (CSG operations), NURBs, polygonal triangulation, 2D curve to 3D shape transformations, and so-forth.
Whatever library chosen for each task has its own way of representing geometry and mathematical types and repeat a lot the same algorithms found in other libraries.
It would be simpler and more efficient to have a single library that has a solid foundation of geometric types and common algorithms, that could be reused by any geometry project in different contexts.
Applications for Geometry Computation with Geospatial Data
Procedural geometry creation for construction projects is too often done without the context of geospatial data (roadways, buildings, terrain, etc.).
For example if creating the procedural geometry for a bridge in a particular location, it should account for variation in height of the terrain. It should also do automatic clash detection to determine whether the generated geometry is too close to a roadway, or is colliding with an existing building's geometry. This is achievable in Rhino / Grasshopper with plugins for reading digital elevation models, and open street map data.
In the browser, the Cesium.JS library provides a robust and efficient library for loading Geospatial data stored in glTF and 3D tiles, streamed over the network (for example, from Cesium ION). It also solves the problem of rendering this data effectively, within a Three.JS context.
What is missing is a unified geometry library to query or transform the geometry both contained in glTF data and created by a procedural geometry tool that can run both natively and in the browser.
Plato.Geometry Proposal
There are many open-source geometry libraries written in multiple languages.
No commercially friendly open-source libraries provide a comprehensive foundation of easily verified and efficient algorithms and data-structures for 2D and 3D geometry that can be used from the browser or native real-time applications.
What we have done at Ara 3D is create a modern geometry library from scratch in a language (Plato) designed specifically for expressing mathematical data-types and algorithms in a straight-forward manner with a minimum of repeated boilerplate. This library uses modern programming practices (e.g., immutable classes, higher-order functions) to emphasize readability, flexibility, and maintainability.
Most importantly the Plato language was designed specifically so that the common geometric algorithms and data-structures, which are for the large part, unchanging and well-known in our industry, can be written down once and for all and used from any programming environment.??
Currently there are 150 data types in Plato.Geometry, and over a thousand functions. We are using it in the development of a Ara 3D Studio, a tool for working with 3D data designed for AEC professionals. Plato.Geometry outputs to C#, but with a small amount of funding we will be able to port it to other languages.
Request for Support
Ara 3D is looking for small grants or projects to extend the open-source geometry work to specific use cases so that it is more widely useful to the AEC community. We are a small and very efficient company, so a little investment will go a long ways in improving the quality of open-source software in the AEC industry.
Reach out to Christopher Diggins to discuss the possibility of collaborations or just share ideas back and forth.
Acknowledgements
Thanks to my team-mates Arthur Faudou , Emanuele Grimolizzi , Konstantin Krasnopjorov , and Saleh Elbehiri as well as the members of Ramboll on-site who provided support and encouragement: Iman W. , Anna Ullersted Rasmussen , Anthony Little
Big thanks to the organizers, leadership, and hosts of the AEC Hackathon: Aske Strandberg , Damon Hernandez , Helle Stendorff , and Torben Klitgaard .
Shout out to Patrick Cozzi and Julien Moutte from Cesium/Bentley for encouraging and supporting open-source standards both financially and through direct contributions to code and standards. Additional kudos to Pablo Mayrgundter from Bldrs.ai who also is contributing financially, and with code, and has provided me with his valuable time
Special shout out to the OG WASM geometry Tom van Diggelen as well as all of the other programming wizards (and their employers) who have improved and extended his work.
Special thanks to Chris Andrews, Arol Wolford, Greg Schleusner AIA and Valentin Noves for providing excellent guidance and encouraging me to pursue my ambitious vision of bringing geometry and computation to the masses.
Finally, thanks also to all of the people who have hired me, encouraged me, or spent their precious time sharing their experiences and knowledge.
M. Architect - Managing Partner and Co-founder of Enzyme APD
2 周Great reading Christopher Diggins !