Games Development Practices 3D Model Import/Export CO2301 Games Development 1 Week 16

Today’s Lecture 3D Model File Formats Writing Export Scripts Commercial Exporters/Converters Dealing with Artists/Designers Common Artwork Problems Ground-rules to Avoid Problems

Saving in Native File Formats We will use Autodesk Maya to do some simple 3D modelling We also have Autodesk 3DS Max available It is easy to save scenes in Maya’s own format .mb for binary files, .ma for ASCII (text) files However, these formats are not suitable for games: Data is not optimised for real-time apps, or for hardware support Maya’s format is effectively a scripted language Very difficult to parse Same applies to other modelling packages

Other 3D Model Formats Could use another simpler export format… Many available: .obj : Wavefront Object file, longstanding simple format – good for basic geometry, but lack of features and rather dated .X : Microsoft DirectX file, closely tied to DirectX and quite simple. Suffers from loose specification and lack of key features (e.g. camera export). .fbx: Format that originated from motion capture software. Has become quite useful for conversions. However, just like the .X file it suffers from having no formal specification. Many other open and proprietary formats…

Limitations of other Formats Each format is lacking in one or more areas, and is unlikely to suit our needs exactly: We will be limited to the feature-set of the chosen format Not always built-in support for such formats E.g. Maya does not support any of these, although Microsoft provide a Maya plug-in exporter for .X files and there are third-party exporters also When there is built-in support, it's often limited or broken There is a lack of specifications for many 3D file formats Animation is particularly hard to export correctly

Writing Export Scripts 3D modelling tools often have built in scripting languages For example, Maya supports MEL (Maya Embedded Language) or the more standard Python language Can access to the elements in the scene using these languages Some have a C++ API Write powerful built-in tools using C++ code Can use scripts or API to write a custom exporter: Go through each scene element and write its data to a file Can write to a known format or specify our own If we write our own, we will not be able to import into other packages though

Writing Export Scripts for Games Custom exporters are not unusual in games development A custom exporter allows us to export richer content from our modelling tool Camera paths, AI networks, object stats etc. Although may be better use a level editor for the latter Add these custom elements to our exporter Create game-specific files from the modelling tool This kind of script development falls under the area of Tools Development It is a common task for Junior Programmers

Exporters/Converters Microsoft provide a DirectX exporter for Maya Also support for 3D Studio Max Limited support for the Maya features, and generates a particular variety of DirectX file Several other free / commercial exporters, the majority of which focus on particular products Here we have a license of PolyTrans (Okino), which can convert between many different formats It is one of the most general-purpose tools Fixes broken files and works around format limitations A useful route for us is to export into the free modelling tool “Blender” and export from there into .X files.

Dealing with Artists/Designers 3D engines have specific technical requirements for their 3D models and other game assets But artists & designers are not necessarily technically-minded Not involved with the details of the 3D Engine Cannot be expected to strictly adhere to technical requirements Two implications: Explain as clearly and simply as possible any technical requirements for game assets Deal professionally with misunderstandings and problem artwork

Artwork Requirements 1 The technical requirements of 3D Engines fall into several areas: Supported features: many features of the 3D modelling package will not be supported in real-time Polygon budgets: game speed will be affected by having too many polygons Supported material types: engine will require materials to be built in a particular way Linked to textures and shaders in the game engine Geometry restrictions: valid ranges for coordinates, topographical constraints etc. - many issues here Also: number of lights, overall complexity of scenes etc. etc.

Artwork Requirements 2 Also common sense requirements: Sensible sizes for objects, compared to other objects in the game - defining units for the game Avoiding redundant geometry, e.g. one object hidden inside another, barely visible geometric detail Avoiding invalid geometry, e.g. cracks in geometry, inside-out objects etc. Some technical and common sense requirements can be checked by a export script But problems always slip through

Example Problem Assets A 180 metre tall character The artist slipped into centimetre measurement An entire building hidden inside another one The designer moved some geometry and lost sight of the extra building A crate built with 15,000 polygons Artist wasn’t given, or ignored the polygon budget – artists often default to “movie mode” A character with 206 bones in their skeleton Another budget issue However, all of these are excusable Until you can write a program without bugs…

Ground-Rules to Avoid Problems To avoid these problems, clearly establish a set of asset ground-rules Specify requirements in a technical design document: Unit size, e.g. 1 unit = 1 metre Target poly count for an in game scene Typical poly counts for different object types, e.g. characters, vehicles, pick-ups Material requirements, e.g. size of textures, available effects and the relative expense of each Geometric constraints Also helps to explain the details face-to-face

More Artwork Ground-Rules Using an export script you must precisely specify how the modelling tool should be used: What features are unavailable How to work with complex features such as animation skeletons or materials What other game features can be specified, and how The file formats to be used for output Tools to use for processing (e.g. normal map generation) Don’t be lazy – don’t force artists to do unnecessary work that could be done in code. Also keep artists updated when changes occur in the engine (improvements or restrictions)