Games Development Practices 3 D Model ImportExport CO

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

Today’s Lecture 1. 2. 3. 4. 5. 6. 3 D 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 3 D modelling – We also have Autodesk 3 DS 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 3 D 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 Direct. X file, closely tied to Direct. X 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 thirdparty exporters also • When there is built-in support, it's often limited or broken – There is a lack of specifications for many 3 D file formats – Animation is particularly hard to export correctly

Writing Export Scripts • 3 D 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 Direct. X exporter for Maya – Also support for 3 D Studio Max – Limited support for the Maya features, and generates a particular variety of Direct. X file – Several other free / commercial exporters, the majority of which focus on particular products • Here we have a license of Poly. Trans (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 • 3 D engines have specific technical requirements for their 3 D models and other game assets • But artists & designers are not necessarily technicallyminded – Not involved with the details of the 3 D 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 3 D Engines fall into several areas: – Supported features: many features of the 3 D 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.

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)