Synchronizing 3D data between software : Driving 3D collaboration forward using direct links

(1)

Linköpings universitet SE–581 83 Linköping

Linköping University | Department of Computer and Information Science

Master’s thesis, 30 ECTS | Datateknik

2021 | LIU-IDA/LITH-EX-A–21/010—SE

Synchronizing 3D data between

software

–

Driving 3D collaboration forward using direct links

Synkronisering av 3D-data mellan mjukvaror

Carl Brage

Supervisor : Jonas Wallgren Examiner : Cyrille Berger

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

(3)

Abstract

In the area of 3D visualization there are often several stages in the design process. These stages can involve creating a model, applying a texture to the model and creating a rendered image from the model. Some software can handle all stages of the process while some are focused on a single stage to try to perfect and narrow down the service provided. In this case there needs to be a way to transfer 3D data between software in an eﬀicient way where the user experience isn’t lacking. This thesis explores the area of 3D data synchronization by first getting foundation from the prestudy and literature study. The findings from these studies are used in a shared file based implementation and a design of a network based system. The work presented in this thesis forms a comprehensive overview which can be used for future work.

(4)

Acknowledgments

My gratitude goes to Jonas and Cyrille for helping me fix all the errors in this report, and to Configura for giving me a chance at my first programming job. I would also like to thank my family for being there for me and supporting me through these years at Linköping University. A special thank you goes to Erika who was my greatest support during these last times.

(5)

2.2 3D design workflow . . . 3 2.3 3D data representation . . . 4 2.4 Network terminology . . . 5 2.5 3D rendering software . . . 6 3 Method 9 3.1 Prestudy . . . 9 3.2 Literature study . . . 10 3.3 File-based implementation . . . 11 3.4 Network-based system . . . 12 4 Results 13 4.1 Prestudy . . . 13 4.2 Literature study . . . 14 4.3 File-based implementation . . . 21 4.4 Network-based system . . . 27 5 Discussion 32 5.1 Results . . . 32 5.2 Method . . . 34

5.3 The work in a wider context . . . 36

6 Conclusion 37 6.1 What research exists on 3D data sharing between software? . . . 37 6.2 What limitations does an automated file-based import-export workflow have? . 38 6.3 How can a network-based 3D data system be described using existing research? 38

(6)

6.4 Future work . . . 38

(7)

List of Figures

2.1 Internet protocol layers. . . 5

2.2 CET Designer. . . 7

4.1 Stages of 3D modeling. . . 15

4.2 AtomDag node type hierarchy. . . 18

4.3 Structure of the two-way cooperation system. . . 20

4.4 Architecture of the collaborative system. . . 21

4.5 CET Designer extension for the Unreal Engine export. . . 23

4.6 Unreal Engine Auto Reimport settings. . . 24

4.7 Blueprints for importing a FBX file. . . 24

4.8 Basic room created in CET Designer. . . 27

4.9 Architecture of the network-based system for CET Designer. . . 28

4.10 Communication chart for the system. . . 29

(8)

List of Tables

4.1 3D render engine features. . . 13

4.2 Revit export file types. . . 16

4.3 Specifications for computer used during development and testing. . . 25

4.4 Specifications for files used during testing. . . 26

4.5 Import/export times in seconds for the files and software used. . . 26

(9)

1 Introduction

This chapter consists of the introduction of the thesis which gives a background of what we want to achieve and why. It is divided into motivation, aim and research questions with a description of delimitations at the end.

1.1 Motivation

Producing 3D content has been made easier with the introduction of different visualization software. These aim to provide many useful features and a clear UI. Over the years some of these software have made breakthroughs when it comes to producing realistic renderings of objects and scenery. Showing correct shadows, lightings and textures is important to give the viewer an accurate representation of 3D models and scenes. The introduction of features such as virtual reality (VR), augmented reality (AR) and haptic feedback has been a part of bringing another level of realism to the digital world.

Given these higher standards for 3D content companies need to meet the changing demands of customers which are accustomed to seeing the content represented more and more visually correct. Implementing a proper graphics engine which meets these demands requires a large workforce with a deep understanding of 3D rendering. This is not only costly, but it is also unnecessary to have several companies which develop the same features. For this reason it is very common to instead rely on a third-party software to handle the graphics. Exporting the 3D content from a drawing and modelling software to a rendering software can be done in various ways which have different benefits. Allowing for continuous changes to the content while having a quick and easy workflow is crucial for designers using this kind of software. The question is how this can be achieved for companies which produce their own design software and are looking to easily create high quality renders.

This thesis was proposed by Configura which is a company with oﬀices around the world. Configura is one of the leading companies in space planning software. The software (CET Designer) is used in areas such as commercial furniture, material handling, kitchen, bath and industrial machinery. It is built with scalability and modularity in mind with many partners delivering custom extensions and plugins. The aim of the thesis is to find out how some well-known 3D rendering engine can be more loosely integrated into the software while retaining important features. Having photorealistic renderings and real time updates are features which are important in this context. CET Designer already has advanced 3D rendering capabilities.

(10)

1.2. Aim

Using a separate 3D rendering engine to complement the existing software means that more features could be available to the end user. Material editing and ray traced lighting are two features which could be interesting for the users. It could also provide a different UI which the user is more familiar with. CET Designer currently supports many different file formats and Configura is always looking to expand their reach when it comes to exporting and importing 3D content. Being able to export drawings to separate rendering software during the design phase for iterative development is highly interesting for the company. This workflow needs to be simple and fast for the designer. Therefore, Configura wants to research this area further.

1.2 Aim

The aim of this thesis is to find out how companies producing design software can implement systems which allow for fast and eﬀicient export to third-party rendering software. Using existing research and implementations by other companies we will find out how the design import export workflow can be optimized and made as simple as possible to the end user. Different approaches will be evaluated such as a file-based approach and a network-based approach. Implementing the approaches for CET Designer will be done if it is possible within the time constraints.

1.3 Research questions

This thesis aims to answer these research questions:

1. What research exists on 3D data sharing between software?

2. What limitations does an automated file-based import-export workflow have? 3. How can a network-based 3D data system be described using existing research?

1.4 Delimitations

This thesis will be focused on evaluating different solutions for optimizing a 3D import export workflow within the architectural visualization and space planning industry. It will be focused primarily on CET Designer as the design software and picking between some third party rendering software for evaluation. The software used in this thesis will be limited by cost as there is no budget for buying licenses and plugins/extensions. Student licenses can be used if they are available for the software.

(11)

2 Theory

In this chapter, relevant theory is presented to give a good understanding of the underly-ing concepts in this thesis. These concepts have to do with architectural visualization, 3D rendering and metrics used to evaluate the implementation.

2.1 Building Information Modeling

Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility. It allows for creating accurate virtual models of a building by utilizing the shared knowledge resource that is BIM. In a practical sense BIM represents relationships, attributes and geometries in a multi-dimensional model. BIM is a continuation of the CAD software since it can also be used for documentation and maintenance of the building. Software using the BIM standard include Autodesk Revit[5] and Graphisoft ArchiCAD[26].

The file format Industry Foundation Classes (IFC) is often associated with BIM. It is a platform neutral model which is used to describe architectural and construction data. IFC is used to communicate between CAD-software and other software. IFC is developed by the organization buildingSMART. [32]

2.2 3D design workflow

A typical 3D design workflow can be composed of several stages. Different software exist to provide specialization in the areas of modeling, materials, animations, post-processing etc. Being able to transfer 3D data between software is crucial since it allows for collaboration and an easier workflow. Creating a 3D design could consist of creating an initial 2D sketch which is then exported into a 3D modeling software where a 3D model will be built using the sketch. This 3D model can then be exported into a separate software which applies a material onto the model. For the final step the model needs to be rendered and there might be a need to apply post-processing to the final rendered images. In the different steps there is a need to allow for import and export functionality in the collaborating software.[36] There are different file types used for these steps, where DWG can be used for drawings, FBX for 3D models and PNG for rendered images.[38] When you want to automate this workflow you can create a shared 3D file which one software writes to and another one reads from. The receiving software will

(12)

2.3. 3D data representation

then check the file system for any changes to the 3D file. If the file has been altered, it will reimport it and update the generated scene or model.[39] This approach to automating a 3D import-export workflow will be referred to as file-based in this thesis.

There is also an approach which doesn’t use the file system. This approach will be referred to as network-based in this thesis. By setting up protocols for communication and specifying a format the data can be streamed between software. The software involved could be on the same computer or spread out across the world on different computers connected through the internet. There can be a server in the middle of the communication channel which handles the 3D model storage and how the data is sent between the software.[12][30] A more detailed presentation of how these approaches can be used in practice will be in the results chapter.

2.3 3D data representation

This section presents theory about 3D data representation, which includes how the data is stored and how different components are connected. Two main components of 3D data are the geometry and the materials applied to the geometry.

2.3.1 Geometry

The geometry of the model can be defined in different ways. The geometry can be solid, which means that the volume of the object is defined, or a shell/boundary which means that only the surface of the model is defined. How the geometry is represented can depend on how detailed the model needs to be and storage requirements. A mesh representation means that the model is made up of vertices connected by edges to create polygonal shapes. Meshes are used in computer graphics and modeling. 3D point clouds are also used for 3D geometry where sets of three-dimensional coordinates define the envelope of the object. This representation is mostly used when a physical object has been scanned through, for example, photogrammetry. Voxel-based geometries have been used where curves and rounded objects aren’t as important as performance and storage limitations. A voxel can be seen as 3D pixels and are simple cubical units.[42][24]

2.3.2 Materials

The appearance of a 3D model is finalized by applying a material to the geometric data. This material can be represented in different ways, for example a simple image which is mapped to the 3D model. Properties can be applied to the material to achieve a higher photorealism. Properties such as reflection, opacity and roughness of the material can elevate it to the next level.[38] There are different ways of specifying properties of materials, one of them is an approach called Physically Based Rendering.

Physically Based Rendering

Physically Based Rendering, PBR, is an approach to render graphics with the aim to achieve photorealism. PBR tries to model the flow of light in the real world. The implementation of PBR can vary since it doesn’t contain a strict set of rules. PBR is more of a methodology. Physical phenomenon such as absorption and scattering of light on an object are studied to accurately simulate materials. Materials are defined through properties which determine light scattering and absorption. The file formats glTF and glb take advantage of PBR to create realistic 3D-models. [40]

2.3.3 3D file formats

There exist several different 3D file formats which were developed for different purposes. Some of these include obj, FBX and glTF. The sizes and attributes vary in these file formats. glTF

(13)

2.4. Network terminology

stands for Graphics Language Transmission Format and was designed by Khronos Group to transport 3D contents eﬀiciently between networks. The structure or formation of a scene is specified by using JSON. It consists of elements such as scene, nodes, camera and mesh. [34] The FBX file format was developed by Kaydara and is now owned by Autodesk. It is used in software such as 3ds Max[2], Maya[3], Blender[17] and Unreal Engine[23] since it can be used to store animation data. The OBJ file format is developed by Wavefront Technologies and supports geometries in form of vertices/edges/faces and parametric surfaces, vertex normals, textures, material properties and groups. The OBJ file format consists of a number of lines with keys and values.[38]

2.4 Network terminology

Some of the implementations used in various direct links between design software and render-ing software are based on a network approach, for example the Live Link plugin for Unreal engine[23]. This section gives a basic understanding of network terminology and how it works. There are five layers of the Internet protocol suite. Each layer is built upon the layer directly below and uses it to create new services. The layers are, from bottom up, physical layer, link layer, network layer, transport layer and application layer.[33]

HTTP SMTP FTP

TCP UDP

IP Ethernet LTE Optical fiber Coaxial cable

Application Transport Network Link Physical Figure 2.1: Internet protocol layers.

2.4.1 Physical Layer

The physical layer is responsible for transferring bits rather than data packets. Bits are converted to signals and then transferred between nodes in the network. The physical layer refers to the hardware components which can be different types of network cables, routers or switches.

2.4.2 Link Layer

The link layer consists of protocols such as Ethernet and wireless network standards. The basic service of a link layer is to move a frame from one node to another, where a frame consists of a data field and a number of header fields. The link layer also provides reliable delivery, error detection and error correction.

2.4.3 Network Layer

The internet protocol, IP, resides in the network layer. On the network layer packets known as datagrams are transferred between hosts. Packets can vary in size depending on what the

(14)

2.5. 3D rendering software

link layer can handle. The packets can be split up into smaller packets before they are handed over to the link layer. The transport layer uses the network layer in a similar way as you would use the postal service to deliver a letter. An internet transport layer protocol (TCP or UDP) sends a segment and a destination address to the network layer which then delivers this segment to the destination host transport layer.

2.4.4 Transport Layer

The transport layer sends messages between application endpoints. There are two dominating transport protocols on the Internet, TCP and UDP.

TCP stands for Transmission Control Protocol and is a connection-based protocol. A connection is set up between two hosts before any data is sent from the application. TCP guarantees that the sent data will make it to the target by asking for acknowledgments. If no acknowledgment is received from the target after a segment has been sent, the source host will try to resend the segment. TCP makes sure to keep the network from being congested by throttling the transmission rate when necessary. It also breaks long messages into shorter segments.

UDP stands for User Datagram Protocol and is a connectionless protocol. This means that there is less reliability compared to TCP as there is no acknowledgment when a segment is sent. UDP doesn’t provide congestion control and flow control. These features combined means that UDP can be faster but less reliable compared to TCP.

2.4.5 Application Layer

The application layer lies closest to the end-user and includes many protocols such as HTTP and SMTP. The application layer describes how information is to be exchanged, in the case of HTTP it describes the exchange between a web browser and a web server. Data is sent from the application layer to the transport layer which then handles the transmission. The protocols can be seen as the format with which we transfer information.

2.5 3D rendering software

This section lists some of the 3D rendering engines and software commonly used in game development and architectural visualization.

2.5.1 CET Designer

CET Designer is developed by Configura which was founded in Sweden and now has oﬀices around the world. CET stands for Configura Extension Technology and the software is used for space planning and configuration of products. What separates CET Designer from a CAD software is that there are rules defined for the different products which for example prevents a table from being stretched to a width that the manufacturer doesn’t support. Products can be grouped together in a user friendly manner which helps the designer to quickly develop spaces to show a customer. Uses for CET Designer range from kitchen spaces to warehouses and storage. Completed drawings can be rendered in high resolution images or exported in formats such as DWG, FBX, OBJ and IFC to other software. There are also extensions for software like Revit and SketchUp[48]. CET Designer[8] is developed in the language created by Configura called Configura Magic (Cm). An image of what the user sees when working in CET Designer is shown in figure 2.2.

2.5.2 Unreal Engine

Unreal Engine is developed by Epic Games and contains a complete suite of creation tools for different uses across several platforms. Unreal Engine is for example used for game

(15)

develop-2.5. 3D rendering software

Figure 2.2: CET Designer.

ment, architectural visualization and television content creation. It is regularly updated with new features, bug fixes and community contributions. The latest version is Unreal Engine 4 and the fifth generation is scheduled to be released during 2021. Epic Games gives full access to the C++ source code for Unreal Engine 4 on GitHub where contributors can fork and modify the engine. Unreal Engine has a well established forum which allows developers and users to ask questions about features of the engine and associated tools.

The license agreements allow for free use of Unreal Engine 4 for smaller projects. In projects which exceed the $1,000,000 USD gross revenue limit Epic Games takes out a 5% royalty fee. There are also custom licenses which companies can apply for. [23]

In Unreal Engine 4 there is a plugin called Live Link which allows other software to stream data such as motion capture. This plugin can be used to connect software such as Maya and Motionbuilder[4] directly to the Unreal engine. The plugin is free to use and is open-source just like the engine code itself. This allows further development to be done to expand the features of the plugin. [20]

For gathering data from different software in a unified format, Epic Games has devel-oped Datasmith which is a collection of tools and plugins. It is supported by 3ds Max, Cinema4D[37], Revit and IFC. [19]

Twinmotion

Twinmotion is a software used for architectural visualization. It was developed using Unreal Engine and uses BIM or CAD models to create realistic renderings. Unlike Unreal Engine the source code is not available and there is no way to collaborate on the development of Twinmotion. Plugins and features are either added by the developers or in close collaboration with partners such as Autodesk and Trimble

Twinmotion is available through a perpetual license at a retail price of $499 USD, and there is also a free license for students and educators. [22]

2.5.3 Unity

Unity is developed by Unity Technologies and is, like Unreal Engine, a cross-platform engine. Unity has been used in industries such as game development, film, architecture and

(16)

construc-2.5. 3D rendering software

tion. The Unity release cycle is fairly frequent, where versions are gathered into Long-Term Support releases. Unity has shared the C# code that goes into the engine, though it does not allow for modification and contributions in the same way that Unreal does. [43]

There is a different licensing for Unity compared to Unreal Engine, where Unity has opted for a model where companies can buy licenses for each user. The plans vary from $399 USD per year to $200 USD per month depending on the needs of the company. The different plans depend on the revenue of the company using Unity. There is also a free plan if revenue is less than $100,000 USD in the last 12 months or if you are a student. [44]

Unity Reflect is a product which enables visualizing BIM and CAD projects in real-time from software such as Autodesk Revit, SketchUp and Rhino[1]. It is offered at an annual subscription cost of $690 USD, though there is also a free 30-day trial. [46]

2.5.4 Blender

Blender is a free and open source 3D creation suite which supports development on Windows, macOS and Linux. Blender is a community-driven project supported by the Blender foundation and the Blender Institute. Features of Blender include rendering, modeling, sculpting and video editing. Python is used as the internal scripting language for Blender. The majority of the Blender code is in C and C++. [17]

2.5.5 Enscape

Enscape is a plugin which integrates into design software to deliver real-time rendering and virtual reality. The plugin is developed by Enscape GmbH and is marketed towards architects and designers. Support for Enscape integration exists for Revit, SketchUp, Archicad and others. The changes made in the design software are automatically translated to Enscape where the higher quality output is shown.

Licensing for Enscape is based on a similar model as Unity where licenses are bought for individual users or computers. A fixed-seat license which is tied to one fixed machine is listed at approximately $39 USD per month and a floating license which can be shared on multiple machine comes in at $58 USD per month. [25]

2.5.6 Lumion

Lumion is an architectural rendering software created by the Dutch company Act-3D which was founded in 1998. Lumion is focusing on a simple workflow with intuitive tools and features. It is compatible with software such as Autodesk Revit, SketchUp, Rhino and 3ds Max. Lumion has its own plugin called LiveSync for direct syncing with other software. Lumion is not open source and development of plugins is done in-house.

The standard version of Lumion 11 costs €1499 for a single time fee, and the pro version costs €2999. There is also a free student license and a free 14-day public trial license.

(17)

3 Method

In this chapter the method used in the thesis is thoroughly explained to elevate the repro-ducibility. Certain choices and thoughts are presented here to show what steps were taken to reach a conclusion. The method is divided into prestudy, literature study, file-based imple-mentation and a network-based system. Dividing the last two chapters into an impleimple-mentation and a system sketch was a choice made in the middle stage of the thesis. The initial aim of this thesis was to create a fully functional network-based implementation and to test its perfor-mance. As the prestudy and literature study progressed the author found that a network-based implementation would take a considerable amount of time to create. Setting up a server for communicating 3D scene changes between clients and creating plugins would be a large chal-lenge considering the time constraints. There were also some reservations from developers at Configura regarding if multi-threading could be implemented in CET Designer to support that kind of implementation. Discussions between the author and supervisor at Configura led to the method described in the following chapters.

3.1 Prestudy

In the prestudy different rendering software were evaluated to find a possible solution for synchronizing 3D-models from CET Designer. This would lay the foundation for the file-based implementation where the best suited software would be used. A list of possible programs was produced by using search terms such as ”rendering software”, ”architectural visualization software” and ”game engine”. The search engine used was Google1_{and results from the searches} were compiled into a list of software candidates. The results were then filtered through by Configura developers who decided on the final list in section 2.5.

3.1.1 Configura’s constraints

Evaluating the software to find a suitable candidate for implementation was done in several stages. The first stage was to gather constraints that Configura had on the software, these are listed below:

(18)

3.2. Literature study

The software should be well known in the architectural visualization/space planning community.

The first criterion was that the software needed to be well known to designers in the archi-tectural visualization/space planning community. This criterion was evaluated through the searches mentioned earlier. Based on feedback from developers at Configura, the software which was most relevant to the use case was gathered.

It should not cost anything to develop a solution. Meaning there should not be any subscription costs for the software during development.

When it comes to cost of development an important criterion for this software was that it wasn’t going to incur any costs. Since this is only a pilot study to show the capabilities and possibilities of connecting two programs Configura didn’t want to pay for a software license. Having free use of the software for development and testing is a vital part in the selection.

The software should be open source or allow for calls to an API which has the necessary features.

Another criterion that was defined is that there needed to be access to the source code in some way, or to an API which could be used to make the proper function calls. There needed to be support for importing meshes, materials and other 3D model data. Previous work in this area by a thesis [41] performed at Configura proved that this isn’t always trivial. Some software manufacturers make sure that the source code is only open to their own developers or partners to make sure they have a competitive advantage. And even if there is access to an API, it doesn’t always allow the developers full control of importing and exporting 3D model data. Doing a proper investigation before starting development is crucial.

3.1.2 Supported file formats

Another part of the evaluation consisted of researching which file formats the software sup-ported when it comes to importing and exporting 3D content. A large range of supsup-ported file formats means that there are many possibilities when it comes to saving the correct 3D information. Making sure that there are no data losses when exporting a drawing down to a file is crucial for designers. 3D content can be designed and defined differently depending on optimizations, how materials are represented and if there should be any additional information stored. Supported file formats for the different rendering engines were evaluated based on the export capabilities of CET Designer as well as what capabilities other drawing software have in this industry. Theory about different file formats is described in section 2.3.3.

3.2 Literature study

The aim of the literature study was to find out what advances had been made in the area of design workflow optimization. More specifically the aim was to find out how to optimize the import-export workflow where 3D data is sent from one software to another. Papers were found through searches in different databases. The main search engine used was Google Scholar2_{which links to papers on different websites and databases. Access to these databases} was provided by Linköping University and the databases mainly used were IEEE Xplore3_, SpringerLink4_{, ScienceDirect}5_{, ACM Digital Library}6 _{and ResearchGate}7_{. The validity of the}

2_{https://scholar.google.com/} 3_{https://ieeexplore.ieee.org/} 4_{https://www.link.springer.com/} 5_{https://www.sciencedirect.com/} 6_{https://dl.acm.org/} 7_{https://www.researchgate.net/}

(19)

3.3. File-based implementation

papers was evaluated by checking how well cited they were, where the papers were published and who the authors were. Finding additional papers in this area was done by searching for papers with related references and papers released by the same authors. In this way many papers could be traversed to find common denominators which could be used for categorizing the papers in the results chapter.

Search terms used to find papers included ”BIM”, ”streaming”, ”TCP”, ”UDP”, ”mesh”, ”plugin”, ”synchronization” and ”3D”. Searching for different game engines and rendering engines was also done to find specific implementations. The engines used in searches are defined in section 2.5. Likewise file specific implementations were included in the searches as well. The relevant file formats found are defined in section 2.3.3.

3.3 File-based implementation

The implementation of a possible improvement to the import-export workflow consisted of finding a simple solution which could be evaluated and possibly improved upon. There were two suggestions provided by developers at Configura which were either a file-based approach or a network-based approach. The file-based approach meant that the design software would create a file in a format which both software supported. The file was then shared between the programs. The network-based approach meant that the 3D data would be sent between the software by means of a TCP or UDP link. Changes in the model would be directly sent through the link to keep the synchronization between the software. The file-based approach seemed to be the simplest to implement and test. Therefore, the file-based approach was implemented in software whereas the network-based approach consisted of a system sketch based on the literature study. This approach was also suggested to the author of this paper by the developers at Configura since some work had already been done when it comes to supporting many different file formats. The current state of available options was further researched in the literature study and network-based system sections.

3.3.1 Evaluation

The evaluation of the file-based system was done in two phases. In the first phase the corre-lation between different file sizes and the export/import times were examined. This provides information about the limitations of using a file-based system and the differences between software. This first phase was performed using the software listed in section 2.5. Files were gathered through designs by users of CET Designer as well as well as from the 3D library SketchUp[48]. Files varied in size depending on file format and how detailed the models or materials were. Since glTF has shown to be a promising format for 3D models it was going to be used for testing if possible. The prestudy provides more information about the different software and which file formats they support. Important metrics about the models such as number of triangles and vertices can differ based on file type according to a recent study[34]. During the tests a timer started when the export or import button in the software was pressed and stopped when the file had completely loaded into the software or was saved to the file system. The results were compiled for further discussions.

In the second phase the actual implementation was tested. From this phase the aim was to find out if this type of system would be useful and if there were any benefits from using different file formats. Smaller files were used in this stage to enable faster testing and to focus in on how file formats affect performance. The overhead eliminated in the implementation comes from the user navigating to and pressing the import and export buttons as well as locating the file in the file system. Each time a change is made to the scene a new file was generated. The testing in this phase included both the initial loading time of the entire scene and the loading time when a change had been made to a model in the scene.

(20)

3.4. Network-based system

3.4 Network-based system

The network-based system was based on information from the prestudy and literature study. Early discussions with Configura developers resulted in a desire to research how a network-based 3D data transfer system could be sketched up. The system was focused around the CET Designer software and the Configura Magic programming language it is built on. Technologies that were used when developing CET Designer are detailed in the results chapter. Limitations which hinder certain implementations are also discussed. The system lays a foundation for further development and research from the literature study provides a basis for the results that will be achieved from using this kind of implementation.

The motivation behind building a network-based system for transferring 3D data between software is that it gives the users more freedom when designing for example oﬀices. CET Designer can be used to set up all the furniture and get a price estimation in real time as more items are added. CET Designer is also used to get assembly instructions and produce 2D CAD drawings. Exporting the entire graphical scene into a different software such as Unreal Engine or Lumion would allow the users to take advantage of more advanced 3D features such as modifying materials, using real time ray tracing and post processing effects. It would also be possible to collaborate in real time with the same drawing where one user is placing down all the furniture while the other person is placing down decorations such as flowers and paintings. The feedback Configura has received over the years on their software and discussions with developers gathered a list of functionalities the system should have.

1. The system should support two-way communication between software.

2. The system should be scalable and support multiple machines at the same time. 3. The system should be able to send updates in real-time.

Supporting two-way communication means that there is a possibility for manipulating objects on a separate client and having that translate to a change in CET Designer. This could open new possibilities for interacting with objects using tools such as virtual reality. Scalability is an important metric as it allows the system to communicate changes to several users at once. A server would be handling all requests so it won’t affect user performance on either end. Sending updates in real time means that when a change has been made in CET Designer it is translated into a 3D format which can be sent to a client quickly and eﬀiciently.

(21)

4 Results

This chapter presents the results in a similar format as the methods chapter in order to give a clear understanding of the development of ideas. The implementation chapter has been expanded to include a more in-depth explanation of the different components used.

4.1 Prestudy

Information for the prestudy was gathered through oﬀicial websites of the companies which are referenced in section 2.5. This was compiled in table 4.1 which covers the questions and constraints listed in the method chapter.

Software Usage Open source Cost File formats Compatible software for direct link Blender

Game development, architectural visualization, film

Yes Free 3DS, FBX, OBJ,_{PLY, STJ} No oﬀicial links

Enscape Architectural visualization No

Single machine $39 USD, multiple machines $58 USD (per month)

FBX, glTF, OBJ ArchiCAD, Revit, Rhino, SketchUp,_Vectorworks

Lumion Architectural visualization No

Free license for students, €1499 for standard version, €2999 for pro version

3DS, DAE, DWG, DXF, FBX, OBJ, SKP

ArchiCAD, AutoCAD, Revit, Rhino, SketchUp, Vectorworks

Twinmotion Architectural visualization No Free license for students,_{$499 USD perpetual license} 3DS, C4D, FBX,_{OBJ, SKP} ArchiCAD, Revit, Rhine, RikCAD,_SketchUp

Unity

Game development, architectural visualization, film, construction

No

Free license for students, $399 USD per year to $200 USD per month

3DS, DAE, DXF,

FBX, OBJ Navisworks, Revit, Rhino, SketchUp

Unreal Engine

Game development, architectural visualization, television content creation

Yes

Free to develop, 5% royalty fee for project exceeding $1,000,000 USD

FBX, glTF, OBJ Grasshopper, Rhino, SolidWorks

Table 4.1: 3D render engine features.

Table 4.1 shows that when it comes to cost of development for a proof of concept there are a few options which would be viable. Since this is a student project it should be possible to have access to student licenses meaning that Unreal Engine, Twinmotion, Unity, Blender and Lumion could be used. The caveat is that these software might not be open source for development. Only Blender and Unreal Engine are fully open source and would allow for greater modifications. Unity does allow for creating functionality using scripts and you can also create plug-ins.[45]

Through researching the companies’ websites and forums it was found that development of plugins is done in close collaborations between the companies. In a forum thread[28] on

(22)

the Vectorworks website employees mention directly working with Epic Games to provide a Twinmotion plugin. The companies can choose which collaborations they want to focus on and which links they want to allow. A consequence of this can be that it is not possible to implement a direct link or even an indirect link using a file-based approach. In the master thesis paper by Pintar[41] it was found that the limitations in the open Revit API prohibits the possibilities of a live connection to CET Designer.

These constraints and limitations lead to the decision that Unreal Engine would be a good candidate for future development. It supports the file formats FBX and glTF which are both used in CET Designer. In addition, it is open source and will not cost anything to get started. The development will be aided by the well-defined documentation1_{as well as the forum}2_where other developers and users can post questions and answers to problems that arise. In the Unreal Engine marketplace3 _{there are plugins which could be used to avoid creating solutions which} already exist. In the Architectural Visualization Rendering Survey by CGarchitect[7] Unreal Engine is one of the top 5 most popular rendering engines, which shows that there is an interest for using this software. The benefit of Unreal Engine over Blender, which has similar features, is that Configura has experience in using Unreal Engine in the past.

4.2 Literature study

The results from the literature study are presented in this section. There are subsections which deal with different components when it comes to transferring 3D data between software. Searches in the area of 3D data sharing show there are two common approaches[39]. One of them is to use a shared file which both software have access to. When changes are made to the file the software reloads it into memory. Another approach is to use a protocol such as TCP to stream the data between software over a network. This is accomplished by establishing a connection and sending data when a model or drawing has been changed. This approach can also use a cloud-based sharing model, where a file is uploaded to the cloud and thereby made available to other software. More about these approaches will be described below through analyzing related papers which were found through the method described in section 3.2.

4.2.1 File-based approaches

Using a shared file is the simplest approach as it will be built using existing technology. Most software already support exporting and importing files in different file formats. The important part is finding a file format which is optimal for both software and having a file path which both can access. This section investigates how this approach can be used to automate and improve the import and export workflow.

Industrial 3D importing

With the purpose of defining the 3D modeling workflow Tran Thi wrote a thesis paper[47] at Helsinki Metropolia University. The thesis deals with the workflow of converting 3D models between CAD software and 3ds Max. As a collaboration between Helsinki Metropolia Uni-versity of Applied Sciences and the ship-design company Deltamarin the problem faced was exporting a 3D model of a ship design from a CAD software to 3ds Max. Tran Thi defined the 3D modeling stages as consisting of importing, set-up, modeling, texturing and render-ing. These stages are shown in figure 4.1. The thesis covers all these stages to give a deeper understanding of the complete workflow.

Tran Thi came across problems with polygon breaking, overlapping, and duplicates when exporting and importing models. Polygon breaking refers to issues where the receiving software

1_{https://docs.unrealengine.com/} 2_{https://forums.unrealengine.com/}

(23)

Importing Set-up Modeling Texturing Rendering

Figure 4.1: Stages of 3D modeling.

cannot interpret parts of the model. An example of this could be a rounded object which is defined in an unusual way. Overlapping means that objects have overlapping layers which cause graphical bugs. Duplicates are copies of objects which are cloned on top of each other. These issues were able to be fixed through various tools in the software. What Tran Thi learned from this work is that the 3D models need to be properly prepared before being imported to other software. Problems often occur in these workflows and depending on the software used there can be different issues and bugs that appear.

CAD to VR workflow automation

In the paper by Engberg and Eriksson [14] the pipeline between CAD software and virtual reality is the focus of exploration. They identified a need in the manufacturing industry of visualizing assembly sequences in virtual reality to get a better sense of scale. The application they developed is based on Unreal Engine and they outline some of the features which could be useful to their implementation. One of the features is Datasmith which is a collection of tools that can be used to import CAD assets. Using Datasmith also allows developers to use a reimport workflow where CAD models are automatically reimported when the source program has been changed. Unreal Engine also allows for prepping data before it is imported into the editor. This is done either through the use of the visual scripting system called Blueprints or by using C++. Engberg and Eriksson explain the various uses of VR in education and engineering through their literature study. They showed that this is an area of great interest and potential and that there have historically been great diﬀiculties in moving CAD data between software. This is also shown in the paper as there are struggles when they import the CAD file to Unreal Engine. Naming conventions for meshes and other assets differ between the software. In the implementation they say that Autodesk Fusion 360 has been used to design and export the CAD files. This leads to the authors having to create a pipeline for renaming assets according to their specifications. There were also problems with origin points for assets which was fixed in a similar way. For the authors it was important to be able to also include part data in the CAD files. This means that the implementation needs to support additional information for components such as size and amount. This also needs custom fixes and implementations as this is a customer specific request. The result was an implementation which was tested and evaluated for usability metrics. It was shown to be working with some flaws; there were still some manual configurations required as the system was not completely automatic. The authors explain that many of the problems are due to limitation in Unreal Engine where they were unable to make runtime import work. It is not a feature which is directly available. Some development is needed but it is also possible to use plugins from the marketplace. It seems you need to understand how Unreal Engine works and the API on a deeper level to be able to create custom import export workflows. The differences in how Unreal Engine interprets CAD data compared to the other software used (Creo, Fusion 360 and Siemens NX) was also a hindrance to the implementation. For future studies the authors mention that it would be interesting to revisit this area after more functionality has been added to Unreal Engine. They would also like to evaluate different file formats.

(24)

Integrating a 3D building model for real-time visualization

Displaying 3D models through immersive technology can be used in many different industries. Presenting a building using a 360-degree immersive display was the foundation of the work done in the paper by Fält [15]. The background of the paper was to investigate how Norrköping Visualization Center could use their 360-degree display to provide services to companies and schools where they can visualize and interact with 3D models of buildings. The software used include 3D Studio Max (3ds Max), Revit and Unity 5. Fält found issues with importing 3D data to a game engine. The file format .rvt which is used by Revit is not supported by Unity which means that a conversion to FBX is needed. The file then needed to be imported into 3D Studio Max where a texture is applied before it could be imported into Unity. Fält found that automating the application of textures to the model could be done using different approaches, but rendering the textures still takes a long time. The conclusion he found is that you need to have an intimate understanding of how the software work to implement a fully functional pipeline. There are settings and features which can differ between two software which causes problems when importing and exporting. Fält found that the model would look significantly different in Revit, 3D Studio Max and Unity 5 even though the same model and textures were used. He did not focus on lighting in the different software as these can be very different and there would need to be some tinkering with settings to get the same results throughout the software. Fält suggested that this could be the basis for the next thesis in this area. He stated that it would also be interesting to evaluate using more models as he only used one building model in his evaluation. He also stated that using 3D Studio Max directly with different rendering software could prove to be more effective, thereby skipping Revit since it caused issues.

Building information models in game engines

The paper[6] by Bille et al. is focused on visualizing buildings using game engines. The authors explain that the purpose of reusing building plans and models in a 3D interactive virtual environment is to aid model refinement and for use in training environments. To show virtual models of oil refineries, production platforms, nuclear power plants and buildings during the construction phase provides a safe and comprehensive experience. The limitation of the BIM model is that it doesn’t provide an interactive environment. It is rather an accurate description of the building and its components. The authors are proposing a move to game engines to provide the interactive 3D environment using BIM data. Their paper focused a bit on related research and found that there have been a few papers about using BIM for game engines. There are often middle steps involved when exporting and importing models where texture mapping and metadata is applied. There can also be problems when models are updated as the link between the model and alterations to the model are severed due to a reimport and rebuild. The FBX file format is often used, and it is also chosen in this project. The authors created a list of properties for the Revit export file types which can be seen in table 4.2

File-type Geometric data Metadata

FBX Yes No

DWG Yes No

OBJ Yes No

DWF/DWFx Yes Partial

NWC Yes Yes

ODBC Yes Yes

gbXML Yes Partial

IFC Yes Partial

(25)

Bille et al. found, like Fält [15], that there needs to be an intermediate step between Revit and Unity since the textures and colors do not transfer. They used 3ds Max with the AMC (Autodesk Material Converter) script to export an FBX file which contained all the correct components. Since FBX doesn’t contain any metadata it would be provided through a separate database. The authors noted a few improvements which could be done. One of them is that if you structure the data correctly it is possible to run automated scripts which attach dynamic events to certain objects in the BIM. One example of this is having a door opening animation. Since the 3D model will have collisions enabled the player won’t be able to enter the building. The conclusion of the paper is that they identified some pipelines from BIM to game engines which could be useful for future research. They also noted that custom tools can be created to be used in the game engines for measuring and interacting with the building structures which provides additional functionality to the users. A conclusion is that game engines provide possibilities for using BIM on many different platforms and further research should be done on which platform would be best suited for virtual demonstrations and skills training.

4.2.2 Network-based approaches

A different approach compared to using a shared file is streaming the 3D data between software through a network. Sometimes the data is sent with a server acting as a mediator. The server could be cloud-based or running locally on the user’s computer. Implementations can be achieved by using different protocols and libraries which will be demonstrated in the papers that have been selected in this study.

Atom: real-time networked streaming of 3D scenes

In the paper[27] by Green the problem of pipeline eﬀiciency is tackled using networked stream-ing of 3D scenes. The focus of the paper is the video game industry where it is common that several different software are used. It is helpful to get quick feedback of how a model will look in the final game even though the designer is working in a different software. Autodesk Maya is referenced as an example. To bypass obnoxious exporting steps every time a preview is desired is a goal for the implementation referenced in the paper. Green mentions that there are solutions which reduce the pipeline stages for iterative development, though the flaw is that the visualizations are localized. Having remote visualizations means that you can preview a scene on a tablet device while the designer is modifying it from a workstation elsewhere. The proposed solution is a plugin for Autodesk Maya which acts as a server which streams data to networked clients. The plugin should be standalone and not restricted to specific third-party client applications. A client could for example be a custom game engine. Green sent out a short survey before the development to find out which components of the product that were considered most important. The survey was sent to 20 people who were artists, programmers or technical artists. Results from the survey showed that speed of data transfer was more important than ease-of-use of the API. The most important data was geometry, materials, lights and rigging. The final product is a plugin called Atom which acts as an interface into scene data similar to the observer design pattern. Green also created a client for development and documentation purposes. The implementation is built on Boost Asio which is a cross-platform C++ library that can be used for networking. Asio was chosen due to ”its superior asynchronous capabilities and widespread usage”. Messages sent by atom are serialized using Google’s Protocol Buffers library. A message sent by Atom consists of a 32-bit signed integer denoting the size of the data followed by the raw data itself. When a server instance is started it will continuously listen to new connection requests. When a connection has been made the client can send a request to the server to send data. The implementation supports multiple threads and multiple connected clients. It is built on TCP since UDP is less reliable even though it would be faster. The data is structured as displayed in figure 4.2.

(26)

Node

Annotation Camera Curve Light Material Mesh Texture Utility Xform

Figure 4.2: AtomDag node type hierarchy.

The nodes in the figure represent different Maya classes. The Mesh node is a representation of the Maya MFnMesh class. The base node called Node contains all essential data for an element in the scene. When Atom was completed the author sent out a feedback survey to artists and programmers to find out the usefulness of Atom. The survey showed that almost all participants thought it was useful if a client could be implemented in their desired game engine or rendering software. The participants also stated that it would reduce the number of steps required for artists to preview their work with in-game visuals during development. Most participants said that Atom would be most suitable for single-object previews, though it does support entire scenes. There was a desire to be able to use Atom for animations. This could be an area for improvement in the future. Since Atom is an API it could be extended at a later stage and there are endless possibilities of using this in combination with third-party software.

Synchronizing BIM data to VR

The architecture, engineering and construction industries have witnessed a steady increase in interest for VR to improve existing work processes. Allowing users to interact with digital objects in real time can lead to new discoveries of flaws and strengths in the processes. En-hancing the process of converting BIM data to VR is the purpose of the paper[12] by Du et al. Converting BIM data to VR displays, such as the HTC Vive headset, has proven to be diﬀi-cult. It starts with an established design built on traditional platforms such as CAD or BIM. The design models are converted into VR displays instead of built from the ground up using game engines. The authors have identified problems with this convertion process. Firstly, the design-to-VR process is time consuming. It could involve rendering a finished BIM model, such as a Revit file, in a third-party graphics program such as 3D Studio Max to FBX format. The file is then transferred into Unity for VR programming and the entire process could take hours to days to complete. Secondly the process doesn’t support real time data synchroniza-tion. Changes are very common, and it is important that feedback is done in a timely manner to avoid high costs later. Having fast feedback loops means that problems can be fixed at an early stage. Thirdly data integrity is diﬀicult to maintain in the present Design-to-VR method with frequent changes. Data needs to be synchronized between many parties and the system should support a variety of formats and different platforms. Du et al. have researched this area extensively and came to the conclusion that many solutions are at a conceptual level and do not show a complete implementation using real software. Studies have also shown that exporting BIM is not straightforward. The problems that occur can vary depending on the environment used. The authors sought to develop an innovative data transfer protocol called BVRS (BIM-VR Real-time synchronization) to solve the problems mentioned before. BVRS uses a cloud-based infrastructure where the middle layer between two software consists of a database. Objects are stored in the database and are identified using an ElementID which is generated using the FBX file format. The database contains information about the

(27)

po-4.2. Literature study

sition, material, model and other metadata. The same structure is then created within the game engine to ensure that the database elements correspond to internal elements in the game engine. Revit is used in this implementation for creating the CAD models and the authors mention both Unity and Unreal Engine as candidates for game engines that could be used for displaying the scene in VR. Changes in Revit will result in a request to the cloud server. The relevant data will be changed and marked. The game engine then scans over all ElementIDs dynamically and examines if changes are discovered. If any changes are found they are used to change the visualization. The reverse process can also be implemented where changes in the game engine are sent to the database, though this is not currently implemented. The authors have focused on four major areas to create a real-time BIM data updating function: Model transfer and refinement, user interface design, cloud server connections and player controller function development. Model transfer and refinement refers to optimizing the response time of the application and database as well as providing the best possible graphical experience for the user. Setting a limiting texture size as well as reusing the same texture for different models means that there will be fewer data packets sent. Occlusion culling is used to optimize the performance in VR. It disables rendering of objects when they are not seen by the camera. The introduction of advanced lighting and shadows provide a more immersive experience for the user. These features are most commonly found in game engines and not in CAD software. The implementation is heavily dependent on cloud server connection optimization. Sending the entire BIM project when the VR application makes a request can be very resource de-manding when the project gets large. The elements are instead tagged when changes have been made to them. Only tagged elements are sent to the application when a request has been made. Hash tables are used to store ElementIDs and properties and searching for properties is done in constant time for a given ID. The application goes through the elements’ updated properties and updates the model. User interface design and player controller function devel-opment refers to how the user traverses and views the 3D scene which isn’t interesting in the context of this literature study. Results from user tests show that real time synchronization of BIM data in VR is possible for different scenarios. BVRS reduced data processing and transmission delays compared to the example system irisVR which took 10s to see a design change whereas BVRS was almost real-time. For the future the authors have found that there needs to be improved efficiency for complex models. For a large number of interdependent objects the synchronization is affected since it needs to dynamically monitor changes to every object. There is a large search/scanning process every time data is accessed and requested. Using ElementIDs as search key seems not to be the most efficient approach according to the authors. Other tree based search algorithms will be examined in the future to improve search efficiency.

Two-way cooperation of 3D data in game engines

For collaborations using 3D data it can be useful to establish a two-way communications channel where modifications can be made to the model or scene on both sides. Kado and Hirasawa presented such a system in their paper[30]. The authors explain that the use of a file-based data coordination proves to be a tedious process which is not suited for the cyclic design and visualization process. Their proposed system has a mesh-based representation in a VR application with smooth transmission and reception. It also allows the user to edit elements that have parametric behaviors and geometrical interactions. As opposed to the system presented by Du et al. [12] the system by Kado and Hirasawa is not limited to updating element locations and modifying element types. The implementation in this thesis uses ArchiCAD 20 as the 3D CAD software which sends information to Unreal Engine 4 using a relay database based on PostgreSQL. The collaborative system consists of the following steps. First 3D data is sent from the 3D CAD software to the database where it is stored. Then the VR application checks the database for any updates and loads them. Lastly the new data is processed and visualized in the VR application. Since there is a two-way connection there

(28)

are also steps in the opposite direction where changes to the model can be made in the VR applications. These changes are then stored in the database and they will be reflected in the 3D CAD software. The structure can be seen in figure 4.3.

ArchiCAD 20 Unreal Engine 4

3D model API VR scene Blue Print API PostgreSQL

Figure 4.3: Structure of the two-way cooperation system.

The implementation supports both a geometric mesh-based representation and a parametric-based representation. The reason for this is that the conversion between the two representations can be costly as you need to implement complex algorithms. The parametric-based representation is needed to be able to modify the 3D model using the VR application. Changes to the parameters are sent to the 3D CAD software which computes and creates the corresponding mesh. Measures were taken by the authors to handle meshes eﬀiciently by the use of a delta update function. The delta update function makes sure that only necessary operations to the database are performed. When a duplicate chair is added to the 3D scene there isn’t a need to send and store the same mesh twice since it can be reused. When a chair is moved only the position is updated and the entire mesh isn’t sent again to the database. A hash function determines if the mesh has been altered in any way. Using the system on a 3D model comprised of 685 elements and more than 87,000 polygons showed promising results where the VR editing function could be used to modify the geometry of a window. By using parametric data the geometry of the wall was also changed to accommodate the smaller hole needed to house the window. Updating accompanying geometries resulted in several second delays which is an area of future improvement by the authors. The authors plan to implement similar systems in with other architectural 3D CAD software and game engines to further explore the possibilities of using game engines as interface of BIM data.

Collaboration and interaction with BIM data

The paper[13] by Edwards et al. tries to address the issue of professional designers not being able to effectively interact and collaborate with users or clients on a functional level. The end users want to be able to explore and interact with buildings and models to give constructive feedback during the development process. The authors propose the use of a game engine com-bined with BIM to solve this problem. They have identified some uses of game engines in the AEC (Architecture/Engineering/Construction) and FM (Facilities Management) industries. These include simulating the evacuation of the population of a building, providing interac-tive visualization of a structure, and teaching students about construction site safety. The system described has a multi-layered architecture consisting of a BIM environment, a data transmission element, a game engine environment and a client end. The BIM environment is based on Autodesk Revit which provides building information as well as an API to access that information. Revit was selected since it was fully compatible with BIM standards and has good third-party support. This environment communicates with the data transmission element which contains the database and FBX converter. It generates semantic and geometric data and stores it in the database which has a two-way connection with the server game which is a part of the Game Engine environment. The Game Engine environment consists of a Unity

(29)

4.3. File-based implementation

game component which feeds data into available clients which have connected through an IP address. Unity was chosen since it has a simple object orientated and editor-based design system. You can create executables which run on Windows and Mac. You can also create web player versions of games. At the client end, end-users and designers can interact with the models via the Unity game engine. Many different input and output devices are supported such as Windows and Mac operating systems that use monitors with keyboard and mouse, mobile platform using iOS or Android with touch screen or Web-based environments that allow the user to connect to the server through their web browser. The figure 4.4 shows all the components and how they interact with each other.

BIM environment Data transmission element Client end Game Engine environment User/Designer Unity Game

Client Game Server Game

Game Collaboration Plug-in Autodesk FBX converter `Micro´ Web-Server

Revit API Revit Main

Application Network

Revit

Figure 4.4: Architecture of the collaborative system.

The system starts up by executing the plugin which exports the BIM data to the FBX format. It is then converted to the OBJ format which can be sent to the server gane instance when a request is made. The server game instance can also request parametric properties which are sent separately. When a game client has connected to the server game it can request the model and parametric data from the server. When objects are modified in the client the data is sent back to the server which sends objects to the plugin. The authors found that there were some issues with sending back data to the plugin which could be a topic for future improvements. The separation of model and parametric data was also an issue since it didn’t provide an elegant solution. Using the IFC format would allow storing both geometric data and parametric data in the same format which is something that isn’t supported in the OBJ format. A technical improvement the authors identified was to implement Universal Plug and Play (UPnP) to reduce the user configuration by allowing programs to negotiate with a firewall in a network.

4.3 File-based implementation

The implementation of the shared file system consists of the exporting software CET Designer and the rendering software Unreal Engine. How they connect to each other and the technologies used are explained in this section.