NOTE: The Prototyping Process
NOTE: 0008 — Monday 21 August 2017
PART 1
It is now week 5 of the semester, and so it makes sense to breakdown the process I’ve taken throughout the time so far into what I’ve put together in terms of a prototype. It definitely would have been preferred that I document this on a daily basis. However, lack of time has resulted with a huge gap in the constant updates.
Week 1 + 2 + 3
First things first, plenty of time was spent in the first couple of weeks (Week 1 — week 3) to get my head around basic programming knowledge:
- HTML ( Hypertext Markup Language)
- CSS ( Cascading Style Sheets)
- Javascript
I mainly used the free sections of https://www.codecademy.com/ to learn the basics.
Week 3 + 4 + …
This followed along with building up skills in using Javascript libraries for WebGL which allowed me to display and interact with 3D objects on the web:
- A-frame (Week 3 onward)
- Three.js (Picked this up in Week 4, however, turned back around to A-frame)
The reason for turning back around was mainly due to feeling restricted within A-frame’s compacted nature of the scripts and therefore feel restricted on how you construct things. In Three.js, you are given more freedom to build the scenes, but that also means a LOT more lines of code…
For that reason, A-frame was built from Three.js and so it made sense to circle back with a stronger sense of understanding how the components were put together.
My First Prototype Scene — Week 3 [170807]
The first official prototype development of this research project would be through pulling out a model for the platform rather than building from the default primitives within A-frame.
Using Revit, I opened and extracted the Sample Revit Model into a 3D DWG file for exporting into OBJ.
In order to export it into solids that are more friendly, choose ACIS solids.
From here, hit ok. Then choose ‘next’.
This will produce a 3D DWG file that Rhinoceros 3D can read and open.
To keep a limited amount of files and objects within the A-Frame scene, I exported each layer as one file — which means that there are objects that are grouped together rather than individual isolated objects to interact with. This is not ideal in practice, as you’d want to obtain information on one single object, however for proof of concept purposes this is still practical.
These of which are exported as OBJ files.
However, A-Frame has the ability to upload different types of files:
- Wavefront (.obj)
- Collada (.dae)
- glTF (.gltf)
- three.js (.JSON) Object
- Polygon (.PLY)
Interestingly, I found that it’s much more difficult to upload OBJ files into a Three.js scene. JSON files are much more appropriate when exported with the use of Three.js’s plugin for Blender.
Due to the ease of exporting objects into OBJ’s over JSON files (unless if using blender’s Three.js plugin), then it makes sense on a practical level to maintain a universal file format. For the time being, anyways.
So below is a shot of all the OBJ files for each layer in Rhino:
These files are now ready to be referenced into an A-Frame scene which we will build in the next medium post.
© 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 Tuesday 22 August 2017