1. Introduction: Research Motivations - CoDe€¦ · Web viewIntroduction: Research Motivations. Optimising collaboration between all stakeholders regarding Building Information

EARLY STAGE COLLABORATION ENVIRONMENT IN AEC INDUSTRY VIA WEB APPLICATIONS

A web-based collaboration platform curated for design phase of AEC projects

S.GIANG,UNSW, Sydney, [email protected](es)

Abstract. In the Architecture, Engineering, and Construction (AEC) industry; buildings are designed in collaboration. This research believes that current practices of designing and collaborating can be re-thought out for processes to be faster and better. Designers from different fields can also overcome the disciplinary silos of other designers and understand their design intention. Flux.io, a web-based platform, offers seamless connection between the design tools. It also include Flux Apps that connects design tools with the browser, hence faster. These two paths of connections makes collaborating more flexible, hence better. This research intends to create a Flux App that can clearly transfer design intentions from one to another with an effective feedback system. This should serve as proof of concept that restructuring and possibly improving the design phase of AEC projects with custom Flux Apps are feasible.

Keywords. Early-stage; collaboration; web-application; design phase; Flux.io

2 S.GIANG

1. Introduction: Research Motivations

Optimising collaboration between all stakeholders regarding Building Information Management (BIM) is an active field. The platonic ideal of BIM, to seamlessly and effectively combine all design and construction information into one elaborate 3D model is not plausible due to all the existing and yet-to-be-identified constraints. The life of a 3D digital model is divided into interrelated stages from design to production, and effective collaboration should begin from the outset.

Design is not a sole effort but a process capitalised through successful collaboration. It is worth looking into the potential improvements for the current practice of designing an AEC project. Generally these projects are multidisciplinary or even transdisciplinary because it involves people from different disciplines and some from multiple disciplines working jointly. Qualitative surveys from engineers have voiced the need of a tool to ‘transfer the intent of the architects directly to my [actor] brain” (Holzer 2009). This research attempts to overcome disciplinary silos and allow project contributors to better understand each other’s design intentions.

A collaboration platform, Flux.io, was founded in late 2010 to connect architects and engineers. With the same belief as researches, Flux.io is open-source enabled in which they not only have an established community of programmers but allow developers to design Flux.io web applications to further improve and introduce ways of connecting people. Flux.io is acknowledged, Flux.io is developing and through designing a web-based application, this research believes this is an appropriate medium to better connect contributors to design of AEC projects.

EARLY STAGE COLLABORATION ENVIRONMENT 3IN AEC INDUSTRY VIA WEB APPLICATIONS

2. Research Aims

The research strives to develop and evaluate a web-based application that facilitates a collaboration environment oriented for the design phase of building projects. There are three subsets of this environment that the paper is seeking to explore. The process of designing in the early phase involves design tool, the sharing platform and, thirdly, a feedback system. For this very instance, the explored tools are respectively, Grasshopper3D, Flux.io and the to-be-designed web application. The feedback system capable of aiding users to effectively understanding each other. It is when this is achieved, that other users can provide proper feedback. This paper aims to bridge the gap between the ideal world of BIM and reality for better AEC projects to be completed.

3. Research Questions

Setting out to create an early collaboration environment demands several questions to be answered throughout this research. This research needs to identify and evaluate previous attempts to target similar problems in this field of research.

“What are some existing precedents that evaluates concerns of architects and engineers for early collaboration or collaboration in general?” Precedents can be evaluated to help identify possible voids in which can be further elaborated or solved.

“What are some collaboration methods that ought to be implemented when designing the web application?” As mentioned before, a feedback system is aimed to be facilitated in the web application that is intended to be programmed. These will all lead up to answering this question, “In what ways can early collaboration environments for the AEC Industry be facilitated via web-based applications?” Ultimately, this research suggests an effective feedback system for effective communication, design and information-wise.

4 S.GIANG

4. Methodology

4.1. RESEARCH METHODOLOGY

4.1.1. Collaboration research and surveys

The first question can be answered by conducting research in the field of BIM and if possible researches in regards to early collaboration in AEC industry. Ideally surveys conducted either qualitatively or quantitatively can help convey the voices of architects and engineers rendering it not compulsory for surveys to be carried out in this research.

As for the second question, current practices of designing and/or collaborating can be taken as reference and adapted into the web application.

4.1.2. Understand technology

Existing precedents are essentially written programs and most-likely open-source. A hosting service, GitHub, is commonly used by programmers and holds repositories of their projects. The case study is initiated by understanding at proficient level the function of those precedents.

Without any knowledge of programming, tutorials online are available to learn the syntax of necessary programming languages. Most importantly to think like programmers, in order to design a feedback system, one must learn how to conduct procedural thinking.

Understanding written programs can be done through two mediums. One can simply download or clone repositories of those projects from GitHub and read the coding on their text editors. Another medium would be in the console of browsers, this is rather effective as the console often comments on all relevant actions made in the program. Downloading the repository allows people to edit the code for better evaluation but debugging in the console does not require any downloading which is beneficial as programs are not always open-source.

4.2. IMPLEMENTATION METHODOLOGY

Following the literature review, it was decided that the ideal environment (figure 1.) for ...which envelops design tools, sharing platform and feedback system have been curated which will guide the approach of the case study.

The initial design model should be streamed into a storage server and be able to be visualised on a web application designed to allow others in the


project to easily understand the design intent. Then feedback can be provided for the designer(s) to update their model. The process would be iterated to implement progressive feedback loops.

Figure 1. Ideal EnvironmentThe start of an AEC project, the very beginning of the design phase is

often carried out by only people of the same field, usually either engineers or architects, before the model is shared with other consultants. This methodology tackles three collaboration factors; the speed of sharing, the flexibility of communication, and the ability to understand others. By facilitating this environment, implementing more iterations of feedback loop (figure 2) can become more plausible and also more impactful for the end result of AEC project.

6 S.GIANG

Figure 2. Early design phase

5. Background Research

5.1. LITERATURE REVIEW

5.1.1. Design Limitations

Potential design limitations of existing BIM applications, Design solutions from different disciplinary silos are combined at the later stage of the combined process to create a central model. Consultants, as Quanjel has stated, could communicate a significant amount of sub-design solutions with their analyses relative to the dominant role of architects. Hence collaboration should be implemented at the early stage to explore complex-geometrical design options with solution inputs from all practitioners and not one designer. (Quanjel, 2013) This is further emphasized by the tendency of early collaboration to induce high impact on the end-result of integral design projects. (Holzer, 2009)

5.1.2. Collaborating vs Sole-Investigating

From conducted surveys, when given informations; individuals tend to spend more time conducting sole investigations as compared to multidisciplinary interactions. In theory, meetings lack the flexibility for practitioners to interpret before implementing. The process of sharing ideas in meetings is disconnected from the process of sharing 3D models. Most generally at the early stage of design, prices analytical data are not required between professions. It is however imperative for the implications of such analyses to be communicated, and communicated quickly. (Holzer, 2009)


5.2. TECHNICAL REVIEW

5.2.1. Grasshopper3D

Desktop design tools for Architects range from SketchUp, a 3D modelling tool, Rhino3D, a computer-aided design (CAD) application, to Revit, a building information modelling (BIM) software. Theoretically speaking, each design tool covers different but overlapping domains of design. By integrating these design tools, the life of a digital model in its early phase can be restructured to cover different bounds of design.

Grasshopper3D is a plugin for Rhino3D that facilitates, the aforementioned, discipline of computational design thus covering a fringe of the design spectrum. Grasshopper3D provides a node-based developer environment, an interface approachable by designers of non-programming background. It allows users to intuitively engage themselves with designing logically simply by connecting nodes, namely ‘components’.(Kilkelly 2016) Grasshopper also allows programming custom components hence flexible for users like professional programmers.

What differentiates Grasshopper3D from its predecessors is its ecosystem, essentiallythe extensive library of plugins. The designer of Grasshopper3D, David Rutten from McNeel programmed Software Development Kits (SDK) to help programmers design their own Grasshopper plugins written with .NET scripting languages including Visual Basic, C#, and Python. McNeel has its own website for multitude of 3rd party plugins, Food4Rhino.(table 1)

GH Plugin Usage(s) Parent discipline(s)

LadyBug Tools Construction analysis,annual daylight, daylight analysis, glare analysis, electric lighting, energy analysis, indoor/outdoor comfort, airflow, thermal satellite imaging

Architecture, fire engineering, mechanical design, environmental design, urban planning & city modelling

Kangaroo Physics Interactive simulation, optimization, form-finding

computational physics, engineering

LunchBox Explore mathematical Architecture, facade-

8 S.GIANG

shapes, panelling, structures, and workflow

planning

KARAMBA Analysis of spatial trusses, frames and shells, structural optimisation

Structural engineering, architecture, manufacturing & fabrication, physics

BIM GEOMGYM Generating and exchanging Industry Foundation Class (IFC) model

BIM, Architecture, Manufacturing & Fabrication, Structural Engineering

VisualARQ Adds BIM features when modelling with Rhino/Grasshopper

BIM, Architecture, Rendering & Visualization

VR EDGE Visualise 3D geometry and data on online platform built with A-frame

Rendering & Visualisation

Flux.io Seamlessly connects data from Grasshopper/Rhino to Revit, SketchUp, Dynamo, Google Sheets, AutoCAD, 3dsMax and Flux.io apps

BIM, Architecture

Table 1. Grasshopper Plugins

Rutten will release Grasshopper 2.0 where it will become a ‘fully fledged programming environment’ (Rutten 2014) where the Grasshopper canvas itself should include debugging tools, documenting and commenting tool. This is due to the feedback given by the large community of end-users of Grasshopper3D in which again in theory, highlights the importance of effective feedback.

5.2.2. Flux.io

Flux.io is a web-based platform that connects desktop design tools (Grasshopper, Sketchup, Dynamo etc.) (figure 3) to the internet and can indirectly connect those tools with each other. This is potential alternative to


emailing design files or using cloud storages like Google Drive or Dropbox currently used by many AEC Industry companies.

Figure 3. Flux cloud diagram

Flux.io connects web browsers to servers via websockets which is essentially how Flux.io can store all the information streamed from design software. Unlike uploading files to dropbox, email etc. Flux.io not only provides web-based storage but is a platform with collaboration services. Flux.io is newly established in 2015 and has already introduced plugins compatible with design and BIM tools. Flux also allow app developers to create Flux applications to expand the collaboration service.

Flux.io provides developers three methods of approach to design their own applications. It originally provide SDK, one written in Javascript and one in C#. These are two different programming languages but only recently in 2017, Flux team provided a third option using React.js in which is also Javascript library.

As previously mentioned, Flux.io uses WebSockets as a gateway to connect web browsers, desktop and storage servers. The WebSocket protocol allows two-way communication (Fette & Barth 2011) supporting bi-directional exchange of data. Websocket use Transmission Control Protocol (TCP) instead of User Datagram Protocol (UDP). Essentially, the difference between the two is speed and error correction. UDP skips error correction which then makes everything much faster. If Flux apps can also use UDP,

10 S.GIANG

then data could be streamed in real-time. Theoretically speaking, interactive animations done in Grasshopper3D can be seen live on web browser or other connected desktop tools.

Animations are only a subset of information that needs to be communicated between designers but the main objective to have a working kickstarter for this environment. UDP cannot be used in Javascript but possible with C# but again, generally speaking, WebSockets uses a TCP connection which does error checks. This is rather important to ensure a certain degree of accuracy in the design model shared.

Sharing design model real-time is also pretty redundant, as previously mentioned, designers in collaboration tend to spend time solely investigating information that is given to them before providing feedback. Flux.io is capable of connecting design tools between contributors where they can directly share design model or a subset of the design model to each other. This serves as strong backbone for this research however a third medium is necessary for the sharing of ‘ideas’ before the design model itself, the browser.

Flux.io web applications are introduced for collaborators to handle information connected to the server within the browser. There are however no attempts so far to create a feedback system intended in this research which serves an opportunity.

The viewport customly written for Flux is rendered with THREE.WebGLRenderer. This became a very good lead that the parent class for the renderer, THREE, can be looked into for designing of a custom viewport in this research to facilitate the aforementioned feedback system. THREE is written with Javascript which indirectly concludes the decision of using Flux-Javascript-SDK to build the web application.

5.2.3. Three.js

Three.js is a Javascript library that is normally set with parent-child interface with HTML and Javascript. Three.js is commonly used to create and display 3D computer graphics in browser. The source code of this library is available on GitHub to be referenced into the Javascript script within HTML.

One of the most notable difference between HTML and Javascript is that all HTML primitives are written with ‘< >’. HTML deals with the layout and content management of the web-browser. The conventional layout between the two is that Javascript is written in HTML and not vice versa.


<!DOCTYPE html><html>

<head></head><body>

<script>// Javascript goes here</script>

</body></html>

A basic setup of three.js requires a container, camera, renderer, and a scene. All other three.js primitives are added in the scene and then along with the rest, elements would be rendered with the renderer/ As mentioned before, the renderer would be THREE.WebGLRenderer.. The container is a HTML element that connects the renderer to HTML where everything can be seen in the browser.

Another syntax of three.js is that all functions in three.js can only be called when it is declared with ‘new THREE.’ for example THREE.Scene, THREE.PerspectiveCamera, THREE.Mesh.

The function that allows Three.js to load JSON files is THREE.JSONLoader. The function allows JSON files to be loaded from both the server and desktop

6. Case Study

6.1. UNDERSTANDING

6.1.1. Understanding Flux-Javascript-SDK

Flux.io provides tutorials in creating a Flux App with a sample application available in GitHub. The web-directory for this tutorial is called GitBook.

The fundamentals of this tutorial is to show the mandatory processes of creating an App repository on Flux.io that can contain your built javascript sdk app and potentially be published into the website for collaborators to use. Sequentially, after creating an App repository would provide the developer two sets of necessary information, client iD and redirect url, when testing the sample application.

12 S.GIANG

Figure 4.Flux-Javascript-SDK

Geometries, for this instance, meshes created in Grasshopper3D was streamed into Flux.io server with the plugin. The plugin allowed users to create a new project in Flux.io and also create keys. Keys acts as various collections of information layered in a project and meshes were streamed through different keys. The source code shows how meshes were parsed into custom Flux viewport. The custom Flux viewport itself is not defined in the the source code. However it was evident that the viewport was imported within Javascript and then appended into a canvas in HTML. The order of operation is same as animating 3D graphics with Three.js in web browser, but the viewport would be created, not imported, in Javascript instead. Theoretically speaking, it should be possible to create viewport externally and import into Flux-Javascript-SDK to build a Flux app with custom viewport designed with a feedback system.


6.1.2. Understanding Noumena A-Frame

To simplify the prototyping process, the research intends to design the custom viewport before importing into Flux-Javascript-SDK. This way programming would be more manageable.

This would require firstly, a different mean of having the design model accessible in Three.js. The data streamed into the sample Flux app was in Javascript Object Notation (JSON) format. Amongst the vast amount of plugins available in Food4Rhino, there is one, VR-EDGE, that serializes Grasshopper geometries into JSON file and also visualised in the browser with a library called, A-frame.

Figure 5. Noumena A-frame tech diagram

A-frame is a compacted three.js library that is setup by default to visualise 3D computer graphics in virtual reality. Just like Three.js, all A-frame codes are written in the <script> tag in the main html file.

All primitive functions in A-frame library required for a basic setup of the canvas is oriented for virtual reality experience. The movement of the camera that views the scene is attached the mouse by default. The clicking function of the mouse is also attached to the centre of the camera, therefore in theory, 3D comments can only be added where the centre of the camera is

14 S.GIANG

facing. Unlike moving a mouse in a desktop screen, the virtual reality interface is not as flexible. Therefore it was decided to use VR-EDGE to serialise Grasshopper geometries into JSON data and reconstructing the data into object model with THREE.JSONLoader. Essentially the viewport will be built with Three.js and not A-frame.

6.1.3. Facilitating

An immediate conclusion for the all the sense-making and background research is as shown in the diagram below.(figure 6)

Figure 6. Facilitating environment

Design Tool Grasshopper 3D, Karamba

Storage Server Flux.io

Web-Application Flux-Javascript

Custom Viewport Editor Three.js


Feedback medium Web-browser

Table 2. Facilitate table

6.2. PROTOTYPING

6.2.1. Serverless prototyping

After understanding the structure of Flux-Javascript-SDK, and the not as favourable interface of A-frame with VR-EDGE, the first prototype of the case study is a web-browser visualisation of Grasshopper geometries exported with VR-EDGE and written with Three.js. (figure7)

Figure 7.Serverless Prototype Tech Diagram

6.2.2. Prototyping with Flux-Javascript-SDK

The continuation of the first prototype should be connecting the custom viewport into the Flux-Javascript-SDK. (figure 8) A method needs to be sought out to reference the JSON files differently. Since the JSON data will no longer be stored in the desktop but rather in the server. Theoretically speaking, parsing the JSON data to the three.js viewport should be feasible as the built-in Flux Viewport is also partially written with three.js.

16 S.GIANG

Figure 8. Flux-Three.js Prototype tech diagram

6.3. SERVERLESS PROTOTYPE

6.3.1. Basic Setup

A three.js scene is constructed with a mother-son interface with HTML and JAVASCRIPT. All Three.js coding are written within the <script> tag. The <script> by default writes in javascript language but Three.js library is not yet accessible until it is referenced. There is two ways of requiring the library, one via node package manager (NPM) and the other is by downloading the source code from GitHub. Source codes referenced with NPM is more compacted compared to the source code from GitHub. For greater flexibility, the case study went with the latter.

<script>var container, camera, scene, renderer

init();animate();

function init() {


container = document.createElement(’div’);document.body.appendChild(container);

camera = new THREE.PerspectiveCamera(70, window.innerWidth / window. innerHeight, 1, 10000};

camera.position.set(0, 10, 25};

scene = new THREE.Scene(); scene.background = new THREE.Color(0x4c4b4b); //grey background

renderer = new THREE.WebGLRenderer();

renderer.setPixelRatio(window.devicePixelRatio); renderer.setSize(window.innerWidth, window.innerHeight); container.appendChild(renderer.domElement);

}

function animate() {requestAnimationFrame(animate);

render();}

function render() { camera.lookAt(scene.position); renderer.render(scene, camera); }</script>

Figure 9.Basic Three.js setup script

The script shown above shows the three.js primitives required to create a basic setup of three.js. There is however no way of navigator through this three.js scene therefore would require an orbit control that either moves the scene around the camera or vice versa.

6.3.2. Rhino Style Viewport

After have a working three.js scene, it still needs to be styled and without any leads, this case study chose to mimic the style of Rhino3D since the design tool for this instance is Grasshopper3D. The scene would include a control that orbits the camera around the scene. That can be achieved with THREE.OrbitControls.

18 S.GIANG

function init() {var controls = new THREE.OrbitControls(camera,

renderer.domElement);}function animate() {

controls.update();}

Figure 10. OrbitControls scriptAfter running the code, it was founded that by clicking left, middle, right

with the mouse, respectively the camera rotates, zooms, pans. With Rhino3D, left and right click is swapped. This case study took it as an opportunity to edit a reference code. Within the three.js source code, a javascript file was found, OrbitControls.js. After the attempt to swap orbiting with panning, the script was re-run and the mouse commands were altered as intended.

A Rhino3D viewport have both axis and grid to help designers identify the XY plane and origin of the scene. This is similar for other design tools hence for consistency, an axis and grid should also be added to the three.js scene.

Figure 11. Basic setup with grid

function init() {gridAxis();

}function gridAxis() { Var axisHelper = new THREE.AxisHelper(14);


Var gridHelper = new THREE.GridHelper(28,140); scene.add(axisHelper); scene.add(gridHelper);}

Figure 11. Basic Setup with grid script

6.3.3. Loading JSON

This case study made an attempt to load geometries created with KARAMBA in Grasshopper3D which is then exported from VR-EDGE as JSON files. After reading the JSON script, the materials exported are MeshPhongMaterials, which will appear black without applying lighting. After lighting was applied, the material appeared grey when it was supposed to be coloured. (figure 12)

Figure 12. Loading Json

6.4. 3D COMMENTING

6.4.1. Raycaster & Sprites

The main purpose of this prototype is to investigate ways of implementing a feedback system. Current BIM practices would use comments on sectioned drawings to provide feedback. Therefore a 3-Dimensional commenting system could be looked into. While investigating through the library of three.js examples, there are several three.js scripts that can interact with objects in 3D space with the 2D positioning of mouse. This is due to the Three.js function, THREE.Raycaster.

The basic setup of a raycaster would require both THREE.Raycaster and THREE.Vector2. Vector2 represents the 2D position of the mouse. Any interactions that want to be implemented with the mouse would require ‘event listeners’.

20 S.GIANG

var raycaster = new THREE.Raycaster();var mouse = new THREE.Vector2();function onMouseMove( event ) {

// calculate mouse position in normalized device coordinates

mouse.x = ( event.clientX / window.innerWidth ) * 2 - 1;

mouse.y = - ( event.clientY / window.innerHeight ) * 2 + 1;}

Figure 13. Raycaster script

One particular script within the directory of three.js examples add a 2D element called ‘sprites’ onto objects in the 3D canvas. A sprite is an invisible 2-Dimensional plane that always faces the camera. Images or SpriteCanvasMaterial(s) can be drawn on this 2D plane, for example, a circle can be drawn with THREE.SpriteCanvasMaterial and applied the THREE.Sprite to have a 2D circle always facing the camera. This compared to adding spheres on to the canvas would require much less memory space hence, reduce the chances of lagging which would slow down the collaboration process.

var PI2 = Math.PI * 2;var spriteMaterial = new THREE.SpriteCanvasMaterial( { color: 0x000000, program: function(context) {Context. beginPath(); context.arc(0,0,0.05,0,PI2, true); context.fill();} } );var sprite = new THREE.Sprite( spriteMaterial );scene.add( sprite );

Figure 14. Sprite scriptAfter learning both raycaster and sprites, both functions can be combined to allow users to add sprites on 3D meshes by mouse clicking.


Figure 15. Add comment sprite

6.4.2. 2D Associative Array

Every time a comment sprite is add on to the canvas, a comment sprite is added to collection of sprites.Each sprite should be able to contain collection of additive messages. Essentially, users should be able to write their feedback on for each individual sprites. Three.js is written in javascript so this research need to first understand how 2D arrays work.(figure 16)

Figure 16. 2D Associative Array Diagram

6.4.3. Appending between HTML and JAVASCRIPT

After understanding the logic of 2D arrays, messages that would be shown on a different canvas in HTML can be connected to three.js 3D canvas. A common methodology to append values, in this instance, messages, would be through jquery.

The second canvas of HTML would contain 3 elements. The text input for name of user, the text area for the input comment and a textarea that holds the list of comments.

22 S.GIANG

Figure 17. Second Canvas

6.4.4. Mouse Handling

The event listener for the raycaster does not differentiate between left, middle and mouse clicks. So far all mouse clicks only add comment sprites. There will be a need to select comment sprites to append comments to the selected sprites. Another option can be deleting sprites for the feedback system to be error-proof.

Figure 18.Mouse diagram


switch (event.which){case 1:

//Add Comment SpriteCase 2:

//Delete Comment SpriteCase 3:

//Select Comment Sprite}

Figure 19. Mouse Handling ScriptAfter implementing a new structure above for event listener, there needs to be another change to show a visual difference between the selected and unselected comment sprites. For this instance, selected sprites are light blue and unselected comment sprites are black.(figure 20)

Figure 20. Mouse Handling

6.5. IMPORTING VIEWPORT TO FLUX

Subsequent to creating the custom viewport in Three.js would be importing it into the Flux-Javascript-SDK. One of the changes that is necessary is that the 2D Associative Array would have to become multidimensional as the loading of JSON data are no longer static. Users are free to select different keys within the flux project which would load different meshes in which would have their own collection of comments and comment sprites.

24 S.GIANG

Figure 21. Flux-Javascript-SDK with Three.js

7. Significance of Research

The purpose of the conducted case study was to facilitate a proof of concept that it is feasible to introduce of an environment curated to replace or improve current practices of design and collaboration. This prototype be much further developed to increase design tool compatibilities and cover a bigger range of benefactors. A limitation of this prototype is the use of only Grasshopper3D as a design tool which limits to be only used by engineers and architects and with computational background. The web-based platform Flux.io, is compatible with not only Grasshopper3D but also other design tools, say, SketchUp and Dynamo. SketchUp for instance, is a prominent design tool used by architects with and without computational background for quick conceptual designing.

Within Grasshopper3D, a physics engine plug-in, Kangaroo, can find and optimize forms with interactive physics constraints. This is another possible tool within Grasshopper3D that can be visualised to expand design possibilities shareable between design contributors. A potential issue is that Kangaroo can animate mesh, however streaming data from design tools to Flux are quick but not real-time. As mentioned before, UDP connections can allow real-time streaming for interactive animations but is not compatible with Flux-Javascript-SDK. Accessing another server to allow sharing files other than information generated with Design tools can allow users to provide feedback with other domains.


8. Evaluation of research project

As an attempt to evaluate the validity of this research; duration of contemporary process of sharing files are compared with the streaming of data in this prototype. The latter process is faster which supports the efficiency of this collaboration environment. Adopting principles suggested by qualitative feedback from Holzer’s work, the prototype includes visual elements to directly allow stakeholders to understand the intention of other contributors.The prototyping process could have been executed more efficiently if when design the custom viewport in Three.js, certain functions could be more well thought out with importing the viewport into Flux-Javascript-SDK in mind. Essentially, the 2D Associative Array could have been replaced with a Multi-Dimensional Array from the start to conserve time spent programming and debugging.

9. Conclusion

This research serves as a proof of concept that it is feasible to design a Flux App to envelop a feedback system to perhaps improve the designing and collaborating of AEC projects.

Literature reviews of mainly Holzer’s paper provided a lot of useful information in terms of evaluating concerns of the early stage of collaboration with the qualitative surveys of engineers. Technical Reviews have also been conducted extensively to understand all possible relevant programs and libraries to the case study.

The prototyping of the case study exists different level of programming difficulties. Attempts have been made to design a feedback system by understanding the capabilities of different programs. Three.js showed great flexibility in manipulating 3D graphical contents hence the greatest achievement of this research is essentially the feedback system that was designed with three.js.

26 S.GIANG

Acknowledgements

Special thanks to the course tutors of Computational Design Graduation Project (Theory and Practice) of UNSW for providing a lot of professional advices. Nicole Gardner and Ben Doherty helped dissipate the ambiguities in this research and corrected several mistakes during the writing of this research. Alessandra Fabri Iain Blampied and Phillip Pham from FJMT have also contributed constructive feedback from the standpoint of Architects in this current AEC industry.

Kyle Maxwell, software engineer of Flux.io have provided significant programming advices. Several Flux applications queries would have been left uncleared without the aid of Kyle.

References

Fette, I. Barth, A. 2011, “The WebSocket protocol, draft-abarth-thewebsocketprotocol-01”, IEFT, Accessed 22 Sep 2017. <https://tools.ietf.org/id/draft-abarth-thewebsocketprotocol-01.html>Flux Cloud Diagram, Parametric Monkey, Accessed 23 Sep 2017, <https://parametricmonkey.files.wordpress.com/2016/06/flux_cloud-diagram_1600x1050.jpg>Holzer, D., 2009. Sense-making across collaborating disciplines in the early stages of architectural design.Kilkelly, M. 2016 "5 Ways Computational Design Will Change the Way You Work" 15 Apr 2016. ArchDaily. Accessed 20 Sep 2017. <http://www.archdaily.com/785602/5-ways-computational-design-will-change-the-way-you-work/>Quanjel, E.M.C.J., 2013. Collaborative design support: workshops to stimulate interaction and knowledge exchange between practitioners. Eindhoven: Technische Universiteit Eindhoven.Rutten, D. 2014, “Grasshopper 2.0, Lecture material for shape to fabrication in London 2014”. Prezi. Accessed 22 Sep 2017. <https://prezi.com/rmgzfqmara3h/grasshopper-20/>

Documents

1. Introduction: Research Motivations - CoDe€¦ · Web viewIntroduction: Research Motivations. Optimising collaboration between all stakeholders regarding Building Information