Games Development Practices 3D Model Import/Export

Games Development Practices3D 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)

Games Development Practices 3D Model Import/Export