Synchronizing 3D data between software

Linköpings universitetSE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer and Information ScienceMaster’s thesis, 30 ECTS | Datateknik

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

Synchronizing 3D data betweensoftware– Driving 3D collaboration forward using direct links

Synkronisering av 3D-data mellan mjukvaror

Carl Brage

Supervisor : Jonas WallgrenExaminer : Cyrille Berger

http://www.liu.se

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 annananvändning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning somgod 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 hemsidahttp://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for aperiod 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-commercialresearch 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 publisherhas taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to bementionedwhen his/her workis accessed as described above and to be protected against infringement.

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

© Carl Brage

http://www.ep.liu.se/

http://www.ep.liu.se/

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 arendered image from the model. Some software can handle all stages of the process whilesome 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 efficientway where the user experience isn’t lacking. This thesis explores the area of 3D datasynchronization by first getting foundation from the prestudy and literature study. Thefindings from these studies are used in a shared file based implementation and a designof a network based system. The work presented in this thesis forms a comprehensiveoverview which can be used for future work.

Acknowledgments

My gratitude goes to Jonas and Cyrille for helping me fix all the errors in this report, and toConfigura for giving me a chance at my first programming job. I would also like to thank myfamily 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.

iv

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables viii

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 32.1 Building Information Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 3D design workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 3D data representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Network terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5 3D rendering software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Method 93.1 Prestudy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 File-based implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Network-based system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Results 134.1 Prestudy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 File-based implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Network-based system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Discussion 325.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 The work in a wider context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

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

v

6.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Bibliography 40

vi

List of Figures

2.1 Internet protocol layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 CET Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1 Stages of 3D modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 AtomDag node type hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Structure of the two-way cooperation system. . . . . . . . . . . . . . . . . . . . . . . . 204.4 Architecture of the collaborative system. . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 CET Designer extension for the Unreal Engine export. . . . . . . . . . . . . . . . . . 234.6 Unreal Engine Auto Reimport settings. . . . . . . . . . . . . . . . . . . . . . . . . . . 244.7 Blueprints for importing a FBX file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.8 Basic room created in CET Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.9 Architecture of the network-based system for CET Designer. . . . . . . . . . . . . . . 284.10 Communication chart for the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.11 Format for the network design data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

vii

List of Tables

4.1 3D render engine features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Revit export file types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Specifications for computer used during development and testing. . . . . . . . . . . . 254.4 Specifications for files used during testing. . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 Import/export times in seconds for the files and software used. . . . . . . . . . . . . 264.6 Testing the implementation with FBX and glTF file. . . . . . . . . . . . . . . . . . . 27

viii

1 Introduction

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

1.1 Motivation

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

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

This thesis was proposed by Configura which is a company with offices around the world.Configura is one of the leading companies in space planning software. The software (CETDesigner) is used in areas such as commercial furniture, material handling, kitchen, bath andindustrial machinery. It is built with scalability and modularity in mind with many partnersdelivering 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 retainingimportant features. Having photorealistic renderings and real time updates are features whichare important in this context. CET Designer already has advanced 3D rendering capabilities.

1

1.2. Aim

Using a separate 3D rendering engine to complement the existing software means that morefeatures could be available to the end user. Material editing and ray traced lighting are twofeatures which could be interesting for the users. It could also provide a different UI which theuser is more familiar with. CET Designer currently supports many different file formats andConfigura is always looking to expand their reach when it comes to exporting and importing3D content. Being able to export drawings to separate rendering software during the designphase for iterative development is highly interesting for the company. This workflow needs tobe 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 implementsystems which allow for fast and efficient export to third-party rendering software. Usingexisting research and implementations by other companies we will find out how the designimport 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-basedapproach. Implementing the approaches for CET Designer will be done if it is possible withinthe 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 exportworkflow within the architectural visualization and space planning industry. It will be focusedprimarily on CET Designer as the design software and picking between some third partyrendering software for evaluation. The software used in this thesis will be limited by cost asthere is no budget for buying licenses and plugins/extensions. Student licenses can be used ifthey are available for the software.

2

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, 3Drendering and metrics used to evaluate the implementation.

2.1 Building Information Modeling

Building Information Modeling (BIM) is a digital representation of physical and functionalcharacteristics of a facility. It allows for creating accurate virtual models of a building byutilizing the shared knowledge resource that is BIM. In a practical sense BIM representsrelationships, attributes and geometries in a multi-dimensional model. BIM is a continuation ofthe 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 aplatform neutral model which is used to describe architectural and construction data. IFCis used to communicate between CAD-software and other software. IFC is developed by theorganization buildingSMART. [32]

2.2 3D design workflow

A typical 3D design workflow can be composed of several stages. Different software exist toprovide 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 andan easier workflow. Creating a 3D design could consist of creating an initial 2D sketch whichis 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 themodel. For the final step the model needs to be rendered and there might be a need to applypost-processing to the final rendered images. In the different steps there is a need to allow forimport and export functionality in the collaborating software.[36] There are different file typesused for these steps, where DWG can be used for drawings, FBX for 3D models and PNGfor rendered images.[38] When you want to automate this workflow you can create a shared3D file which one software writes to and another one reads from. The receiving software will

3

2.3. 3D data representation

then check the file system for any changes to the 3D file. If the file has been altered, it willreimport it and update the generated scene or model.[39] This approach to automating a 3Dimport-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 referredto as network-based in this thesis. By setting up protocols for communication and specifyinga format the data can be streamed between software. The software involved could be on thesame computer or spread out across the world on different computers connected through theinternet. There can be a server in the middle of the communication channel which handlesthe 3D model storage and how the data is sent between the software.[12][30] A more detailedpresentation 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 isstored and how different components are connected. Two main components of 3D data arethe geometry and the materials applied to the geometry.

2.3.1 GeometryThe geometry of the model can be defined in different ways. The geometry can be solid, whichmeans that the volume of the object is defined, or a shell/boundary which means that onlythe surface of the model is defined. How the geometry is represented can depend on howdetailed the model needs to be and storage requirements. A mesh representation means thatthe model is made up of vertices connected by edges to create polygonal shapes. Meshes areused in computer graphics and modeling. 3D point clouds are also used for 3D geometry wheresets of three-dimensional coordinates define the envelope of the object. This representation ismostly 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 importantas performance and storage limitations. A voxel can be seen as 3D pixels and are simplecubical units.[42][24]

2.3.2 MaterialsThe appearance of a 3D model is finalized by applying a material to the geometric data. Thismaterial can be represented in different ways, for example a simple image which is mappedto 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 nextlevel.[38] There are different ways of specifying properties of materials, one of them is anapproach called Physically Based Rendering.

Physically Based Rendering

Physically Based Rendering, PBR, is an approach to render graphics with the aim to achievephotorealism. PBR tries to model the flow of light in the real world. The implementation ofPBR 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 toaccurately simulate materials. Materials are defined through properties which determine lightscattering and absorption. The file formats glTF and glb take advantage of PBR to createrealistic 3D-models. [40]

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

4

2.4. Network terminology

stands for Graphics Language Transmission Format and was designed by Khronos Group totransport 3D contents efficiently between networks. The structure or formation of a scene isspecified 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 insoftware such as 3ds Max[2], Maya[3], Blender[17] and Unreal Engine[23] since it can be usedto store animation data. The OBJ file format is developed by Wavefront Technologies andsupports 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 lineswith 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 Unrealengine[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 directlybelow and uses it to create new services. The layers are, from bottom up, physical layer, linklayer, 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 LayerThe physical layer is responsible for transferring bits rather than data packets. Bits areconverted to signals and then transferred between nodes in the network. The physical layerrefers to the hardware components which can be different types of network cables, routers orswitches.

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

2.4.3 Network LayerThe internet protocol, IP, resides in the network layer. On the network layer packets knownas datagrams are transferred between hosts. Packets can vary in size depending on what the

5

2.5. 3D rendering software

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

2.4.4 Transport LayerThe transport layer sends messages between application endpoints. There are two dominatingtransport protocols on the Internet, TCP and UDP.

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

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

2.4.5 Application LayerThe application layer lies closest to the end-user and includes many protocols such as HTTPand SMTP. The application layer describes how information is to be exchanged, in the caseof HTTP it describes the exchange between a web browser and a web server. Data is sentfrom the application layer to the transport layer which then handles the transmission. Theprotocols 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 gamedevelopment and architectural visualization.

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

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

6


Figure 2.2: CET Designer.

ment, architectural visualization and television content creation. It is regularly updated withnew features, bug fixes and community contributions. The latest version is Unreal Engine 4and the fifth generation is scheduled to be released during 2021. Epic Games gives full accessto the C++ source code for Unreal Engine 4 on GitHub where contributors can fork andmodify the engine. Unreal Engine has a well established forum which allows developers andusers 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 projectswhich 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 streamdata such as motion capture. This plugin can be used to connect software such as Maya andMotionbuilder[4] directly to the Unreal engine. The plugin is free to use and is open-sourcejust like the engine code itself. This allows further development to be done to expand thefeatures 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 UnrealEngine and uses BIM or CAD models to create realistic renderings. Unlike Unreal Enginethe source code is not available and there is no way to collaborate on the development ofTwinmotion. Plugins and features are either added by the developers or in close collaborationwith partners such as Autodesk and Trimble

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

2.5.3 UnityUnity 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 construc-

7


tion. The Unity release cycle is fairly frequent, where versions are gathered into Long-TermSupport releases. Unity has shared the C# code that goes into the engine, though it does notallow 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 optedfor a model where companies can buy licenses for each user. The plans vary from $399 USDper year to $200 USD per month depending on the needs of the company. The different plansdepend on the revenue of the company using Unity. There is also a free plan if revenue is lessthan $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-timefrom software such as Autodesk Revit, SketchUp and Rhino[1]. It is offered at an annualsubscription cost of $690 USD, though there is also a free 30-day trial. [46]

2.5.4 BlenderBlender 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 foundationand the Blender Institute. Features of Blender include rendering, modeling, sculpting andvideo editing. Python is used as the internal scripting language for Blender. The majority ofthe Blender code is in C and C++. [17]

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

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

2.5.6 LumionLumion is an architectural rendering software created by the Dutch company Act-3D whichwas 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. Lumionhas its own plugin called LiveSync for direct syncing with other software. Lumion is not opensource and development of plugins is done in-house.

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

8

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 toreach 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 implementationand a system sketch was a choice made in the middle stage of the thesis. The initial aim of thisthesis 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-basedimplementation would take a considerable amount of time to create. Setting up a server forcommunicating 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 atConfigura regarding if multi-threading could be implemented in CET Designer to support thatkind of implementation. Discussions between the author and supervisor at Configura led tothe method described in the following chapters.

3.1 Prestudy

In the prestudy different rendering software were evaluated to find a possible solution forsynchronizing 3D-models from CET Designer. This would lay the foundation for the file-basedimplementation where the best suited software would be used. A list of possible programswas produced by using search terms such as ”rendering software”, ”architectural visualizationsoftware” and ”game engine”. The search engine used was Google1 and results from the searcheswere compiled into a list of software candidates. The results were then filtered through byConfigura developers who decided on the final list in section 2.5.

3.1.1 Configura’s constraintsEvaluating the software to find a suitable candidate for implementation was done in severalstages. The first stage was to gather constraints that Configura had on the software, these arelisted below:

1https://www.google.com/

9

3.2. Literature study

The software should be well known in the architectural visualization/spaceplanning 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 thesearches mentioned earlier. Based on feedback from developers at Configura, the softwarewhich was most relevant to the use case was gathered.

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

When it comes to cost of development an important criterion for this software was that itwasn’t going to incur any costs. Since this is only a pilot study to show the capabilities andpossibilities 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 thenecessary features.

Another criterion that was defined is that there needed to be access to the source code in someway, or to an API which could be used to make the proper function calls. There needed to besupport for importing meshes, materials and other 3D model data. Previous work in this areaby a thesis [41] performed at Configura proved that this isn’t always trivial. Some softwaremanufacturers make sure that the source code is only open to their own developers or partnersto make sure they have a competitive advantage. And even if there is access to an API, itdoesn’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 formatsAnother 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 supportedfile formats means that there are many possibilities when it comes to saving the correct 3Dinformation. Making sure that there are no data losses when exporting a drawing down to afile is crucial for designers. 3D content can be designed and defined differently depending onoptimizations, how materials are represented and if there should be any additional informationstored. Supported file formats for the different rendering engines were evaluated based on theexport capabilities of CET Designer as well as what capabilities other drawing software havein 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 areaof design workflow optimization. More specifically the aim was to find out how to optimizethe import-export workflow where 3D data is sent from one software to another. Paperswere found through searches in different databases. The main search engine used was GoogleScholar2 which links to papers on different websites and databases. Access to these databaseswas provided by Linköping University and the databases mainly used were IEEE Xplore3,SpringerLink4, ScienceDirect5, ACM Digital Library6 and ResearchGate7. The validity of the

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

10

3.3. File-based implementation

papers was evaluated by checking how well cited they were, where the papers were publishedand who the authors were. Finding additional papers in this area was done by searching forpapers with related references and papers released by the same authors. In this way manypapers could be traversed to find common denominators which could be used for categorizingthe 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 renderingengines was also done to find specific implementations. The engines used in searches aredefined in section 2.5. Likewise file specific implementations were included in the searches aswell. 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 offinding a simple solution which could be evaluated and possibly improved upon. There weretwo suggestions provided by developers at Configura which were either a file-based approachor a network-based approach. The file-based approach meant that the design software wouldcreate a file in a format which both software supported. The file was then shared betweenthe programs. The network-based approach meant that the 3D data would be sent betweenthe software by means of a TCP or UDP link. Changes in the model would be directly sentthrough the link to keep the synchronization between the software. The file-based approachseemed to be the simplest to implement and test. Therefore, the file-based approach wasimplemented in software whereas the network-based approach consisted of a system sketchbased on the literature study. This approach was also suggested to the author of this paperby the developers at Configura since some work had already been done when it comes tosupporting many different file formats. The current state of available options was furtherresearched in the literature study and network-based system sections.

3.3.1 EvaluationThe 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 providesinformation about the limitations of using a file-based system and the differences betweensoftware. This first phase was performed using the software listed in section 2.5. Files weregathered through designs by users of CET Designer as well as well as from the 3D librarySketchUp[48]. Files varied in size depending on file format and how detailed the models ormaterials were. Since glTF has shown to be a promising format for 3D models it was goingto be used for testing if possible. The prestudy provides more information about the differentsoftware and which file formats they support. Important metrics about the models such asnumber 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 pressedand stopped when the file had completely loaded into the software or was saved to the filesystem. The results were compiled for further discussions.

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

11

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 CETDesigner software and the Configura Magic programming language it is built on. Technologiesthat were used when developing CET Designer are detailed in the results chapter. Limitationswhich hinder certain implementations are also discussed. The system lays a foundation forfurther development and research from the literature study provides a basis for the resultsthat will be achieved from using this kind of implementation.

The motivation behind building a network-based system for transferring 3D data betweensoftware is that it gives the users more freedom when designing for example offices. CETDesigner can be used to set up all the furniture and get a price estimation in real time as moreitems are added. CET Designer is also used to get assembly instructions and produce 2D CADdrawings. Exporting the entire graphical scene into a different software such as Unreal Engineor Lumion would allow the users to take advantage of more advanced 3D features such asmodifying materials, using real time ray tracing and post processing effects. It would also bepossible to collaborate in real time with the same drawing where one user is placing down allthe 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 withdevelopers 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 manipulatingobjects on a separate client and having that translate to a change in CET Designer. Thiscould 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 severalusers at once. A server would be handling all requests so it won’t affect user performance oneither end. Sending updates in real time means that when a change has been made in CETDesigner it is translated into a 3D format which can be sent to a client quickly and efficiently.

12

4 Results

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

4.1 Prestudy

Information for the prestudy was gathered through official websites of the companies whichare referenced in section 2.5. This was compiled in table 4.1 which covers the questions andconstraints listed in the method chapter.

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

BlenderGame development,architectural visualization,film

Yes Free 3DS, FBX, OBJ,PLY, STJ No official links

Enscape Architectural visualization NoSingle machine $39 USD,multiple machines $58 USD(per month)

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

Lumion Architectural visualization NoFree 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

UnityGame development,architectural visualization,film, construction

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

3DS, DAE, DXF,FBX, OBJ Navisworks, Revit, Rhino, SketchUp

Unreal EngineGame development,architectural visualization,television content creation

YesFree to develop,5% royalty fee for projectexceeding $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 thereare a few options which would be viable. Since this is a student project it should be possibleto have access to student licenses meaning that Unreal Engine, Twinmotion, Unity, Blenderand Lumion could be used. The caveat is that these software might not be open source fordevelopment. Only Blender and Unreal Engine are fully open source and would allow forgreater modifications. Unity does allow for creating functionality using scripts and you canalso create plug-ins.[45]

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

13


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

These constraints and limitations lead to the decision that Unreal Engine would be a goodcandidate for future development. It supports the file formats FBX and glTF which are bothused 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 forum2 whereother developers and users can post questions and answers to problems that arise. In the UnrealEngine marketplace3 there are plugins which could be used to avoid creating solutions whichalready exist. In the Architectural Visualization Rendering Survey by CGarchitect[7] UnrealEngine is one of the top 5 most popular rendering engines, which shows that there is an interestfor 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 subsectionswhich 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 ofthem is to use a shared file which both software have access to. When changes are made to thefile the software reloads it into memory. Another approach is to use a protocol such as TCPto stream the data between software over a network. This is accomplished by establishing aconnection and sending data when a model or drawing has been changed. This approach canalso use a cloud-based sharing model, where a file is uploaded to the cloud and thereby madeavailable to other software. More about these approaches will be described below throughanalyzing related papers which were found through the method described in section 3.2.

4.2.1 File-based approachesUsing a shared file is the simplest approach as it will be built using existing technology. Mostsoftware already support exporting and importing files in different file formats. The importantpart is finding a file format which is optimal for both software and having a file path whichboth can access. This section investigates how this approach can be used to automate andimprove the import and export workflow.

Industrial 3D importing

With the purpose of defining the 3D modeling workflow Tran Thi wrote a thesis paper[47] atHelsinki Metropolia University. The thesis deals with the workflow of converting 3D modelsbetween 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 wasexporting a 3D model of a ship design from a CAD software to 3ds Max. Tran Thi definedthe 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 deeperunderstanding of the complete workflow.

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

1https://docs.unrealengine.com/2https://forums.unrealengine.com/3https://www.unrealengine.com/marketplace/

14


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 isdefined in an unusual way. Overlapping means that objects have overlapping layers whichcause 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 learnedfrom this work is that the 3D models need to be properly prepared before being imported toother software. Problems often occur in these workflows and depending on the software usedthere 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 virtualreality is the focus of exploration. They identified a need in the manufacturing industry ofvisualizing assembly sequences in virtual reality to get a better sense of scale. The applicationthey developed is based on Unreal Engine and they outline some of the features which couldbe useful to their implementation. One of the features is Datasmith which is a collection oftools that can be used to import CAD assets. Using Datasmith also allows developers to use areimport workflow where CAD models are automatically reimported when the source programhas been changed. Unreal Engine also allows for prepping data before it is imported into theeditor. This is done either through the use of the visual scripting system called Blueprintsor by using C++. Engberg and Eriksson explain the various uses of VR in education andengineering through their literature study. They showed that this is an area of great interestand potential and that there have historically been great difficulties in moving CAD databetween software. This is also shown in the paper as there are struggles when they import theCAD file to Unreal Engine. Naming conventions for meshes and other assets differ betweenthe software. In the implementation they say that Autodesk Fusion 360 has been used todesign and export the CAD files. This leads to the authors having to create a pipeline forrenaming assets according to their specifications. There were also problems with origin pointsfor assets which was fixed in a similar way. For the authors it was important to be able toalso include part data in the CAD files. This means that the implementation needs to supportadditional information for components such as size and amount. This also needs custom fixesand implementations as this is a customer specific request. The result was an implementationwhich was tested and evaluated for usability metrics. It was shown to be working with someflaws; there were still some manual configurations required as the system was not completelyautomatic. The authors explain that many of the problems are due to limitation in UnrealEngine where they were unable to make runtime import work. It is not a feature which isdirectly available. Some development is needed but it is also possible to use plugins from themarketplace. It seems you need to understand how Unreal Engine works and the API on adeeper level to be able to create custom import export workflows. The differences in howUnreal Engine interprets CAD data compared to the other software used (Creo, Fusion 360and Siemens NX) was also a hindrance to the implementation. For future studies the authorsmention that it would be interesting to revisit this area after more functionality has beenadded to Unreal Engine. They would also like to evaluate different file formats.

15


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 workdone in the paper by Fält [15]. The background of the paper was to investigate how NorrköpingVisualization Center could use their 360-degree display to provide services to companies andschools where they can visualize and interact with 3D models of buildings. The software usedinclude 3D Studio Max (3ds Max), Revit and Unity 5. Fält found issues with importing 3Ddata to a game engine. The file format .rvt which is used by Revit is not supported by Unitywhich means that a conversion to FBX is needed. The file then needed to be imported into 3DStudio Max where a texture is applied before it could be imported into Unity. Fält found thatautomating 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 needto have an intimate understanding of how the software work to implement a fully functionalpipeline. There are settings and features which can differ between two software which causesproblems when importing and exporting. Fält found that the model would look significantlydifferent in Revit, 3D Studio Max and Unity 5 even though the same model and textures wereused. He did not focus on lighting in the different software as these can be very different andthere would need to be some tinkering with settings to get the same results throughout thesoftware. Fält suggested that this could be the basis for the next thesis in this area. He statedthat it would also be interesting to evaluate using more models as he only used one buildingmodel in his evaluation. He also stated that using 3D Studio Max directly with differentrendering software could prove to be more effective, thereby skipping Revit since it causedissues.

Building information models in game engines

The paper[6] by Bille et al. is focused on visualizing buildings using game engines. Theauthors explain that the purpose of reusing building plans and models in a 3D interactivevirtual environment is to aid model refinement and for use in training environments. Toshow virtual models of oil refineries, production platforms, nuclear power plants and buildingsduring the construction phase provides a safe and comprehensive experience. The limitation ofthe BIM model is that it doesn’t provide an interactive environment. It is rather an accuratedescription of the building and its components. The authors are proposing a move to gameengines to provide the interactive 3D environment using BIM data. Their paper focused abit on related research and found that there have been a few papers about using BIM forgame engines. There are often middle steps involved when exporting and importing modelswhere texture mapping and metadata is applied. There can also be problems when modelsare updated as the link between the model and alterations to the model are severed due to areimport 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 intable 4.2

File-type Geometric data MetadataFBX Yes NoDWG Yes NoOBJ Yes NoDWF/DWFx Yes PartialNWC Yes YesODBC Yes YesgbXML Yes PartialIFC Yes Partial

Table 4.2: Revit export file types.

16


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

4.2.2 Network-based approachesA different approach compared to using a shared file is streaming the 3D data between softwarethrough a network. Sometimes the data is sent with a server acting as a mediator. The servercould be cloud-based or running locally on the user’s computer. Implementations can beachieved by using different protocols and libraries which will be demonstrated in the papersthat have been selected in this study.

Atom: real-time networked streaming of 3D scenes

In the paper[27] by Green the problem of pipeline efficiency is tackled using networked stream-ing of 3D scenes. The focus of the paper is the video game industry where it is common thatseveral different software are used. It is helpful to get quick feedback of how a model willlook in the final game even though the designer is working in a different software. AutodeskMaya is referenced as an example. To bypass obnoxious exporting steps every time a previewis desired is a goal for the implementation referenced in the paper. Green mentions that thereare solutions which reduce the pipeline stages for iterative development, though the flaw isthat the visualizations are localized. Having remote visualizations means that you can previewa scene on a tablet device while the designer is modifying it from a workstation elsewhere. Theproposed solution is a plugin for Autodesk Maya which acts as a server which streams data tonetworked clients. The plugin should be standalone and not restricted to specific third-partyclient applications. A client could for example be a custom game engine. Green sent out ashort survey before the development to find out which components of the product that wereconsidered most important. The survey was sent to 20 people who were artists, programmersor technical artists. Results from the survey showed that speed of data transfer was moreimportant 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 intoscene data similar to the observer design pattern. Green also created a client for developmentand 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 superiorasynchronous capabilities and widespread usage”. Messages sent by atom are serialized usingGoogle’s Protocol Buffers library. A message sent by Atom consists of a 32-bit signed integerdenoting the size of the data followed by the raw data itself. When a server instance is startedit will continuously listen to new connection requests. When a connection has been made theclient can send a request to the server to send data. The implementation supports multiplethreads and multiple connected clients. It is built on TCP since UDP is less reliable eventhough it would be faster. The data is structured as displayed in figure 4.2.

17


Node

Annotation Camera XformCurve UtilityLight MeshMaterial Texture

Figure 4.2: AtomDag node type hierarchy.

The nodes in the figure represent different Maya classes. The Mesh node is a representationof the Maya MFnMesh class. The base node called Node contains all essential data for anelement in the scene. When Atom was completed the author sent out a feedback survey toartists and programmers to find out the usefulness of Atom. The survey showed that almostall participants thought it was useful if a client could be implemented in their desired gameengine or rendering software. The participants also stated that it would reduce the numberof 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, thoughit does support entire scenes. There was a desire to be able to use Atom for animations. Thiscould be an area for improvement in the future. Since Atom is an API it could be extended ata later stage and there are endless possibilities of using this in combination with third-partysoftware.

Synchronizing BIM data to VR

The architecture, engineering and construction industries have witnessed a steady increase ininterest for VR to improve existing work processes. Allowing users to interact with digitalobjects 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 diffi-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 usinggame engines. The authors have identified problems with this convertion process. Firstly, thedesign-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 takehours 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 mannerto avoid high costs later. Having fast feedback loops means that problems can be fixed at anearly stage. Thirdly data integrity is difficult to maintain in the present Design-to-VR methodwith frequent changes. Data needs to be synchronized between many parties and the systemshould support a variety of formats and different platforms. Du et al. have researched thisarea extensively and came to the conclusion that many solutions are at a conceptual level anddo not show a complete implementation using real software. Studies have also shown thatexporting BIM is not straightforward. The problems that occur can vary depending on theenvironment used. The authors sought to develop an innovative data transfer protocol calledBVRS (BIM-VR Real-time synchronization) to solve the problems mentioned before. BVRSuses a cloud-based infrastructure where the middle layer between two software consists of adatabase. Objects are stored in the database and are identified using an ElementID whichis generated using the FBX file format. The database contains information about the po-

18


sition, material, model and other metadata. The same structure is then created within thegame engine to ensure that the database elements correspond to internal elements in the gameengine. Revit is used in this implementation for creating the CAD models and the authorsmention both Unity and Unreal Engine as candidates for game engines that could be used fordisplaying the scene in VR. Changes in Revit will result in a request to the cloud server. Therelevant data will be changed and marked. The game engine then scans over all ElementIDsdynamically and examines if changes are discovered. If any changes are found they are used tochange the visualization. The reverse process can also be implemented where changes in thegame engine are sent to the database, though this is not currently implemented. The authorshave focused on four major areas to create a real-time BIM data updating function: Modeltransfer and refinement, user interface design, cloud server connections and player controllerfunction development. Model transfer and refinement refers to optimizing the response timeof the application and database as well as providing the best possible graphical experiencefor the user. Setting a limiting texture size as well as reusing the same texture for differentmodels means that there will be fewer data packets sent. Occlusion culling is used to optimizethe 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 forthe 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. Sendingthe 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 havebeen made to them. Only tagged elements are sent to the application when a request has beenmade. Hash tables are used to store ElementIDs and properties and searching for propertiesis done in constant time for a given ID. The application goes through the elements’ updatedproperties 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 thecontext of this literature study. Results from user tests show that real time synchronizationof BIM data in VR is possible for different scenarios. BVRS reduced data processing andtransmission delays compared to the example system irisVR which took 10s to see a designchange whereas BVRS was almost real-time. For the future the authors have found that thereneeds to be improved efficiency for complex models. For a large number of interdependentobjects the synchronization is affected since it needs to dynamically monitor changes to everyobject. 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 theauthors. Other tree based search algorithms will be examined in the future to improve searchefficiency.

Two-way cooperation of 3D data in game engines

For collaborations using 3D data it can be useful to establish a two-way communicationschannel where modifications can be made to the model or scene on both sides. Kado andHirasawa presented such a system in their paper[30]. The authors explain that the use of afile-based data coordination proves to be a tedious process which is not suited for the cyclicdesign and visualization process. Their proposed system has a mesh-based representation ina VR application with smooth transmission and reception. It also allows the user to editelements that have parametric behaviors and geometrical interactions. As opposed to thesystem presented by Du et al. [12] the system by Kado and Hirasawa is not limited toupdating element locations and modifying element types. The implementation in this thesisuses ArchiCAD 20 as the 3D CAD software which sends information to Unreal Engine 4 using arelay 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. Thenthe VR application checks the database for any updates and loads them. Lastly the new datais processed and visualized in the VR application. Since there is a two-way connection there

19


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

ArchiCAD 20 Unreal Engine 4

3D model API

VR sceneBlue Print

API

PostgreSQL

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

The implementation supports both a geometric mesh-based representation and aparametric-based representation. The reason for this is that the conversion between the tworepresentations 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 thecorresponding mesh. Measures were taken by the authors to handle meshes efficiently by theuse of a delta update function. The delta update function makes sure that only necessaryoperations to the database are performed. When a duplicate chair is added to the 3D scenethere isn’t a need to send and store the same mesh twice since it can be reused. When a chairis 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 a3D model comprised of 685 elements and more than 87,000 polygons showed promising resultswhere the VR editing function could be used to modify the geometry of a window. By usingparametric data the geometry of the wall was also changed to accommodate the smaller holeneeded to house the window. Updating accompanying geometries resulted in several seconddelays which is an area of future improvement by the authors. The authors plan to implementsimilar systems in with other architectural 3D CAD software and game engines to furtherexplore 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 beingable to effectively interact and collaborate with users or clients on a functional level. The endusers want to be able to explore and interact with buildings and models to give constructivefeedback 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 theAEC (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. Thesystem described has a multi-layered architecture consisting of a BIM environment, a datatransmission element, a game engine environment and a client end. The BIM environmentis based on Autodesk Revit which provides building information as well as an API to accessthat information. Revit was selected since it was fully compatible with BIM standards andhas good third-party support. This environment communicates with the data transmissionelement which contains the database and FBX converter. It generates semantic and geometricdata and stores it in the database which has a two-way connection with the server game whichis a part of the Game Engine environment. The Game Engine environment consists of a Unity

20


game component which feeds data into available clients which have connected through an IPaddress. Unity was chosen since it has a simple object orientated and editor-based designsystem. You can create executables which run on Windows and Mac. You can also createweb player versions of games. At the client end, end-users and designers can interact with themodels via the Unity game engine. Many different input and output devices are supportedsuch 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 thatallow the user to connect to the server through their web browser. The figure 4.4 shows allthe components and how they interact with each other.

BIM environment

Data transmissionelement

Client end

Game Engine environment

User/Designer

Unity Game

Client Game Server Game

Game CollaborationPlug-in

Autodesk FBXconverter

`Micro´Web-Server

Revit APIRevit 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 FBXformat. It is then converted to the OBJ format which can be sent to the server gane instancewhen a request is made. The server game instance can also request parametric propertieswhich are sent separately. When a game client has connected to the server game it can requestthe model and parametric data from the server. When objects are modified in the client thedata is sent back to the server which sends objects to the plugin. The authors found thatthere were some issues with sending back data to the plugin which could be a topic for futureimprovements. The separation of model and parametric data was also an issue since it didn’tprovide an elegant solution. Using the IFC format would allow storing both geometric dataand parametric data in the same format which is something that isn’t supported in the OBJformat. A technical improvement the authors identified was to implement Universal Plug andPlay (UPnP) to reduce the user configuration by allowing programs to negotiate with a firewallin a network.

4.3 File-based implementation

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

21


4.3.1 File formatThe file format glTF was chosen for the implementation since it is supported by Unreal Engineand it offers many new capabilities when it comes to rendering models compared to olderformats. glTF uses PBR which provides realistic materials with different properties. PBR isdescribed in section 2.3.2. There was a desire from Configura to use the glTF format sincesupport is currently being developed for the CET Designer software. In the study[34] by Lee etal. the file formats OBJ, FBX, STL and glTF are presented with comparisons of performanceand structure. They find that glTF has more 3D attributes compared to the others andperforms better for most of their test cases. They also expect that the glTF format will beused in more applications in the future. The problem with using glTF is that not a lot ofsoftware support it. To be able to make a correct evaluation of this implementation thereneeds to be support for the more commonly used format FBX as well. This isn’t an issuesince both Unreal Engine and CET Designer support FBX and it is simple to configure theimplementation to support both file types.

4.3.2 CET DesignerThe exported file comes directly from CET Designer and the code which performs the exportis written in the CM programming language. CM is a strongly typed object-oriented pro-gramming language with extensible syntax and support for incremental development[9]. Thedevelopment of the language started as there was a dissatisfaction with C++. Mostly thedissatisfaction was caused by the long work cycles caused by the need for restarting and re-compiling the program after changes to the source code. A garbage collector is used to reclaimmemory that is allocated by objects and other values. CM source files are compiled to machinecode before they are executed, though this doesn’t happen immediately. The source code istranslated into different intermediate formats on-demand and is only compiled to machine codewhen the compiler cannot delay it any further. This means that the source code is directlytied into the execution of the program. Files can be recompiled at runtime which enables anincremental development style. For this implementation it means that during developmentit was possible to make changes to the export process and have it up and running instantlywithout having to restart the CET Designer software.

In CET Designer most objects are known as Snappers which inherit from an Object baseclass. Snappers can be seen as 3D elements with custom properties and functionality. TheSnapper base class is extended when more functionality is needed which is the traditionalobject-oriented workflow. Each Snapper in the scene in the scene holds information aboutits position, materials and meshes. The export function in CET Designer makes sure eachSnapper is included in the exported file. The file is exported to a specific path on the computerwhich could be either statically defined or determined by the user through a save dialog. Anew file is generated every time there is any changes to the scene. Changes are defined asany modification to a Snapper on the drawing area. This could include moving a Snapper,deleting a Snapper, changing Snapper properties or altering the material used on a Snapper.All of this functionality was gathered into an extension (also known as a plugin) which simplyinitiated the process of creating a shared file and keeping it up to date. The extension canbe seen in figure 4.5. There are buttons which launch the Unreal Engine 4 editor, manuallyexport the file to the specified location and also a button which allows the user to set the filelocation through a dialog window.

4.3.3 Unreal EngineUnreal Engine is used as the rendering software for this implementation. It is used to visualizethe scene which has been exported from CET Designer as a glTF file. The implementation onthe rendering software side consists of an automatic file import system which continuously looksfor updates in the shared file. Two approaches have been identified for creating a workflow

22


Figure 4.5: CET Designer extension for the Unreal Engine export.

where a file is automatically imported and updated in Unreal Engine. The first approachinvolves setting up the Auto Reimport feature which is enabled by default in Unreal Engine.The other approach is to create a plugin which the user can download from the Unreal EngineMarketplace or directly from the developer. Developing the plugin can be done using BlueprintsVisual Scripting or C++. Both approaches will be explained more in detail below.

Auto Reimport

Auto Reimport is an Unreal Engine feature which allows the user to monitor a certain folderfor changes in source content files[18]. This feature was described in the paper by Engbergand Eriksson [14]. The user modifies settings in the editor which define how the feature works.These settings available are: Directories to Monitor, Import Threshold Time, Auto CreateAssets, Auto Delete Assets, Detect Changes On Startup, Prompt Before Action. Under theDirectories to Monitor setting the user can determine which directory should be monitoredand which folder it should map to in the internal Unreal file structure. Import Threshold Timedefines the time it takes before a change is reflected in the automatic reimport. Auto Createand Auto Delete determines if newly added source files should automatically create or deleteUnreal Engine assets. Checking the setting Detect Changes on Startup means that UnrealEngine will update assets if any changes have occurred in the monitored folders on restart.Finally, the setting Prompt Before Action allows the user to get a prompt whenever a newchanges are to be imported. For our implementation it would suffice to add our export folderto the setting Directories to Monitor. This is the folder which CET Designer exported the

23


glTF file to in the file system. The Import Threshold Time should be set to 0 for the quickestupdate time and the rest of the settings should be checked except for Prompt Before Action.How settings are defined for this implementation can be seen in figure 4.6.

Figure 4.6: Unreal Engine Auto Reimport settings.

Plugin development

Creating a new plugin for Unreal Engine is done by simply opening up the Unreal Editor’sPlugin Browser and selecting from a few templates[21]. The development can then be doneby using Blueprints or writing C++ code in an editor such as Visual Studio. Blueprints is aVisual Scripting system which uses a visual interface where nodes are created and connectedto each other. An example of Blueprints scripting is shown in figure 4.7.

Figure 4.7: Blueprints for importing a FBX file.

Nodes are representations of C++ concepts such as variables, functions, objects and classes.The advantages to using Blueprints is that it allows for faster creation, faster iteration and

24


flexible editing. You can easily connect inputs and outputs to different nodes and create entireprograms. The advantages that come from instead using C++ is faster runtime performance,more data control and easier version control. Using both Blueprints and C++ for UnrealEngine development is the best approach as it provides a good balance.

While using the existing Auto Reimport feature would be the quickest way to get animplementation up and running, it doesn’t provide the easiest workflow for the user. Theuser needs to go into the settings and find the correct output folder as well as make selectionsfor the different check boxes. To make this as simple as possible a plugin was developedwhich uses predefined values where the user only has to click on a single button to initiatethe synchronization with CET Designer. Thus, it is ensured that only a minimal amount ofinput is needed from the user in both software. This doesn’t have a significant impact onperformance; it will only affect the user experience. A button is placed in the Unreal Engineeditor menu. This button uses Blueprints to read the file from a url in the filesystem andimport it into the scene. It continuously reloads the file when changes have been made. Thisbuilds upon existing code from the Auto Reimport feature provided by Epic Games.

4.3.4 EvaluationTo answer the second research question this thesis evaluates whether or not an automated file-based import-export workflow is viable for use with different types of 3D files. The evaluationis done in two phases. In the first phase the import and export loading times are evaluated forthe software used in the prestudy. In the second phase the implementation described above isevaluated with regards to limitations when it comes to file format and file sizes.

Testing hardware

It is important to mention the specifications of the computer used during testing since itdirectly affects the performance of the software used. In this instance the tests are doneon a computer running Windows 10 with high-level specifications which was tested usingUserBenchmark4. Results from this benchmark and the specifications can be seen in table 4.3.The percentages refer to how the individual component performs compared to the averagecomponent from other user benchmarks. UserBenchmarks also provides a rating for how wellthe system is suited for gaming, desktop work and as a workstation. The results from thistest gives the following scores: Game - 105%, Desktop - 95%, Workstation - 89%. During thetesting most software running in the background was closed down to minimize the interference.

CPU Intel Core i5 8600k 92.2%GPU Nvidia GTX 1080 112.6%SSD Samsung 960 Evo NVMe PCIe M.2 250GB 185%RAM G.SKILL F4 DDR4 2400 C15 2x8GB 73%MBD Asus ROG STRIX Z370-E GAMING -

Table 4.3: Specifications for computer used during development and testing.

First phase of testing

Enscape was excluded from the tests since it is a plugin which doesn’t provide the import-export functionality. There were four different files used for this testing. The files calledKitchen[16] and House[10] came from the SketchUp 3D Warehouse and were downloaded asCollada Files and then imported to Blender. In Blender the models were then exported asFBX files. The files called Industrial and Office were created in CET Designer using existingSnappers in the built in extensions. The files were saved as CET Designer Drawings and then

4https://www.userbenchmark.com/

25


exported as FBX files. Information about the files was gathered in Blender and compiled intable 4.4. It was not possible to use glTF since most software didn’t support it. There wasunofficial support for glTF in some software through plugins or extensions though it mightnot provide a good comparison.

Name File size (kB) Objects Vertices Edges Faces/TrianglesHouse 596 203 17,197 21,292 9,556Industrial 38,088 2,857 1,566,021 2,469,690 1,126,099Kitchen 3,824 497 165,533 241,648 122,848Office 18.8 796 192,005 354,719 181,145

Table 4.4: Specifications for files used during testing.

Testing was performed by importing the FBX file into the software and then exporting itto a new location using the menus in the software. Both stages were timed and results werecompiled into table 4.5. Times are shown in the format Import time/Export time. Tests wererepeated five times and the values in the table represent the mean values of those five runs.For Twinmotion and Lumion there are no export times since the software do not support thatfunctionality. These software are most commonly used as rendering engines and provide thefinal step for designers.

House Industrial Kitchen OfficeBlender 0.91/1.36 27.22/16.19 1.95/2.32 5.45/3.48CET Designer 2.44/1.27 58.49/3.42 6.27/1.03 6.36/1.41Lumion 2.01/- 62.02/- 3.44/- 15.24/-Twinmotion 2.29/- 17.14/- 6.22/- 4.63/-Unity 1.05/1.2 25.9/76.98 3.41/3.98 4.69/6.55Unreal Engine 32.77/1.61 188.55/3.68 56.92/1.65 362.01/1.55

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

There were large differences in both import and export times depending on which file andsoftware was used. Unreal Engine was shown to be very inefficient in loading files as it tooka lot of time to compile shaders. The Industrial file gave the slowest results in general, whichmakes sense since it is the largest file and has the highest number of objects.

Second phase of testing

The second phase of testing involves the implementation developed using CET Designer andUnreal Engine. In this test both FBX and glTF files are used to compare how fast theexport and loading is compared to table 4.5 and see which file format is best suited for theimplementation. The addition of glTF support in CET Designer is very recent so there hasn’tbeen much optimization yet. A smaller scene was chosen which was created directly in CETDesigner. This scene is shown in figure 4.8. The smaller scene is used due to the results we cansee in table 4.5. It would take too long to use any of those files. Since we are only interestedin comparing the formats FBX and glTF it should not affect the overall results.

From the testing in the first stage it is clear that Unreal Engine didn’t handle large filesizes particularly well. The tests were performed by clicking the export button in the CETDesigner extension and waiting for the file to load completely in Unreal Engine. When theshaders had completely compiled in Unreal Engine the process had finished. The next stepwas to determine fast Unreal would reload a file when it had been changed. This was testedby moving one object in the CET Designer drawing and rewriting the FBX/glTF file. Unreal

26


Figure 4.8: Basic room created in CET Designer.

then reimported the file and took care of the changes that had been made. When the shadershad completely compiled in Unreal Engine the process had finished. Results from testing theimplementation is shown in table 4.6

Format File size (kB) Initial load time Reload timeFBX 12,265 128,06 10,31glTF 14,291 64,4 50,62

Table 4.6: Testing the implementation with FBX and glTF file.

From these results there is a minimal difference in size for the different file formats. Theload times also differ significantly where FBX had a high initial load time compared to glTFbut it was faster to reload the FBX file when changes had been made to a single object.Discussions about the results from this section will be in chapter 5.

4.4 Network-based system

The network-based system is an effort to apply findings from the literature study to a systemusing CET Designer as a drawing software. A previous thesis[41] at Configura tried to imple-

27


ment a similar system between CET Designer and Revit. This system involved using RemoteProcedure Calls to create a direct link on a local machine. The author found that there wereissues with using the Revit API since it had some limitations which affected functionality inthe system. There was also a problem to get optimal performance since CET Designer doesn’tlet multiple threads work with their models. At the end of the paper the author suggestedsome improvements for future projects. One of the improvements was to use a shared databasewith which both software can interact. Using a database/server as a middlelayer between thesoftware means that the time to transfer data will be slower compared to a direct link. Witha direct link the system can simply send the updated model to the rendering software whichloads the changes and updates the visualization. With a server in the middle it needs to processthe changes and update the database before passing the changes on. It does however meanthat the implementation can be scaled up to handle more clients. This was demonstrated inseveral papers[13][27][12] in the literature study. This route was chosen for the system designdescribed in this section.

4.4.1 ArchitectureThe architecture of the proposed system is described in this section. It includes the overallstructure as well as data flow graphs and data format descriptions. The simplified structureof the system can be seen in figure 4.9.

CET Designer Client software

3D scene API

3D sceneAPI

Server

Applicationserver

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

Instead of a two-tier architecture, which is used in the paper[30] by Kado and Hirasawa,an application server was added which handles the communication between clients and thedatabase. A three-tiered system is slower[11], however it does open up for more possibilities interms of scaling up the system and improving reliability. From the data perspective the systemwants to make sure that the correct clients are writing to the database and that changes areproperly propagated through the system before any changes are made. The three-tiered systemwas used in papers[27][12] presented in the literature study which showed great performanceresults.

The clients in this system could be anything from game engines to rendering software andeven websites. Any software that is capable of communicating with the server can requestinformation even if they do not possess the ability to visualize it. When using game enginessuch as Unity and Unreal Engine there will be a need to create custom plugins/extensions whichhandle the connection to the database and make sure that the requested data is converted tothe proper local assets. Since software use different formats to store and manage their assetsthere will need to be some configuration done before the link is working properly. Theredoesn’t exist a format or system which all rendering software support so the focus is to keepthis system simple so that development will be kept as easy as possible. Taking Unreal Engine

28


as an example, Blueprints Visual Scripting can be used as described in section 4.3.3 to quicklyget a client application up and running.

Since CET Designer is working with a lot of parametric data, the relations between objects(Snappers) need to be kept when changes are made. An example of this can be that when atable is stretched length-wise the chairs should move at the same time so they are uniformlyspaced out. Another example given by Kado and Hirasawa[30] is related to how a wall willaccommodate a window model by creating a hole in the mesh. When moving or changing thesize of the window the hole needs to change as well to make sure the scene looks realistic.Figure 4.10 describes how the components of the system communicate with each other to keepthe scenes up to date on the server and all the connected clients. An observer pattern is usedto make sure that connected clients receive updates when changes have been made.

CET Designer Server Client

Send scene data

Receive scene data

Send changes

Send changes

Update scene data

Receive scene data

Connect to server (observer)

Connect to server (observer)

A modelis

modified

Update scene data

Receive scene data

A modelis

modified

Figure 4.10: Communication chart for the system.

4.4.2 Database formatWhen it comes to database format the design should be efficient while containing all theinformation the system needs. Adding more functionality in the future should be supportedwhere information such as prices, information about materials used and assembly instructionscould be of interest in the areas which Configura is present. The format should be based onthe internal components in CET Designer since scenes and models should be sent from CETDesigner to the server as quickly as possible. Conversion between the data stored on the serverand the internal structure in the client should be done in each client to off load computationfrom the server. The important data identified from the literature study is position, material,texture and mesh. Additional information such as camera position, lighting information andother visual effects could also be added. Constantly updating the camera position could bevery costly and there isn’t a need to have the cameras on both software synchronized. Thiscould even be obtrusive for the users. Lighting information is difficult to implement as it willvary depending on software. Du et al. [12] mentioned this issue in their paper. Usually BIM

29


models don’t contain lighting information so it’s up to the user to place light fixtures in therendering engine manually to suit the model used.

Building on the Snapper structure in CET Designer each Snapper is assigned a unique IDwhich is stored in the database. The Snappers will be individual nodes which together makeup the scene. Each node contains information about its own position, material, texture andmesh. The latter three components will be stored separately and accessed through unique IDs.Since materials, textures and meshes can be reused for different Snappers they shouldn’t bestored them more than once. This format is similar to the ones used by Green [27] and Du etal. [12]. Using a relational database objects are stored according to figure 4.11.

Snapper ID

Position

Texture ID

Mesh ID

Material ID

.

.

.

Material ID

Material data...

Texture ID

Texture data...

Mesh ID

Texture data...

Figure 4.11: Format for the network design data.

Texture data can be in the form of jpg or png files and the materials define physicalproperties of an object. An example of this comes from the glTF reference guide[31] wheredata is stored in the JSON format which describes the structure of a scene containing 3Dmodels. A further study in this area could compare different types of data formats and seewhich is faster with rendering engines. In the paper[29] by Hatledal both JSON and GoogleProtocol Buffers(GPB) were compared using Firefox, Chrome and Unity. GPB was shown tobe significantly faster in Unity.

4.4.3 Protocols and technologiesNetwork protocols and technologies were seldom referenced in the papers from the literaturestudy. Green [27] mentioned using TCP instead of UDP to get better reliability with thedrawback of worse performance. A library which can handle TCP requests as well as IPC andUDP is ZeroMQ5. Since there is existing support in CET Designer for streaming data usingZeroMQ it would be a good candidate for this system. There is support for ZeroMQ in Unity6,Unreal Engine7 and Blender8. The library can be used in many programming languages suchas C, C++, Python and Java. Hatledal[29] used ZeroMQ to create a network interface for areal-time simulation framework. It proved that the library could be used to stream 3D datato Unity with good performance results.

4.4.4 OptimizationFrom observations of the papers in section 3.2, there is an importance in employing optimiza-tions of the 3D data and system. Optimizations could for instance be that the user definesthe level of details in the models that are to be stored on the database. Perhaps there aren’tstrict requirements on the client for high quality models. The system could for instance reduce

5https://zeromq.org/6https://github.com/valkjsaaa/Unity-ZeroMQ-Example7https://github.com/hdhauk/UnrealZeroMQ8https://github.com/NumesSanguis/Blender-ZMQ-add-on

30


models mesh and compress the texture to lower the file size. The user could determine the levelof detail using a setting in the extension where possible options are ”Low”, ”Medium”, ”High”and ”Super”. This option already exists in CET Designer for local drawings so it would bestraight forward to implement in an extension. Du et al. [12] mentioned that this optimizationcould be important to improve the response time between server and client. Another optimiza-tion that was used by Kado and Hirasawa [30] is to only update the database when mesheshave been changed. This can be applied to textures by using hash functions and time stampsin the same way. When a new Snapper is added to the database it checks if the mesh/texturealready exists. In that case it can be reused and the client doesn’t need to download the samemesh/texture again. If the mesh or texture has been altered for a certain Snapper it will beuploaded to the database.

31

5 Discussion

This chapter contains the discussion of the results and method. There is also a section detailinghow the work applies in a wider context.

5.1 Results

The results consisted of four main sections: prestudy, literature study, file-based implementa-tion and network-based system. Findings from each section will be presented here.

5.1.1 PrestudyThe prestudy looked at different software used for architectural visualization and game devel-opment to find out which would be suitable for collaborations with CET Designer and otherdrawing software. It looked at cost, available file formats and access to source code as metricsfor this evaluation. As detailed later in the implementation this was not enough to get a com-plete grasp of the software and their capabilities. How fast the software imported and exportedfiles of varying sizes would have been a good complement to this. Given the results from theevaluation another software such as Blender could have been picked. It is ultimately a tradeoff with several factors which the developer has to put their own weight into. Unreal Enginewas chosen since it was known and used previously by developers at Configura and there is alarge user forum where most questions can be answered about development. Using the factthat the software is open source or not might have been a too large requirement for this thesis.The thesis could have looked further into the softwares APIs and tools for development to geta fairer representation of these software and what developers can do with them. Going deeperinto plugin/extension development for software such as Lumion, Twinmotion, Unity and Revitcould be a basis for future work as there wasn’t enough time to do it in this paper.

5.1.2 Literature studyIn the literature study papers were divided into either file-based approaches or streamingbased approaches. There are some general conclusions that can be drawn from the file-basedapproaches. They all seemed to be in agreement that there is a need for simplifying the processof transferring 3D data between software. There were a few different ways this problem was

32

5.1. Results

tackled in the included papers. Tran Thi[47] focused on how 3D models should be properlyprepared whereas the other papers by Engberg and Eriksson[14], Fält[15] and Bille et al.[6]turned their attention towards automating this process. The papers used in this section allmentioned difficulties in converting 3D models between software where intermediate steps hadto be taken between for example drawing software such as Revit and rendering software suchas Unity. Difficulties with textures not being applied in certain software caused additionalsteps where software such as 3ds Max needed to be used in order to combine both texturesand meshes. Finding papers relating to file sharing was found to be more difficult which couldbe due to a lacking interest in this area of research. The results from the implementation inthis thesis could shed a light on why sharing files between software is not an effective approach.This will be discussed later on in this section. Out of the four papers referenced two of themused Revit and Unity and three of them used 3ds Max. In addition, one thesis used UnrealEngine in combination with Autodesk Fusion 360. A greater spread of software used mighthave produced different results. The prestudy and implementation evaluation showed that theresults can vary greatly depending on which software is used. The software dictates whetheror not a certain file format can be used and also how fast an implementation can be. Twosoftware might not be compatible either as they choose to handle 3D data in different ways.On the other hand, some software do not provide outsiders with the proper tools to buildcomplete plugins or extensions. Therefore, it might be a limitation which has caused mostresearch to be skewed to the software listed in these papers.

When it comes to streaming 3D data there are many papers which can be found thoughthey might not always be relevant to a certain area of research. These papers were mostlyfocused on synchronizing data between 3D software for the architectural visualization andspace planning industries. Sources had to be discarded if they dealt with topics that strayedaway from this area or if streaming 3D data was only a byproduct of a different area of research.The papers selected for this study had different approaches to streaming 3D content and theyall provided good findings which can be used for future research. Game engines were used inthree of the four papers whereas Green[27] chose to build his own rendering client. His paperwas heavily focused on users getting fast feedback on their models to see how they will look inthe final game. He used short surveys to get feedback on his implementation which streameddata from Autodesk Maya to networked clients. A large part of the paper explained the nodestructure and how it ties into Mayas internal structure. The papers by Du et al.[12] and Kadoand Hirasawa[30] were focused on providing a VR interface to the user where modificationscan be made to the model. The implementations thoroughly detailed how optimizations canbe made to make the latency as small as possible and provide a lag-free user experience. Theirimplementations were designed to work with a variety of different software which was alsomentioned as future improvements. The final paper[13] by Edwards et al. used a uniqueapproach where users either interacted with a client game or a server game. It also supportedweb player versions of the game. The implementation used a combination of the FBX andOBJ file format but found that IFC would have been a better candidate due to it allowing forstoring both geometric and parametric data. The other three papers created their own formatfor storing the 3D data which shows that both methods are possible.

5.1.3 File-based implementationThe implementation section described a file-based approach using CET Designer and UnrealEngine. Despite producing a small amount of code an automated workflow was set up whichallowed the user a hands-free export and import between software. Since Unreal Engine alreadyhad a lot of functionality built in there wasn’t a lot of work on that end. Using another softwaresuch as Unity or Blender might have resulted in a longer and more difficult implementation.Since no papers were found to support or refute this claim, it would be interesting to findout more about this. Compared to a streaming based approach this method is significantlyeasier to set up. The problems arose from picking the correct format and creating models

33

5.2. Method

which were well suited for evaluation. The initial aim was to test using glTF but it showedto be not feasible since there was poor support in other software. This meant that changeshad to be made during the results phase. As stated previously the software should have beentested during the prestudy as well to give a more comprehensive view of their capabilities anddownsides.

The results from the evaluation shows that there is a difference when using different files ofvarying sizes. It can depend on the number of objects, triangles, how large the texture files areand how many textures are used. There is also difference in using FBX and glTF. glTF wasonly just added in CET Designer and it’s in an experimental stage. This could have affectedthe results negatively with regards to the time it takes to create the glTF file as well as how itconforms with the file standards. Many different established software don’t even support glTFyet which shows that it might be in an early stage of adoption. Loading files in Unreal tooka lot of time due to ”Compiling shaders”. This process has a lower priority to not interferewith other processes. According to user forums there were fixes for this, however the fixestried didn’t show an improvement to the load time. During loading the CPU and RAM usagespiked up to above 90%. When very large files were loaded it wasn’t possible to interact withthe Unreal editor and CET Designer was also less responsive. In the future these tests shouldbe revisited with proper knowledge about the software and how they are used optimally. Thedifferences in results come from how the software handle the imported files. In the case ofCET Designer the models are turned into assets in the form of Snappers. Snappers are objectswhich contain not only meshes and textures but also information about how they relate toother Snappers. The same thing occurred in Unity and Unreal Engine where the models wereturned into internal assets for use later as game objects. This does not seem to be the case forLumion which loaded the models much quicker. In the paper[39] by Nopachinda and Erganthey found that game engines were very slow in importing files compared to the time it tookto render them. Using three different geometric granularities (Coarse, Medium, Fine) in thefiles they found that the import times grew from 12 minutes to almost an hour whereas therendering time reached a peak at 7 minutes. Evaluating this further for different software andusing files varying in geometric and material detail would be useful for future work in thisarea.

5.1.4 Network-based systemThe sketch of the network-based system used lessons from the literature study. It combineduseful architecture structures, database formats and optimizations. It could have been moredetailed and become a larger part of this thesis. To give a comprehensive view of the entire3D data synchronization area of research the thesis was divided into these four parts. Therewasn’t enough time to put this system into actual code, though that could be the basis forfuture work. The papers which form a basis for the network-based system needed to be moredetailed in how the systems were built in order to replicate them successfully. There aremissing parts such as which programming languages, libraries and protocols were used. Thisleads to a sketch which is less detailed than a fully functional implementation. In general,there was a lack of detailed information in the papers which might have been mitigated bylooking at code bases instead. The papers didn’t include links to GitHub repositories or siteswhere the source code can be audited. Combining the literature study with a code study couldhave proved helpful when getting down into the finer grained details of the system. Searchingfor plugin implementations for rendering engines on GitHub and going through the code wouldbe a great complement to the literature study.

5.2 Method

The method was divided into the same sections as the results chapter. This structure allowedfor easing into the subject and get more knowledge about this area as the work progressed.

34

5.2. Method

Having these four parts meant that there was more flexibility when it comes to the size of thepaper as certain parts could be removed if there wasn’t enough time. The implementation waskept small to allow for work on a network-based system which could be the basis for futurework.

5.2.1 PrestudyImprovements could be made to the method used. Starting with the prestudy there was a lackof input from the community. Gathering feedback from Configuras users could be interestingto find out which rendering software they prefer to use and which they have used in the past.This was an idea that came up late in the project and wouldn’t have been possible to completein the given time frame. This information should have been taken advantage of in a usefulway as well. The direction of this paper didn’t align with performing such a study. Anotherimprovement is that the paper could have gone more in-depth on what opportunities thedifferent software provided for developers and what type of development they support. Thisinformation could be useful for future work in this area.

5.2.2 Literature studyThe use of a literature study provided great insights into what has been done previously inthis area and what has been suggested for future work. It was difficult to sort through allthe papers and a more clearly defined list of prerequisites should have been done beforehand.Such as only including papers released in the last five years, papers that contain more thanone author and papers which have been published in esteemed journals. The papers seemed tobe very focused on BIM and architectural visualization in general. This could have skewed thegeneral findings since it is only a part of the use case for 3D data and 3D rendering software.When it comes to replicability it is simple to find which sources have been used in the referenceschapter though if you only use the same search words and follow the method described youcould end up using other sources and coming to other conclusions. Many of the papers usedwere published in journals and were well-cited, though the validity of some sources could becriticized since they are part of master thesis work and might not be sufficiently peer-reviewed.Since so many papers were used and the findings seem to align the validity shouldn’t be anissue.

5.2.3 File-based implementationThe method of the file-based implementation is based on creating a simple workflow using aminimal amount of code. Since CET Designer is used, which isn’t open source, it would bedifficult to replicate this method. However, the general concept should be replicable in manydifferent software using the explanations in this thesis. Unreal Engine is well-documentedand has an active forum where developers can get help with all kinds of problems. Theimplementation could have been tested and evaluated by developers or end users to see if itwas useful and sufficiently simple to use. This was discarded since the implementation couldnot be fully packaged in time to allow for user testing. User testing was not the focus of thisthesis as this work was exploratory and a proof-of-concept for future work as explained in thedelimitation section 1.4. The performance was tested instead of user metrics since it wouldnot be interesting to keep working on this type of implementation if it wasn’t viable and therewere more optimal solutions such as a network-based approach.

5.2.4 Network-based systemThere wasn’t enough information in the method to get a proper grasp on how the network-based system worked. This is partly due to the fact that it is dependent on the research foundin the literature study which is described at a later stage in the paper. If there was more time

35

5.3. The work in a wider context

available the network-based system could have been implemented. To not go through withthat was a decision made between the author and one of the supervisors at Configura. Tocreate a complete solution would take too long and Configura wanted to focus on creating afoundation for future work instead. In comparison, a similar system by Lin et al. [35] involvedconnecting BIM models to a database that sent 3D data to a VR display. This work took 4developers a total of 6 months to create. It is a much larger implementation compared to whatwould have been created so it can be seen as a high estimation for this kind of project. Thisthesis previously mentioned the project by Green [27] where he created a system for streaming3D data from Maya. That paper was also part of a master thesis though he didn’t include apre-study survey, literature study and implementation of a file-based system. He also didn’tstream the data to a 3rd party software. This could have led to some additional issues.

5.3 The work in a wider context

The focus of this thesis is to find ways of allowing collaboration between 3D software. Col-laboration can be very good for both companies and users since it allows software to be morespecialized within a certain area. It is in the company’s interest to keep the users satisfied andthat goes hand in hand with allowing them to produce content freely. Being able to exportand import your drawings and designs to many different software means that you can take ad-vantage of different features that might not be available if you were locked to a single software.As seen in table 4.1, the software have different usage and supported file formats. Some mightsupport features such as virtual reality, augmented reality, material editing, animations andrigging whereas others don’t. Providing easy to access plugins which enable direct links meanthat users can get feedback instantly to changes in the model or drawing. This also opensup to collaborations between users where two or more computers can be linked together andperform changes in unison. This could greatly improve the efficiency of the users and couldbe an interesting foundation for a new study in this area.

36

6 Conclusion

This chapter summarizes the conclusions that can be made from this work. It is divided intosections relating to each research question. At the end of the chapter future work is presented.

6.1 What research exists on 3D data sharing between software?

Several papers were found in the area of which those deemed most interesting were includedin this thesis. Some papers were also excluded because they showed the same results as othersor were old enough that the methods and software used were outdated. What was found isthat 3D data sharing can be done using a local shared file which software have access to forreading and modifying. There is also an approach where the 3D data is streamed throughcommunication protocols either directly or through intermediate servers and databases. Thelatter approach seemed to be a greater topic of research as it was easier to find papers onthis subject, and they came with many different variations and modifications. It seems tobe a continuing topic as there were papers released in 2021 as well. Both approaches haveadvantages and disadvantages. The file-based approach seems to be easier to set up sinceit uses existing functionality with small modifications. All 3D software have some sort ofimport and export functionality and the modifications needed to automate the workflow can berelatively simple compared to a streaming approach. This can be seen by the implementationdeveloped and tested in this thesis. It only required slight modifications in the CET Designersource code and on the Unreal Engine side it was possible to use existing features and code.Setting up a server and database or creating a protocol for streaming 3D data over TCP wouldhave required greater efforts. This can be proved by studying the papers in section 4.2.2. Anexample is the work by Du et al. [12] which involved three authors who created a data transferprotocol and format which needed many improvements to function optimally. At the sametime file-based approaches can also create problems where bugs can occur between differentsoftware where for example file formats are interpreted differently. In summary, there is afair amount of research in this area and there are some optimizations which can be applied tothe processes and technologies used in the implementations. There is not yet a system whichconnects all major 3D drawing and rendering software and there could be a great opportunityfor researchers and developers to try and tie them all together.

37

6.2. What limitations does an automated file-based import-export workflow have?

6.2 What limitations does an automated file-based import-exportworkflow have?

The implementation described in section 4.3 shows that it can be fairly easy to set up anautomated import-export workflow, at least using the software described in this thesis. Othersoftware such as Revit, 3ds Max and Unity are referenced in papers in the literature studywhich also show that it is possible. Limitations mostly come from not having access to thesource code or an API which holds all the necessary functions.

There is also the issue of selecting which file format to use. In the prestudy in section 3.1,some file formats are only supported by a small amount of software. This caused problemsas glTF was initially chosen for the implementation though there wasn’t enough support forthis in the software used for reference testing. Both FBX and glTF were used for testing theimplementation to get a comparison. There isn’t a single perfect file format for every use caseas some do not hold necessary information such as parametric data. There are also differencesin how materials and geometric data are represented which can lead to varying results whenvisualizing the 3D scenes and models. You also need to make sure that files are properlyprepared before being imported into other software.

From the testing the conclusion can be drawn that software can severely impact the userexperience in the form of slow loading times. When choosing which 3D software to use for animplementation there should be a consideration taken for how efficient it is at importing andexporting files. When files get too large or too detailed it will result in long wait times duringwhich the computer could not be used properly. When software need to load in large modelsand scenes it takes up resources which other software cannot use. These resources includeprocessing power and memory.

6.3 How can a network-based 3D data system be described usingexisting research?

Using existing research developers can take advantage of optimizations and avoid pitfalls whichauthors have come across in the past. Useful information such as architecture designs, databasestructure and communication charts could be researched. Combining this with knowledgeabout the software and systems developers want to work with they can create a customizedsystem for a potential implementation. One thing that was lacking in the existing researchwas more in-depth descriptions about programming languages, libraries and protocols used.Since there isn’t access to any source code it would be difficult to completely reproduce theresults from the papers. One possible improvement to the method used in this paper could beto research working implementations published on GitHub. This could tie together theory andpractice so the reader gets a complete overview of how an efficient system could be designedand implemented. The system specified in this thesis could be used in future work where anevaluation of the user benefits as well as performance requirements can be made.

6.4 Future work

For future work in this area it would be interesting to see the network-based system describedin this paper be put into code and tested according to user centered metrics. Demands onlatency and usability could be evaluated to find out what users want to get out of this kind ofsystem. Something which was missing from some of the reports was a comparison to existingframeworks and tools. Creating a system from scratch takes a significant amount of timeand there could be systems which already have the sought after functionality. In this thesispaper there wasn’t enough time to explore this fully. Therefore, for future work it could be

38

6.4. Future work

interesting to look at systems like the NVIDIA Omniverse Platform1 which is currently in anopen beta stage.

1https://developer.nvidia.com/nvidia-omniverse-platform

39

Bibliography

[1] Robert McNeel & Associates. Rhino3D. url: https://www.rhino3d.com/. Accessed:2020-12-17.

[2] Autodesk. 3ds Max. url: https://www.autodesk.se/products/3ds-max/overview.Accessed: 2020-12-17.

[3] Autodesk. Maya. url: https://www.autodesk.se/products/maya/overview. Ac-cessed: 2020-12-17.

[4] Autodesk. MotionBuilder. url: https : / / www . autodesk . com / products /motionbuilder/overview. Accessed: 2020-12-17.

[5] Autodesk. Revit. url: https://www.autodesk.se/products/revit/overview. Ac-cessed: 2020-12-17.

[6] Ross Bille, Shamus P. Smith, Kim Maund, and Graham Brewer. “Extending BuildingInformation Models into Game Engines.” In: Proceedings of the 2014 Conference on In-teractive Entertainment. IE2014. Newcastle, NSW, Australia: Association for ComputingMachinery, 2014, pp. 1–8. isbn: 9781450327909. doi: 10.1145/2677758.2677764. url:https://doi-org.e.bibl.liu.se/10.1145/2677758.2677764.

[7] cgarchitect. Architectural Visualization Rendering Engine Survey Results. url: https:/ / www . cgarchitect .com / features / articles /b352ebe4 - 2019 - architectural -visualization-rendering-engine-survey-results. Accessed: 2021-02-11.

[8] Configura. CET Designer. url: https : / / www . configura . com / products / cet -designer. Accessed: 2020-12-07.

[9] Configura. CM Language. url: https : / / support . configura . com / hc / en - us /sections/360008682434-CM-Language. Accessed: 2021-02-11.

[10] Dilbert. House | 3D Warehouse. url: https://3dwarehouse.sketchup.com/model/bad472a435d3fab41992a70eb6b3a2a6/House. Accessed: 2021-03-01.

[11] Dmitriy Dorofeev and Sergey Shestakov. “2-Tier vs. 3-Tier Architectures for Data Pro-cessing Software.” In: ICAIT’2018. Aizu-Wakamatsu, Japan: Association for ComputingMachinery, 2018, pp. 63–68. isbn: 9781450365161. doi: 10.1145/3274856.3274869.url: https://doi-org.e.bibl.liu.se/10.1145/3274856.3274869.

40

https://www.rhino3d.com/

https://www.autodesk.se/products/3ds-max/overview

https://www.autodesk.se/products/maya/overview

https://www.autodesk.com/products/motionbuilder/overview

https://www.autodesk.com/products/motionbuilder/overview

https://www.autodesk.se/products/revit/overview

https://doi.org/10.1145/2677758.2677764

https://doi-org.e.bibl.liu.se/10.1145/2677758.2677764

https://www.cgarchitect.com/features/articles/b352ebe4-2019-architectural-visualization-rendering-engine-survey-results



https://www.configura.com/products/cet-designer

https://www.configura.com/products/cet-designer

https://support.configura.com/hc/en-us/sections/360008682434-CM-Language

https://support.configura.com/hc/en-us/sections/360008682434-CM-Language

https://3dwarehouse.sketchup.com/model/bad472a435d3fab41992a70eb6b3a2a6/House

https://3dwarehouse.sketchup.com/model/bad472a435d3fab41992a70eb6b3a2a6/House

https://doi.org/10.1145/3274856.3274869


Bibliography

[12] Jing Du, Zhengbo Zou, Yangming Shi, and Dong Zhao. “Zero latency: Real-time synchro-nization of BIM data in virtual reality for collaborative decision-making.” In: Automationin Construction 85 (2018), pp. 51–64. issn: 0926-5805. doi: https://doi.org/10.1016/j.autcon.2017.10.009. url: http://www.sciencedirect.com/science/article/pii/S0926580517309172.

[13] Gareth Edwards, Haijiang Li, and Bin Wang. “BIM based collaborative and interactivedesign process using computer game engine for general end-users.” In: Visualization inEngineering 3.1 (Feb. 2015), p. 4. issn: 2213-7459. doi: 10.1186/s40327-015-0018-2.url: https://doi.org/10.1186/s40327-015-0018-2.

[14] Gustav Eriksson and Anton Engberg. “Automating the CAD to Virtual Reality Pipelinefor Assembly Simulation.” MA thesis. Linköping University, Machine Design, 2020, p. 71.url: https://www.diva-portal.org/smash/get/diva2:1444936/FULLTEXT01.pdf.

[15] Viktor Fält. “Strategies to effectively integrate a 3D model of a building in a softwaresystems for real-time visualization.” MA thesis. Linköping University, The Institute ofTechnology, 2015, p. 32. url: https://www.diva-portal.org/smash/get/diva2:838677/FULLTEXT01.pdf.

[16] FineHouse. Outdoor Kitchen Pergolas | 3D Warehouse. url: https://3dwarehouse.sketchup . com / model / f67b258f7f61d9a8e79d181dec16bca / Outdoor - Kitchen -Pergolas. Accessed: 2021-03-01.

[17] The Blender Foundation. Blender. url: https://www.blender.org/about/. Accessed:2020-11-11.

[18] Epic games. Auto Reimport. url: https://docs.unrealengine.com/en-US/Basics/AssetsAndPackages/AutoReImport/index.html. Accessed: 2020-12-07.

[19] Epic games. Datasmith. url: https://www.unrealengine.com/en- US/datasmith.Accessed: 2020-12-07.

[20] Epic games. Live Link Plugin. url: https : / / docs . unrealengine . com / en - US /AnimatingObjects/SkeletalMeshAnimation/LiveLinkPlugin/index.html. Accessed:2020-12-07.

[21] Epic games. Plugins. url: https : / / docs . unrealengine . com / en - US /ProductionPipelines/Plugins/index.html. Accessed: 2020-12-07.

[22] Epic games. Twinmotion. url: https://www.unrealengine.com/en-US/twinmotion.Accessed: 2020-11-11.

[23] Epic games. Unreal Engine. url: https://www.unrealengine.com/en-US/faq. Ac-cessed: 2020-11-11.

[24] Scott Gebhardt, Eliezer Payzer, Leo Salemann, Alan Fettinger, Eduard Rotenberg, andChristopher Seher. “Polygons , Point-Clouds , and Voxels , a Comparison of High-FidelityTerrain Representations.” In: Simulation Interoperability Workshop and Special Workshopon Reuse of Environmental Data for Simulation—Processes, Standards, and LessonsLearned. 2009.

[25] Enscape GmbH. Enscape. url: https://enscape3d.com/features/. Accessed: 2020-11-11.

[26] Graphisoft. Archicad. url: https://graphisoft.com/solutions/products/archicad.Accessed: 2020-12-17.

[27] Daniel Green. “An Interface for Real-Time Networked Streaming of 3D Scenes.” MAthesis. Teesside University, Jan. 2016, p. 50. url: https://www.researchgate.net/publication/327867528_An_Interface_for_Real-Time_Networked_Streaming_of_3D_Scenes.

41

https://doi.org/https://doi.org/10.1016/j.autcon.2017.10.009

https://doi.org/https://doi.org/10.1016/j.autcon.2017.10.009

http://www.sciencedirect.com/science/article/pii/S0926580517309172


https://doi.org/10.1186/s40327-015-0018-2

https://doi.org/10.1186/s40327-015-0018-2

https://www.diva-portal.org/smash/get/diva2:1444936/FULLTEXT01.pdf



https://3dwarehouse.sketchup.com/model/f67b258f7f61d9a8e79d181dec16bca/Outdoor-Kitchen-Pergolas



https://www.blender.org/about/

https://docs.unrealengine.com/en-US/Basics/AssetsAndPackages/AutoReImport/index.html

https://docs.unrealengine.com/en-US/Basics/AssetsAndPackages/AutoReImport/index.html

https://www.unrealengine.com/en-US/datasmith

https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/LiveLinkPlugin/index.html

https://docs.unrealengine.com/en-US/AnimatingObjects/SkeletalMeshAnimation/LiveLinkPlugin/index.html

https://docs.unrealengine.com/en-US/ProductionPipelines/Plugins/index.html

https://docs.unrealengine.com/en-US/ProductionPipelines/Plugins/index.html

https://www.unrealengine.com/en-US/twinmotion

https://www.unrealengine.com/en-US/faq

https://enscape3d.com/features/

https://graphisoft.com/solutions/products/archicad

https://www.researchgate.net/publication/327867528_An_Interface_for_Real-Time_Networked_Streaming_of_3D_Scenes



Bibliography

[28] Nemetschek Group. Vectorworks. url: https://forum.vectorworks.net/index.php?/topic/51142-twinmotion-plugin-sync/page/14/. Accessed: 2021-02-11.

[29] Lars Ivar Hatledal. “A Flexible Network Interface for a Real-time Simulation Frame-work.” MA thesis. NTNU, 2017. url: https://ntnuopen.ntnu.no/ntnu- xmlui/handle/11250/2685194.

[30] Keita Kado and Gakuhito Hirasawa. “Two-Way Cooperation of Architectural 3d Cad andGame Engine.” In: Proceedings of the 16th ACM SIGGRAPH International Conferenceon Virtual-Reality Continuum and Its Applications in Industry. VRCAI ’18. Tokyo,Japan: Association for Computing Machinery, 2018. isbn: 9781450360876. doi: 10.1145/3284398.3284420. url: https://doi- org.e.bibl.liu.se/10.1145/3284398.3284420.

[31] Khronos. glTF 2.0 Quick Reference Guide. url: https://www.khronos.org/files/gltf20-reference-guide.pdf. Accessed: 2021-03-01.

[32] Sam Kubba. “Chapter Five - Building Information Modeling (BIM).” In: Handbook ofGreen Building Design and Construction (Second Edition). Ed. by Sam Kubba. Sec-ond Edition. Butterworth-Heinemann, 2017, pp. 227–256. isbn: 978-0-12-810433-0. doi:https://doi.org/10.1016/B978- 0- 12- 810433- 0.00005- 8. url: http://www.sciencedirect.com/science/article/pii/B9780128104330000058.

[33] James Kurose and Keith Ross. Computer networks: A top down approach featuring theinternet. Pearson, 2010.

[34] Geon-hee Lee, Pyeong-ho Choi, Jeong-hwan Nam, Hwa-seop Han, Seung-hyun Lee, andSoon-chul Kwon. “A Study on the Performance Comparison of 3D File Formats on theWeb.” In: International journal of advanced smart convergence 8.1 (Mar. 2019), pp. 65–74.

[35] Yu-Cheng Lin, Yen-Pei Chen, Huey-Wen Yien, Chao-Yung Huang, and Yu-Chih Su.“Integrated BIM, game engine and VR technologies for healthcare design: A case studyin cancer hospital.” In: Advanced Engineering Informatics 36 (2018), pp. 130–145. issn:1474-0346. doi: https://doi.org/10.1016/j.aei.2018.03.005. url: http://www.sciencedirect.com/science/article/pii/S1474034617303373.

[36] Ellen Lupton. Graphic design theory: Readings from the field. Chronicle Books, 2009,pp. 127–132.

[37] Maxon. Cinema4D. url: https://www.maxon.net/en/cinema-4d. Accessed: 2020-12-17.

[38] Kenton McHenry and Peter Bajcsy. “An overview of 3d data content, file formats andviewers.” In: National Center for Supercomputing Applications 1205 (2008), p. 22.

[39] Sutenee Nopachinda and S. Ergan. “Challenges in Converting Building Information Mod-els into Virtual Worlds for FM Operations and User Studies in the Built Environment.”In: The 16th International Conference on Computing in Civil and Building Engineering(ICCCBE 2016). Osaka, Japan, 2016.

[40] “Physically Based Rendering.” In: Physically Based Rendering (Third Edition). Ed. byMatt Pharr, Wenzel Jakob, and Greg Humphreys. Third Edition. Boston: Morgan Kauf-mann, 2017, p. 1235. isbn: 978-0-12-800645-0. doi: https://doi.org/10.1016/B978-0-12-800645-0.50029-4. url: http://www.sciencedirect.com/science/article/pii/B9780128006450500294.

[41] Freddie Pintar. “Investigation and Implementation of a Live Connection between Con-figura CET and Revit Architecture 2009.” MA thesis. Linköping University, PELAB -Programming Environment Laboratory, 2009, p. 70. url: http://liu.diva-portal.org/smash/get/diva2:208793/FULLTEXT01.pdf.

42

https://forum.vectorworks.net/index.php?/topic/51142-twinmotion-plugin-sync/page/14/

https://forum.vectorworks.net/index.php?/topic/51142-twinmotion-plugin-sync/page/14/

https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/2685194

https://ntnuopen.ntnu.no/ntnu-xmlui/handle/11250/2685194

https://doi.org/10.1145/3284398.3284420

https://doi.org/10.1145/3284398.3284420



https://www.khronos.org/files/gltf20-reference-guide.pdf

https://www.khronos.org/files/gltf20-reference-guide.pdf

https://doi.org/https://doi.org/10.1016/B978-0-12-810433-0.00005-8

http://www.sciencedirect.com/science/article/pii/B9780128104330000058


https://doi.org/https://doi.org/10.1016/j.aei.2018.03.005



https://www.maxon.net/en/cinema-4d





http://liu.diva-portal.org/smash/get/diva2:208793/FULLTEXT01.pdf

http://liu.diva-portal.org/smash/get/diva2:208793/FULLTEXT01.pdf

Bibliography

[42] Florent Poux. How to represent 3D Data? url: https://towardsdatascience.com/how-to-represent-3d-data-66a0f6376afb. Accessed: 2021-01-21.

[43] Unity Technologies. Unity. url: https://unity.com/products/unity- platform.Accessed: 2020-11-11.

[44] Unity Technologies. Unity - Compare plans. url: https://store.unity.com/compare-plans. Accessed: 2020-11-12.

[45] Unity Technologies. Unity - Plug-ins. url: https://docs.unity3d.com/Manual/Plugins.html. Accessed: 2020-11-12.

[46] Unity Technologies. Unity Reflect. url: https : / / unity . com / products / unity -reflect. Accessed: 2020-12-07.

[47] Thien Tran Thi. “Importing a 3D model from an industrial design.” BA Thesis. Metropo-lia Ammattikorkeakoulu, 2015. url: https://www.theseus.fi/handle/10024/97743.

[48] Trimble. SketchUp. url: https://www.sketchup.com/. Accessed: 2020-12-17.

43

https://towardsdatascience.com/how-to-represent-3d-data-66a0f6376afb

https://towardsdatascience.com/how-to-represent-3d-data-66a0f6376afb

https://unity.com/products/unity-platform

https://store.unity.com/compare-plans

https://store.unity.com/compare-plans

https://docs.unity3d.com/Manual/Plugins.html

https://docs.unity3d.com/Manual/Plugins.html

https://unity.com/products/unity-reflect

https://unity.com/products/unity-reflect

https://www.theseus.fi/handle/10024/97743

https://www.sketchup.com/

Documents

Synchronizing 3D data between software