NOTE: Starting with Flux
NOTE: 0015 — Monday 28 August 2017
For a week now, I’ve been delving myself into the Flux SDK Documentation in order to build the default Flux app as part of the research and prototype of the project.
Why use Flux?
That is a solid question that revolves around the idea of how Flux works. Specifically, Flux is essentially a web platform that allows users to send and receive data to and from the web. This is possible through the way that they organise the data. In this case, you can send various types of data, from integers, strings and even 3D geometry from a modelling or BIM software to Flux through their many plugins and whatever you’ve sent gets stored within your account, in a project and allocated a key. Just like JSON, you have a key and a value {"key": "value"}
What happens then is the geometry becomes the value as expressed in JSON format, and you give the key a specific name in order to organise and structure the data for use when sending over to other users, etc.
The concept of the JSON key and value is one of the most powerful ways to translate data. But more importantly, it makes data so much more feasible in terms of its lightweight format, whilst controlling what you send and receive.
For this reason, by building a web application using Flux, we can potentially build on from the success of this concept and focus on the purpose of the data used (in this case, geometry).
First Step — PROCESS
- Within the last week, we have managed to follow the Flux SDK tutorial and built the default web application using their documentation
Results — POSITIVES
- When it is built, it has the potential to generate new keys
- Has a geometry viewer made from Three.js
- Can select from projects that aren’t solely for one (can use whatever projects you have available in your account)
- Requires sign-in, so only those who have access can see
Results — PROBLEMS
- The app did not work a fair few times, is quite unreliable in a sense that the localhost server for some reason did not sync fast enough? Reason is because as I progressed further through the tutorials, the steps before finally worked and the latest addition to the code had not transgressed onto the application. Not necessarily a negative for Flux, but the process of building the app.
- It does not target 1 particular project. Therefore if you want the application to only work a specific project, it will show other projects in the user’s account. HOWEVER, within the SDK tutorial, the process entails the creation of a JSON cube in the viewport without being connected to your Flux projects. This was possible through referencing the .js script of the cube into the HTML document. This could be an alternative.
- Can only select 1 key to display at a time. Overlaying, adjusting opacity of other objects is not possible — at the moment.
- Requires sign-in to access the app — must create their own Flux account
- Unsure of how JSON schema is embedded in process. Uses their own core JSON schema to generate geometry
- You have to set up the parameters most likely externally from Flux to edit colours, sizes etc.
- Interacting with the objects in the scene is limited. Can only view objects at the moment.
- When creating keys, they are empty and cannot add any data to it — unless if you go back into their Flux apps whilst sending their own data to that key… which doesn’t necessarily make sense
- When you select a project > Select a Key to show, say a cube > select a key to change, say “colour” — it changes the data for the cube to the integer of the colour… How does that work? You would most likely need to know what data is connected with what — a bit of manual work before actually delving into making changes that will supersede the previous…
What have we learnt from this step of the process?
What we’ll need for the moment is to confirm what the process will entail. Specifically, a diagram that shows the workflow of how the transition of data may be required to pursue the project and what part we are focusing on. Below is the resulted outcome:
What’s happening in this diagram above is essentially breaking down each individual part of the process as to how streaming geometry as JSON on the web will work. It even touches base on parts of the process that may be out of my scope:
- A 3D BIM / CAD model is created on your computer / server
- The model is pushed through some JavaScript that will turn it into unencrypted JSON data / geometry and is stored on a server
- The JSON data is displayed on the Web platform
- Users have access to interact with the geometry. Add data, adjust colours and make changes, etc.
- The changes are pushed into a Database (CRUD spreadsheet)
- The Scripts will pick up the changes and notify a server
- The Architect / Model Manager approves of the changes and syncs it back into the original model
What’s interesting to note, is that throughout discussing the creation of the diagram, I realised what I needed to prove its necessary presence to pursue the project. That is, the dotted line that cuts between the model element and the rest of the workflow is what is either done locally and done via the web (or what I call “delocalised”). If the model was created via the web, there wouldn’t be a need for applications on desktops, local servers, or new and upcoming devices to cater for the strength of computation required to create the models and compute the data. Instead, we can solely rely on the web to do the exact same thing AND increase success of collaboration because access to data is much quicker, easier and readily available.
REFERENCES
Database:
Server:
JS / JSON File:
Person:
Geometry Model:
Visual Sketching:
OBJ file:
3D printer:
Visual Sketching:
© 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 Monday 28 August 2017
