Utilising Game Engines for Architectural Visualisation

for Dad.

Abstract In the last few years visualisaion has become a more integral part of the architectural process.

From development to planning to markeing images, projects of all sizes oten require the services of an architectural visualiser for one reason or another. The digital architectural visualisaion process itself has, however, remained much the same since 3DS Max and Photoshop became widely accessible. This thesis aims to quesion whether now is the ime to embrace new technologies, namely that of the game engine, by construcing an interacive architectural visualisaion using the Unreal Development Kit. The worklow for creaing a game engine-based visualisaion will be dissected and explained in order to ascertain whether it is a viable avenue for a visualiser with litle or no gamecreaion experience to venture down. The resuling scene will then be explored to determine the advantages and disadvantages of the game engine worklow when compared to a more tradiional digital visualisaion worklow.

Whilst the game engine method for visualisaions is quite a complex one it does ofer numerous advantages to both architects and clients, the ability to extract fully rendered images in a mater of seconds and walk around a virtual environment being one of the main ones. However these are ofset by the steep learning curve and the cost of using a high-end game creaion program for commercial purposes. What is certain though is that game engines deinitely provide myriad opportuniies for research and development of architectural visualisaions.

03

Acknowledgements I would like to thank Dr. Ertu Unver of the University of Huddersield, Ray Buterworth of ArcMedia and everyone else who ofered their help and guidance during this project.

I would also like to thank my friends and family for keeping me sane during my ime as a Masters student.

05

Uilising Game Engines for Architectural Visualisaion

by Paul Fox

August 2013

Table of Contents Abstract

03

Acknowledgements

05

Table of Contents

08

1.0 - Introducion

12

2.0 - Literature Review

14

2.1 - Architectural Visualisaion 2.2 - Game Engines & Real-Time Visualisaion

3.0 - Methodology 3.1 - Architectural Worklow 3.2 - Sotware Evaluaion 3.2.1 - CAD Drating 3.2.2 - ‘Tradiional’ 3D Modelling 3.2.3 - Rendering Engines 3.2.4 - Building Informaion Modelling 3.2.5 - Game Engines/Real-Time Rendering Engines

08

22

4.0 - Experiment

32

4.1 - Design Development 4.2 - Creaing a Scene for UDK 4.2.1 - 3DS Max to UDK Worklow 4.2.2 - Construcion in 3DS Max 4.2.3 - Scene Development in UDK 4.3 - Tesing the Scene

5.0 - Analysis

48

5.1 - Tradiional vs. Game Engine 5.2 - Exploring the Scene

6.0 - Conclusions

54

References

64

Appendices

66

A - Interviews with Site Residents B - Interview with Funeral Director C - Conversaion about Real-Time Technologies D - Exploring the Interacive Visualisaion

09

1.0 - Introducion Whenever an interesing new technology emerges, people inevitably look for ways to expand and exploit the opportuniies available to them through it. So it was with game engines, the programs developed and used to create video games. The term ‘game engine’ came around in the 1990s (Al-Najdawi, 2007) with the advent of First Person Shooter (FPS) games such as ‘Doom’ and has stuck around ever since.

Nowadays, game engines are used for far more than just creaing games and content for the entertainment industry. From the moment the power and possibiliies ofered by game engines began to increase, other industries began to noice their potenial for use in other industries. One such industry is the built environment. From as early as 1994 the idea of a virtual walkthrough of an exising or imagined urban environment had been mused (Miliano, 1999). The real-estate market was the irst to noice this potenial, mulling over the fact that the ability to show one client many properies from a single locaion would make good business sense, but the architectural world itself soon caught on.

Architecture is a very complex and precise subject requiring a vast amount of work and research to achieve results that will not only fulil a client’s expectaions but also provide something that its within its intended surroundings. So it stands to reason that a lay-person may not be able to completely follow all of an architect’s ideas and drawings that are presented to them which could cause confusion and misunderstanding about a project. ‘Visualizaion has been married to architecture since the beginning of ime’ (Karenoke, 2012) as it has always been necessary to communicate ideas in the most efecive way possible and, in much the same way as any longstanding pracice, visualisaion has evolved with ime and technology.

Architectural visualisaion has become an increasingly sophisicated, not to menion necessary, tool in the last few years thanks in part to more powerful hardware and increasingly versaile sotware and this in turn has led to architects and visualisers waning to explore new, and potenially beter, ways of communicaing ideas since this is the main goal of architectural visualisaion. This is where the current generaion of game engines comes into play.

This thesis aims to explore the viability of game engines as a useful tool for architectural visualisaions focusing mainly on small to medium sized companies or individual arists. What are the beneits, drawbacks, cost and ime implicaions to using game engines and will it provide a beter way for the public to experience the un-built environment?

12

This thesis will centre on documening the challenges faced and the process of using a game engine to create an interacive, virtual walkthrough of an architectural project and whether game engines are a viable tool for an architectural visualiser. The game engine in quesion is Epic Games’ Unreal Development Kit (UDK) which will be used to create a virtual, interacive presentaion of a Funeral Parlour in Lytham St. Annes, England, a live project being undertaken by architectural visualisers Arc-Media.

The thesis will discuss the diferent sotware available for creaing compelling visualisaions for either staic, animated or real-ime imagery however it will not go in to great detail about all the technical aspects of a game engine as they are far too numerous to be dissected here.

13

2.0 - Literature Review This secion aims to provide an overview of exising research into the ields of architectural visualisaion, game engines and the amalgamaion of the two.

The purpose of this thesis is to ascertain whether we are now at a stage where game engines can be a viable producion tool in the architectural visualisaion industry and to see if Dr. Hudson-Smith of the Centre for Advanced Spaial Analysis at the University College London was correct in his assumpions that ‘game engines are desined to play an ever-increasing role in the industry’ (Varney, 2007) and inally to judge whether preconcepions that the use of game engines in visualisaion is sill seen as a ‘slightly amusing sideline’ (Hudson-Smith, 2007).

Schroeder (2007) summarised previous research into virtual reality which unanimously concluded that the use of video game engines, paricularly those based around the ‘First Person Shooter’ (FPS) format, was the most pracical way of bringing the desired level of interacivity and visualisaion to a mainstream audience at afordable cost. Conway (2011) concurred with this asserion adding that ‘the irst person shooter is the only game genre that incorporates all the features necessary to make this method of architectural visualizaion efecive’. Conway coninues on to describe the features necessary for a convincing interacive visualisaion, including a irst-person point of view, gravity, collision detecion and realism.

The mid to late 2000s was perhaps the irst ime that the use of game engines to create architectural visualisaions became a feasible possibility, partly due to the availability of free to use, or at least afordable, game engines such as Oblivion. If one imagines all the opions and possibiliies available to a player during a game, for instance the ability to open doors, pick up weapons, interact with other characters and so on, if the principles that deine these types of acions were to be translated over to an architectural visualisaion then one would be able to create an immersive, explorable world which could greatly aid the design, development and indeed markeing of architectural projects at any stage of their life.

The potenial of game engines for uses other than purely gaming has come about thanks to their coninuing development in to the realms of ‘user-friendliness’. To a seasoned 3D arist the layout of a game engine would not be too far removed from their usual tools, thus allowing for an easier transiion from a tradiional 3D worklow to a game engine worklow.

It is not just the beneit to the arist that is the main draw behind the desire to uilise game engine technology in the architectural industry. It was noted by Neal Bürger (2013) during

14

interviews of paricipants exploring a game engine visualisaion that thanks to these technologies ‘people without training or the ability to imagine the architecture have a higher accessibility to architecture.’ This is because an interacive game engine-based visualisaion provides an experience much closer to real life than sills or animaions can. The ability to take up any posiion within an environment and view it from any angle is without a doubt the main aspect that sets interacive visualisaions apart from their staic counterparts.

2.1 - Architectural Visualisaion For as long as there have been architects there has existed the need to communicate their ideas. Tradiional architectural drawing has generally taken the form of measured, technical surveys and drawn construcions which, in their nature, are more useful as a guide for building than a perspecive drawing would be. Perspecive drawings emulate the way we see the world, with lines converging at some imaginary ‘vanishing point’ in the distance, whereas technical drawings do not as they are, by their very deiniion, ‘technical’, which leads to a problem with these drawings, arguably the default way of communicaing an architect’s ideas, since they are requirements for planning applicaions and construcion documents. Anything technical generally has to be learnt before it can be understood and the majority of an architect’s clients will not have had the need to learn how to read technical drawings. This disparity in abiliies could lead to miscommunicaion in aspects of design or planning with negaive consequences for a project.

‘Visualizaions provide a look into the future at the envisioned physical structure’ (Karenoke, 2012) and as civilisaion has become more demanding, and technology increasingly more capable at realising our thoughts, so it has been required that more and more accurate representaions of projects have become necessary.

Possibly the irst architect in History, the Egypian Imhotep who lived around 2600 BCE (Benge, n.d.) was ‘always conceived holding his medical scrolls and his architectural drawings’ (Imhotep, 2013) alluding to the fact that the visualisaion of ideas has been around as long as the profession. It’s not unlikely that methods of architectural visualisaion may have gone hand in hand with preferred methods of communicaion and art creaion of the ime they were produced. The images on the right demonstrates a possible history of architectural visualisaion relaing directly to the popular arisic processes of the ime. It’s important to note that this diagram does not represent the history of conceptual visualisaion as it would be diicult to photograph an imaginary building.

16

The more perinent points in visualisaion history relaing to this thesis occurred irst in 1982 with the iniial release of Autodesk’s AutoCAD (Hurley, 2013), a program which is now very much the industry standard architectural drating program, and then in 1990 with the irst public release of Autodesk’s 3D Studio (Baker, et al., 2010), known today simply as 3DS Max, another industry standard program within architectural profession, in which it is widely used for the creaion of computer-generated architectural visualisaions (Slick, n.d.), and the games industry. 3DS Max is so widely used that in a 2009 survey of the architectural visualisaion community CGArchitect it was discovered that 83% of architectural visualisers used the program (Motle, 2009). It is sill widely used today, and the preferred method of working, by the vast majority of architectural visualisers and that usage shows no sign of abaing.

2.2 - Game Engines & Real-Time Visualisaion It’s no surprise that computer-based games have been around for a while. Possibly the irst interacive electronic game, patented in 1948 by Thomas T. Goldsmith Jr. and Estle Ray Mann, was a missile simulator played on a Cathode Ray Tube (Conway, 2011) rather than using any sort of graphical display. The irst computer designed speciically to play games came about soon ater when Ferrani Internaional Plc. created the NIMROD, albeit it was only designed to play one game; ‘Nim’.

There is debate over what is deiniively the irst computer game; Bellis (n.d.) and Campbell (2009) argued that it could be ‘OXO’ (Noughts and Crosses) created by Alexander S. Douglas in 1952 and the irst game to use a digital graphical display, ‘Tennis for Two’, created by William Higinbotham in 1958 to liven up science for open day visitors to his lab, 1962’s ‘Spacewar!’ created by Steve Russell or ‘Chase’, created in 1967 by Ralph Baer which was the irst ‘video game’ to be played on a television set. What goes without quesion is that they were all precursors to today’s technology and the direcion in which gaming travelled.

The current generaion of 3D game engines arguably have their roots in the ith generaion of games consoles (Laud, n.d.), such as the Sony PlayStaion and Sega Saturn both released in 1994 and the Nintendo 64 released in 1996, as well as games such as the Quake series, Epic’s Unreal and Super Mario 64; a game to which ‘any 3D game of the past 15 years owes a debt of graitude’ (Sliva, 2012). This point in ime marked the switch to the technological path which is sill travelled today, uilising polygon worlds and characters, hardware rendering and advanced lighing and post-processing efects such as coloured lighing, bloom, depth of ield and moion blur.

18

As menioned previously, First-Person Shooter games are the direct inluences for game engine-based architectural visualisaions. Games such as Doom, Quake, Unreal and Call of Duty pioneered many of the principles which will lend themselves perfectly to the creaion of believable architectural environments.

20

3.0 - Methodology This thesis will take an empirical approach to assessing the viability of game engines for architectural visualisaion supported by qualitaive research to aid in the assessment of its success. This chapter will outline and address the main issues and requirements which underlie the pracical project to be undertaken.

3.1 - Architectural Worklow In order to ascertain where game-engine technology could be of use in architectural visualisaion, it is important to understand the general worklow of an architectural project.

At their base, architectural projects generally follow a set procedure. Once a client has employed an architect a feasibility study along with sketch designs will usually be produced before technical drawings can be created. Technical drawings used to be created with pens and pencils on drawing boards but nowadays it is most likely they will be produced with a CAD drating package.

Not all architectural projects will require 3D models, either digital or physical, but in general a digital 3D model, especially those of a photorealisic nature, will be produced ater the technical drawings and designs have been more or less inalised. This is due to digital renderings generally being required somewhere within the RIBA (Royal Insitute of Briish Architects) work stages A to D (RIBA, 2013), right, and as planning documents or for markeing and illustraion purposes.

This is by no means a rigid structure which one must sick to, as 3D modelling can be used for any aspect of a project for which it is deemed necessary.

3.2 - Sotware Evaluaion There are various 3D modelling programs that seem to be ubiquitous with diferent aspects of digital design. Some programs, for example, are designed for, and are paricularly adept at, sculping ine details at a high-polygon level, whereas others are focused more towards modelling large structures or creaing high-quality, professional animaions. Whatever a person’s needs, there is likely to be one, or many, packages to suit.

22

A B C D E

Appraisal

Design Brief

Concept

Design Development

Technical Design

This secion will discuss the various 2D drating, 3D modelling and rendering packages available to digital arists. It will begin with a look at the more tradiional programs associated with creaing architectural visualisaions and other CG content before moving on to a look at what opions there are for creaing real-ime interacive visualisaions.

3.2.1 - CAD Drating With architectural visualisaion, a project oten starts with 2D CAD drawings. As these are the architect’s preferred method of detailing projects they are oten used as a base from which to create a 3D model.

Autodesk leads the way in CAD drating programs with its AutoCAD program. This is the industry standard program and will be found in the majority of architect’s pracices. As with most computer programs it is updated yearly in an atempt to keep things fresh and relevant.

AutoCAD includes a basic ability to model in 3D but what it excels at is an ability to create and organise drawings in 2D. Other programs such as ArchiCad and Microstaion ofer similar features but won’t be discussed in detail here.

3.2.2 - ‘Tradiional’ 3D Modelling Autodesk has a irm grip on the 3D design sotware market thanks to its extensive suite of programs which ofer seemingly anything anyone in any part of the CG industry might need.

Programs such as 3DS Max and Maya are industry leading, and indeed industry standard, programs (Slick, n.d.) in the ields of hard surface modelling and computer animaion and visual efects respecively whilst Mudbox is constantly pushing Pixologic’s ZBrush to be the character arist’s tool of choice.

In the ields of architectural visualisaion and game asset creaion 3DS Max has long been the industry standard. This is thanks in part to a huge variety of content creaion tools including the ability to use polygons or NURBS (Non-Uniform Raional B-Splines) to create assets, UV map them and texture them with relaively simple to learn tools.

In recent years SketchUp has become a very useful tool for digital arists and architects alike. It’s not uncommon to ind a version in any architect’s oice or university architecture department thanks in part to its ease of creaing 3D models and the availability of a free version. SketchUp is incredibly useful for creaing and developing concepts and sketch images due to its ‘push and pull’ modelling interface.

24

3.2.3 - Rendering Engines Rendering is one of the inal stages of compiling a 3D scene. It is the process of taking all the data provided in an arist’s scene and translaing it into a inished image. Arguably the most inluenial rendering tool available to architectural visualisers is Chaos Group’s ‘V-Ray.’ Indeed Jef Motle’s 2009 survey on the state of the architectural visualisaion industry saw 72% of respondents claim they use V-Ray in their work. V-Ray is famed for being the fastest, easiest and one of the highest quality rendering engines available (Alexander, 2010).

Possibly V-Ray’s main rival in the rendering stakes is NVidia’s Mental Ray (originally developed

by Mental Images). Mental Ray has an advantage straightaway over V-Ray in that it now comes shipped with 3DS Max so by default it will be the rendering engine of choice for many. However, it is sill not quite as popular in the architectural visualisaion industry as V-Ray with Motle’s survey suggesing that only 33% of the industry uses Mental Ray. Both V-Ray and Mental Ray ofer a similar service at a similar level and generally the decision on which sotware to use is down to arist’s preference.

3.2.4 - Building Informaion Modelling Building Informaion Modelling (BIM) is a relaively new concept. It combines tradiional 2D drating with 3D modelling whilst also incorporaing building informaion such as costs and quaniies. The aim is to make the model the primary tool for documentaion from which ‘reports’ such as plans, schedules and bills of quaniies can be derived (Pitard, n.d.).

Autodesk’s Revit sotware is the forerunner in the ield due to it being speciically built for Building Informaion Modelling. Revit provides features which support architectural design, structural engineering and construcion (Autodesk, n.d.) with the aim of helping people through all aspects of a building’s life, from concept to demoliion. It is important to note that BIM is not a 2D or 3D modelling soluion but it is in fact a way of working and of documening and managing all aspects of a building.

3.2.5 - Game Engines/Real-Time Rendering Engines When beginning to look into readily available and accessible game engines to uilise for realime architectural rendering there are three standout candidates to look at; UDK, CryEngine and Unity 3D. Developed by Epic Games, UDK (Unreal Development Kit) is ‘the free professional development framework of Unreal Engine 3, which powers many of the most popular video games throughout

26

the world.’ It also contains a number of tools for the creaion of real world physics, facial animaions, foliage editors and scriping tools amongst many other things (NVidia Developer Zone, n.d.). Of the three engines UDK has been around the longest, since 2009, and has a wellestablished user base, community forum and boasts a wealth of documentaion allowing new and exising users to learn quickly and get as much out of it as they can.

One of the main features of UDK is the ‘lightmass’ advanced global illuminaion solver. This provides the user with the ability to create efecive, realisically lit environments from as litle as just one sun light. Lightmass also allows the user to take advantage of ambient occlusion and fully dynamic specular lighing. Lighing is an incredibly important aspect of creaing accurate, believable computer-generated visuals.

The UDK is free for non-commercial use which is ideal for students and hobbyists but would restrict architects or property developers from using it on real-world schemes as licensing can cost up to a seven-igure sum albeit only for AAA games.

CryTek’s CryEngine, originally used for the game Far Cry, is primarily focused around a ‘sandbox’ editor capable of creaing huge terrains. Where CryEngine difers from UDK is that it works ‘addiively’, meaning objects are added whereas UDK likes to subtract from illed areas. Much like UDK though, it is freely available to anyone for non-commercial use but a user would have to pay a potenially substanial igure if they wanted to start making money from their creaions.

CryEngine contains all the features you’d expect of a high end interacive rendering soluion such as natural lighing, dynamic sot shadows, real-ime global illuminaion, real-ime local relecions, high dynamic range (HDR) lighing, colour grading as well as character and animaion tools, physics and much more. CryTek pride themselves on creaing world-leading, high quality graphics by pushing technology to the limit and CryEngine 3 has been described previously as possibly being the most powerful tool for creaing graphics on Earth (Batjes, 2012).

Unity 3D, developed by Unity Technologies, is by far the cheapest opion of the three game engines discussed here. In contrast to UDK and CryEngine, Unity’s free version can be used to sell games so long as the creator’s annual gross revenues do not exceed US$100,000 (Unity Technologies, 2013). However, a Pro version of Unity is available for $1500.

Unity is described as ‘a powerful cross-plaform 3D engine and a user friendly development environment’ (Zamojc, 2012) and aims itself at all abiliies of game designer. However it has so far not been used to create the sort of AAA games which UDK/Unreal and CryEngine have. Unity is seemingly pitched more towards mobile devices and indeed part of its allure is the simplicity in creaing content for iOS and Android devices.

28

It’s important to note that some companies have taken the idea of real-ime rendering for architectural visualisaions a step further by creaing architecture-speciic real-ime rendering engines. These are essenially game engines stripped of the game elements and used to provide real-ime interacive rendering speciically for architectural projects. The main products in this category are Lumion 3D and Twinmoion, however this thesis will not describe them in detail.

30

4.0 - Experiment The pracical aspect of this thesis will centre upon the creaion of an interacive architectural visualisaion created with 3DS Max and the UDK game engine. As the author has no prior experience with using game engines, the project will serve as an indicator to ascertain whether or not using a game engine for visualisaions is a viable path for the architectural visualiser by addressing the learning curve as well as seing out to achieve the goals stated in Chapter 1.

The project for which the visualisaion is to be created is a Funeral Parlour at Bank House in Lytham St. Annes, Lancashire, England (right). Visualisaion professionals Arc-Media were tasked with creaing a sill image of the proposal and have provided CAD plans and associated imagery for this thesis. All other reference informaion such as elevaions and planning proposals were obtained from the Fylde Borough Council website (www.fylde.gov.uk).

In order to create a successful visualisaion it is important to know what the purpose of the visualisaion is to be. In this case residents occupying the houses surrounding Bank House have expressed concerns about the nature and logisics of a Funeral Parlour in a residenial area. A number of residents were strongly opposed to the project and expressed their concerns over many aspects of it including the ability of a hearse to adequately access the proposed entrance, the impact of the extra traic and worries over seeing the deceased being manoeuvred into the building, paricularly as the two adjacent properies have windows directly overlooking the rear entrance (Personal Communicaion, July 2013, see Appendix A). Therefore the most advantageous use of an interacive visualisaion for this project would be to create something which might be able to address residents’ concerns and possibly help design something beneicial to all paries.

32

4.1 - Design Development A Kirklees-based Funeral Director provided a list of facility requirements which any Funeral Parlour should ideally address (Personal Communicaion, July 2013, see Appendix B). These include: • • • • • • • • •

private area/s for clients to meet assembly area to gather before leaving for a funeral chapel/s of rest recepion area oice workshop/s for the preparaion of caskets/coins sterile embalming area refrigerated storage area preparaion area for the deceased

Some or all of these areas, possibly including addiional areas if needs be, should be included in any proposal depending on the size and nature of the Funeral Parlour. This thesis will focus on creaing the areas the public might reasonably be expected to have access to such as the recepion area, gathering point and chapel/s of rest.

As the exising building contains two loors one of the main aims of the interior layout was to open up the public area and take full advantage of the South East facing full height windows by seing the irst loor back. This creates a mezzanine area allowing a greater amount of light to penetrate through to the ground loor recepion/gathering area providing a much lighter, more welcoming space. As the primary focus of the building is dealing with death it is important to provide the Funeral Parlour’s clients with a comfortable space. The layout of the main public space has been designed in such a way as to create a comfortable area for those arriving to view the deceased. As much space as possible has been intended as the recepion/gathering area, so visitors don’t feel hemmed in or isolated, and sot furnishings are also provided to aid with visitor’s comfort.

The goal of creaing something warm and welcoming is coninued externally with the addiion of a natural wood screening system to the main Cartmell Road Elevaion. This was intended to break up the repeiive, worn red brick façade as well as to provide a light, natural element to what will be many people’s irst experience of the building as they arrive in the car park. The nature of the wood screening also serves as a slight relecion on the wooden fencing choices of many of the surrounding residences.

34

Proposed Lower Floor

Proposed Upper Floor

4.2 - Creaing the Scene Once the design had been inalised the 3D model must be created. Autodesk’s 3DS Max sotware was used for this as it provides many tools to accomplish such a task and is an industry standard product in the architectural visualisaion industry. When beginning construcion of a 3D model it is important to have an idea of its purpose in mind. This model is to be exported to a game engine, UDK, which has limits on the maximum number of verices of an object. It also requires various texture maps, someimes at high resoluions, to be applied to the enire building, internally and externally, as well as the site. Therefore it was decided early on that the building needed to be split up into carefully chosen secions.

4.2.1 - 3DS Max to UDK Worklow Many aspects of the iniial modelling phase for creaing game engine-ready content can be comparable to that of a regular asset-creaion worklow. Objects must be carefully modelled in a 3D modelling package such as Autodesk’s 3DS Max or Maya before being properly UV Mapped and textured ready for transferring. Unreal provides extensive online documentaion regarding the usage of their engine which is ideal for beginners trying to get to grips with the program and its requirements.

When modelling assets speciically for UDK there are a few key issues to keep in mind such as the limitaion that a staic mesh inside UDK must not exceed 65,535 verices (Epic Games, 2012). Possibly the most important thing to remember is that each individual object created and exported must be imported in to UDK’s content browser before it can be dragged and dropped in to a scene. This means each individual object should ideally be created at the origin in your modelling program (point 0, 0, 0 in 3D space) as this point becomes an object’s pivot point in UDK. All this means that great care should be taken when modelling because it is important to know when to model as one object and when to model as numerous objects as a scene would have to be recompiled once inside UDK.v Texturing must be done in a speciic way when creaing assets for UDK. All objects must irst be UV mapped before being textured just like with almost any other 3D worklow. In the case of using 3DS Max, UDK will only recognise Max’s ‘Standard’ or ‘Muli/Sub-Object’ material types upon import. Creaing texture maps also requires a fairly unique worklow as UDK only likes to handle TARGA (.TGA) image iles as this ile type contains an alpha channel as well as the standard RGB channels. Generally, three TARGA texture maps are created for each material, those for difuse, bump (or ‘normal’) and specular. In addiion to all texture maps being TARGA iles they must also be square and at a muliple of two pixels, for instance some common texture map sizes are 512 x 512, 1024 x 1024 and 2048 x 2048 pixels etc., this is because graphics cards

36

and rendering engines work more eiciently with scale values of 2.

The UV mapping worklow for UDK difers slightly from that of a normal 3D worklow in that a second UV map channel is required. Whilst the irst channel is used for the standard texturing element, the second channel will contain a diferently unwrapped ‘light map’ UV. The top two images illustrate the diference between a texture map UV and a light map UV. The light map UV allows UDK to calculate accurate lighing and shadows on a staic mesh and difers from the texture UV in that each shell should only consist of planar faces and requires a suicient amount of padding around them.

Once all game assets have been set up correctly they can be exported. The current recommended method for exporing iles from a program like 3DS Max to UDK is to use the .FBX ile format.

This allows muliple objects to be exported at once and it also supports texture data, smoothing groups and provides the ability to triangulate meshes which is important when imporing in to UDK. In UDK, any FBX iles must be imported into the Content Browser as a package, a ile containing binary data, such as textures, staic and skeletal meshes, physics etc., which can be manipulated and accessed via the Unreal Engine (Marshall, 2012). Once these packages have been imported into the content browser they must irst be saved as a package to the UDK folder on the arist’s installaion drive (usually the C Drive) before being able to be dragged and dropped into a scene and then manipulated like any other asset in UDK. Failing to save packages before using the assets contained within them will cause problems when trying to reopen a saved scene.

4.2.2 - Construcion in 3DS Max The irst step was to import 2D CAD plans and elevaions to be used as reference and to take advantage of Max’s snapping tools for quick and easy construcion of the 3D model. This allows boxes to be converted into editable polys before having verices, edges or polygons snapped to various points in 3D space relaive to the 2D plans. Whilst construcing the model, it helps to ensure that all polygons are ‘quads’ meaning they have four sides, as this helps to keep a model clean and easy to work with as well as making it simple for UDK to turn the geometry into triangles which it will do automaically upon import.

Once everything has been constructed it needs UV mapping in order for textures to be applied and, paricularly for game engines, lighing to be properly precomputed using the lightmap UV channel menioned in Chapter 4.2.1. The botom two images illustrate the diference between objects with no lightmap UV channel and one which has been correctly lightmapped.

38

All assets for this thesis were textured with Adobe Photoshop which involved rendering out the UV map from 3DS Max’s Unwrap UVW modiier as a .PNG ile before opening it in Photoshop and applying textures. Most real-world texture images (such as brick, concrete, wood etc.) were sourced from cgtextures.com and edited by hand using Photoshop’s various brushes and adjustment tools to correct colour and add more realism in the form of dirt, moss and cracks.

Most textures were created at 2048 x 2048 pixels in order to provide suicient resoluion however some were created smaller where possible. Where necessary, three texture maps were created for each object; difuse, specular and normal (top). The difuse map contains all the colour informaion whilst specular maps contain light relecion informaion, black signalling no relecivity and white meaning high relecivity, and normal maps containing simulated height informaion or ‘bump’. As stated in Chapter 4.2.1 only 3DS Max’s ‘Standard’ and ‘Muli/Sub Object’ materials must be used with all texture maps saved as Targa images.

Due to the nature of a game, essenially an explorable environment, collision objects must be created. These prevent the player from walking of the edge of an object or falling through the loor. The middle images demonstrate the diference between an object and its collision object.

Creaing collision objects in 3DS Max is simply a case of construcing a simpliied version of an object and adding the preix ‘UCX_’ to its name. This allows UDK to recognise it upon import, link it to the related staic mesh and automaically block players from walking through it.

4.2.3 - Scene Development in UDK As detailed in Chapter 4.2.1 3DS Max scenes need to be exported as FBX iles before being imported to a Package into UDK’s Content Browser. Muliple objects can be exported as one FBX ile to save on ime. On import, UDK provides the opion to combine meshes which shouldn’t be done as it will result in errors as UVs are also combined. It is important to again note that a Package must be saved to UDK’s installaion folder before any of its contents can be used otherwise an arist will be unable to save, close and reopen progress without errors.

When staring a ‘level’ in UDK an arist can either create a scene from scratch with a blank map or choose from one of four map templates; morning, midday (botom), aternoon or night lighing. This can simplify maters in some respects as it provides a ready-made environment in which to construct a scene. These preset environments include a couple of basic BSP (Binary Space Pariioning) brushes, the tools used to create scenery directly within UDK, a dominant direcional light (i.e. a Sunlight), an animated cloudy skydome and a player start icon which deines where the interacive visualisaion begins when it is played. For this project the ‘midday lighing’ preset was selected as it was deemed the most suitable for visualisaion purposes. It is possible to create and code an adjustable daylight system within UDK but that is beyond the scope of this thesis.

40

For this project, the 3DS Max scene was created as a realisic, ‘in-situ’ representaion of the building and its surroundings, rather than creaing each element at point 0, 0, 0 as the previously outlined worklow model suggests should be done. The primary purpose of this was for ease of compiling in UDK. When meshes were dragged and dropped into the scene from the Content Browser, placing their pivot points in exactly the same locaion in the UDK world meant that everything lined up perfectly and since very few objects are required to move this is suicient.

This way of working proved a great ime saver as there were 59 staic meshes which would have had to have been moved and rotated into place assuming also that UDK’s grid snapping system allowed everything to line up exactly. In standard game creaion pracice all meshes would have been created ‘modularly’ at predeined grid sizes to allow for easy alignment but since this was a real world project that method was not possible.

Once all staic meshes had been placed in the scene they needed to be resized as a standard unit in UDK is diferent from that of a standard unit in Max. One unit in UDK roughly equates to 2cm in 3DS Max so an object would have to be scaled up by a factor of about 1.75 in UDK for it to be the same size as it was in Max (Flynt (2010) cited in Schroeder (2011)).

Assuming all your materials have been set up correctly in 3DS Max, i.e. Standard materials only with Targa textures, then they should all work perfectly in UDK. Difuse, specular and normal maps are all automaically applied to the correct slot in each object’s material window. The main area where materials need to be manually adjusted within UDK is for opacity and relecions.

UDK only has one standard shader but this can be used to create just about anything an arist could require through the changing of seings and the plugging in of various nodes.

Adjusing lighing can be a fairly straight forward process, the key element of any lighing set up in UDK is to create a ‘LightmassImportanceVolume’ which encompasses the whole of the scene. A Lightmass Importance Volume ‘controls the area that Lightmass emits photons in, allowing you to concentrate it only on the area that needs detailed indirect lighing’ (Wright, 2012). It is basically a way of keeping the lighing calculaions as eicient as possible by only calculaing light where it is needed. UDK will warn you if you try to build the lighing without having a Lightmass Importance Volume. Building the volume is simply a case of selecing the ‘Add Volume’ buton from the Volumes toolbar and then using UDK’s geometry mode to edit the volume to the correct size.

When adding lights themselves there are two main light types to pay atenion to; dominant direcional lights and point lights. A dominant direcional light can be described as a sun light and as such only one is required in a scene. This will spread light over an enire scene at an angle deined by the arist therefore it does not mater where in the scene the icon is placed.

42

The dominant direcional light also has the ability to render shadows, light shats and place a representaion of the sun at the relevant point in the sky but it is important to have a skydome in the scene for this to work. The dominant direcional light in this scene was adjusted to imitate a midday spring/summer situaion in Lytham St. Annes.

Point lights work slightly diferently in that they emit light in all direcions from the point they’re placed in the scene over a deined radius. They also have the ability to render shadows and light shats but for the purposes of this scene those opions were disabled. Point lights were placed in each room inside the Funeral Parlour and set to an almost white light with a slightly yellow hue. The brightness was reduced just enough to provide a natural daylight type of illuminaion to the interior. Two more point lights were also added to the scene to be used as ‘ill’ lights.

These were placed in the opposite direcion to the sun light, shadows turned of, their radius set large enough to encompass the scene and the light fallof set as low as possible. The purpose of these lights was to soten the rather dark shadows cast from the sun light and to lighten the areas obscured by it thereby brightening the whole scene somewhat and giving it more of a realisic look (top).

UDK comes complete with the ‘SpeedTree’ vegetaion modelling program (botom), a comprehensive tool for creaing a wide variety of trees, plants and bushes with the ability to easily texture them, add collision and even add efects such as gravity and wind. These opions, paricularly the wind simulaion meant SpeedTree was the preferred choice for adding vegetaion to the scene as other opions, such as imporing a pre-made model found on the internet, don’t allow for movement and are oten very high in polygons resuling in lower performance. It’s very simple to create a tree in SpeedTree as it works in a very linear manner; irst you specify a trunk, then branches, fronds and inally leaves. Since the program can use textures with transparent alpha maps for the leaves, it allows the polygon count to be kept fairly low even when creaing quite detailed-looking models.

To achieve the look of inal rendered images, UDK also has a series of post-processing opions which work in real ime. Fog, depth of ield and moion blur all work relaive to a player’s posiion in the scene so are constantly changing with movement. In UDK it is possible to set up diferent areas with diferent post-processing styles through the use of a ‘PostProcessVolume.’

This volume works in much the same way as a Lightmass Importance Volume in that it is created to encapsulate the area which you want it to afect, then when a player steps inside the volume the post-processing efects will be rendered. In this instance a post-processing volume was set up inside the Funeral Parlour to increase the brightness, reduce the saturaion and alter the depth of ield efect through the windows.

To add more realism some elements of interacivity were added including the ability for doors

44

to open for a player. This is a relaively simple addiion which adds an amount of believability to a visualisaion as doors would be unlikely to be let constantly open. The ability to open doors requires the use of Kismet, an arist-friendly gameplay scriping tool, and Mainee, an animaion and cinemaic creaion tool. To create the opening doors in this project each door was irst keyframed with a simple 30 frame long opening animaion in 3DS Max before being exported as an FBX ile making sure to check the bake animaion radio buton. Then each door was imported into the Content Browser as a skeletal mesh before being scaled up and placed in the correct locaion within the scene. To create the desired in game efect a ‘trigger’ must irst be placed near the door. Then, in Kismet, a new event using the trigger can be created as well as a new mainee, both by right-clicking in the Kismet window. Double clicking the mainee event opens up the mainee editor and this is where the required animaion tracks need to be added from the Content Browser. Once this is done the trigger and mainee events need to be linked through the touch and play nodes. An extra funcion can be added to the mainee in terms of a ‘delay’ event which will stop the animaion reversing straight away. The top image illustrates the door opening and closing sequence.

4.3 - Tesing the Scene Once everything has been set up to the desired standard everything needs to be ‘built’. Building is the process whereby UDK calculates and constructs everything within the scene. It is similar to the rendering stage of a regular visualisaion worklow. This is the stage where proper opimisaion of a scene and eicient construcion of lightmaps comes into play as UDK bakes all the staic shadow informaion into them. There are four choices of lighing quality in UDK, preview, medium, high and producion, and for inal visualisaions it is recommended to choose producion lighing to provide the best quality albeit with the caveat that it will take longer to build. Once the build had started for the Funeral Parlour it took around 20 minutes to calculate using producion quality lighing.

Following techniques set out by taz1004 (2010) cited in Schroeder (2011) it was decided to test disabling lightmap compression in the baselightmass.ini system ile in UDK’s installaion folder in order to try and achieve as high a quality of lighing as possible. This had the anicipated efect of greatly increasing the ile size but in this case did not greatly increase the quality of the lighing. As a result the lightmap compression was re-enabled making ile sizes much more manageable.

46

5.0 - Analysis The full scene was compiled in both 3DS Max (top) and UDK (botom) in order to get a comparison of visual quality between a game engine visual and that of a rendering engine. The game engine visual was extracted straight from UDK whilst ‘in-game’, i.e. walking around the scene, by typing the command ‘iledshot’ into the command bar. This has the efect of creaing a bitmap ile screenshot of the current in-game view. Mental Ray was used to render an image from 3DS Max using fairly highly quality seings including inal gather and global illuminaion which was postprocessed using Adobe Photoshop.

The game engine visualisaion was tested further by recruiing paricipants to explore the scene before asking them to complete a short quesionnaire (Appendix D). Paricipants were observed during their use of the visualisaion to determine how well they were able to move around inside it as well as gaining an insight into where they went and what they looked at. The main purpose of the survey was to discover the paricipant’s thoughts on the visualisaion and to decide where or for what purpose they thought such a system would be of best use.

5.1 - Tradiional vs. Game Engine For an architectural visualisaion such as this the majority of the work was done using 3DS Max and Photoshop, more or less the same way as any standard visualisaion worklow. It is a relaively simple process to set up a convincing looking scene in UDK once all the modelling and texturing work has taken place in 3DS Max. All an arist need do for a basic scene composiion is add in a sun light and adjust a few seings. Of course this would only create a very basic, rather simple scene and to create something a litle more professional takes a litle more ime, but this is arguably a similar or even lesser amount of ime than it would take to adequately set up and post-process a rendering engine-rendered image.

A straw-poll comparison of the Mental Ray rendered and post-processed image and a screen shot direct from UDK showed that 6 out of 10 people surveyed thought the Mental Ray image looked beter. This suggests that visually, the game engine renderer might not be quite on a par with what can be achieved with a dedicated rendering engine and an image ediing program, but it also goes to show that there isn’t a great deal between the visual quality of the two.

This was evident when two computer graphics experts were asked to idenify which image was created with which method. They each had to inspect the images closely for a number of minutes before being able to draw a conclusion.

48

When used correctly, both the tradiional way of producing architectural visualisaions and the game engine based method are capable of producing very high quality results. Game engines have a disinct advantage in the ability to create an enire 3D scene with one rendering operaion whereas a single rendering operaion from a rendering engine will produce one single image which, more oten than not, will need addiional post-processing in order for it to be considered complete.

The ability to quickly extract an image from any angle at or near inal quality would serve muliple purposes. If an arist can produce more images in less ime they potenially provide the client with more opions and a greater understanding of their project. A game engine worklow also provides the possibility of quickly creaing animaions, a process that can take hours or even days using a tradiional worklow as each frame has to be rendered fully before being compiled, as each frame can theoreically be rendered in ‘real-ime’. This means that a 30 frames per second animaion could possibly be rendered at 30 frames per second, a feat which would be impossible using tradiional methods. This technique would be uilised in screen capturing ingame footage, the more likely case however is that each frame may take around a second or two to render which is sill a marked improvement upon tradiional rendering methods.

5.2 - Exploring the Scene The main advantage a game engine visualisaion has over a tradiional sill or animated visualisaion is the fact that it is dynamic. Even an animated visualisaion is classed as staic as it never changes from one viewing to the next. The dynamic nature of a game engine visualisaion comes primarily from the user. Each diferent user will experience the same scene in a diferent way as they have free reign to explore the scene, to go where they like and to look where they like.

This dynamic nature also provides one of the game engine methods main drawbacks; the ability to use it adequately. This was noted in the difering abiliies of various people to engage with the visualisaion. A female in her 50s with litle computer experience had trouble using the mouse and keyboard navigaion system which is generally used with the visualisaion. She found using the mouse to look around whilst simultaneously using the keyboard to move a tricky task to accomplish. Whilst this wasn’t a huge problem in a relaively small scene such as the Funeral Parlour with just one building and four rooms to explore, it would become more of an issue for a larger project with much more to explore.

50

Users with more computer experience, especially those with game experience, had litle to no trouble geing to grips with the navigaion system and used it well to quickly navigate the scene. One paricipant however was let with a slight feeling of moion sickness which could be due to the speed at which mouse movement allows the camera to pan and the amount of moion blur speciied when seing up the scene.

A number of the paricipants invited to explore the scene visualisaion came to the conclusion that it could be uilised as an efecive tool for planning applicaions, designing a building or when buying a new house with some even commening on the high level of realism of the scene.

This correlates somewhat with the original intenion of using game engines in architecture; as a real-estate tool.

52

6.0 - Conclusions To create an adequate, professional-looking visualisaion using a game engine involves a fairly steep learning curve. Whilst the game engines have strived to become more ‘arist-friendly’ in their user interface, thanks in no small part to the ever-increasing popularity of video games, there is sill an element of technicality about them which may be of puing to some arists. If one can get past this iniial fear though, then game engines represent a huge opportunity for increased producivity and interacion with clients.

Where game engines are no doubt at their most efecive is with the amount of informaion they can provide to a user. Exploring a virtual, interacive environment would enable a user to garner a much higher degree of understanding of a project than simply viewing 2D plans or a single staic image might since the virtual, interacive environment is much closer to physically experiencing a space than either of the aforemenioned methods. As stated by Bürger (2013), a paricipant who had previously had issues with understanding designs based on 2D plans felt conident they ‘understood the correct spaial dimensions’ of a room ater exploring it with a game engine visualisaion.

This alludes to where a game engine based worklow is potenially at its most beneicial; as a client liaison and design development tool. As discovered in Chapter 5.1, the majority of people surveyed believed a tradiionally produced visualisaion looked the best but game engine visualisaions provide a greater understanding of a project thanks to the ability to explore from a human point of view.

One of the main drawbacks to this technology is accessibility to it. Real-ime visualisaion requires good hardware and, according to Hadis and Addy (n.d.), the technology isn’t quite there yet and GPUs must irst become faster and cheaper. From a sotware point of view, in the case of tradiionally rendered visualisaions the result is usually a sill image or an animaion in a widely accessible format (JPEG, PNG, BMP, AVI, YouTube etc.) that just about anyone will be able to view. In the case of UDK, in order to properly experience the inal outcome a user must have a relaively high speciicaion computer and the technical knowledge to install and run the inal outputed .exe format visualisaion. The ability to upload completed visualisaions to the internet to be played through a browser, something which Epic Games is currently working on (Epic Games, 2013) and which is already available with Unity3D (Unity Technologies, 2013), would greatly enhance the accessibility and overall usefulness of game engine based visualisaions.

54

Game engines certainly contain myriad opportuniies for development and taking visualisaion down new routes. Their explorable nature makes them perfectly compaible with developments such as CAVE (Cave Automaic Virtual Environment) and the Oculus Rit Virtual-Reality head set which both allow the user to become fully immersed in the environment bringing with it a new depth to their experiences. Game engines are also perfectly poised to take advantage of the ever increasing tablet and smart phone market as each of the main three engines discussed in this thesis have the ability to create content for these devices.

It appears as though, whilst they are incredibly useful tools, game engines are not quite ready to take over from tradiional digital architectural visualisaion tools for the masses just yet.

Whether an architect or a visualiser, paricularly in small to medium sized pracices, would be willing to spend the ime and money on a game engine visualisaion for something that might only be used as a design aide is debatable since, as stated by Hart (2013), ‘there will always be an advantage in providing the client with views of a building that WE want them to see.’

56

References Alexander (2010) What is VRay? How it’s Working and Where it’s Going [online] Available at: htp://www.vrayguide. com/2010/04/what-is-vray-how-its-working-and-where-its-going/ [Accessed 30 July 2013] Al-Najdawi, N. (2007) Introducion to Visualizaion using Game Engines. Research Paper, Loughborough University.

Available at: htp://www.arts-humaniies.net/iles/gameenginedevelopments-1.pdf [Accessed 13 May 2013] Autodesk (n.d.) Sotware for BIM [online] Available at: htp://www.autodesk.com/products/autodesk-revit-family/ features [Accessed 30 July 2013] Batjes, N.H. (2012) CryEngine 3: Now Everyone Can Make a Game As Good As Crysis 2… For Free [online] Available at: htp://indie-games-ichiban.wonderhowto.com/inspiraion/cryengine-3-now-everyone-can-make-game-asgood-as-crysis-2-for-free-0129444/ [Accessed 30 July 2013] Bellis, M. (n.d.) Computer and Video Game History [online] Available at: htp://inventors.about.com/library/ inventors/blcomputer_videogames.htm [Accessed 22 June 2013] Benge, V.A. (n.d.) The First Architect in History [online] Available at: htp://www.ehow.com/info_7743777_irstarchitect-history.html [Accessed 24 June 2013] Bürger, N. (2013) Realime Interacive Architectural Visualizaion using Unreal Engine 3.5. Master’s Thesis, University of Munich. Available at: htp://nealbuerger.com/wp-content/uploads/2010/10/Neal-Burger-Interacive_ Architectural_Visualizaion.pdf [Accessed 13 May 2013] Campbell, H. (2009) What Was The First Computer Game? [online] Available at: htp://www.science20.com/ science_20/what_was_irst_computer_game-46008 [Accessed 22 June 2013] Conway, K. (2011) Game Engines for Architectural Visualizaion in Design. Master’s Thesis, University of Washington.

Available at: htp://dmg.caup.washington.edu/pdfs/Thesis.KevinConway.2011.pdf [Accessed 12 May 2013] Epic Games (2012) FBX Staic Mesh Pipeline [online] Available at: htp://udn.epicgames.com/Three/ FBXStaicMeshPipeline.html [Accessed 30 July 2013] Epic Games (2013) Epic Games Releases ‘Epic Citadel’ on the Web [online] Available at: htp://www.unrealengine. com/news/epic_games_releases_epic_citadel_on_the_web/ [Accessed 20 August 2013] Hadis, P. and Addy, J. (n.d.) Neoscape on the State of the ArchViz Industry [online] Available at: htp://www. maxunderground.com/neoscape_on_the_state_of_the_archviz_industry [Accessed 12 June 2013] Hart, B. (2013) Real Time Arch Viz [online] Available at: htp://forums.cgarchitect.com/73651-real-ime-arch-viz. html [Accessed 5 June 2013] Hudson-Smith, A. (2007) Percepion of Gaming in Architecture and Transport Modelling - Trainz [online] Available at: htp://digitalurban.blogspot.co.uk/2007/03/percepion-of-gaming-in-architecutre.html [Accessed 19 June 2013]

64

Hurley, S. (2013) AutoCAD Release History [online] Available at: htp://autodesk.blogs.com/between_the_ lines/autocad-release-history.html [Accessed 24 June 2013] ‘Imhotep’ (2013) Wikipedia. Available at: htp://en.wikipedia.org/wiki/Imhotep [Accessed 24 June 2013] Karenoke (2012) The Evoluion of Architectural Visualizaion [online] Available at: htp://normandthegang. com/2012/07/05/the-evoluion-of-architectural-visualizaion/ [Accessed 10 June 2013] Laud, J. (n.d.) History of the First 3D Video Games [online] Available at: htp://www.ehow.com/about_6436661_ history-irst-3d-video-games.html [Accessed 22 June 2013] Marshall, W. (2012) Unreal Packages [online] Available at: htp://udn.epicgames.com/Three/UnrealPackages. html [Accessed 5 June 2013] Miliano, V. (1999) Unrealty: Applicaion of a 3D Game Engine to Enhance the Design, Visualizaion and Presentaion of Commercial Real Estate [online] Available at: htp://old.hirevito.com/oldporfolio/unrealty/ vsmm99/ [Accessed 19 May 2013] Motle, J. (2009) CGarchitect 2009 Industry Survey Results - Spotlight on the Future of the Architectural Visualizaion Industry [online] Available at: htp://www.cgarchitect.com/2009/11/cgarchitect-2009-industrysurvey-results---spotlight-on-the-future-of-the-architectural-visualizaion-industry [Accessed 23 June 2013] NVidia Developer Zone (n.d.) Unreal Development Kit [online] Available at: htps://developer.nvidia.com/ unreal-development-kit [Accessed 13 June 2013] Pitard, S. (n.d.) What is BIM? [online] Available at: htp://www.rics.org/Global/Downloads/What_is_BIM_1_.

PDF [Accessed 30 July 2013] RIBA (2013) RIBA Plan of Work [online] Available at: htp://www.architecture.com/iles/ribaprofessionalservices/ pracice/frontlineleters/ribaplanofwork2013consultaiondocument.pdf [Accessed 30 July 2013] Schroeder, S. (2011) Adoping Game Technology for Architectural Visualizaion. Master’s Thesis, Purdue University. Available at: htp://docs.lib.purdue.edu/cgi/viewcontent.cgi?aricle=1005&context=cgtheses&sei [Accessed 12 May 2013] Slick, J. (n.d.) List of 3D Sotware - Full 3D Suites [online] Available at: htp://3d.about.com/od/A-Guide-To-3DSotware/tp/Full-3D-Suites.htm [Accessed 12 June 2013] Sliva, M. (2012) The Essenial 100, No. 5: Super Mario 64 [online] Available at: htp://www.1up.com/features/ essenial-5-super-mario-64 [Accessed 22 June 2013] Unity Technologies (2013) Frequently Asked Quesions [online] Available at: htp://unity3d.com/unity/faq [Accessed 30 July 2013] Unity Technologies (2013) Unity for Web Games [online] Available at: htp://unity3d.com/unity/muliplaform/ web [Accessed 20 August 2013] Varney, A. (2007) Connecing the Dots: London in Oblivion [online] Available at: htp://www.escapistmagazine. com/aricles/view/issues/issue_109/1331-London-in-Oblivion [Accessed 25 May 2013] Zamojc, I. (2012) Introducion to Unity 3D [online] Available at: htp://mobile.tutsplus.com/tutorials/gameengine/introducion-to-unity3d/ [Accessed 30 July 2013]

65

Appendix A Interviews with Site Residents

1. Are you aware of the proposal for a funeral home at Bank House, Alexandria Drive?

Yes:

7

No:

0

2. If so, do you or have you had any prior objecions to the proposal? a)

Yes:

7

No:

0

b) If so, what are/were your objecions?

Not it for a residenial area

5

Vehicles will cause problems

5

Hours of operaion are a concern

1

Detrimental to house prices

2

Issues seeing hearses/bodybags

5

Site isn’t for the purpose

1

Too close to nearby houses

1

66

Appendix B Interview with Funeral Director

Main design consideraions for a funeral parlour: A private area to meet Assembly area to gather before a funeral Pre-chapel of rest Chapel of rest from which bodies need to be moved in and out quite regularly Recepion area(s) Workshops for the preparaion of coins Embalming area (sterile) Refrigerated storage for bodies

67

Appendix C Conversaion about Real-Time Technologies Paul Fox: What are your experiences of using game engines for architectural visualisaions?

Do many people use them commercially and if so have you found that it helps clients/architects/property developers etc.?

Scot Schroeder: The killer for real ime arch viz in the early phases, for most places, is simply the deadlines imposed. It is near impossible to get a good quality real ime presentaion in the, “Oh we need this in 2 days” mentality. Then, you have the last 2 hours before its due changes that inevitably come along. All of that ights and clogs the pipeline that is needed to get good real ime visuals. This isn’t the jam my 5 billion poly SketchUp model in UDK and cross my ingers and hope it comes out good. To see how that screws things up, all you need to do is look at the Dallas Cowboys stadium that was done in UDK. Which has a playback of about 2 fps and the giant rows of exactly scaled and oriented trees.

However, once the bid and designs have been established you gain yourself a bit more ime and real ime becomes feasible.

You will have to contend with other factors. One being most architects/cleints think a real ime engine like UDK is one of them bang-bang shooter games. They don’t realize the power of serious gaming/simulaion. All they think of it as is that COD thing them kids play. The other is cost. UDK isn’t cheap. Yes, it is free. Yes you can create apps for free. However, once you start making money you have to pay royalies back to Epic. Usually in the terms of 25% ater your irst $500,000 made. Your pipeline also has to change slightly. You think to think in terms of, modularity, modeling opimizaions, texture opimizaions (ie no jpegs ever!), 2nd UVW lightmap channels, and proper unwraping.

Now if you are thinking that you’ll just bake the light maps in max and be done with it, then why use UDK? Use Unity for that, since it is free and even Unity Pro isn’t a very steep cost.

My 2 cents, either do real ime right or sick to the tradiional way of rendering. Nothing looks worse than real ime done wrong, especially when games get it right and we don’t. Real ime could be a useful tool if given the proper development ime. But that just won’t happen over night.

Paul Fox: On the surface it seemed like a perfect soluion for leing clients, or even the public, explore unbuilt developments but then like you said there’s all the set up ime of things like only ever using targa iles, baking lightmaps, staic meshes limited to 65,000 verices and people mistaking something created in a game engine for actually being a game etc. etc.

I think Epic could be onto something with making proper games available in web browsers, would make it more viable for archviz to use game engines as you could just email a link to someone and hey-presto they can theoreically explore the enire ‘built’ project.

I’m inclined to agree with you on the doing it right thing, it could be more of a hindrance if it makes any possible designs look crap. Maybe it could be used for massing studies, might help avoid some issues with quality and cost as you might not really be making any money of it, but then again using something like UDK for a massing study is probably a bit of overkill!

Scot Schroeder: I don’t think you will see Epic do too much on the web side. They have already stated that they won’t port UDK to the web, they do mobile but not web. If you want an incredibly easy to use web player, you’ll want to focus more on Unity. I also don’t think Epic would be too keen on a company using their product on projects that are generaing revenue and not be collecing some

68

sort of payment. You aren’t selling the real ime app but you are using it on a project that will or could generate future income for your company.

One of the myriad of things you have to watch out for with this is that can people understand basic controls? How oten do principal architects or senior architects use the WASD key layout for navigaion? Can they really understand the project if they are stuck in a wall and don’t know how to turn around? I know a few principal architects that struggle opening email so geing them to igure out WASD and mouse look or game controller controls would be like teaching a monkey to do brain surgery. There is some research into this topic if you have access to the SIGGRAPH white papers.

Another factor against real ime is scale. With the old imey rendering, you render what you want the client to see and leave the backs of the buildings blank. With real ime, you need to render all sides of the building. Every nook, every cranny. Which can get ime consuming. Again, if you are going to restrict the view in real ime, why do real ime at all?

Doesn’t that defeat the purpose of being able to explore your project?

However, rendering is a snap with real ime. With the project I did for last year’s CGArchitect awards it was 45 minutes to bake my full lightmaps and ater that, the render ime to spit out high quality frames was as long as it took to play the animaion. You can tell UDK to save each frame at full res, ani aliased, and capped at 30 FPS, then take those frames into post (Ater Efects, etc) and compile your super high quality video. It’s the way most game cut scenes are pre-rendered in the engine. So if the animaion was was 3 minutes, my render ime was 3 minutes. If I wanted to add another camera for 1 more minute? That’s just 1 minute of render ime plus the ime to add the camera. There is no need to re-bake light maps. So once you get your project into the engine, you gain massive amounts of ime in rendering ime saved. But does that ime savings equal out the longer development ime required to get the project into UDK? Your example about a massing model is actually a good case study. It’s a simple massing model so baking light maps would be a snap with automaic unwrap. If your client wants to see another view, you simply orbit the view in real ime. There is no delay in rendering a new camera. But is it really worth it? How long would it take to create the same massing model in Max? What advantage, other than the unlimited views and the ability to move through the project, does real ime ofer in this type of project? Do you really need to make this type of massing project like you would an environment or could you just dump the enire max scene in UDK? It is simple massing ater all. You could probably just create the masses out of BSP brushes in UDK even.

Xavier Marin: I’ve been working with both engines Unity and UDK, i even tried to make the same arch visualizaion scene with each of them, and I have to agree with Scot, I think Unity is a more suitable choice for our area of work.

First on the GI soluions : UDK uses the lightmass system witch provide impressive results for a game lighing with high contrats and a kind of dramaic mood, but it’s very diicult to set it up for architectural mood, especially for an interior.

The seings provided in the UDK GUI are not deep enough to get the kind of even and smooth lighing you’re looking for in arch viz interior lighing, so you have to go in the .ini iles and ind the good parameters to tune, veeeeeeery long. In Unity you get the Beast engine for free (with the pro version) witch allow you to have a very convincing result in a reasonable amount of ime.

Concerning the controls, I couldn’t say it beter than Scot, that’s criical. And to make that beter suited for non-gamer, you will have to do some coding. Once again unity wins. Its open system allow to implement new funcions or only modify the exising ones in a very simple maner, and once you have something you like, adding your code to other archviz soluions is as simple as a copy/paste, whereas in UDK you really need a strong understanding of the sotware’s coding architecture just to get reed of the camera’s ilt when the character walks...

That coding simplicity is decisive. I think the main advantage of a real ime arch viz applicaion, except the rendering ime witch sill doesn’t provide a visual quality that can compete with a post-producted Vray rendered sequence, is the interacivity. As we use a game engine, why not propose funcions that can provide a stronger experience to the viewer.

With a well designed GUI you can go outside and see the neighbourhood (not considering the huge amount of work) for a real estate project for exemple, have some infos you couldn’t make it in a movie and so on. I think real ime arch viz isn’t opposing head-on with rendered arch viz, it’s another product. The idea is that you can provide a lot more services than a video or a sill, and that’s when you’ll be happy to have a simple and open dev system.

Last but not least Unity provide a web player wich sill needs a plugin except with chrome for wich you can export a naive applicaion. For UDK, as a client, you need to download a 200 Mo at least ile, and then follow an installaion process as

69

complex as any game’s one. Not everyone can do that.

The only thing where Unity needs to get beter (in our line of work, no quesions about a AAA producion, UDk is made for that) is about the shaders, its naive library is quite short compared to the UDK’s material editor, but once again it’s quite easy to create your own shaders.

Scot Schroeder: Xavier, I absolutely agree with you. The “cleanness” of architecture is why most real ime GI soluions don’t work so well without insanely high render seings or disabling the compression as you have to do in UDK. Games can hide the lightmass arifacts with grunge and grime or textures like brick and stone. Smooth or painted walls (even more if it’s close to a white color) will show the lightmass arifacts like no other. Unity’s lack of good stock shaders is a small hindrance, but thankfully there is the Strumpy shader editor which makes creaing new shaders quite easy.

I think real ime can get close to Vray (or other engine) as long as the proper ime is given to develop your scene and there is a level of knowledge with the real ime engine you are using. Which, that’s where the botleneck always happens in this industry.

You really need to give the proper ime in pre-planning and pre-producion when dealing with real ime. That stuf has to happen before actual work starts, it can’t run concurrently or not happen at all.

Paul Fox: It’s looking like Unity might be the beter way to go for the project rather than UDK. I think the project is sill an interesing one to look at though and has some viability, as I’m sure you agree, Scot, ater wriing a thesis on it already!

With the state of current technology it does appear as it might be a more viable soluion for smaller projects which can be created in greater detail rather than larger projects, the Cowboy’s stadium again for instance. Although this would raise issues of whether a smaller project would provide the budget necessary to create a real-ime walkthrough!

Scot, I like your point about easily being able to generate walkthroughs/animaions. My previous project was a 1min 30sec Max animaion which took about 90 hours of rendering, if it took maybe a day to transfer everything created in Max to something like UDK to render an animaion in real-ime that could potenially save a hell of a lot of ime. But even with the fairly small scenes I created I sill ‘clipped’ some things, for example I only textured one half of a rusty caravan because my animaion path meant you only saw one half and eventually the landscape just ended but again this didn’t mater because the animaion wouldn’t allow you to see it. My thinking with real-ime is that you should be able to explore the full extent of a project but you will have to know when to cut it of. And adding to your point about the computer/game-literacy of a lot of people, how many architects/developers would ‘die’ walking of the edge of a map that didn’t have any barriers? If creaing enough extra scenery around your project takes an extra day then somebody’s got to pay you for that day’s work!

Xavier, I agree with your point that “real ime arch viz isn’t opposing head-on with rendered arch viz”, in my iniial thinking I wondered whether game-engines and the arch-viz-speciic real-ime engines might possibly replace the more tradiional archviz but I see them as serving two diferent purposes; real-ime would be more about exploring and evaluaing a project whereas sills and animaions are about markeing and showing of a project in all its glory.

Xavier Marin: That’s right Scot the pre-producion ime should be planned in every real ime project especially when you have to add some funcionaliies to enhance the visualizaion experience, and that’s what is the most diicult to make the clients understand.

Most of the ime they expect a real ime project to be cheaper and faster completed than a video... there is a lot of educaion and explaining to do on that level.

And yes mr Fox the real ime ofers a more pragmaic and “funcional’ approach to a project whereas the rendered pictures will show a dreamed result.

I have to say it’s good to see people like you guys doing so deep and detailed research on that subject, things are moving.

Scot Schroeder: This was released for Unity a few days back, htp://www.marmoset.co/skyshop It might be interesing to see how this could be used to show models or even axon views. Though unfortunately, the don’t ofer

70

a trail version so you’d have to buy it to try it.

Bruce Hart: On kind of a side note - one of the 3D guys in our oice bought in an Oculus Rit headset the other day (he’s always pushing the real-ime thing). We all had a go at some of the demo scenes included with the pack, and a good percentage of the oice got moion sickness - myself included. It had a Cool factor of 10/10 and perhaps a pracical value of 2/10. Apart from the bad graphics, that was why VR headsets never really took of in the 90s I think there will always be an advantage in providing the client with views of a building that WE want them to see rather than lying around aimlessly.

Hel Nash: I have to admit the whole real-ime thing for Arch Viz is something that hits a note with me, I feel that this has a big role to play in the future for this line of work especially with the abiliies and what you can do within next-gen.

I also agree with that it takes some ime to pre-plan awork low for it, but being as you should always pre-plan your project it’s not really that much extra ime when you think about it. The real killer is the steep learning curve that HAS to happen if you chose to go down this road, I know this as I am on it at the moment.

Arch Vis has a very clean style of imagery especially for new developments and Game Art has that lived in feel of grunge, dirt and wear n’ tear to it that helps you connect with the game, this I think is the big reason that Arch Viz doesn’t seem to work that well in real ime. A lot of people think they can just make the leap between the two disciplines, leaving textures looking lat, edges not lowing in the same direcion or ofset and overly obvious repeat iling textures that when they catch the eye draw atenion away from the purpose of the scene/level.

You have to take the ime to learn UVmapping, and material deiniion with Difuse, Specular, Gloss, Displacement (etc, etc) maps. Learning to unwrap your models properly and not just rely on the standard unwrap Box/Sphere/Plane etc, etc, will change the way you model (it has with mine anyway, and helped me understand modelling more and improved what I can do, not only in deiniion of the model but the ime it takes me to build an object has reduced greatly) it takes me less ime to unwrap an object to UV now as it does to build it in the irst place (it took me hours if not days when I irst started learning this technique but ater a week or two I got the hang of the process).

At the moment I am concentraing on material generaion (my porfolio work is taking longer because of it, but I am loving the results so far, and I’m only just geing started on it).

My husband uses Marmoset all the ime, so I use it to test the materials I make before taking them into 3D Max, it really is a fantasic program, meaning I can make changes on the ly, even the smallest ones that make a huge diference to the rendered image without having to wait hours for a good quality render to see if something looks right (one thing while I remember, the normal bump will not show the same result in Marmoset as in 3D Max as you have to lip one of the RGB channels, hope that makes sense).

I am sill rendering out the inal images though at the moment as I have yet to fully commit to a real ime engine, we have UDK (my son is learning it at the moment) but from what I understand it isn’t really the right one for Arch Viz, I don’t know much about Unity3D myself (but I bet my husband can give me a full run down of that one later).

The one that I am interested in is Cryengine 3 as everything I have heard is that this is the one for Arch Viz work, plus the results are just... wow... htp://www.youtube.com/watch?v=JWvgETOo5ek This is a trailer for the engine showing Crysis3 so yeah all overgrown and destroyed environments but I can’t wait to see what I can do with it when it comes to some clean Arch Viz work, might start playing around with it soon.

Scot Schroeder: UDK, CryEngine, Unity, Twinmoion, Luminon, they are all suited for architecture. It just depends on how you use them and if you understand the program.

UDK and CryEngine are higher quality but come at a cost that 99% of architecture irms won’t want to pay. Just because

71

you can download them for free doesn’t mean you can make money from them for free.

Benjamin Steinert: This was prety recent news, probably what the OP was referring to: htp://www.unrealengine.com/html5/ FWIW, it is UE running on the web browser, and litle more than an experiment at this point but it does give indicaion that Epic is not ignoring the web.

Paul Fox: Through my research so far it does seem as though real-ime would be at its most useful for development and simulaion purposes and not for something like compeing for jobs or maybe even markeing. It’s interesing to note the amount of people that appear to be even looking into the ield though even if it’s not yet geing properly integrated into people’s worklow.

Hopefully it means the game engines will coninue to develop new and beter ways to be used by arch viz-ers and maybe even come out with feasible pricing structures!

Bruce, I’ve looked into the Oculus Rit as a further development point and it’s prety interesing. The low res nature of it is because the only version currently available is the development kit. I’m prety sure they said the actual commercial release will be HD so I’d imagine at least 720p although I’m not too sure as I don’t think a headset will be 16:9... Anyway, I’m not too sure of it’s viability for arch-viz anyime soon but it does look prety cool!

Also, I agree that it’s helpful to provide clients with views you want them to see, this is partly why I think real-ime could be useful as a development tool, something to be used at a ime when your clients are irmly YOUR clients and you can show them all aspects of a project without needing to shield them from anything.

Hel, I completely agree that the learning curve is prety immense. There’s a hell of a lot to get your head around before you can even really start using it. It took me a litle bit of ime just to igure out how to get packages to load up properly ater previously saving a level and exiing the editor! UDK does seem to be geared around grungey textures but I guess that relects the lived-in nature of games. Those videos of Scot’s are prety awesome examples that it should be ine for arch-viz when you know what you’re doing! That’s a fair way of for me yet though!

Benjamin, that is what I was referring to, yes. I had a look around it, had to download the irefox nightly development version thing but it was impressive nonetheless. I think Chrome has a plugin that’ll allow it to be played on the browser’s current version but don’t quote me on that. It’s something that if it is developed further would help out a lot with an architectural worklow as you’d only need email a client a link (in theory!).

On a slight side not, has anyone else heard of Euclideon and unlimited detail modelling? htps://www.youtube.com/watch?v=UO5tFZC8wWU Scot Schroeder: I’ve heard of it as the brunt of many jokes, statements that it is just a rehash of current technology, or accusaions of it being a hoax from the games folks. Show me unlimited detail on 1,000,000 unique objects and I’ll be slightly more impressed.

Right now, it’s just instancing which most game engines are really good at handling in the irst place. Sure your elephant as 540,000 polys. But it’s one copy instanced around, dito with the rocks. htp://www.kotaku.com.au/2012/09/euc...e-suggests-so/ Jonathan Knox: Ive spent some ime on realime development recently, my conclusion is that realime and arch-viz must progress from the simple ‘walkaround’ noion adopted from game engine mentality to a hybrid form which allows for more control of content.

Without a speciic and more linear imeline interacive walkarounds can be quite dull and meaningless right? I would suggest a hybrid approach fusing 3D navigaion with interacive video, imagery etc would be more appealable to clients and ofer greater potenial to ‘sell’ and frame stories.

Oculus Rit looks great for single users, not sure how this would translate to archviz though? And my shameless plug ,

72

ENTERacive - immersive and interacive dome experiences: htp://pixogram.co.uk/?page_id=1439 Euclidean’s real alright, I saw it demo’d last year. Interacivity with huge Lidar point clouds is a breeze, its not just instancing, htp://www.euclideon.com/products/geoverse/ How they are going to transfer this tech to the rest of us though is sill uncertain although I suspect we will all start to move from polygons to points in the future.

Scot Schroeder: Meh, if unlimited detail was so groundbreaking more than zero of the big game development companies would have backed it especially as the next gen consoles are coming online (Xbone’s cloud compuing would have been a good tesing ground for this). But they all laughed and went on their way. That’s why Euclidean has shited away from games to more scieniic viz.

All I’ve seen are demos, pre-recorded demos which could be fake or smoke and mirrors in any number of ways. I haven’t seen any demo where someone is actually manipulaing objects in real ime. In the 2 years or so this has been out, there isn’t much out there other than just words and pictures. Plus for a company that is supposedly on the cuing egde, they are always so hush-hush about their stuf. You can only get a demo if you request it for a small group? What is that, the magician who can only disappear if everyone else turns around?

I’m sill highly skepical about them and their “product.” It doesn’t mean it is a hoax, but I just can’t igure out why it feels ishy. Maybe because for unlimited detail they use the same tree 6 bajillion imes. Instances or not, if you want to convince me of your capabiliies you might want to show more than one tree model.

Jonathan Knox: Well, Ive seen it in real ime in real life, it is real! But I agree something doesnt feel quite right, maybe thats down to dodgy PR though? Of course unil they igure out how to integrate it with the current and wider industry unlimited detail will have ‘limited use’.

Paul Fox: Admitedly I’ve only seen a few litle bits here and there on Euclydeon and the Geoverse thing but it manages to look impressive and sound a bit dodgy all at the same ime. I don’t think it’s helped by the fact they disappeared for a year or the comical voice overs! It is hard to imagine it being useful for arch-viz though as it’s seemingly all geared around displaying exising scanned data.

Jay Weston: Another +1 for Marmoset Sky Shop, I’ve had a play around with that in Unity (free version). The real ime shadows in Pro would be prety awesome when combined with it. I imagine it will be the irst of a number of HDR soluions. Its not the most accurate (it IS real ime), but it sure does look nice, and you can tweak away endlessly with diferent values for exposure, difuse, specular levels etc. They use a similar idea to sIBL where you have separate low res difuse lighing maps, specular and a skybox/cube map.

I’ll have to load in an architectural model and light it some ime, have so far only messed with their default moped model with their sweet, sweet shaders atached.

Antonio Abrussi: Re: the oculus, there’s a roller-coaster demo somewhere and i’ve found that wearing a pair of noise cancellaion headphones furthers the sicky feeling

73

Appendix D Exploring the Interacive Visualisaion

1. Gender:

Male

2. Age:

13 - 19 50 - 59

2

1

Female

4

20 - 29

2

60 or over

1

30 - 39

2

40 - 49

3. Occupaion: Paricipant 1: Arist Paricipant 2: Sculptor Paricipant 3: Reired Paricipant 4: NA Paricipant 5: Electrician Paricipant 6: NA 4. Average computer experience of paricipants from 1 (no computer experience) to 10 (computer expert): 4.7 5. Average computer game experience of paricipants from 1 (no game experience) to 10 (avid gamer): 3.2 6. Please sum up your thoughts on the interacive visualisaion: Paricipant 1: Very easy to use and understand, I discovered I could jump over walls! Impressed by the density and variety in the trees and enjoyed looking at the sun rays through the leaves. The lampposts were also very realisic and recognisable as those ugly 1970s ones!

Paricipant 2: I was impressed by the detail achieved, the manoeuvrability. The light on the trees was paricularly impressive. I am surprised by the level of realism.

Paricipant 3: Movement too sensiive. New to me, so can’t think of how to improve/alter.

74

Paricipant 4: Very easy to use, good graphics, good atenion to detail Paricipant 5: Very simple and easy to use. Very good detail in the buildings and on the building’s land 7. Where, or for what purpose, do you imagine a visualisaion technique such as this being of use?

Paricipant 1: If looking to buy a new house or to gain planning permission for a renovaion/conversion to a properyty!

Paricipant 2: New building developments. new homes, shopping centres etc. Would be a useful tool to adverise for planning. Visualisaion to show how environments can be used.

Paricipant 3: Buying or designing a house. Planning a journey. Visiing a museum etc.

Paricipant 4: Planning applicaions - for local residents to see what is being proposed. Interior design.

Paricipant 5: When undergoing renovaions or a new build project. Would be a good tool to have to get a possible look of a inished project.

8. In what way(s) do you think the visualisaion might be improved?

Paricipant 1: I would have liked to have seen the buildings/houses around in more detail and to have seen the sea (as it was Lytham St. Annes).

Paricipant 2: Perhaps just add more detail, perhaps people on the street, parked cars etc. to make it even more realisic/ convincing.

Paricipant 3: Use a joysick instead of a mouse. A ‘home’ posiion to return to beginning.

Paricipant 4: The opening of the doors could be a bit smoother so that it doesn’t seem like they hit you in the face. Using the mouse to look around could be a litle less sensiive.

Paricipant 5: Other than it being a bit too sensiive, nothing.

75