Realtime Interactive Architectural Visualization Using Unreal Engine 3.5 (UDK)
Realtime Interactive Architectural Visualization Using Unreal Engine 3.5 (UDK)
Heinrich Humann
Masterarbeit
Bearbeitungszeitraum: 01.10.2012 bis 31.03.2013 Betreuer: Prof. Dr. Wolfgang Hhl, Henri Palleis Verantw. Hochschullehrer: Prof. Dr. Heinrich Humann
II
Abstract: This project investigated the Unreal Development Kit (UDK) and the possibilities it presents for architectural visualization. To create a cost and time efficient solution, a workflow improvement as Maya plugin was created and used to convert architectural data into UDK assets. To use UDK for architectural visualization, the UDK was extended with a modular framework that provides these features: exchangeable environments, time of day visualization, interior lighting, basic architectural shaders, and an interface for user interaction. The system was used to build a demonstration prototype for visualizing a minimalistic house. The protoype was evaluated in a qualitative user study. The results show that users react positively to the visualization and that is has potential for marketing uses. Future projects can build upon the framework to investigate other UDK features, for example, dual-device interactions. Kurzzusammenfassung: Dieses Projekt untersucht das Unreal Development Kit (UDK) und die Mglichkeiten, die es fr Architektur-Visualisierung bietet. Um eine kostengnstige und zeitsparende Lsung zu erstellen, wurde eine Workflow-Verbesserung als Maya Plugin erstellt und verwendet um architektonische Daten in UDK-Assets umzuwandeln. Ein modulares UDK-Framework wurde fr Architektur-Visualisierung mit folgenden Features erstellt: Austauschbare Umgebungen, Tageszeitvisualisierung, Innenbeleuchtung, grundlegende Shader und eine Schnittstelle fr Benutzerinteraktion. Das System wurde verwendet, um einen demonstrativen Prototyp zur Visualisierung eines minimalistischen Hauses zu erstellen. Der Prototyp wurde in einer qualitativen Benutzerstudie evaluiert. Die Ergebnisse zeigen, dass die Nutzer positiv auf die Visualisierung reagierten und dass es ein Potenzial fr Marketing-Zwecke gibt. Zuknftige Projekte knnen auf dem UDK-Framework aufbauen, um weitere UDK Funktionen zu untersuchen, zum Beispiel Dual-Device-Interaktionen.
III
IV
Task Definition for a Masterthesis in Media Informatics Topic: Realtime Interactive Architectural Visualization using Unreal Engine 3.5
Background: The cost of many large architectural projects are in the multimillion dollar range [4]. Architects have to persuade the investors that it is the right decision to invest in the project. They have to show that their design is well suited for the project. Through realtime architectural visualization the investors can explore a building before it has been constructed. Current solutions require expensive specialized hardware and software, and employees operating the system require long and special training. This so far has limited visualization to large projects where the expense could be justified. As alternative we are exploring game engine technology for architectural visualization. In recent years they have become more sophisticated; the benefits are: low cost hardware requirements support of a broad range of devices (PC, console, mobile) low software licensing costs This allows visualization to be also used for significantly smaller projects. General Objectives: Game engine technology provides a realm of features specifically designed for gaming environments. Some features are not directly required for visualizing architecture, like networking and multi-player features. There are also limitations, like the maximum polygon count of a single object, or maximum number of dynamic lights, that are put in place to ensure optimal performance. The game engine has to be adapted to support architectural visualization features. The main objective of the thesis is to create a prototype framework for architectural visualization. The prototype should explore the limits of the game engine. 3D artists should be able to create visualizations without specialized training, simply building on basic knowledge of game engine technology. The 3D artists asset creation workflow has to be complemented with automation tools to effectivly use game engine technology. The game engine has to be extended with a framework to support the needs for architectural visualization like: time of day simulation, interacting with interior lighting environment, or simulating city life. The framework needs to be implemented in a modular fashion so that parts can be reused or extended. The final architectural visualization should allow the viewer to freely experience the architecture. A graphical user interface should allow the user to interact with his surroundings. The prototype should be shown to architectural clients to receive qualitative feedback about the visualization. V
Tasks: Improving the Maya to Unreal Engine workflow with an extension for Maya. Create a library of basic Unreal Engine shaders used for architecture with primary focus on optimization for medium end desktop computers. Create a custom Unreal Engine Gametype for architectural visualization and apply it to visualize an exemplary architectural structure. Support of interactions in the real time environment, interactive lighting, time and day simulation, city environment controls, nature environment controls. Design and implementation of the user interface. Qualitative evaluation of the prototype Giving bi-weekly status updates of the work in progress and a final presentation of the work in the Disputationsseminar Master. Written thesis
VI
Ich erklre hiermit, dass ich die vorliegende Arbeit selbststndig angefertigt, alle Zitate als solche kenntlich gemacht, sowie alle benutzten Quellen und Hilfsmittel angegeben habe.
VII
VIII
Table of Contents
1. Introduction
1 2 3 7 10 12 14 17 18 18 19 22 22 27 27 29 1.1. Motivation1 1.2. Goal of the Thesis 1.3. Structure of the Thesis
2.
Related Work
2.1. Uses of Architectural Visualization 2.2. Real-time Visualization Technology 2.3. Utilizing Game Engine Technology for Visualization
3.
Prototype requirements
3.1. Animation Production Pipeline 3.2. UDK Production Pipeline 3.3. Architectural Visualization Data 3.4. Interactive Elements 3.5. Technical Specifications
4.
4.1. Analyzing the Workflow 4.2. Plugin Development 4.3. Plugin for Optimized Workflow 4.4. Limitations of the Plugin 4.5. Optimized Workflow
5.
5.2. Materials31 5.3. Lighting35 5.4. Time of Day Visualization 5.5. Exchangeable Environments 5.6. Helper Layer 5.7. Visualization Menu 5.8. UDK Configuration 37 40 44 44 45 47 IX
6.
Architectural Visualization
48 49
7.
User Study
7.1. Conditions50 7.2. Tasks50 7.3. Study Design 7.5. Qualitative Feedback 50 51 7.4. Participants51 7.6. Observations56 7.7. Discussion57
8.
Summary
58 59
9. 10. 11.
11.1. Code UDK ToolBox 11.2. Example T3D File 11.3. ActionScript Code
XI
1.
Introduction
In the architectural business, visual presentation have always played a major role. Often these projects are in the multi-million dollar range [4]. Architects have to convince their clients that their solution is the best one. Realtime visualization allows both architects and clients to discuss all aspects of the proposed design.
1.1. Motivation
Many smaller 3D production studios focus entirely on animations and rendering of 3D still images. Creating an interactive 3D environment is complex and more expensive than traditional animation. The studio must factor in the cost of creating (or licensing) a realtime 3D engine solution and the need of a large team size. In addition, the 3D artists have to be trained to create usable 3D assets as required by the 3D engine as well as operating the software. On top of that, licensed 3D engines have to be modified to suit the individual use case, and in most cases, they only run on specialized hardware. In the last few years, many game engines have become available for free (or very low licensing costs) [32]. Computer game technology is accessible, modifiable, and can be utilized for new uses beyond the typical gaming application [36]. However, the entry barrier to use game engine technology is very high as a variety of technologies are unified in a game engine. The core functionality of a game engine typically includes a 2D or 3D rendering solution. The rendering capabilities have increased drastically over the last few years to a point where near photo-realistic renderings can be made in realtime. Beside the benefit of having low licensing costs, there are minimal hardware requirements. When integrating game engine technology into a 3D animation workflow, it enables fast pre-visualization of complex animation [40]. The 3D game engine technology can be applied to architectural visualization. Usually, visualization focuses on the exterior or the interior of a building, and the viewer is limited by still images or animations to view the building at a specific angle and at a specific time of day. By creating an interactive visualization, both visualization types can be merged into a single experience. The architecture is experienced by walking through the rooms, by dynamically simulating various times of day, room layouts, or weather conditions. Game development uses a large team size to create a game. However, architectural visualization is a rather specific application and it is feasible to develop a system that can be handled by a small team or single person to create visualizations in a short time frame.
The system should improve parts of the asset creation pipeline, making it easier for architects or 3D artists to create assets for the game engine. The completed visualization concept should be evaluated with regard to user experience for interacting with the system, the lighting visualization, and for marketing purposes.
2.
Related Work
This chapter covers the related work in the areas of architectural visualization, realtime rendering solutions, and use of game technology for visualization.
Visualization can also take the form of animation. The architect defines a path through the building to guide the camera animation. Overall, this type of visualization is more costly than single frame renders, because more frames have to be rendered, a visually suitable path has to be chosen, and usually ambient music is added to the animation [41]. The benefit of such animation is that a full story about the architectural project can be told. However, the viewer only sees, what the architect has chosen, but may not see all aspects of the building. Since 1994 it was envisioned that real estate brokers could allow clients to walk-through potential properties on their computer [15]. The idea was that the client enters the brokers office and the broker shows multiple properties to the client on his computer. Only if the client finds a potential property, the broker takes the client to the property. When utilizing virtual reality (VR), the client can move around freely in the environment, and explore any aspect of the building. With this freedom the client develops his own viewing experience without being influenced by the marketing department. The virtual environment experience can be further enhanced by utilizing VR-Helmets, a helmet with integrated screens and motion sensors, or VR-Cave environments, a room with projections on every wall for visualization. 2.1.3. City Scape Visualization In the urban planning process, architectural visualization is used to see how the new building is going to be integrated into its environment. The visualization focuses only on the most basic silhouettes of the surrounding buildings. The new building is visually distinctive by adding more detail or color [41]. This allows city scape planners to judge how the new building fits with its environment.
To analyze potential hazards, the city scape visualization can be extended with crowd simulation software. The architectural visualization can be used to figure out how the new building effects, for example, emergency situations. A crowd simulation creates a crowd made up of entities that represent people and simulates an emergency event. The crowd simulation uses a psychological model that is derived from analysis from crowds in the real world. Additionally, entities like firefighters, police or ambulance can be added to the simulation. The city scape planners can then visually identify potential problems where the flow of the crowd results in bottlenecks or forms gridlocks. This information is valuable because in this phase of planning it is easy to redesign the building to remove potential hazards. Crowd simulation models are very complex and at the same time every crowd is made up of different people that have unpredictable reactions, making the accuracy of these models debatable. However, it is difficult to conduct studies of real life danger situations and the results of the studies do not provide conclusive results. This means that even the most advanced crowd prediction model has a limited validity of their results and should be used only as a guideline. 2.1.4. Sustainable Architecture Visualziaton Architects use visualization as planning tool. An interesting example is designing sustainable structures. One tool to analyse strutures is Autodesk Ecotech [12]. A few key features are: analysing thermal performance, solar radiation, photovoltaic collection, and day lighting [13]. For each of these features a physical model and unique visualization technique is used. One of the key features when planning for solar panels is the butterfly shadow diagram (see Figure 2.3). The system requires a model of the site, location, and building geometry. The sun settings based on the analysis goals are then simulated, factors like sunlight hours, shadow range, and overshadowing are taken into account. The result of the simulation is then visualized in Ecotech [28]. Changing the position of, for example, the sun results in a recalculation of the simulation and real-time update of the visualization [54].
2.1.5. Reconstruction of destroyed architecture Historic structures, like the Cluny Abbey in France, were dismantled by the French revolution in 1790. Today only a few remnants of the site exist. Already in 1993 a team of students at IBM France created a visualization of the destroyed Abbey. The team utilized all available archeological data to bring back the Abbey in virtual reality [37].
Figure 2.4.: Extracted image from the film Memoires de pierres [37]
In recent efforts of preserving the site, the preservation society added augmented reality displays to the Abbeys interior. The displays show a fully rendered 3D visualization of the Abbey. By moving the display the virtual camera is adjusted accordingly. This enables the Abbey to be viewed from any angle. The displays serve as a tourist attraction. The visitors are encouraged to walk through the remaining structures of the Abbey, and the missing pieces are augmented with the displays allowing the visitor to explore the now destroyed parts of the Abbey [19]. 6
Due to the competition and rapid advances in GPU technology, the rendering capabilities of game engines increased notably in quality. For comparison, an image from Half-Life created by professionals with Valves GoldSrc Engine in 1998 (Figure 2.7) and an image from the Black Mesa Mod created by hobbyists rendered with Valves Source Engine in 2007 are shown (Figure 2.9) [63].
Many game engines support a variety of operating systems and consoles, including mobile devices. Potentially visualizations can be extended to be used on multiple devices. Crytek - CryEngine 3 Crytek has developed a game engine that can render stunningly realistic graphics. But to unleash the full potential of the game engine, high-end hardware is required. Currently the CryEngine 3 does not support mobile devices [25]. Photorealism is further enhanced by the support of dynamic indirect lighting [24]. The CryEngine only recently has become freely available; however, limitations have been built into the editor and launcher. Most of the information regarding the engine is not freely available except through the developer network, and at the time of writing, the documentation is still work in progress [23].
Unity Technologies - Unity 3.0 The Unity Engine has a high popularity in the fields of game development for iOS and Android devices. Many projects use low-poly objects (objects with as little detail as possible to keep the polygon count low) and cartoony graphics to suit the low hardware specification of the iPhone/iPad devices (see Figure 2.8). Besides iOS, Unity supports Android, current generation consoles (Sony PlayStation 3, Microsoft Xbox 360, Nintendo Wii), PCs, Macs, and Adobe Flash 11. The licensing model allows for free usage of the editor and engine for the PC platform. A license must be acquired for developing on iOS (400USD) and an additional license for Android (400USD). The documentation is freely available and is supported by an active community. Additionally, premium support can be acquired for 12.000USD per year [69].
Epic Games - Unreal Engine 3.5 (UDK) The Unreal Engine is one of the industrys leading 3D Game Engines. Since November 2009, Epic Games has provided free access to major parts of the Unreal Engine 3 by making their Unreal Development Kit (UDK/Unreal Engine 3.5) available [32]. The UDK is based on the Unreal Tournament 3 Editor and can be used to create fully functioning games. The editor is easy to learn because of access to official documentation of the engine as well as a large active modding community. One of the Unreal Engines lighting features is the lightmass system, a global illumination (GI) system to calculate indirect lighting. Lightmass bakes the GI information into textures to avoid in-game calculation. This type of GI is only effective when using mainly static environments. The alternative is to use dynamic lights, however, this needs more resources to render and has a significant impact on performance. More efficient dynamic lighting will become available in the next version of the Unreal Engine [70]. Several architects are already visualizing their work with the Unreal Engine; Epic Games is advertising the Engine as suitable for 3D architectural visualization.
2.2.3. Comparison Current commercial real-time rendering solutions (iRay, Deltagen 11) do not provide capabilities to build custom user interfaces. On the other hand, game engine technology can be extended with a customized user interface for architectural visualization. To create a framework that supports a wide range of features, we compared the most popular technologies with emphasis on photorealism, documentation, support of mobile devices, and licensing costs. Photorealism Documentation Mobile devices Licensing Unity 3 Low Medium Yes iOS 400USD CryEngine 3 High Low No Free UDK Medium High Yes Free
We decided not to use the Unity Engine because of the additional licensing costs for iOS development. When comparing UDK to the CryEngine, the CryEngine currently has superior render qualities due to the support of dynamic lighting. It is not known, if the CryEngine is going to be available on the iOS/Android systems. For our research, the Unreal Engine seems to be the best match due to the high compatibility with other operating system platforms. It is also a great benefit to have an active community and extensive documentation of the engine. In addition, the upcoming Unreal Engine 4 will address the currently lacking features in the lighting engine [29].
10
2.3.1. Architecture in Video Games In the levels of computer games there are various architectures. Basic level design of computer games consists of designing and planning virtual worlds. These virtual worlds are not bound to physical limitations. Level design paradigm focuses more on atmospheric mood and game design than on architectural functionality [73]. This allows game designers to construct architectures that are primarily beneficial for game play. A level can have rooms with bottomless pits, missing staircases, or other types of structures that would be absurd in reality. 2.3.2. Architectural Visualization in Game Engines For the purpose of city scape planning, integrateing geo-spatial data to visualize architecture with game engine technology has been explored. Various technologies were explored like the Quake III Engine (also known as id Tech 3) [38]. id Tech 3 was optimized for indoor environments and was not well suited for displaying outdoor geospacial data. Other technologies of the time like, Unreal Engine 2, support the seamless transition between indoor and outdoor environments [1]. The major challenge of applying game engine technology to the city scape planning project was that existing model data had to be converted to the specific game engine format [1]. 2.3.3. Immersive Interactive Theater Presentations, where the projected images could respond directly to the audience itself, are called interactive theater. The presentation is more like a large interactive game, which has applications in the fields of education and entertainment. By using virtual reality (VR) technology, the viewers are fully immersed into the experience [43]. In the field of VR research, a set of modifications was made to the Unreal Engine to support multiple views. This type of projection is used in VR-cave systems. In large theaters multiple walls are usually included to project the images. In the BNAVE Cave projection system even the floor and ceiling are used as screens [43]. The project CaveUT is specifically designed to support one-person theaters [56]. The technology can be further adapted to support large theaters, like the Earth Theater at the Carnegie Museum. The technology was explored because scenes could be generated rapidly and without special hardware. The project was designed for Unreal Tournament 2004, but is no longer supported [56].
11
3.
Prototype requirements
In this chapter the general requirements of the prototype are analyzed and defined. It covers the topics animation production pipeline and Unreal Engine production pipeline. It continues with data available for visualization and interaction possibilites. In the last part we specify the technical requirements.
3.1.1. Production Preparation The client has to supply the blueprints of the architectural object. The technical drawings provided by the architect are typically made with traditional drawing boards or CAD programs, like AutoCAD. Depending on how the architect works, the blueprints are available as bitmap data or CAD data [4]. In many cases, the client provides a storyboard and a description of the construction materials being used. If these items are not delivered, the artists creates their own. Artists focus on optical design aspects; they do not check if the virtual materials they apply to the building could support the structure in reality. 3.1.2. 3D Artist If the architect provided bitmap data, the 3D artist has to model the building based on the drawings from scratch. Depending on the complexity and level of detail, this can be a time consuming process. If the modeler receives CAD data, it has to be ensured that the imported CAD data is 12
suitable for visualization. A typical problem is overlapping geometry. This happens when the same geometry is exported multiple times. An example is a double-sided window. Another common problem is that unneeded geometry artificats may be imported that require correction. These issues have to be manually corrected by the artist. The CAD data is represented in 3D authoring software as NURBS (non-uniform rational basis spline) objects. At the time of rendering, the objects are automatically converted into polygonal objects. Common problem when using NURBS are visible seams between objects resulting in holes in the geometry [27]. The permanent way to eliminate all seams is to convert these objects into polygon objects and stitch the geometry. This ensures that no errors occur during the render process. When the artist has completed his work, the completed scene is passed to the next production step. 3.1.3. Animation The typical animation for architecture is a fly-through of the model. The animator creates a virtual camera, defines a movement path, and animates the camera movement. If the animation is more complex, for example, like opening of blinds, the animator has to create a simple animation rig to control the blinds and then create the animation. For more complex animations an additional professional Rigging TD is needed. The animation is added to the scene as provided by the 3D artist and then passed to the next production step. 3.1.4. Lighting and Rendering To properly light a scene all camera positions have to be defined beforehand. Virtual lights are then added to the scene to create a specific mood. Architectural lighting uses warm evening lighting to create the impression of a pleasant ambiance, or nighttime lighting with many different lightsources to make it visually interesting [74]. Depending on the realism of the scene, light probes of real lights are made and integrated into the scene. In practice, the Lighting TD and Rendering TD work closely together to create a realistic rendering. The Rendering TD has to ensure that the scene is optimized for the render process. He has to select and modify the materials so that they are effective and time efficient for rendering. This means, for example, that objects that are in the background and barely visible do not have very complex shaders. When the scene is finalized, the render process creates for every frame of the animation an image. This image sequence is then passed to the next production step. 3.1.5. Post processing The Compositor uses tools like The Foundry - Nuke [64] or Adobe - AfterEffects [6] to enhance the visual quality of the images. The sequence is color graded to create a specific mood. To further enhance the image, visual effects, like bloom or lens flares, are added. Depth of field is a common tool to emphasize photorealism. While 3D render engines 13
have the capability to render depth of field, in most cases, it is more efficient to add blurring in the post processing step. As final step, the Compositor converts the image sequence into a movie clip.
Crazybump
3D Object (.fbx)
UDK MaterialEditor
Normalmap (.tif )
Level (.udk) Kismet Script Scaleform Adobe Flash Actionscript 3.0 UDK Programming (.uc/.swf ) UI Game Con g Unreal Script Matinee Lighting Actorlocation Output
14
3.2.2. Asset Creation There are three main types of assets required for creating a basic UDK Game: 3D assets, containing geometry 2D textures Flash files (.swf), containing the graphical user interface Assets that are created in external programes are imported and managed in the UDK Editor. Each of these asset types have their own workflow. 3D Assets UDK supports two main types of geometry: binary space partitioning (BSP) and static meshes. BSP geometry is directly created in the Unreal Editor, but is discouraged to use due to potential performance issues. A static mesh has two components: The geometrical 3D model and the associated shading instructions. The shading instructions are combined with the textures of the model in the UDK Material Editor.
Static Mesh
Model
Shader
Collision Model
Game Model
Instructions
Textures
High Detail
Low Detail
Geometry
UV-Layout
Geometry
UV-Layout
Texture Mapping
Light Mapping
Texture Mapping
Light Mapping
The 3D geometry is created in a 3D authoring program, like 3DsMax [11] or Maya [14]. In addition to the game model, a collision model should be created. UDK models require a second UV-Map for storing baked lighting information (light-map). When the model is fully prepared for export, the FBX-file format (Autodesk standard transfer format) is used to transfer the data from the 3D authoring program to the game engine. 2D Assets As soon as the UV-Mapping of the 3D object is complete, a 2D-Artist can paint textures. Usually two textures are painted, one for the diffuse channel, and one for the specular channel. Textures should be stored in the Targa format. The benefit of the format is that it can store RGBA color information and has lossless compression. 15
Flash Assets Scaleform is a middleware solution to allow the playback of Flash files in a 3D environment. These Flash elements are used to create a graphical user interface for the game environment as well as the menu. Scaleform implements a subset of Actionscript 3.0 commands, allowing dynamic functionality. These assets can be created with Adobe Flash [7] or any alternative program, as UDK requires the compiled flash format (.swf). Other Assets UDK also provides the possibility to import other types of file formats, for example, video files (Blink Format) or tree models (SpeedTree files). 3.2.3. Asset Management The game engine tries to be as efficient as possible when using assets. To minimize memory used when playing the game, UDK stores and organizes its data in form of Unreal packages (.upk). All assets must be imported into packages before UDK can use the asset. The content of these packages can be viewed with UDKs Content Browser.
3.2.4. Level Creation Map files (.udk) can store all information about the level. Every object in the level is referred to as actor. When, for example, a static mesh is placed in the level, additional information is stored about the object, like the location, rotation, collision properties, etc. Kismet is Unreals visual scripting language; it can be used in combination with Matinee Unreals animation editor to create scripted events for the player. For example, when the player approaches the door, the player could trigger an event, e.g. a keystroke, to open the door. Matinee would then animate the door opening.
16
To create a playable level, a starting location in form of a player spawn point has to be defined, basic geometry and a light actor has to be placed. 3.2.5. Programming/Scripting The UDK can be modified with configuration files and with the UnrealScript language. The C++ interface of the Unreal Engine 3, however, is not available for the UDK. The core settings are designed for gaming purposes, limiting game time, providing a player inventory, etc. These settings are configured in a game type class and a player controller class.
3.3.1. City Scape Planning The data needed for city scape planning requires at least the information about the heights of the surrounding buildings as well as road information. Additional information about vegetation properties, or distance of lamp posts in the streets, maybe included. From this data abstract schematic blocks can be created to represent the buildings. Prominent landmarks usually are represented by a basic silhouette. To further support the abstract nature of the visualization, lamp posts and trees are also represented by abstract objects. As alternative to the urban environment, basic natural environments can be provided; the major settings are forest, mountains, and ocean. This data cannot be extracted from the existing blueprints and reference images. However, 17
other tools, like Google Earth, can provide access to such types of data. As alternative, random generated city data can be used for a proof of concept. 3.3.2. Main Building Visualization Data about the exterior design and floor layout of a building are usually stored in form of blueprints as well as reference images. This data can be used to model the building as well as indicate the usage of different rooms. Room usage can be displayed in an abstract fashion; it is also common to include furniture. 3.3.3. Other Data that could be Visualized The following data, if available, could be also shown in the visualization: Information about the pipe works or electrical wiring could be displayed by making the walls transparent. Historic data of a building that show the modifications made over time Multiple design ideas for a facade Information about escape routes of a building in the form of animated arrows
18
4.
We decided to use Autodesk Maya, because it provides several tools to import CAD data and to create assets for the Unreal Engine; however, the process using the default Maya tools is very time consuming and requires multiple repetitive steps that make it inefficient and error prone. To increase efficency, we designed a plugin to automate parts of this process and increase the efficiency when creating assets for UDK. In this chapter we describe the FBX workflow, the requirements for writing the plugin, and the features we provide with the plugin. In the end we will present the optimized workflow and discuss its limitations.
Prepare Material
Shader Type
Naming Convention
Prepare Model
UV-Mapping
Collision Model
Light Mapping
Correct Naming
Position Objects
Export
Triangulate Meshes
FBX Settings
Import
Shader Settings
Position Objects
19
Preparing the Material As first step we select the material type. UDK only supports the basic types of materials (lambert, blinn, or phong shader). More advanced materials, like mental rays mia_ material, are not supported and cause import errors. Similar limitations apply to texture files. All textures used must be stored as Targa or Tiff file. For asset management purposes, it is best practice to name the textures with an identifying prefix, like TEX_, to ensure that the texture file has a unique identifier. Preparing the Model Architectural data is stored in the form of CAD data. This data is imported in Maya as NURBS geometry that has to be converted to polygonal geometry. The topology should consist entirely of quads or triangles. When processing the model, it usually consist of multiple objects that have to be unified. To optimize the model for performance as few as possible polygons should be used. Normal maps can be used to add details without increasing the polygon count [77]. To create normal maps, a high-poly object and the corresponding low-poly object is needed; it is calculated by measuring the difference between the objects and storing the data in an image file. The model requires a second UV-map to serve as lightmap [76]. It is important to note that to avoid artifacts, the UV-shells in the map do not touch each other and the map requires a minimum of 5% padding. It is optional to include a collision model. A collision model is a tightly fit low polygonal object encompassing the original object to be used in the physics simulation of UDK. 3D artists can model a collision model manually; in many cases it is sufficient to use simple primitive objects, like cubes or spheres. UDK associates the collision model with its model through a naming convention. The collision model must have the same name as the original-model with the prefix UCX_ attached. During the import process UDK analyses the object names and automatically combines the two objects to a single object. Alternatively many types of collision models can be generated manually by the game engine. Exporting the Model with Material In Maya it is required that the FBX-Exporter has to be enabled. It is a UDK requirement that every model has to be exported as its own file. The final 3D model must consist entirely of triangular polygons. This can be ensured by enabling Triangulation in the FBX-export settings. The UDK specific export options can be stored as an individual preset file. Information of the location of the pivot point is not exported. UDK assumes the pivot point is at the origin. It is best practice to position all objects at the orgin to avoid placement errors. Importing the Model with Material The positions of the objects created in Maya are not transferred. To accuratly reproduce the positioning in Maya, the positions need to be converted from Maya units to Unreal units and manually entered for each object.
20
Further, translucent materials are imported as solid material and have to be adjusted in the material editor. 4.1.2. Observations The participants of the course Project Competence Multimedia: Unreal Development [47] had the task of creating a simple game using the Unreal Engine. While working on the game several observations were made: General In many cases the students could not successfully export objects, they were puzzled what went wrong. In most cases, it was a simple typing error in naming the collision object. In other cases, it was because the mesh was not triangulated, or it had a faulty topology. Even after several successful exports, the students still failed at the export process. The team leaders provided a step-by-step guide that simultaneously served as checklist for the export process. It was observed that already exported objects were imported to Maya to verify that objects were at the right scale. Grid size When the students were working on UDK related objects, they set grid size to the same size used in the Unreal Engine. However, the students found themselves switching constantly from the common Maya grid size to the Unreal grid size depending on the project they were working on. Scene organization To organize the scene the students used the display-layer features of Maya. They created their own layer collisions to store the associated collision objects. Errors Even after having learned how to export objects successfully and using the guilde, the students experienced the same errors in the exporting process. In most cases, the lightmap was missing 4.1.3. Conclusions Even though the FBX workflow has only four major steps, the steps are complicated and errors do occur. Many of the errors could be avoided if the user had tools augmenting the process. The most time consuming process is laying out objects. This process is further lengthened by not having the ability to export the positions from Maya to UDK. This forces the user to repeat this task. Automating this process would significantly increase efficiency for architectural visualizations. In addition, these processes could be also automated: The creation of primitive collision objects Creation of primitive lightmaps Export of multiple objects to single files. 21
format 1 cm = 0.525 uu [72]. 3D artists usually work with a grid size based on meters or centimeters [26]. The default Maya grid size is based on centimeters. The user has to open several submenus to change these settings. The plugin allows the user to switch between the centimeter grid size and the UDK grid size with the push of a single button. 4.3.2. Reference 3D Models In game development, reference objects are represented by a simple cube. These cubes can be used in the level creation process and are replaced by fully modeled objects. A simple feature to quickly create cubes of appropriate sizes was added to the plugin. However, in the context of architectural problems it is important how the surroundings fit to a human. The plugin allows a quick import of a correctly sized adult human reference figure. This joint doll is fully rigged so users can quickly change poses of the character. This enables the artist to verify that, for example, furniture used is scaled correctly. It is common practice to export assets and reuse them as size reference [3]. The plugin scans a directory for existing models and provides a drop down menu to import the selected model.
4.3.3. Primitive Collision Objects 3D assets in UDK have two parts, a model part that can be seen visually, and a collision model that is used for calculating collisions. It is best practice to provide for each UDK model a specifically designed collision object. When no collision object is provided it would allow the UDK players to walk through the object. Manually creating collision objects is a tedious task. The UDK Editor provides a tool to create collision models, however, this has to be done for each individual object. When
23
creating the collision model in Maya, the model has to be placed at the exact same position as the original object and named correctly. The plugin provides three ways to create basic collision objects: Box, sphere, and duplication. The box collision object can be used for most parts of a building, like windows, walls, floors, and ceilings. The plugin calculates a bounding box around the object and then creates it as a collision object. The sphere collision object is suited for complex and round shapes, like chandeliers. The radius of the collision sphere is calculated based on the size of the bounding box. Collision objects created by duplication provide a quick way to test complex objects in the UDK. The plugin names the collision object correctly and parents it to the original object. This ensures that object and collision object move together. 4.3.4. UV-Mapping and Lightmaps Lightmaps are required to reduce the CPU and GPU load. The lighting information is baked into textures [68]. To prevent errors while interpreting the UV-Map, a secondary UV-Channel (light-map) must be created. The script automatically re-projects the UV coordinates, and by doing so, gives every polygon-face its own UV shell. All UV shells are then reorganized and repositioned with the required 5% padding.
Figure 4.3.: Left: UV-Map for a cube, Right: Lightmap for a cube
4.3.5. Export Tools The most effort for the plugin was required for improving the export-import workflow. Besides exporting multiple objects it also supports the asset management file structure. A method was implemented to export all positions of the object and import the positions into UDK. 24
Direct Transfer of Map We explored the possibility of creating a direct connection between the UDK Editor and Maya with the help of C++ or network features. Due to limitations by Epic Games for the UDK we determined this was not possible. Thus the user has to manually import the exported assets. Asset Management A commonly overlooked feature of UDK is that all imported assets keep a reference to the original FBX-file. Exporting all files in the same folder structure allows rapid re-import of assets. The main scene folders to create are: sourceimages (for textures/Photoshop files), scenes (for Maya scene files), and fbxExport (for the original FBX-files). The plugin has the option to always export FBX-files to the same folder. Shader Naming A minor timesaver was introduced to automatically add a prefix MAT_ to the material name and the prefix TEX_ texture files. This ensures a standardized format and uniqueness of the names avoiding common errors. Multiple Mesh Export The standard export operation exports all selected objects to a single file. UDK, however, needs every object stored in its own file. Initially we created a method to move the object to the origin, then export each object as a single file, and then move the objects back to its original position. While this is the correct way to export optimized assets for the UDK, it is only needed if assets have to be reusable. As in architectural projects the geometry of the building is unique, it makes this feature unnecessary. To reduce the complexity of the plugin, we removed this feature in the final version. T3D - Level Export To export the level correctly, besides the model itself, the positions, rotation, and scale of the assets have to be stored, and then imported to a UDK map. While researching the problem, no solution could be found using the official documentation. Even the deprecated official ActorX plugin did not offer this feature. However, we discovered that UnrealText file format (.t3d) is used for level import. The main use for the file format is to allow the import of custom BSP-Brushes. This file format is deprecated and no official documentation is available for the file format [71]. To investigate the file format, we exported a level and discovered that information is stored in plain text. The text is structured simililar to a markup-language. Methodically we removed data structures and then reimported the file to see if the remaining information was still importable. The initial file had 35000 lines. We noticed that texture files were represented in binary. Simply removing the binary data from the file resulted in errors. Removing the entire PackageTexture section of the file allowed the remaining data to be imported without problems. It became apparent that the UnrealText file did not store any information about
25
the 3D geometry and only stored a reference to the corresponding Unreal Package that contained the object. We removed all information not directly related to the static mesh UDK actor. We also removed the MapPackage and Surface sections of the code. The import of the remaining 24 lines of code worked without problems. The file now contained just information about attributes regarding the actors that were being set by default. As we were only interested in the location, rotation, and scale attributes of the object, all other attributes were removed. The file was reimported successfully. However, there were no rotation and scale attributes defined in the file. We speculated by using a different actor and setting values for the rotation and scale attributes that the information would be stored in the t3d file. We repeated the entire process and, as expected, the attributes DrawScale3D and Rotation showed up in the t3d file. This provided us the basis for writing the function export_T3D to generate the file based on the objects present in the Maya scene. The script adds a unique Actor block for every object and converts the translation and scale from cm to uu. Rotation values are represented with the full integer range in UDK, so the Maya rotation values have to be converted with angle/360 * sys.maxint. An example of a t3d file is shown in the appendix. It is important to note that this method only works for objects that are already present in UDK packages. Transfer of the Scene from Maya to UDK In the final implementation, the level export exports all objects as FBX-files and stores them in a folder, the folder name indicates the package name while importing these objects in UDK. In addition it exports the t3d file. Due to the lack of a direct connection between Maya and UDK the user must manually import the FBX-files to the correct package, then save the package, and finally import the t3d file. 4.3.6. User Interface The user interface was created using the default Maya Python API. The PyQT interface was not used as no callback functions were required for the interface. Visual cues from the Maya Attribute Editor interface were used to design the plugin. Functions are organized in two tabs General and Export.
26
4.3.7. Deployment The plugin is stored in the folder ../My Documents/maya/scripts. Executing the Python command import UDKToolBox starts the plugin.
Shader Type
Naming Convention
Prepare Model
UV-Mapping
Collision Model
Light Mapping
Correct Naming
Position Objects
Export
Triangulate Meshes
FBX Settings
Import
Shader Settings
Position Objects
To determine if the new workflow is better than the old workflow, we conducted a simple test. First we created a scene with 10 basic spheres positoned at random. Then we transferred all objects with collision model and lightmap, and positioned all objects correctly in UDK as quickly as possible. Using the FBX workflow the time required to complete all operations was 7min 10sec. When using the UDKToolbox plugin, all operations required 40sec.
28
5.
UDK Framework
In this chapter we will discuss how we extended the Unreal Engine to serve as a framework for architectural visualization.
Game Engine Configuration Files Many settings concerning the render engine are set in the configuration files, for example, Anti-Aliasing-Quality settings or display resolution. 5.1.2. Ideal workflow for architectural visualization with UDK The artist/architect should only have to import the building and the rest of the system is already configured to present the building in UDK. To accomplish this goal, we identified potential elements that are present in every type of architectural visualization. If possible, these elements should only be created once and then reused in further architectural visualization projects. 5.1.3. Framework Setup We created following structure for the framework: UDK Maps Unreal has the possibility of Level streaming, this allows multiple maps to be combined at runtime into a single map. The original map is then called the Persistent Level, which serves at the same time as the startup level. The feature is used to create a seemingly endless environment without the need for loading screens. In our framework, however, we are using it simply as a layer organization tool. Multiple levels are used to manage the featueres in dedicated maps. Parts of the visualization are split into different categories and their corresponding maps: building, Kismet scripts, time of day, city environment, nature environment, helper assets. The benefit of such a setup is that now only the building-map has to be exchanged to create a different architectural visualization. In addition, the level setup can be easily extended with features if necessary. UDK Packages The uniqueness of every architectural project is the actual building. Separating the geometry of the building and the materials into its own package allows the materials created for the visualization to be reused. Prefabs are stored in the architectural_visualization_assets package. Unreal Script Classes The framework includes an architectural visualization game type class to control the engine that does not have to be further modified. Game Engine Configuration Files The Unreal Engine configuration files are modified depending on the hardware used. However, the configuration settings can be set to a low-end environment removing the need to modify these files further. 5.1.4. Asset Management UDK organizes its assets in packages (.upk). However, to create assets for UDK one has to utilize a 3D content creation tool for mesh creation, as well as 2D imaging programs for 30
texturing and a Flash authoring tool. For this project, Autodesk Maya, Adobe Photoshop, and Adobe Flash were used for asset creation. 3D Asset Management 3D models are stored as maya-Ascii-files (.ma) for maximal backwards compatibility. To separate the newly created assets from the UDK default files, the folder Archviz was added. The Maya subfolder was set up as a default maya project folder, using scenes to store the maya files, sourceimages for textures/references (as well as Photoshop files). The FBX Export subfolder stores the exported models. 2D Asset Management 2D Textures and images created in Photoshop are stored as Photoshop Files (.psd) and then exported as UDK readable Targa files (.tga). Texture files have to be saved as square images with RGB or RGBA channels. For optimal performance, the texture files have a length represented by a power of two but not larger than 4096. Flash File Management UDK uses Scaleform to render GUI elements. Scaleform requires all Flash swf-files to be stored in the specific path ..\UDK\UDKGame\Flash. To use the Flash elements they have to be imported into their own Unreal package and then applied as a texture to an actor. UDK Level Management We are using the default directory ...\UDK\UDKGame\Content\Maps to store the UDKmaps.
5.2. Materials
Materials used for architectural visualization should support the following attributes: diffuse reflections, specular reflections, and refractions. To demonstrate the material shader capabilites we are using a Utah teapot as standard reference object. During the material creation process the artist should be communicating with the architect. It is easy to create material shaders that are visually pleasing, however, it may not be feasible to build the building with the suggested materials [41]. 5.2.1. Default UDK Material The default UDK material is based on the Phong shading model. It has a diffuse and specular highlight shading component. Diffuse materials scatter light in every direction. In our surroundings most objects have a diffuse reflection component, for example, plaster walls.
31
By using a wood texture for the diffuse reflection and enabling the specular component you could, for example, create a convincing material for a wooden parquet floor.
5.2.2. Reflective Materials The basic material shader does not directly support specular reflections due to performance optimizations. A method to create specular reflections requires the use of a lightprobe to sample the environment. The sampled data is stored and then used as texture map for the reflection. In the UDK Editor, a SceneCaptureCubeMapActor is placed in the level on the exact same position as the object. The SceneCapture node has attributes to define a near and a far clipping plane. As texture target a new TextureRenderTargetCube object is created in the UDK ContentBrowser. The node stores the reflection data as cubemap texture; this texture has to be projected onto the specific object. This is accomplished by modifing the texture coordinates using a reflection vector and vector transformation node. The converted texture is then used as diffuse reflection.
32
Few materials have primarily a specular reflection, an example are chrome materials. For other materials that have a diffuse and a specular component, the shading network has to be extended to allow the blending of the diffuse property with the specular property. In the following example, see Figure 5.4, we used the additive method to blend the diffuse component with the reflection component and provided parameters to control the diffuse and reflection amount.
Figure 5.4.: Material editior shading network with blending of diffuse and reflection components
The default setting for the material is dynamic, allowing the viewer to see himself in the reflection. When dynamic is enabled, UDK constantly updates the material, which can lead to performance issues. UDK allows the storing of rendered SceneCapture into a
33
static texture file. Static reflections are calculated only once when the level is generated and then never updated. In addition to the potential performance issues, the method requires that for each object that uses a direct reflection component, a unique material and accompanying light probe must be placed. This process can be very time consuming for the artist. It is generally discouraged to use reflective materials in UDK. 5.2.3. Refractive Materials Transparent objects, like glass, cause the light being refracted by the material. UDK offers the possibility to create transparent objects, using the Translucent shading model. The model has additional attributes to modify the opacity and distortion. When looking at a rounded transparent object, like a glass, the object is usually very transparent in the center; however, on the edges of the glass it appears to be less transparent. The light is refracted and reflected simultaneously; this effect is called Fresnel reflection[17]. UDK offers a Fresnel node. This node is added to the shading network to control the opacity. A similar setup can be used to control the distortion factor.
For the direct reflective component, the previously described method has to be applied also. A major issue when using this material is that it has no option to enable translucent shadows as well as stencil shadows. Another issue is that UDK does not calculate refraction, it only distorts the environment based on the values in the map passed to the distortion attribute. Refraction index values cannot be directly applied and distortion attributes have to be manually adjusted. 5.2.4. Glowing Materials Lamps when turned on emit light and have a visual glow around them. The basic material has an emissive attribute to make objects glow. Values above 1.0 are needed to be able to see a visible effect. 34
The glow does not actively emit light. However, the property can be used to create the material of the lampshades and by placing light sources near the lamp it appears that the lamp would be actively emitting light into the scene.
5.2.5. Adjusting Materials during Gameplay The UDK shading system has the feature to use the ParameterValue nodes. These nodes function as named variables. An instance of the material can be created, however, the ParameterValues can be overridden. This allows complex shading networks to be easily reused for multiple variations of the material. In addition, the system has the possibility to modify these values dynamically. To enable this functionality, the MaterialInstance has to be created, and a MaterialInstanceActor is added to the level for managing it. Using Kismet the ParameterValues can be set to a specific value. As alternative a Matinee sequence can be used to change the ParameterValues over time.
5.3. Lighting
We discuss the basics of the UDKs lighting system and how it can be used in an architectural context. 5.3.1. Light Placement When lighting for animation is used it is common practice to use 3-point lighting: a keylight, fill-light, and rim-light. The light sources in most cases cannot be seen and can be simulated by using basic virtual lights [75]. However, this type of lighting setup is created based on the camera position. For lighting in interactive 3D environments it is important to place lights in a plausible fashion and independent from the camera. In addition, because the user can explore the environment, in most cases the user should be able to see the source of the light. 5.3.2. Direct Light UDK provides four common basic light types: Point light, Spotlight, Directional Light, and Skylight (a type of ambient light). 35
The point light, spotlight, and directional light come in four different versions and can be classified into two groups: Static Lights: Basic: provides common features of the light and is the base class for other light types Dominant: creates only static shadows Toggleable: can be turned on and off (by using Matinee the intensity can be varied) Dynamic Lights: Movable: the light source can be moved in the game All static lights are calculated once by the light baking process. The process requires all levels to be loaded. All lights visible are used in the process regardless of its level location. For each individual object the UV coordinates for the lightmap are used to generate a unique lightmap texture. This texture is then loaded at runtime. Dynamic lights are constantly calculated during runtime; they do not have any effect on the lightmass system. Due to performance issues Epic Games recommends having at most 3 dynamic lights in any given scene. 5.3.3. Indirect Light (Lightmass) Lightmass is a static global illumination system. As with static lights, the indirect lighting information is stored in the texture of the objects. The lightmass process is very complex and drastically increases light calculation. As a matter of fact, UDK provides the Epic Games Unreal Swarm network rendering solution to calculate the lightmass effect by multiple computers. It is important to note that when using toggleable lights only the first state of the light is used to calculate lightmass effect. During runtime of the game increasing or decreasing the light intensity has no effect on lightmass. It is for the same reason that dynamic lights do not influence the lightmass effect as it has been statically calculated. 5.3.4. Photometric Data Especially in the field of architectural visualization the photometric data is used to imitate realistic lighting. The illumination Engineering Society (IES) has standardized how to physically probe lights. This data is used for ISO Standard verification and is stored in the IES file format. Lighting manufacturers, like Phillips or ERCO, provide IES data for free. 3D production quality rendering solutions support interpreting IES files to accurately simulate lights. For example, mental ray has its own photometric-lighting node to be used as a light source (see Figure 5.7). However, UDK does not support IES lighting information. Direct C++ access to the engine would be required to extend the UDK.
36
5.4.2. Fixed time model To avoid the shadow artifact issues, a fixed time model was persued with four times of day being implemented: Morning, Midday, Afternoon, Night Initial Level Streaming Setup Our initial concept used the level streaming technique to switch between the different basic maps (as provided by the standard UDK) for the four different time of day settings. To ensure that the correct time of day is displayed it must unload all other time of day maps. The system did not work due to the sunlight being implemented by a DominantDirectional Light in every level. UDK does not compute multiple DominantDirectonal lights correctly. This behavior is not documented, as levels usually only have one DominantDirectional lightsource as sun.
38
Modified Level Streaming Setup We removed all lights and created an additional map sunlight that only contains a DominantDirectionalLightMovable light source as sun. The main level would stream the sunlight map and this in turn would stream the correct time of day. To update the suns rotation to a specific time a Set Actor Location node was used to modify the light rotation attribute. It was not possible to directly adjust the color of the light to reflect the time of day. Instead we used a workaround by creating a Matinee sequence with the duration of 0 seconds to set the lightcolor attribute. Final Implementation By using the level streaming method it is tedious to extend the system to support additional day times, also the feature requires multiple map-files. We further analyzed the different elements contained in the default maps. We discovered that every map had the same basic skydome element, however, the material was different depending on the time of day. We moved the skydome and sunlight to the time_of_day map and used a Kismet set material node to change the skydomes material. This setup eliminates the need to stream levels and, at the same time, makes it simpler to extend this feature.
39
The toolset allows painting the landscape by using 3D brushes. The system interactively modifies the heightmap and displays the result. The landscape actor can be further modified to include transparent sections. This feature is useful when the viewer should be able to access basement sections of a building. Due to performance optimizations only heightmaps with specific dimensions are supported. The minimum size is 127x127, the maximum size is 4033x4033, which is equivalent to 10.5 square kilometers [31]. To support such complex geometry, the UDK Landscape system automatically reduces the complexity of the geometry based on the view distance. The shading system provides the possibility to blend various textures based on the heightmap information. For example, in a mountain environment the highest points could be covered in snow, while the rest of the mountain is covered in grass. We created a 509x509 height-map to create the surrounding landscape and stored it as its own level.
It is important to note that the deprecated UDK Terrain tool is also available due to backwards compatibility. The Terrain system is independent from the UDK Landscape system. UDK Terrain materials cannot be applied to UDK Landscape environments. The UDK Terrain system is not compatible with mobile devices. UDK Terrain Actors can be converted to UDK Landscape actors, though. Vegetation Epic Games provides UDK access to the program IDV Speedtree. This program generates trees based on node definitions. The various nodes can be given random values to create variation of the tree models.
41
When using the UDK Landscape system it is possible to paint vegetation onto the landscape. The user can create a brush made up of multiple objects and the density, rotation, and distribution can be defined by a randomizing function to create the appearance of a natural distribution of the objects. We used two types of trees available in the default packages of UDK and painted them onto the landscape actor.
42
UDK supports the display of foliage, like falling leaves. This type of effect can be created by using the UDK Particle system. This would allow time of year visualization. We did not explore this further. 5.5.2. Urban Environment In urban environments the shadows of surrounding building greatly influence the lighting conditions of a building. Our system should visualize these effects. The viewer, however, should not be distracted by these buildings. By using simple block representations of surrounding buildings, a contrast is created that draws the viewers attention to the highly detailed building. Skyscraper We created a grid of eight skyscraper sized buildings that surround the property. These skyscrapers would completely block the sun so that minimal sunlight would reach the property.
It is important to note that while using the time of day system in combination with the skyscraper visualization, shadow draw errors occurred. The shadow would not be visible on buildings far away. To eliminate this effect, we increased the maximum shadow draw distance, even though this has an effect on performance. Cityscape Visualization Data As alternative to the surrounding skyscrapers, we tried to gain access to real world cityscape visualization data. We discovered a method to extract data from the program Google Earth 3D [59]. The method uses the program 3D Ripper DX. Due to potential legal issues we did not further explore this possibility [61]. 5.5.3. Environment Switch To switch between the cityscape and nature enviroment we used level streaming. This method causes problems while unloading the current environment as the floor is removed 43
that the viewer is standing on. The viewer starts falling into infinity. This issue has been resolved through introducing player restrictions in the Helper Layer.
the UDK environment. The command was originally designed to be used to communicate between the Flash Player and the Web browser or ActiveX component thus limiting the command to broadcast strings. 5.7.2. Graphical User Interface The basic menu allows the direct control of the static time of day visualization in form of four buttons labeled Midday, Afternoon, Night and Morning. Two buttons are available for the environment control. Mouse cursor The user should be able to use the menu using the mouse; however, UDK automatically hides the mouse cursor. To enable the user to see a mouse pointer an image of a cursor was added as the top layer of the Flash file. An Actionscript command enables the mouse to drag the image, thus visualing the mouse position. ActionScript Code Due to the limitation to only broadcast strings, we decided that for the click event of the button the variable name of that button is broadcast to UDK. All buttons are stored in an array for extensibility of the menu design. Upon initialization of the Flash file, a MouseEvent listener is added to all objects in the array. When a new button is added to the GUI, only the array has to be updated, no other code has to be modified. Kismet Script A keyboard input event for the R-key activates the GFXMenuNode to display the menu.Fscommand event nodes are added to control the environment and time of day.
5.8.3. Keymapping We kept the default navigation scheme of the WASD movement. The WASD keys are used on QUERTY keyboards because it is more ergonomical than the arrow keys when using a righthanded mouse. As default, the key E is mapped as Use-key. We added the R-key to the keymap (using Kismet) to open the visualization menu.
46
6.
Architectural Visualization
This chapter covers the creation of a architectural visualsation prototype. Architects typically use a computer aided design (CAD) program, like Autodesk AutoCAD [9], to create architectural blueprints. No CAD-designed houses were available free of licencing fees; bitmap images of blueprints, though, are available online. To keep the project simple, the minimalistic XY-house was chosen for this research. All assets were created in Autodesk Maya and then exported using the UDKToolbox (see section 4. Maya Plugin UDKToolbox).
47
Based on the reference images, we created basic models for the living room area to make it easier for the user to perceive the scale of the building. The materials used for these objects are described in 5.2. Materials on page 31.
In Flash two sections Light Combinations and Lights were added. The buttons controlling the lights were organized in rows according to floor. Kismet Script When toggling the lamp the light and the material have to turn off or on. To be able to control the material effect individually, for each lamp a unique material instance of the glow material was created and applied to each lamp. The lamp trigger activates when using the Use-key (E) or the menu. The glow property of the material is controlled by a Matinee sequence. To simulate incandescent light bulbs a zero-second animation was used to toggle the glow property on or off. However, the Matinee sequence could also be used to animate the glow property and the light intensity in synchronization to simulate the flickering/slow start of compact fluorescent lamps. Support for all lights on/off and light combinations adds complexity to the Kismet script. These events have to connect to all individual light sequences. To simplify the script we introduced a Switch node. The Switch node takes an input and maps it to one of several outputs depending on its counter. By disabling the counter and manually setting the index, the node can be used as an array node. Using an int counter node all lights can be turned on/off; by including simple conditions to the script, light combinations can be set. The switch node is useful to preserve existing light combinations when more lights are added.
49
50
7.
User Study
We conducted a qualitative user study to figure out if potential users would want to use such a system. The remainder of this text is structured as follows: In the first part, the conditions, tasks, study design, and participants are described, in the second part, qualitative feedback, and observations are presented. The last part has a discussion of the outcome.
7.1. Conditions
The study was conducted in a living room environment. The prototype was running on a desktop computer with following specifications: Intel i7-2600 @ 3.40 GHz, 8GB Ram, NVidia GeForce GTX 550 Ti, Samsung 830 256GB SSD. The monitor used a full HD resolution (1920x1080). The prototype was reset and running before the participant was seated at the computer. The prototype allowed the user to explore the XY-house. Using the menu, the time of day could be adjusted, different light settings could be applied, and the environment could be changed. The initial settings of the map were: All lights active, nighttime lighting, and the participant is facing the entrance of the building. The participant was only allowed to explore the XY-house and was not allowed to switch the displayed map.
7.2. Tasks
The participants had to perform five tasks: 1. 2. 3. 4. 5. Walk to the second floor and toggle the light Toggle a light using the Use-key or toggle a light using the menu Switch the environment to the nature environment Switch lighting scenarios Activate the midday time of day setting
51
7.4. Participants
Ten participants (6 female, 4 male, aged 25 to 65) volunteered for the study. The participants were home makers, media informatics students, and professionals from various fields, for example, medicine, chemical engineering, higher education, a tool and configuration manager, and an IT consultant. Only one participant was left handed. Five participants were experts using computers, three experienced, and two had no or little experience using computers. Only two participants were experienced using 3D authoring software, one was a Maya expert, and one an experienced AutoCAD user. Four participants had no prior experience playing video games, two participants had some experience, and four participants had very much experience.
4.50 4.00 3.50 3.00 2.50 2.00 1.50 1.00 0.50 0.00 Computer Experience Experience with 3D authoring software (z.B. AutoCad, Maya, 3DsMax)? Experience with Video Games (e.g., Portal, Quake III)?
52
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 It is easy to enter It is easy to get to The menu (key R) I had no problems the house the second oor was easy to use orienting myself
7.5.2. Light Interaction It was observed that using the E-Key to control the light caused problems for all users; however, in the feedback five participants stated that they had no difficulties. The menu was well received. Six participants answered in the survey that it was easy to control the kitchen light with the menu. It is important to note that the menu gives no indication what button controls the kitchen light and all participants controlled the light by trial and error. No users had problems switching between different lighting setups. However, four users were unclear why such a feature is needed. One participant stated: if I can control every light individually there is no need to have predefined combinations. Three participants were interested if they could place their own lights or move the existing lights.
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Direct control of the lights(key e) doesnt cause problems Changing Controling the With the menu the lights with the kitchenlamp could lightsettings was easy be controled menu (Taste R + without any Menupunkt) was problems easy
7.5.3. Time of Day The entire feature set of the Time of Day possibilities was very well received. Users actively explored the different settings, even though it was not part of their task. Several participants liked how the shadows changed and were amazed of the large differences in length of the shadows. The predefined points in time were sufficient for all participants. Midday, night, morning and afternoon settings were perceived as accurate. One user stated that the afternoon and morning settings were very saturated. 53
6 5 4 3 2 1 0 The ability to The Midday was Afternoon change the predened displayed was time is useful points in correctly displayed time were correctly sucient Nighttime Morning was was displayed displayed correctly correctly
7.5.4. Nature and Cityscape Environment The ability to switch the surroundings was well received. One participant stated he would have liked even more environments to choose from, especially he would have liked to see the building in a typical urban environment. Four participants liked both environments equally. The cityscape environment was preferred by three participants, whereas three participants preferred the nature environment. It is interesting to note that all three participants that preferred the nature environment were female and all three participants that preferred the city environment were male. For four participants the loading time required to switch between the environments disturbed their feeling of being immersed in the experience, however, for four participants the immersion into the experience was not disturbed. One of these participants, a selfdeclared hardcore gamer, stated that he didnt notice any loading time at all.
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 The ability to switch environments is useful The loadingtime during the switch breaks immersion I prefer the city environment over the nature environment
7.5.5. Real Estate Marketing Viability All participants liked the visualization. They had no difficulties imagining how the building would look like if it would have been built in reality. Eight participants were interested to see the building in real. The majority of participants could imagine investing in an architectural project based on 54
the visualization. However, four participants stated they would need more information on the project. All participants were very excited by the prospect of having such a visualization embedded in real estate websites. Almost all participants could not imagine to use such visualization on a mobile device. Two participants stated that the interactions with the hands on a touch display would occlude the display, thus making the visualization useless. One user was interested to use a mobile version of the visualization. The participant stated that it would be enjoyable to brag about his house and letting people virtually walk through his house.
6 5 4 3 2 1 0 I would I would use I would use I liked the I could I am visualization imagine the interested to invest based this this on this visualization visualization property in explore the reality property in visualization on a website as a mobile reality app
7.5.6. Uses of the Visualization The users were asked if they would come up with potential use cases for the visualization. Communication Medium for Architects The biggest complaint of the participants of the study was that architects not always anticipate the needs of people living or working in the building. They believed the visualization was an ideal tool to improve the communication between the architect and the client. One participant stated that while working with an architect, she relied entirely on the architects professional opinion; she did not want to admit that she had difficulties reading technical drawings. She ended up with a room that had the right proportions but was half as big as she would have needed. By using the prototype she felt confident that she understood the correct spacial dimensions of the room. Another participant stated that in the hospital she works for, the architect planned a room encompassing an MRT machine. He was unaware that the machine had to be removed on a three year maintenance schedule. Thus the building was not designed for this requirement. The hospital solved the problem by tearing down and rebuilding the wall every three years. At the time, the head of the hospital was busy figuring out how to read technical drawings and was not fully focused on optimizing the building for the specific needs. By using the visualization, the client could have fully focused on the building and the potential problems with the design; also the staff could have provided valuable input. Realtor / Marketing purposes 55
Most users saw the main benefit of the visualization for marketing purposes. Unlike architectural flythrough animations one has the possibility to freely explore the building. The participants especially liked the benefit of being able to explore potential properties in their web browser and to eliminate the need to visit the sites. Interior decoration Two participants would have liked to have more features, like being able to place furniture into the visualization, enabling the visualization to be a tool for interior decoration. Idea pitching tool for architects A participant suggested that the tool would be an ideal way to persuade investors to invest in large building projects. The increased interactivity and the immersion would be an ideal way to get investors interested in such projects. Learning tool One user suggested the prototype could be used to teach architecture. 7.5.7. Benefits of the visualization The users listed the various perceived benefits of the visualization. Control of the Presentation Participants stated that they liked having control and time to think about the architecture. The size of the building was clearly communicated. In addition, having control of the camera offers the possibility to view any angle without difficulties. This allows detailed views of the property, eliminating the possibility to hide an unfavorable chimney or crooked room. The users perceived the 3D representation superior to 2D technical drawings. Especially people without training or the ability to imagine the architecture have a higher accessibility to architecture. Relocation and International Relocation The visualization saves the time to go and see the property. The ability to view the property independent from the current location would make the search for a suitable property much easier, especially in the context of international relocation. 7.5.8. Downside of the visualization The users listed the various perceived downsides of the visualization. Navigation One participant had a concern that when users were left on their own they could not operate the visualization. System Requirements One participant was concerned that a high end gaming PC is needed to operate the system. Light Visualization Two participants stated that they did not need the internal light visualization in its current form. They would like to have the ability to relocate lights. They argued that when they 56
would move into the house they would put in different types of lamps. Surroundings Two participants stated that the visualization is not connected to the actual surroundings making the displayed surroundings feel too abstract and unnatural. 7.5.9. General Feedback The participants were giving the option to give general feedback. Season Visualization One participant suggested a feature to visualize seasons to even more emphasize how the building would look throuout the year. Glass Material One participant stated that he did not like the reflections of the glass material; he would have expected to see himself in the glass when walking near the glass window. This way he had no way to distinguish between an empty space and a window. Usability A participant had problems activating/deactivating the lights with the E-Key. The user suggested adding a targeting cross hair that indicates if the use function is available or not.
7.6. Observations
Here are some observations on how the participants were using the prototype. 7.6.1. WASD input method Seven participants utilized the WASD controls without having any explicit demonstration or information from the study conductor. The remaining 3 participants had never before played computer games and needed an introduction to the controls. Performing actions using the E-Key was familiar due to similar use in video games. On the other hand, opening the menu with the R-Key was unfamiliar to all participants and had to be explained. Users expected to be able to open the menu using the escape key. No participant utilized the arrow keys for navigation. 7.6.2. Personal All participants reacted to the prototype in a rather personal way; they immediatly drew comparisions with their current living arrangements or work environment. 7.6.3. Age Participants of age 60+ did not see any practical use for the prototype. It was a nice gimmick without any practical use. However, when asked about their current living situation it was revealed that they lived in their home for more than 30 years and did not have any intension of relocating, Participants of age 40-50, were housewives, primarily wanted to use the prototype for interior planning. 57
Students of age 20-30 strongly wanted to see website integration of the prototype.
7.7. Discussion
The study shows, even though the sample size is small, a clear tendency that the users were very engaged in the visualization. None of the participants had major difficulties using the system. Minor usability features could be added to create a smoother user experience. The viewers were neither aware of the artificial nature of the sky visualization nor of the lighting design aspects. Average users take lighting for granted. The users were not aware of the lighting system specifically designed for architectural light visualization. The biggest influence on the perception of the visualization appeared to be dependent on the plan to relocate or invest in a property. If the user is happy with his current living arrangement and has no interest to invest, the viewer has no interest in the visualization. The prototype gives the user the ability to control the visualization and view the building from any angle in different times of day. This tool would make the visualization a powerful marketing tool to appeal to the average user.
58
8.
Summary
The project analyzed the capabilities of using Unreal game technology to be applied in the field of architectural visualization. Maya was used to convert architectural data into UDK assets. This required the creation of a plugin to streamline the workflow. The aim was to lower the entry barrier for professionals and increase efficiency, as well as allowing rapid prototyping of 3D visualizations. Game engine development requires knowledge of different fields: 3D modeling (hard surface modeling, texturing, normal mapping), UDK features (Kismet Visual Scripting, Matinee Animation, UnrealScript), and Scaleform (Flash, ActionScript 3.0). A modular UDK architectural visualization framework was created with following features: configuration of the UDK to support architectural visualization, exchangeable environments, time of day visualization, interior lighting, basic architectural materials, and interface for architectural interaction. The modular nature of the framework allows components of the framework to be easily updated and extended. The core of the framework can be used as the foundation for different types of visualizations not limited to architectural visualization. Using the Maya plugin drastically reduces the time needed to create 3D assets; at the same time 3D artists require no explicit knowledge of the FBX workflow and the plugin is selfexplanatory. In combination with the framework this reduces the entry barrier to work with UDK. Newcomers to the systems only require basic knowledge of 3D modeling, UDK, and optionally Flash, to create visualizations. The framework was used to represent the XY-house. The lighting features available in the UDK were further explored to be able to provide interior lighting. A qualitative study was performed where users could interact with the visualization. The visualization was positively received. The participants were pleased to see a 3D visualized building instead of having to deal with technical drawings. They felt that this would be a good communication medium to confidently provide their ideas to the architect.
As alternative to UDK it is possible to consider open source engines, like GarageGames Torque 3D [35]. At this time the engines do not support full dynamic lights, and other features available in UDK are missing. However, they provide open access to the engine enabling programmers to implement missing features.
60
9.
[1] [2] [3] [4] [5] [6] [7] [8] [9]
References
1. Fritsch D, Kada M. Visualization using game engines. 2004. 3D Cluny III. 1. Dec. 2012. <http://strabic.fr/Cluny-III-en-3D.html> 3D Motive, Modular Building Workflow. 21. Mar. 2013. <https://www.3dmotive. com/f101001> 3ds Max 8 Architectural Visualization, Brian L.Smith A-HSN. (n.d.). Azuma House by Tadao Ando. 1. Mar. 2013, <http://courtyardhouse.blogspot.de/2010/06/azuma-house-by-tadao-ando.html> Adobe After Effects, 20. Mar. 2013. <http://www.adobe.com/products/aftereffects. html> Adobe Flash, 20. Mar. 2013. <http://www.adobe.com/products/flash.html> Amresh, A., & Okita, A. (2010). Unreal Game Development. Natick: A K Peters, Ltd. Autodesk, I. (n.d.). AutoCAD-Funktionen. May 28, 2012, <http://www.autodesk. de/adsk/servlet/pc/index?siteID=403786&id=14564212>
[10] Autodesk. 3D Data Interchange Technology. 20. Mar. 2013. <http://usa.autodesk. com/fbx/> [11] Autodesk 3DsMax, 20. Mar. 2013. <http://usa.autodesk.com/3ds-max/> [12] Autodesk Ecotect Analysis, 27. Mar. 2013. <http://usa.autodesk.com/ecotectanalysis/> [13] Autodesk Ecotect Analysis Visualize sustainable design <http://images.autodesk. com/adsk/files/autodesk_ecotect_analysis_2011_brochure.pdf> [14] Autodesk Software Maya. 1. Oct. 2012. <http://usa.autodesk.com/maya/> [15] Berger, Warren. Future Quest: Go Where No Real Estate Company Has Gone Before. Real Estate Today. January 1994 [16] Busby, J., Parrish, Z. & Wilson, J., Mastering Unreal Technology Volume I: Basic Level Design Concepts with Unreal Engine 3 [17] Busby, J., Parrish, Z. & Wilson, J., Mastering Unreal Technology Volume II: Advanced Level Design Concepts with Unreal Engine 3 [18] Chen L, Architectural Visualization. 2004. [19] Christian Pre, Sbastien Faucher, Cluny : de la gestion de donnes la ralit augmente, 2007 [20] Circus Productions, CIRKUS ANIMATION ABC HOW IT WORKS 1. March 2013 <http://cirkus.co.nz/blog/2010/02/cirkus-animation-abc-how-it-works/> [21] Computer Animation: Expert Advice on Breaking into the buisiness [22] Creating Customer Utopia Through Your Customer Experience, 27. Mar. 2013. <http://www.ravetopia.com/triggering-your-word-of-marketing-strategy-throughyour-customer-experience> 61
[23] CryTek, Official CryEngine 3 Free SDK Documentation, 20. Oct. 2012. <http:// freesdk.crydev.net/dashboard.action> [24] Crytek, Visuals, php?conid=8> 20. Mar. 2013. <http://www.myCryEngine.com/index.
[25] Crytek. Visuals. 1.Oct. 2012. <http://myCryEngine.com/index.php?conid=8> [26] Derakhshani, D., (2012), Introducing to Maya 2013, John Wiley & Sons [27] Digital Tutors, CG 101, 2012 [28] Ecotect: Shadows & Sunlight Hours, 27. Mar. 2013. <http://sustainabilityworkshop. autodesk.com/buildings/ecotect-shadows-sunlight-hours> [29] Epic Games, Introducing Unreal Engine 4, 5 Dec. 2012. <http://www.unrealengine. com/unreal_engine_4/> [30] Epic Games, Introduction to UDK Training Videos, 2007 [31] Epic Games, Landscape Creation, 20. Mar. 2013. <http://udn.epicgames.com/ Three/LandscapeCreating.html> [32] Epic Games. Epic Games Announces the Unreal Development Kit Powered by Unreal Engine. 1.10.2012 <http://www.udk.com/launch> [33] Epic Games. FBX workflow. 1. Oct. 2012. <http://udn.epicgames.com/Three/ FBXStaticMeshPipeline.html> [34] Escape Studios, VFX Career Bible, 2013 [35] GarageGames. Torque 3D. 20. Mar. 2013. <http://www.garagegames.com/products/ torque-3d> [36] Holt T., Games get serious, Computer Games for Visualization and More. 20. Mar. 2013. < http://dusk.geo.orst.edu/Pickup/holt_serious_games.pdf> [37] IBM France, Artway Editions, Cluny : ou, memoires de pierres, 1993, VHS video [38] idSoft. Get Quake 3 engine open source. 11. Nov. 2012. <http://ioquake3.org/getit/> [39] IGN Entertainment. Unreal Engine 3: Official Samaritian Demo. 7. Oct. 2012. <http://www.youtube.com/watch?v=RSXyztq_0uM> [40] Interview Curtis Edwards [41] Interview TUM Architekturinformatik [42] iRay, Speed, Simplicity, Quality [43] Jacobsen, Jeffrey, Hwang, Zimmy, Unreal Tournament for immersive Interactive Theater, 2002 [44] Joshua Buck, jbUDK Tools 20. Mar. 2013. <http://www.cgartistry.com/code.html> [45] Julio Juarez, UDK Sun [46] Karan Shah, Create A 3D Floor Plan Model From An Architectural Schematic In Blender, 2012, 20.Mar. 2013, < http://cg.tutsplus.com/tutorials/blender/create-a-3dfloor-plan-model-from-an-architectural-schematic-in-blender/> 62
[47] LMU-Munich, LFE Medieninformatik, Projektkompetenz Multimedia: Unreal Development, Sommersemester 2012, <http://www.medien.ifi.lmu.de/lehre/ss12/ pkmu/> [48] Microsoft XBox SmartGlass, 27. Mar. 2013. <http://www.xbox.com/en-US/ smartglass> [49] Mozilla is Unlocking the Power of the Web as a Platform for Gaming, 27. Mar. 2013. <http://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlocking-the-power-ofthe-web-as-a-platform-for-gaming/> [50] Nintendo Wii U, 27. Mar. 2013. < http://www.nintendo.de/Wii-U/Wii-U-344102. html> [51] P.Baudisch, Lumino: Tangible Blocks for Tabletop Computers Based on Glass Fiber Bundles [52] Papam Studios. UDK Study: Day cycle Simulation, Work in Progress. 1. Nov. 2012 <http://www.papamstudios.com/projects.html> [53] Perforce, Software Version Management, 20. Mar. 2013. <http://www.perforce. com/> [54] Preview of Autodesk Ecotect Analysis 2010, 27. Mar. 2013. <http://www.youtube. com/watch?v=BKZ35xh4ofw> [55] Prof. Dr. Hermann Parzinger, Neuordnung der Kunstsammlungen der Stiftung Preuischer Kulturbesitz, 30. Nov. 2012. <http://www.rotary1940.de/berlin/00_ aktuell/parzinger_kunstsammlung.php?mydesign=tuerkis&client=berlin&clie nt_wID=888&print=true> [56] PublicVR, CaveUT. 5. Dec 2012. http://publicvr.org/html/pro_caveut.html [57] Ramamoorthi, Ravi, and Pat Hanrahan. An efficient representation for irradiance environment maps. Proceedings of the 28th annual conference on Computer graphics and interactive techniques. ACM, 2001. [58] Recoil Games. Rochard Screenshot. 21. Mar. 2013. <http://www.rochardthegame. com/en/screenshots/> [59] Rman197, Extract Google Earth models to 3ds max tutorial, 20. Mar. 2013. <http:// www.youtube.com/watch?v=18QbZyuy2JY> [60] Rodrigo Zacharias, Decorated Suite, 1. Dec 2012. <http://www.cgarchitect. com/2012/12/decorated-suite> [61] Roman Lut, 3D Ripper DX , 20. Mar. 2013. <http://www.deep-shadows.com/ hax/3DRipperDX.htm> [62] RTT AG, System requirements and installation. 2012 [63] Team Black Mesa Modification. About the Mod. 11. Nov 2012. <http://wiki. blackmesasource.com/Black_Mesa:About_the_Mod> [64] The Foundry Nuke, 27. Mar. 2013 <www.thefoundry.co.uk/products/nuke/> [65] Tiffany Ortis, Is Solar Design a Straitjacket for Architecture? [66] Ubisoft Farcry 3, php?conid=69&id=18> 20. Oct. 2012. <http://myCryEngine.com/index. 63
[67] UDK Documentation, ActorX Plugin, http://udn.epicgames.com/Two/ActorX.html [68] UDK Documentation, Level optimization guide, 20. Oct. 2012. <http://udn. epicgames.com/Three/LevelOptimization.html> [69] Unity Technologies. Unrivaled Power Meets Unparalleled Productivity. 1. Oct. 2012. <http://unity3d.com/unity/engine/> [70] Unreal Engine 4 - GT.TV Exclusive Development Walkthrough <http://www. youtube.com/watch?v=MOvfn1p92_8> [71] UnrealWiki, Legacy:T3D File. 20. Mar. 2013. <http://wiki.beyondunreal.com/ Legacy:T3D_File> [72] Unreal Wiki, Legacy:Unreal Unit, 20. 0ct. 2012, <http://wiki.beyondunreal.com/ Legacy:Unreal_Unit> [73] Valve, Half-Life 2 raising the bar, Prima Games, Roseville 2004 [74] Viktor Fretyan, Lighting La Salle - Indoor Illumination Tutorial Series [75] Wissler V, Illuminated Pixel, 2012, Cengage Learning [76] World of Level Design. UDK: 18 Important Principles for Creating and Using Lightmaps in UDK (Lightmapping Basics). 1.Oct. 2012. <http://www. worldofleveldesign.com/categories/udk/udk-lightmaps-01-basics-and-importantprinciples-for-creating-using-lightmaps.php> [77] Yanni Hajioannou, 2013, 20. Mar. 2013. <http://gamedev.tutsplus.com/articles/ glossary/quick-tip-what-is-a-normal-map/>
[78]
64
65
+ version), wh = (windowWidth, windowHeight), sizeable = False, mbv=True, mnb = True, mxb=False, menuBar = True) cmds.menu( label=? , helpMenu=True) cmds.menuItem(About) cmds.columnLayout(w= 255, h = 350) widgets[tabLayout] = cmds.tabLayout(imw = 5, imh = 5) for item in tabnames: widgets[ (item + _ tab) ] = cmds.columnLayout(w = 254, h = 350, parent = widgets[tabLayout]) cmds.tabLayout(widgets[tabLayout], edit = True, tabLabel = (widgets[ (item + _ tab) ], item)) createTab(item) cmds.showWindow(window) def createTab(name) : Creates a Tab for the UI Call the function from UDKToolBox() name: Name of the Tab categoryWidth = 250 threeBtnWidth = 80 oneBtnWidth = 3*threeBtnWidth btnHeight = 30 tabname = (name + _ tab) if name == tabnames[0]: categoriesGeneral = [Grid, References, Collision, UV Layout, Misc] for item in categoriesGeneral: widgets[ (tabname + item) ] = cmds.frameLayout(label = item, collapsable = True, parent = widgets[tabname]) parent = cmds.rowColumnLayout(nr = 1, w= categoryWidth, p = widgets[ (tabname + item) ]) if item == categoriesGeneral[0]: widgets[grid _ btn] = cmds.button( w= threeBtnWidth, h = btnHeight, c= toggleGridSnap, p = parent) toggleGridSnap(init) cmds.button( w=threeBtnWidth, h=btnHeight, label=UDK Grid, c=partial(changeGridSettings,udk), p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Default Grid, c=partial(changeGridSettings,default), p = parent) if item == categoriesGeneral[1]: 67
parent = cmds.rowColumnLayout(nr = 5, w=categoryWidth, p = widgets[ (tabname + item) ]) widgets[references _ import] = references _ import cmds.optionMenu( widgets[references _ import], w=categoryWidth, label=Choose a Reference: , p = parent) populateReferenceImportMenu() cmds.button( h=btnHeight, w = oneBtnWidth, label=Import, c = referencesImport, p = parent) cmds.separator(h= 10, p = parent) cmds.rowColumnLayout( nr= 1, cs= [ (1,2), (3,3), (5,3) ], p= parent ) cmds.text(w= 10, label=W) widgets[references _ wField] = references _ wField cmds.floatField( widgets[references _ wField], w=40, min=0, v=4.0, pre=1 ) cmds.text(w= 10, label=H) widgets[references _ hField] = references _ hField cmds.floatField( widgets[references _ hField], w=40, min=0, v=6.0, pre= 1 ) cmds.text(w= 10, label=D) widgets[references _ dField] = references _ dField cmds.floatField( widgets[references _ dField], w=40, min=0, v=4.0, pre=1 ) cmds.button( h=btnHeight, w=oneBtnWidth, label=Cube Reference(cm), c = referenceCube, p = parent) if item == categoriesGeneral[2]: cmds.button( w=threeBtnWidth, h=btnHeight, label=Box, c=partial(createCollision,box), p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Sphere, c=partial(createCollision,sphere), p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Duplicate, c=partial(createCollision,duplicate), p = parent) if item == categoriesGeneral[3]: cmds.button( w=threeBtnWidth, h=btnHeight, label=UV Editor, c=uv _ openUVEditor, p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Auto Map, c=uv _ autoMap, p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Light Map, c=uv _ lightMap, p = parent) if item == categoriesGeneral[4]: 68
cmds.button( w=threeBtnWidth, h=btnHeight, label=Name Materials, c=applyTextureNaming, p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Del CH /& FT, c=cleanup, p = parent) cmds.button( w=threeBtnWidth, h=btnHeight, label=Normalize Position, c=normalizePosition, p = parent) elif name == tabnames[1]: categoriesAnimation = [Set Animations] for item in categoriesAnimation: widgets[ (tabname + item) ] = cmds.frameLayout(label = item, collapsable = True, parent = widgets[tabname]) elif name == tabnames[2]: TODO: Add Animation Export categoriesExport = [Export Tools, Static Mesh Level Export ] for item in categoriesExport: widgets[ (tabname + item) ] = cmds.frameLayout(label = item, collapsable = True, parent = widgets[tabname]) parent = cmds.rowColumnLayout(nr = 1, w= categoryWidth, p = widgets[ (tabname + item) ]) if item == categoriesExport[0]: #Validate cmds.button( w=threeBtnWidth, h=btnHeight, label=Validate, c=uv _ openUVEditor, p = parent) cmds.button( w=81, h= 30, label=FBX Export, c=uv _ openUVEditor) cmds.button( w=81, h=30, label=FBX Settings, c=export _ fbxSettings) elif item == categoriesExport[1]: #Export Actor cmds.rowColumnLayout( numberOfColumns=2) cmds.text( label=Export Directory: ) cmds.text(label = ) widgets[export _ Dir] = cmds.textField(text = C:/UDKExport/) cmds.button(label = Browse, c = export _ browse) cmds.text( label=PackageName: ) widgets[export _ packagename] = cmds. textField(text = MyPackage) cmds.rowColumnLayout( numberOfColumns=1, columnAttach= (1, right , 0), columnWidth=[ (1, 100), (2, 250) ] ) cmds.separator(h= 10, p = parent) 69
cmds.button( w=81, h=30, label=Level Export, c= export _ Level) ################################################################ ################################ #Grid def changeGridSettings(mode, *args) : #default settings s, sp, div, ncp, fcp, gac, ghc, gc, trans = 12, 5, 5, 0.1, 10000.0, 1, 3, 3, 100.1 cmds.grid ( size=s, spacing=sp, divisions=div ) if mode == udk: #sets UDK grid settings s, sp, div, ncp, fcp, gac, ghc, gc, trans = 512, 16, 1, 0.1, 160000.0, 1, 3, 2, 10000.0 cmds.grid ( size=(sp * 32), spacing=sp, divisions=div ) ) ) cmds.displayColor ( gridAxis , gac, c=True, dormant=True cmds.displayColor ( gridHighlight , ghc, c= True, dormant= True cmds.displayColor ( grid , gc, c=True, dormant=True ) cmds.setAttr ( perspShape.farClipPlane , fcp ) cmds.setAttr ( perspShape.nearClipPlane , ncp) cmds.setAttr ( topShape.farClipPlane , fcp ) cmds.setAttr ( topShape.nearClipPlane , ncp ) cmds.setAttr ( sideShape.farClipPlane , fcp ) cmds.setAttr ( sideShape.nearClipPlane , ncp ) cmds.setAttr ( frontShape.farClipPlane , fcp ) cmds.setAttr ( frontShape.nearClipPlane , ncp ) cmds.setAttr ( top.translateY , trans ) cmds.setAttr ( front.translateZ , trans ) cmds.setAttr ( side.translateX , trans ) mel.eval(fitPanel -selected;) def toggleGridSnap(*args) : mode = cmds.snapMode(q=True, gr = True) if args[0] != init: if mode: cmds.snapMode(gr=False) print here else: cmds.snapMode(gr=True) if mode: 70
cmds.button(widgets[grid _ btn], e= True, label =Enable GridSnap ) else: cmds.button(widgets[grid _ btn], e= True, label =Disable GridSnap ) ################################################################ ################################ #References def populateReferenceImportMenu() : projectPath = os.path.dirname( _ _ file _ _ ) + /UDKToolBox/ ReferenceObjects files = os.listdir(projectPath) for item in files: if (item.rpartition(.) [2] = = mb) or (item.rpartition(.) [2] == ma) : niceName = item.rpartition(.) [0] cmds.menuItem(label = niceName, parent = widgets[references _ import]) def referencesImport(*args) : sel = cmds.optionMenu(widgets[references _ import], q = True, select=True) - 1 projectPath = os.path.dirname( _ _ file _ _ ) + /UDKToolBox/ ReferenceObjects item = projectPath + / + os.listdir(projectPath) [sel] cmds.file(item, i = True, gr = True, ra = True, pr = True, ns = item.rpartition(.) [0] ) def referenceCube(*args) : width = cmds.floatField(widgets[references _ wField], q=True, v=True) height = cmds.floatField(widgets[references _ hField], q=True, v=True) depth = cmds.floatField(widgets[references _ dField], q=True, v=True) cmds.polyCube(n = ref _ cube,w=calc _ cm _ to _ uu(width), h=calc _ cm _ to _ uu(height), d=calc _ cm _ to _ uu(depth), sx = width, sy = height, sz = depth) cmds.move ( 0, ((height*16)/2), 0 ) def calc _ cm _ to _ uu(value) : return value * 16 ################################################################ ################################ 71
#Collision def createCollision(mode, *args) : createCollisionDisplayLayer(); selection = cmds.ls(selection = True) for item in selection: #check if boundingBox exists if not cmds.objExists((UCX _ + item)) : name = item #prevent Bounding Boxes to get Collision Objects if item.rpartition( _ ) [0] != UCX: if mode == duplicate: boundingBox = cmds.duplicate(item, n = (UCX _ + item)) else: #create bounding box x, y, z = cmds.polyEvaluate(name, boundi ngBox=True,accurateEvaluation=True); boundingBox = None; #Center Pivot originalPivot = cmds.xform(name, query=True, cmds.xform(name, centerPivots=True) piv = cmds.xform(name, query=True, piv=True
piv=True ) )
#create Bounding Box width = x[1] - x[0]; height = y[1] - y[0]; depth = z[1] - z[0]; boundingBox = cmds.polyCube(n = (UCX _ +name), w = width, h = height, d=depth, ch = False); if mode == sphere: #create Sphere radius = 0.0; for i in range(0, 7) : print i vtx = cmds.pointPosition((boundingBox[0] xd = vtx[0]-piv[0] yd = vtx[1]-piv[1] zd = vtx[2]-piv[2] 72
+ .vtx[%s] % i))
+ yd*yd + zd*zd))
distance = math.sqrt(math.fabs(xd*xd
if distance > radius: radius = distance print radius cmds.delete(boundingBox) boundingBox = cmds.polySphere(n = (UCX _ +name), r=radius, sx = 16, sy = 16, ch = False) #Translate Bounding Box to Original Object trans = cmds.xform(name, query=True,
translation=True)
cmds.xform(boundingBox, translation = (piv[0] + trans[0], piv[1] + trans[1], piv[2] + trans[2]) ) cmds.makeIdentity(boundingBox, apply=True, t= 1, r= 1, s= 1, n=2 ) cmds.xform(name, piv= (originalPivot[0], originalPivot[1], originalPivot[2])) #Parent to original Object cmds.parent(boundingBox, name) cmds.editDisplayLayerMembers(collision _ DisplayLayer, boundingBox) cmds.select(name) else: print (%s has a collision Object % item) cmds.setAttr(%s.visibility % (UCX _ + item), 1) 1) cmds.setAttr(%s.visibility % (collision _ DisplayLayer),
def createCollisionDisplayLayer() : collisionLayerName = collision _ DisplayLayer if not cmds.objExists(collisionLayerName) : cmds.createDisplayLayer(n=collisionLayerName, empty = True) cmds.setAttr(%s.displayType % collisionLayerName, 1) ################################################################ ################################ #UV Layout def uv _ openUVEditor(*args) : mel.eval(TextureViewWindow) def uv _ autoMap(*args) : selection = cmds.ls(selection = True) for item in selection: pm.select(item) 73
cmds.polyAutoProjection(item, planes = 6, optimize = 1, layout = 2, scaleMode = 1, n = autoprojection, ws = 0, uvs = map1) def uv _ lightMap(*args) : lightmapName = lightMap selection = cmds.ls(selection = True) for item in selection: pm.select(item) indices = cmds.polyUVSet(item, query= True, allUVSetsIndices=True) createUVSet = True for i in indices[:]: name = cmds.getAttr(item +.uvSet[+str(i)+]. uvSetName) if name == lightmapName: createUVSet = False if createUVSet: cmds.polyUVSet(item, create = True, uvSet = lightmapName) cmds.polyAutoProjection(item, planes = 6, optimize = 1, layout = 2, scaleMode = 1, ws = 0, uvs = lightmapName) cmds.polyLayoutUV(item, layout = 2, percentageSpace = 3, scale = 2, se = 1, rbf = 2, uvs= lightmapName) ################################################################ ################################ # Verification def verification() : geometry = cmds.ls(geometry = True) for geo in geometry: if checkNurbs(geo) : print Error convert %s to Polygon % geo else: transform = cmds.listRelatives(geo, parent = True) [0] if not checkCollision(transform) : print (Error no collision object for %s % geo) return False if not check _ lightmapExists(transform) : print (Error no LightMap %s % geo) return False return True def checkNurbs(obj) : return cmds.nodeType(obj) == nurbsSurface 74
def checkCollision(obj) : if obj.rpartition( _ ) [0] == UCX: return True return cmds.objExists(UCX _ %s % obj) def check _ lightmapExists(obj) : if obj.rpartition( _ ) [0] == UCX: return True lightmapName = lightMap indices = cmds.polyUVSet(obj, query= True, allUVSetsIndices= True) for i in indices[:]: name = cmds.getAttr(obj +.uvSet[+str(i)+].uvSetName) if name == lightmapName: return True return False def applyTextureNaming(*args) : materials = cmds.ls(mat=True) for mat in materials: if (cmds.nodeType(mat) = = lambert) or (cmds. nodeType(mat) = = blinn) or (cmds.nodeType(mat) = = phong) : #Format material Name if mat.rpartition( _ ) [0] != MAT and mat != lambert1: mat = cmds.rename(mat, (MAT _ + mat)) #Format Color / Diffuse node = cmds.connectionInfo(%s.color % mat, sfd = True) .rpartition(.) [0] if node != : if cmds.nodeType(node) == file : filename = cmds.getAttr(%s.fileTextureName % node) .rpartition(/) [2] if filename.partition( _ ) [0] != TX or filename.rpartition( _ ) [2] != D : path = cmds.getAttr(%s.fileTextureName % node) newFilePath = path.rpartition(/) [0] + /TX _ %s _ D. % mat.rpartition( _ ) [2] + path.rpartition(.) [2] cmds.setAttr(%s.fileTextureName % node, newFilePath, type = string) os.rename(path, newFilePath) #format Normal Map node = cmds.connectionInfo(%s.normalCamera % mat, 75
sfd = True) .rpartition(.) [0] if node != : if cmds.nodeType(node) == bump2d : node = cmds.connectionInfo(%s.bumpValue % node, sfd = True) .rpartition(.) [0] if cmds.nodeType(node) == file : filename = cmds.getAttr(%s.fileTextureName % node) .rpartition(/) [2] if filename.partition( _ ) [0] != TX or filename.rpartition( _ ) [2] != N : path = cmds.getAttr(%s.fileTextureName % node) newFilePath = path.rpartition(/) [0] + /TX _ %s _ N. % mat.rpartition( _ ) [2] + path.rpartition(.) [2] cmds.setAttr(%s.fileTextureName % node, newFilePath, type = string) os.rename(path, newFilePath) if (cmds.nodeType(mat) != lambert) : print here #format specular (not available on lambert) node = cmds.connectionInfo(%s.specularColor % mat, sfd = True) .rpartition(.) [0] if node != : if cmds.nodeType(node) == file : filename = cmds.getAttr(%s.fileTextureName % node) .rpartition(/) [2] if filename.partition( _ ) [0] != TX or filename.rpartition( _ ) [2] != S : path = cmds.getAttr(%s.fileTextureName % node) newFilePath = path.rpartition(/) [0] + /TX _ %s _ S. % mat.rpartition( _ ) [2] + path.rpartition(.) [2] cmds.setAttr(%s.fileTextureName % node, newFilePath, type = string) os.rename(path, newFilePath) def normalizePosition(*args) : selection = cmds.ls(selection=True) for item in selection: print item bb = cmds.xform(item, q = True, ws = True, bb = True) cmds.xform(item, ws = True, rp = (bb[0], bb[1], bb[2]), sp = (bb[0], bb[1], bb[2])) cmds.move(0,0,0, item, a = True, rpr = True) 76
cmds.makeIdentity(item, apply=True, t=1, r=1, s=1, n=2 ) cmds.delete(item, ch = True) def cleanup(*args) : items = cmds.ls(selection = True) for item in items: cmds.makeIdentity(item, apply=True, t=1, r=1, s=1, n=2 ) cmds.delete(item, ch = True) ################################################################ ################################ def export _ Level(*args) : TODO: Prior verification TODO: Check if Selection != 0 filepath = cmds.textField(widgets[export _ Dir], q = True, tx=True) packagename = cmds.textField(widgets[export _ packagename], q = True, tx=True) selection = ls(selection = True) if 0 == len(selection) : cmds.confirmDialog(title = Error, message = No valid selection has been made, button = OK) else: selection2 = ls(selection = True) export _ T3D(filepath, packagename,selection) export _ FBX(filepath, packagename,selection2) cmds.confirmDialog(title = Export Completed, message = Export Successful! \n Next steps: \n 1) Import FBX-files to UDK \n 2) Save the Package \n 3) Import T3D File, button=OK) def export _ FBX(filepath, packagename, selection) : directory = filepath + / + packagename + / if not os.path.exists(directory) : os.makedirs(directory) for i in selection: if i.rpartition( _ ) [0] != UCX: pm.select(i) if cmds.objExists((UCX _ + i)) : cmds.select((UCX _ + i), tgl = True) cmds.file(directory + i +.fbx, es = True, type = FBX export, f = True) def export _ T3D(filepath, packagename, selection) : pm.ls(sl = True) sceneTitle = + sceneName() 77
if (sceneTitle.rpartition(.) [2] == mb) or (sceneTitle. rpartition(.) [2] == ma) : sceneTitle = sceneTitle.rpartition(.) [0] sceneTitle = sceneTitle.rpartition(/) [2] elif len(sceneTitle) == 0: sceneTitle = untitled try: # This tries to open an existing file but creates a new file if necessary. print filepath + str(sceneTitle) +.t3d f = open(filepath + str(sceneTitle) +.t3d, w) try: f.write(Begin Map Name= + str(sceneTitle) + \n ) f.write(\tBegin Level NAME=PersistentLevel\n) for i in selection: actorName = i f.write(\tBegin Actor Class=StaticMeshActor Name=%s Archetype=StaticMeshActorEngine.Default _ _ StaticMeshActor\n % actorName) f.write(\t\tBegin Object Class= StaticMeshComponent Name=StaticMeshComponent0 Archetype=StaticMeshComponentEngi ne.Default _ _ StaticMeshActor:StaticMeshComponent0\n) f.write(\t\tStaticMesh=StaticMesh%s.%s\n % (packagename, actorName)) f.write(\t\tEndObject\n) loc = pm.xform(i, q = True, t=True, ws=True) rot = pm.xform(i, q = True, ro=True, ws=True) scale = pm.xform(i, q = True, s=True) loc[1], loc[2])) f.write(\tLocation=(X=%f,Y=%f,Z=%f) \n % (loc[0],
f.write(\tRotation=(Roll=%f,Pitch=%f,Yaw=%f) \n % (rot[0], rot[1], rot[2])) f.write(\tDrawScale3D= (X=%f,Y=%f,Z=%f) \n % (scale[0], scale[1], scale[2])) f.write(\tEnd Actor\n) f.write(\tEnd Level\n) f.write(End Map\n) finally: f.close() except IOError: pass 78
def export _ browse(*args) : indir = cmds.fileDialog2(fileMode = 2, okCaption = Select) [0] cmds.textField(widgets[export _ Dir], e = True, text = indir) def export _ fbxSettings(*args) : mel.eval(FBXUICallBack -1 editExportPresetInNewWindow fbx;)
btn btn btn btn btn btn btn btn btn btn btn btn btn btn btn btn );
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
second _ two, second _ three, second _ four, third _ one, night, morning, evening, midday, city, nature, lamppost, cancel, allLights, lightsetting1, lightsetting2, lightsetting3
//register EventListener for (var i:int = 0; i < btn _ arr.length; i++){ b t n _ a r r[i].a d d E v e n t L i s t e n e r( M o u s e E v e n t.C L IC K, sendFscommand); } //Send Commands to Scaleform function sendFscommand(e:MouseEvent) :void{ var button:SimpleButton = SimpleButton(e.target) trace(button.name); fscommand(button.name); } stop();
80