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

2. 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

3. 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

4. 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…

5. 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

6. 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

7. 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

8. 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.

9. 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

10. 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.

11. 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

12. 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…

13. 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

14. 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)