Games Development Practices3D Model Import/Export

CO2301 Games Development 1

Week 17

Today’s LectureToday’s Lecture

1. 3D Model File Formats

2. Writing Export Scripts

3. Commercial Exporters/Converters

4. Dealing with Artists/Designers

5. Common Artwork Problems

6. Ground-rules to Avoid Problems

Saving in Native File FormatsSaving 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 FormatsOther 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 FormatsLimitations 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 ScriptsWriting 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 GamesWriting 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/ConvertersExporters/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/DesignersDealing 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 1Artwork 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 2Artwork 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 AssetsExample 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 ProblemsGround-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-RulesMore 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)