games development practices 3d model import/export co2301 games development 1 week 17
TRANSCRIPT
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)