As a follow-up to our previous post on two-dimensional browser interaction, we looked into Three.JS and added the library to our D3 workflow. This allows us to toggle between D3 diagrams and a 3D Model, and the user can download either an SVG file or an OBJ file from the interface.
We’ve provided a series of demos and videos in this post to show the revised interface. The ThreeJS portion requires WebGL compatibility for your computer, and since the last two interfaces may be slow to load (depending on hardware/internet speed), we’ll start with a basic version to communicate the idea (Note: this page should be loaded in Firefox or Chrome to have full functionality):
This is an exoskeleton example, and by clicking on the cube in the top right corner, the scene switches to three-dimensional mode and you can navigate in space. Upon changing views, you’ll notice the animation is different between the two view modes for camera transition. For the 2D transitions, we are simply moving vertices from point A to point B and animating paths in between. The 3D version is instead animating camera movement through the scene from point A to point B.
The ThreeJS library is insanely impressive. The OBJMTLLoader script allows one to setup an entire scene in Rhino and import the geometry (with render materials and texture mapping) directly into a browser. ThreeJS also offers a range of scene customization, along with several scripts for animation and interaction. Coupling this library with the powerful data parsing of D3.JS offers a lot potential.
Here’s a more practical look at basic building components:
Now, we mentioned some reservations about 3D browser rendering in our previous post. Simply dropping a 3D model into a browser doesn’t do much, so it’s important for this to offer something more than just a passive model viewer. The browser is great because it’s free of all of the templates, toolbars, and widgets of our modeling programs. All of this allows for simpler interaction. So rather than regarding the browser as a model viewer, we want it to be an interface with a clear design.
With this in mind, here was our first inclination: the abstraction of a 2D interface lends itself well to a more deliberate approach. It’s clear that 3D geometry in the browser offers much opportunity for exploration of designs. We just want to recognize potential constraints in the interface which will enable the user to understand a model without getting lost in it. By having a set choice of views for example, the user is able to rein in the potential sloppiness of 3D interaction.
This tool is intended to create presentations which iterate through views and reveal design concepts and construction logic. An abstract diagram can be presented at each view transition, and since each path drawn is fully interactive with D3, we can allow a basic mouse hover to offer any amount of information for a selected building component. The same can be done for each piece of geometry in Three.JS.
Unfortunately this tool isn’t ready for release to the public. While the workflow is relatively streamlined from Grasshopper to the browser, there were some isolated issues concerning the OBJMTLLoader and complex geometries. This setup involves a script which exports an obj to a target folder to load into Three.JS. It would likely be more efficient to export a range of geometries to a database and then query those geometries for the browser. In a related note, we’re very much looking forward to TTACM Group’s release of Platypus, which will create a live connection between Grasshopper and WebGL.