NOTE: Where to from here?
NOTE: 0014 — Wednesday 23 August 2017
Now that we’ve created a working prototype that:
- Loads .obj files
- has interactivity (changes colour when clicked)
- shows data of object by referencing JSON when the object is clicked
- has buttons that can alternate the colour of all objects in the scene / override
These points are fantastic, HOWEVER, when using .obj files, you’ll realise that the load time is not ideal! As stated in this Medium post, the ‘Do’s and Don’ts of Web Design’ by Nick Babich: https://uxplanet.org/dos-and-don-ts-of-web-design-8c9d6a5de7c6 :
“Don’t make your visitors wait for content to load!”
But more importantly, in relation to Architectural practice, it’s so much more productive to find ways around gaining instant results!
So, where does this leave us?
We will most likely take a step back in the process of moving forward into continuing to build an interactive web-platform, and instead focus on pursuing the increase of speed in loading objects into our A-Frame scenes!
Given that there are a myriad of ways to load objects into a scene, we’re assuming that by using Flux, we can build a live connection between:
- Models built in 3D modelling softwares
- Flux (web platform)
- A server that stores the geometry’s data
- Three.js / A-Frame Scene
In order to do that, there will most likely be a myriad of steps going back and forth between deconstructing how our JSON geometry is written and read!
Why JSON you ask?
As stated before in previous posts, JSON data is very lightweight information that can be passed through a webpage without maximising the time to process the page. Flux also uses JSON, which is most likely the reason why it has been successful in processing geometry from BIM and 3D CAD models to the web!
We can start by looking into how to build a Flux app, using their SDK documentation:
Flux SDK
- Open Node.js command prompt
- Type: npm install -g http-server
- Type: http-server
- To switch to D drive, type: d:
- Type: cd then the filepath of the folder
- Type: http-server
- Open the browser at http://localhost:8080
- This will open your browser with the files you’ve created
From here, we’ll focus on how Flux and Three.js process JSON through their Schema and ultimately create a fluid and seamless connection with both platforms!
STEP 1 — Blender to Three.js
In this step, we’ll be solely looking into the output of JSON data to create a simple cube of 2m x 2m x 2m because it is the default geometry you see every time you open up Blender.
STEP 2 — Rhinoceros / Grasshopper to Flux
Now we can compare how it reads in Flux. By generating it in a different program that is compatible with Flux, we can seamlessly generate the same geometry:
The reason as to why these JSON files are different would be because of the way in which either programs parse through their defined JSON schema.
JSON Schema?
In the book “Understanding JSON Schema, Release 1.0”, JSON Schema is:
“…a powerful tool for validating the structure of JSON data”
But what does that mean exactly?
When we talk about JSON, we know that it is a document that stores data values within keys. However, the data inside is unique to the way it is structured as it is dependent on what has written and read the document. Therefore, by defining a JSON Schema, we can ultimately translate and extrapolate the data that a script may require in order to generate a specific output. In our case, we aim to focus on understanding how different applications read and write JSON geometry.
Possible workaround?
Could we for the moment, pull in geometry from a 3D modelling program and in Flux deconstruct it to “fit” the correct structure of JSON for uploading into Three.js?
Precedent — LMN Architects workflow using Python to connect Grasshopper to Three.js and D3JS
This is an interactive model viewer on the web (https://lmnarchitects.com/tech-studio/featured/grasshopperthree-jsd3-js/) that focuses on streamlining Grasshopper geometry to the web and illustrate design concept iterations and construction logic via a basic mouse hover. For the moment, this tool isn’t ready for release to the public because there are isolated issues concerning the OBJMTLLoader and complex geometries.
How it is supposed to work:
- a script that exports an obj to a target folder for Three.js to load
They say that:
“It would likely be more efficient to export a range of geometries to a database and then query those geometries for the browser.”
Precedent — Platypus
It’s come to my attention that there exists a Grasshopper Plugin called ‘Platypus’ (http://core.thorntontomasetti.com/announcing-platypus-for-grasshopper-2/) that achieves the live connection between a grasshopper model to WebGL through websockets, node.js, Three.js, Socket.io and SocketIO4Net. Interestingly, they say that:
“All Grasshopper data is sent to and from our servers as unencrypted JSON data using the websockets protocol. No user data is stored on our servers — all data just gets bounced off of our servers to everyone else in the session.”
What that basically means is that it does not store the data of any geometry / object for others to gain access to, but rather when everyone is available to the “session”, then the data is passed around at the same time.
You also have control of the parameters in the web-page UI, but that does not mean that it will be documented. For spontaneous design iterations, this is the tool for it.
However, we are looking more suitably for
- storing data on a web server
- allow for geometry data to be accessible
- still achieve live feedback of change of geometry on the web
- still use unencrypted JSON data
- send data back to BIM / CAD programs (Revit, Rhinoceros, etc)
- ideally a bi-directional / multi-directional system
REFERENCES:
- http://jasonwatmore.com/post/2016/06/22/nodejs-setup-simple-http-server-local-web-server
- https://github.com/flux-labs/flux-seed/blob/master/tutorials/chapter_1_login/README.md
- https://blog.hfarazm.com/node-js-tutorials/
- https://socket.io/get-started/chat/
Flux Schema
Collada to JSON
Minecraft JSON Model Viewer
D3JS + Three.js
© Emily Y Leung and Project Redback, 2017. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Emily Y Leung and Project Redback with appropriate and specific direction to the original content.
Last modified on Sunday 27 August 2017
