Professional Documents
Culture Documents
Revision History
Issue Date Person Reason - include problem #, ECN #, etc.
0.2 July 20, 2001 Adam King General revisions and updates
0.3 July 23, 2001 Adam King Collision volume tool help in model pipeline
0.5 July 25, 2001 Adam King Added facial animation pipeline
General Revisions
0.6 July 27, 2001 Adam King General revisions based on review by Bert Sandie
0.7 Aug 1, 2001 Adam King General revisions based on reviews by Juneko
Kurahashi and Bert Sandie
0.8 Aug 17, 2001 Adam King Animation, Facial Animation, and World Builder
S ti d t d
Radical Entertainment. All rights reserved. No part of this publication, or any software included with it may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, including photocopying, electronic, mechanical, recording or otherwise, without prior written
permission of the copyright holder.
This document contains proprietary information of Radical Entertainment. The contents are confidential and any disclosure to persons other than
the officers, employees, agents, or subcontractors of the owner or licensee of this document, without prior written consent of Radical
Entertainment is strictly prohibited.
Radical Entertainment
DA Content Pipelines 18-Oct-02
Sections updated.
1.0 Sept 10, 2001 Adam King Updated Bounding Volume Section
1.1 Sept 11, 2001 Adam King Letterboxing and NIS bundle info added
TABLE OF CONTENTS
1. Introduction............................................................................................................................13
1.1 Scope..............................................................................................................................13
1.2 Intended Audience .........................................................................................................13
1.3 References......................................................................................................................13
1.4 Acronyms and Definitions .............................................................................................14
2. General Information...............................................................................................................15
2.1 Loading Data..................................................................................................................15
2.2 Version Control..............................................................................................................16
8. FMV Pipeline.........................................................................................................................69
8.1 Description.....................................................................................................................69
8.1.1 Pipeline Description...................................................................................................69
8.1.2 Goals of the Pipeline..................................................................................................69
18. Appendix B: When your Maya files are blowing out of proportion:...............................119
18.1 Regular maintenance on the file ..................................................................................119
18.2 After the Maya file is final and is ready to be exported to the game….......................122
Figure 6: Plug-in manager were p3dDeformer.mll must have both boxes checked......................30
Figure 26: Setting custom polygon display options to show CBV lighting. .................................94
1. INTRODUCTION
The document describes all of the pipelines to be used for the Dark Angel project. It outlines the
pipelines purpose, associated tools, workflows, restrictions, etc. The main purpose is to collect
all of the information for all pipelines for the game in a single technical document.
1.1 Scope
This document deals with all of the content pipelines for the DA game.
Primarily this document is aimed at programmers and other technical personnel on the project
team and in support and management roles. The document will also be of interest to the art
director and the technical artists working on the team.
1.3 References
[5.] Sandie, Bert and Kusy, Brad: DA World Builder Technical Overview
(//depot/docs/TechDesign/DA_WorldBuilderTechOverview.doc).
[6.] Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
[8.] Brandt, Bryan: Fight Tree Reference Hair Club Perforce (SV060:1679).
[9.] Ancessi, Laurent: Building the Motion Tree and Animation System Hair Club Perforce
(SV060:1679).
[10.] Brooke, Nigel: Dark Angel Rendering Engine Technical Design Document
(//depot/docs/TechDesign/RenderingEngine.doc).
[15.] Keong Gary and Sandie, Bert: Requirements for DA Skeleton Structure
(//depot/docs/TechRequirements/DA_SkeletonRequirements.doc).
[17.] Kurahashi, Juneko and Kusy, Brad: World Builder Workflow Description
(//depot/docs/TechDesign/WorldBuilderFlow.doc).
Some useful acronyms and definitions to help the reader better understand some concepts are
provided below.
DA Dark Angel
PS2 Playstation2
NPC Non-player character – characters in the game that are controlled completely by
the AI without user input
Level A collection of connected rooms or areas ( via portals ) on which a mission takes
place
Mission A set of objectives that must be met by the user player in the game
NIS Non-interactive sequence
SFX Special Effects
FE Front-End
HUD Heads-up Display
LOD Level of Detail
AI Artificial Intelligence
Mipmapping Mipmapping is a method of avoiding the shimmering effect that can result from
high detail textures being displayed on an object that is “far” away which can
result in pixels popping in and out.
Tri-strip A set of connected triangles that share vertices for efficient drawing.
Portal A connection between any two rooms or areas.
Room The smallest interior unit of a world that can be realized without passing through a
portal (convex).
World A collection of levels that compose the world the game will take place in.
Blueprint A 2D construction/layout of a level upon which a 3D model will be built.
Trigger volume When a collision with this geometrical construct takes place a game event will be
generated.
TBD To Be Determined
Multicontroller The controller that looks after an animation.
2. GENERAL INFORMATION
This section deals with information that is applicable to more than one of the pipelines that will
follow.
[shot12]
file nis\preprod\nis1\shot12.p3d
file nis\preprod\nis1\shot12.seq
export nis1 nis control:shot12 draw:shot12 camera:pp_shotShape1 lights:Scene
events:shot12 next:shot3 alone
[shot3]
file nis\preprod\nis1\shot3.p3d
export shot3 nis control:shot3 draw:shot3 camera:pp_shotShape3 next:shot4
lights:Scene alone
[shot4]
file nis\preprod\nis1\shot4.p3d
export shot4 nis control:shot4 draw:shot4 camera:pp_shotShape4 lights:Scene
next:shot4b alone
[shot4b]
file nis\preprod\nis1\shot4b.p3d
export shot4b nis control:shot4b draw:shot4b camera:pp_Shot4bShapeo next:shot4c
lights:Scene alone
[shot4c]
file nis\preprod\nis1\shot4c.p3d
export shot4c nis control:shot4c draw:shot4c camera:ppShot4cShape next:shot5
lights:Scene alone
[shot5]
file nis\preprod\nis1\shot5.p3d
export shot5 nis control:shot5 draw:shot5 camera:anim_camsShape lights:Scene alone
Each bundle starts with the name of the bundle in square brackets, then has a list of keywords.
The three keywords are file, depend and export.
"file" just adds a file to the list of what will be loaded for that bundle
"depend" indicates that the given bundle required another bundle to be loaded previously, and
the local objects can reference object in the other bundle.
"object name" is the name used to reference the object in the game.
"object type" is a standard identifier indicating what the object is, and "arguments" are additional
type specific initialization info.
The loading system is set up in such a way that it is easy to add new export types without
changing the rest of the system.
A couple of points that should be noted for the loading of NIS files in bundle files you will want
to add on the extra parameters for specifying the control, drawing, camera, transition (specify
next NIS in the sequence, and allowing for specification on whether the NIS will be running over
the regular world or not. The camera parameter allows you to specify the camera that will be
used to start the NIS off. There is also the capability to use either alone or nothing that gives the
NIS the capability to be displayed over the game geometry or separate from the game geometry.
For any set of files that need to be loaded you should be using the Bundle Loader. By using the
Bundle Loader consistently we will minimize duplicating code and will also make the way
things are loaded uniform so that anybody on the team should be able to understand it.
For more information on bundles and how you can use them you can refer to the Dark Angel
Rendering Engine Technical Design Document
(//depot/docs/TechDesign/RenderingEngine.doc).
The version control for all the textures, models, p3d files, scripts, and code is handled through
Perforce. Perforce provides an excellent way to organize versions of and allows for easy access
to older versions of files.
3. ANIMATION PIPELINE
3.1 Description
The animation pipeline is the process by which animations are created, exported into a supported
format, tweaked for optimal use within the game, and finally imported for use within the game.
Also included within this pipeline are any verification tools that are needed to ensure that data is
correct and will be able to work in the game. It is important to note here that the modeling
occurs in the model pipeline. The end result of that modeling (the Maya binary) is used in the
animation pipeline as the starting point for all the work that is done.
The users of this pipeline will be animators as well as those programmers who will be using the
output provided from these tools and methods.
The skeletons placed in the master_skeleton directory must be prefixed with the name of the
character. For example, for the max character, the characters in the master_skeleton directory
will be named max_master.mb and max_master_core.mb. The _master file contains the master
skeleton for this character. The _master_core file contains the core skeleton for this character
(only the primary bones that are the same as the master skeleton).
The animations are contained in the art directory in perforce under the directory anims.
The anims directory contains all character animations. This includes all animations to be used in-
game by the user characters and NPCs. The anims directory contains a chars directory that holds
all the individual characters. The anims directory structure can be seen in Figure 2.
Under the chars directory is a folder for each character in the game. The global folder contains
animations that can be applied to all characters in the game. The assumption is that every
character in the game will share the same core skeleton. The global animations are those that are
applied to that core skeleton. These animations could be reapplied to any character in the game,
as they do not animate any secondary bones.
Under each character’s directory are a clips directory, a p3d directory, and a scenes directory.
The artists will work on Maya binary (.mb) files in the scenes directory. At export time, the
animation in the Maya binary file will be applied to a skeleton that exists in the master_skeleton
directory by the animation export tool developed by Hair Club (see Section 3.3.4.1 for more
details on this tool). The resulting animation will be stored in a Maya ASCII (.ma) file that will
be placed in the corresponding clips directory. Files in the clips directory contain only animation
data; no models or skeletons will be stored in the clips directory. Further manual work can be
done on the files in the clips directory by temporarily importing the master skeleton file. At final
export, the files in the clips directory will be exported into Pure3D (.p3d) files in the
corresponding p3d directory.
3.2.3 Instructions
When you are working on your animations in Maya make sure that you are using the same
skeleton as the model uses and also ensure that you use the same skeleton for all the animations
related to a character.
To verify that the data going through the animation pipeline is correct we can follow a series of
simple steps. The first step is to verify the animation is working in Maya. The second step
would be to use the p3dviewer to not only preview the animation, but also to see the vital
information pertaining to the animation. The vital information that is displayed for the
animation includes the frames per second it is running at, the number of polygons and vertices,
and it also allows for viewing of the multicontroller. The third and final step for verifying the
correctness of the data would be to run it in the game itself and ensure that it works properly.
A key point that should be verified is that the number of joints in the animation matches the
number of joints in all the other animations of that character. This can be extended to make sure
that the animations and models for a character are using the same skeletons.
The current limitations of the animation pipeline are that the animation tools that were created by
Hair Club are still in the process of becoming supported by Pure3d. Both of these tools should
become available by the end of August and will be very important for the users of the pipeline.
There is minimal risk involved in the waiting for these tools from Pure3D because the tools
already exist and are just being amalgamated into Pure3D.
3.2.6 Troubleshooting
Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
The file format being used for the animations that will be loaded into the game is p3d. Initially
the animations will be stored in a Maya binary file (.mb) that will then be converted to a Maya
ASCII file by Hair Club’s animation exporting tool. This process will be done outside of Maya
by running the tool.
It is important point to note is that the master skeleton that is referred to in this section is a
texture-less model whose skeleton is used in the pipeline. The reason the textures are not stored
here is to avoid having huge scene files.
Animation Pipeline
Take the
Create an animation Use Hair Club's Use Pure3D
Maya binary Take the Take the p3d Run in the game
in Maya animation exporter exporter
file Maya ASCII file
Step 2: Use Hair Club exporter to convert from Maya binary format to Maya ASCII format. In
the conversion process this exporter provides the ability to generate animation sequences for
movement and also allows for retargeting of animations to different skeletons.
Step 3: Use the Pure3d exporter to convert the Maya ASCII file to a p3d file
2. Export all animations and test on console viewer with NTSC monitor with a composite video
connector before checking into Perforce. Animations can also be tested through the
p3dviewer on the PC.
Rationale: Animations must be thoroughly tested before it is placed into the build – we wish to
discover issues/problems with content early in the process and correct it.
One area of exporting in the animation pipeline is with the Hair Club animation exporter, which
takes a Maya binary file and creates a Maya ASCII file.
Another area where exporting is used in the animation pipeline is with the Pure3d exporter,
which takes the Maya ASCII file and creates a p3d file.
The animations are optimized via the p3d export. Pure3D provides compression capabilities for
handling animations. The areas where compression is available are: angles are stored in
11:11:10 compressed format; joints that don't animate are special cased in the animations to take
less memory; one-degree-of-freedom (DOF) joints are also special cased.
The procedure for loading is standard because the file format is p3d.
Location:
This tool consists of two components: an exporter and a re-targeting capability. The animation
exporter takes a Maya binary file and converts it into a Maya ASCII file. The re-targeting
capability allows animations developed for one skeleton to be re-targeted to allow them to work
with a different skeleton. This tool was created by Hair Club and is soon to be supported by
Pure3d.
Location:
The animation locomotion generator takes a character and will generate a series of animations
for it based on the number of directions that the character should be able to move in as well as
the length of the player’s stride. This tool was created by Hair Club and is soon to be supported
by Pure3d.
The animation locomotion generator takes as input a skeleton, which it will then generate,
animations for based on inputs such as stride length and the desired direction of locomotion.
The role for this type of tool has yet to be defined and the necessity of it is as of yet still
undetermined. If we do decide that we need a tool of this nature then the initial plan is to use a
third party tool.
The purpose of this tool would be to give the animators the ability to view their animations
repeatedly in order to determine improvements that could be made. This tool does not currently
exist and will have to be created. The projected timeline for this tool is to start on it in October
or November. The tool would end up allowing for animations to be previewed and strung
together in a game environment without actually being loaded into the game itself. This would
allow artists to be able to view their animations quicker and with less effort since the current
viewer and Maya are not able to provide all of this on their own. More detailed requirements for
this tool will be laid out later on.
There are not any platform specific instructions or functionality at this time.
The size of animations will need to be considered. For more information on the data
optimization methods available for animations you can refer to the data optimization section.
Potential extensions for the animation pipeline are the expansion of the verification scripts that
were used by Hair Club. These scripts provide useful functionality, but could be altered to focus
more on the constraints that are unique to our game.
Error checking in the animation pipeline is currently limited to the exporting phase of Maya.
Hair Club also wrote some additional verification scripts to handle ensuring that the skeleton
used in the animation was the same as that used in the model.
4.1 Description
The facial animation pipeline is responsible for the animations that appear on the faces of
characters from the initial design in Maya to their actual use in the game.
The users of this pipeline will be animators as well as those programmers who will be using the
output provided from these tools and methods.
The directory structure for facial animations is going to be very similar to the one used for
character animations. Under the art directory there will be a facialanims directory that will
contain a chars directory. The chars directory holds the directories for each character that will
have facial animations in the game. For every character directory there will be a p3d and scenes
directory.
The naming convention for the facial animations is a combination of character name, a phrase or
word describing the facial animation, and a number if it is part of sequence of animations.
4.2.2 Instructions
TBD
To verify that the data going through the animation pipeline is correct we can follow a series of
simple steps. The first step is to verify the animation is working in Maya. The second step
would be to use the p3dviewer to not only the preview the animation, but also the see the vital
information pertaining to the animation. The third and final step for verifying the correctness of
the data would be to run it in the game itself and ensure that it works properly.
A current limitation of the facial animation system is that it needs to be viewed as an AVI that
has been exported or in the game in order for the sound to be heard. Currently there is a request
to Pure3D to add sound support to the viewer, but this is not being done for release V15.
4.2.6 Troubleshooting
Currently the deformer will only allow you to have 3 blend states. Another point to note when
using the deformer in Maya is that you cannot have more than 32 expressions. It is possible to
get around this in Maya, but any additional expressions used in Maya will not be exported.
If a problem occurs with tweaks not having any data you can export using the MEL export script
instead. By using the MEL export script you slow down the export process, but all offset data
will be exported. The reason this occurs is that some operations that can be performed in Maya
are not stored in the tweak node. Generally this should not be a problem so only worry about
this if you get a message saying that there is no tweak data to export.
One other point to watch out for is ensuring that you skin the mesh before you try to export it to
make sure that the offsets are exported correctly.
The file format for the facial animations is the standard pure3d file. The specific chunks that are
used in the facial animation file are: tlExpressionGroupChunk16, tlExpressionMixerChunk16,
tlExpressionAnimChunk16, and tlPoseAnimChunk16.
Step 1: The first step in the facial animation pipeline is to create the facial geometry that will be
animated.
Step 2: To create the facial animation you need to use the deformer plug-in for Maya.
Step 3: After the facial animation has been completed it needs to be exported from Maya. Make
sure that it is skinned and double check that it uses the proper skeleton. It is also possible at this
point to run p3dskin or p3dprimgroup to optimize the data.
Step 4: Finally the facial animation can be loaded into the game and tested. Before you load it
into the game make sure that it has been tested in the p3dviewer.
4.3.3.1 Exporting
Exporting from Maya is done just like all other exporting from Maya with the exception that the
meshes must be skinned. This is a small abnormality that Pure3D currently requires.
One method of optimizing the data is to use the p3dskin tool with the –T option. This tool will
allow for offsets that are less the number specified to be deleted. By deleting offsets that are
Another means of optimization is to use the p3dprimgroup tool with the –s option. This update
to the p3dprimgroup tool has yet to be released, but should be available shortly. By using the –s
option the tool will take primgroups and split them into two new primgroups: one with offsets
and one without. The result of this process is a large memory savings due to the fact that non-
offset primgroup elements will not have to have any offset storage space where as in the original
single primgroup they would have enough storage space to hold the maximum number of offsets.
The loading of facial animations into the game is handled through the default p3d load
mechanism. There are not any special files in the facial animation pipeline that need to be
loaded.
4.3.4.1 Deformer
2) It is critical that the Maya files that you are going to copy over via Perforce go into the
correct location. To ensure that this happens you need to make the following addition to
your Perforce Client Specification.
//depot/tools/p3dplugins/... //host_name/c:/AW/Maya3.0/...
+//depot/tools/maya/DAWB/distribution/... //host_name/c:/AW/Maya3.0/...
3) Sync to Perforce to get the latest plug-ins and scripts that are located under
//depot/tools/p3dplugins/bin/plug-ins.
4) Open Maya and in the menu choose Window, Settings/Preferences, and Plug-in Manager.
In the window that appears you need to make sure that you select p3dDeformer.mll for
loaded and auto-loaded (check both of the boxes beside it).
Figure 6: Plug-in manager were p3dDeformer.mll must have both boxes checked
The Expression Deformer is a tool contained in the Deformer plug-in. The Expression Deformer
is a vertex animation tool designed to help you easily create simple facial animations. The
Expression Deformer allows you to:
An extension of the Expression tool is the expression presets. An expression preset is a blended
combination of expression states. When selected, a preset will combine the expressions states to
these stored values.
With expression presets, you can easily set keyframes on previously created states. As well, you
can create overall facial expression made up of a number of states (e.g., brow up, eyes wide,
mouth open and nostrils flared to indicate a global facial state of surprise).
2. Switch to object mode and select the tweaked mesh. (Note: You can quickly toggle
between object and component mode in Maya with F8)
3. Click the Expression Deformer shelf button to launch the Expression Deformer tool.
4. Select the tweaked mesh and click Create State. A new expression state will be created,
appearing in the expression window, and the mesh will snap back to its neutral position.
The joint deformer gives you a way to connect the orientation of a particular joint with the slider
value of an expression state. Clicking the “Pure3D Joint Deformer” shelf button launches the
Pure3D Joint Deformer window.
4.3.4.1.3 Convert
The convert tool on the deformer shelf allows for the conversion of geometry from the pure3d
version 13 format to the current format. This should not be necessary for us because all of our
geometry should have been and will be created under the new format.
• Take a duplicate of your target mesh (the mesh you wish to apply expression states to),
You can also use this tool to create a new expression state that blends between the target mesh's
neutral state, and the duplicate's shape.
At this time there are not any specific instructions or functionality for any of the platforms.
A limitation of the Snap to Reference tool is that it will not work properly on skinned meshes
whose joints are rotated away from the bind pose.
When creating an expression state a limitation that exists is that you cannot apply materials to a
mesh after adding expression states (especially when rendering meshes). This bug will appear
intermittently.
Another limitation is that when using the Erase function of the Script Polygon tool, or undoing a
Sculpt Polygons operation and then performing further tweaks prior to creating an expression
state, will cause undesirable deformations in the original mesh. To fix this problem you can use
Updated Mesh to revive the mesh’s neutral state.
There is not any specific error checking that occurs in this pipeline at the present time.
5. MODEL PIPELINE
5.1 Description
The model pipeline is the process by which models are created in Maya, exported into a
supported format, tweaked for optimal use within the game, converted to the pure3d file format,
and finally imported for use within the game. Also included within this pipeline are the
verification tools that are needed to ensure that data is correct and will be able to work in the
game.
- Provide a means for models to be tweaked and undergo changes in format to allow for
moving content quickly into the game
The main users of this pipeline will be artists. The results of this pipeline will also be of great
importance to programmers involved in rendering and anyone else interested in the rendering
process.
Character models will use 3-letter abbreviations. Here is a list of the following symbols for each
character.
Characters Abbreviation
1. Max Max
2. Logan Log
3. Brin Brn
5. Madame X Mad
7. Stretch Str
8. Herbal Hbl
9. Normal Nor
Models will be created with different LODs. This is especially true for art targeted towards the
XBox or for the PS2. The following postfixes will be used to identify the different LODs.
• _x – XBox target
• _p – PS2 target
• _n – NIS target
Due to the fact that NISs will be used on both the XBox and the PS2 the last postfix can be used
in conjunction with the first two for NISs models.
Geometry/Maya:
Skeleton Structure:
Naming:
World_Root
Description:
The world root is used to parent IK rigs and skeleton controls under and is used to
position and scale the character in Maya for other Maya purposes
Naming:
Motion_Root
Description:
The Motion_Root is the skeleton root as far as Pure3D is concerned. The key points are:
• It contains X and Z translation only.
• It is used to describe the simple major motion of the character.
• It has the Character_Root as a dependent.
The motion root joint is placed underneath the character (at coordinate y = 0) and traces
the characters movement path across the XZ plane. This joint will have Tx,z data and
traces the path which the character moves in space.
The motion root coordinate data will be used in game to translate the character in world-
space.
Naming:
Character_Root
Description:
The Character_Root is the first real bone in the hierarchy and contains all 3 degrees of
freedom (DOF) in rotation and translation. An animator uses this joint to describe the
subtle motion of a characters center of mass (i.e., side-to-side hip motion) and all Y
translation.
The Character_Root joint is placed at the character’s pelvis. This joint will have Rotx,y,z
and Tx,y,z data.
It encodes the location and rotation angle of the character at the pelvis. The game will
use the location of this joint to derive the in-game location of effectors such as the hands
and feet.
In case you went straight to this section, we should contrast the character root with the
motion root. The main difference is that the character root may have a lateral “sway”
relating to counterbalancing of a body at the area as the body moves forward. So if we
were to project the character root onto the XZ plane (by setting y = 0) for the duration of
the animation, and overlaying this path onto the path mapped out for the motion root, we
would find that the line made by the character root would criss-cross the line made by the
motion root.
Naming:
Description:
The orientation root joint encodes the facing direction of the character using Roty data.
The orientation direction is essentially the direction that the character has its face
oriented towards. So recall that while the character root also records the pelvic forward-
facing direction, the orientation root represents the head facing direction. For instance, a
boxer’s stance is an example where the pelvic forward-facing direction differs from that
of his facing direction.
5.2.1.5 Effectors
Naming:
Description:
These joints will be the effector points where functions such as punches, grabs, foot plants and
kicks are triggered in game.
Textures:
Majority of the characters will have at least two textures: a texture for the head and a texture for
the body. Naming convention for body textures will identify the character, the geometry (style)
version, body/clothing part, colour palette change and the LOD. Naming convention for body
textures will identify the character, the body part, and the LOD. Naming convention for texture
will follow this structure.
Head: maxstl_head1_x.bmp
*Please note: if alpha maps are required, we will use png files. Similar to targa files in saving
the alpha map in a layer. These png files are supported by P3d and will export as an 8-bit
texture.
All models will be located in the models directory. The models directory contains source art for
the character models and skeletons. Each model should have its own directory containing a
scenes and p3d folder. An example can be seen in Figure 5.
5.2.3 Instructions
TBD
The data in the model pipeline can verified for correctness in many ways. One way to verify the
correctness of the data is to use the p3dviewer or the quickviewer. These two tools will allow
models to be viewed to ensure that they are coming through the pipeline properly before they are
even loading the work into the game.
An additional verification step that should be done is to view model textires on the PS2 and
XBox viewers on a NTSC monitor to ensure that they look okay.
TBD
5.2.7 Troubleshooting
- Naming collisions
Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
Lambie, Stephen and Sandie, Bert: Dark Angel Technical Art Specification
(//depot/docs/ArtTech/DATechnicalArtReqs.doc).
Characters & props are stored using standard Pure3D data chunks, namely a Pure3D skeleton,
for the base hierarchy if the object has one, and a drawable for the rendering structure (generally
a composite drawable in the case of characters, or a geometry in the case of props).
5.3.3.1 Exporting
1. Check polygon counts in console viewers to ensure they are within budgets.
Rationale: The budgets for art content will be based on numbers that are shown in the P3D
viewers, these numbers are to be used as the final numbers for determining art budgets.
When models are being exported from Maya it is important to remember whether or not
tristripping should be done. All character geometry that is going to be used must be tristripped.
On the other hand, when dealing with world geometry we do not need any tristripping to be
done.
Another important point to note is that for all geometry to be used on the PS2 the geometry must
be deindexed.
One aspect of data optimization for the model pipeline is ensuring that the tristrips that are used
for the model are as long as possible. We can accomplish this by running the tristrip tool and
having it color the various tristrips. This allows the artists to see where potential snags are in
and make improvements that will speed up the use of the model in the game. This functionality
does exist in the tristrip tool.
Model files will be in p3d format so loading into the game will follow standard practice.
The exporter profiles that would be used are: animations, character models, world objects, NISs,
and world/level. The functionality that would be provided by these profiles may be replaced
with pre-existing tools (Pure3D command line tools).
Shader exporters will be an extension of what is currently found in toollib. This is currently in
development and being explored by Pure3D (Mark James)
Location: //depot/tools/quickview
This viewer is based on the p3dviewer found in the Pure3D command line tools. What makes
the quick viewer different is that the debug information has been removed, the background is
now black, and the camera begins in a more useful position. Altering the scripts that are used by
the viewer made these alterations possible.
5.3.4.4 tristrip
Location: //depot/sdks/pure3d/tools/commandline/bin/
This is a pre-existing command line tool provided by Pure3D that deals with taking meshes and
converting them into tristrips. It is important to use tristrips and to set your geometry up in such
a way that you maximize the number of triangles per tristrip, but it is also important that art is
not compromised for the sake of tristripping. It should also be noted that the cubic interior nature
of the Dark Angel environment does not lend itself to good tri-stripping. Tri-stripping of this
type of geometry will not produce any speed gains because the resulting strips are too short.
Hard edges are fine for the geometries, but should not be used if they are not really needed.
Note: For vertices in a mesh to be shared in a tristrip, ALL the vertex components must be the
same. The components of a vertex are:
- Texture map
- Normals. If the normals don’t match, the strip will be broken. This typically occurs with
“hard edges”
- Bone Weightings
“tristrip.exe -m -D <filename>.p3d”.
This particular command line will artificially colour the individual tristrips so that they are easily
visible. The advantage of this is that it allows the artist to identify vertices that break the tristrip.
The most common options that will be used with this tool are –o, -D, and –x. The –o option is
used to specify an output filename so that the changes made to the file are saved in a new
location. The –D option, as mentioned above, is used to run the program in debug mode
allowing for the easy identification of spots that are breaking up tristrips. The last option that
could be used is the –x option, which optimizes the strips for the XBox.
For more information on what tristripping is and how it works look at Appendix A.
5.3.4.5 p3ddeindex
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3ddeindex tool converts indexed prims to non-indexed prims for the PS2. The only option
that is important to remember is the –o, which allows you to specify an output file for the results
of the de-indexing process.
5.3.4.6 p3ddeinstance
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3ddeinstance tool converts meshes to polyskins for batched rendering on the Xbox. The
common options that will be used with p3ddeinstance are –o, -S, and –m. The –o option as usual
allows for the specification of an output file where the results of the process are saved. The –m
and –S options respectively allow for specific meshes or skeletons to be selected for processing.
5.3.4.7 p3dprimgroup
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dprimgroup tool manipulates primitive groups in meshes and skins. The options for the
p3dprimgroup tool allow for separating and reorganizing the primgroups in a p3d file.
Primgroups can be separated base on vertices weighted against one bone vs. many bones (-b),
5.3.4.8 p3dskin
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dskin tool modifies skins. p3dskin is used to control the number of influences on joints. It
allows you to delete joints that have too few influences (-t) and cap joints to a certain maximum
number of influences (-m).
5.3.4.9 p3dsubdivide
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dsubdivide tool subdivides all of the triangles in a mesh. The main option that will be
used with this tool is –a, which allows for the specification of an area of polygons over which the
subdivision will occur.
Location: //depot/tools/plugins/
The bounding/collision volume tool is a plug-in that works with Maya. This plug-in was created
and is supported by Pure3d. The online help documentation can be found on the intranet under
Pure3d’s Artist Guide.
1) Sync to Perforce to get the latest plug-ins and scripts that are located under
//depot/tools/p3dplugins/bin/plug-ins.
2) Open Maya and in the menu choose Window, Settings/Preferences, and Plug-in Manager.
In the window that appears you need to make sure that you select
p3dBoundingVolume.mll for loaded and auto-loaded (check both of the boxes beside it).
3) Once the bounding volume tool is loaded you can then load in a model that you will be
putting bounding volumes around.
4) Before you can place bounding volumes you must first click on Create Bounding Volume
to pop up the bounding volume editing tool.
5) All bounding volumes must be based off a transform node. This means that before you
can create a bounding volume you must click on a transform node in the Hypergraph. To
bring up the Hypergraph you go to the Window menu and click on Hypergraph.
6) Once you have clicked on a transform node you can then go to the bounding volume tool
and click on one of the bounding volumes at the top of the window (box, sphere,
cylinder, capsule, and plane). This will automatically place the bounding volume around
what the transform node is related to (i.e. foot, arm, body, etc.).
Bounding Nodes
Bounding nodes are used to organize multiple bounding volumes for an object. A bounding
node may have any number of bounding volumes beneath it. A bounding node may also have
another bounding node as a child. You should never parent a bounding volume to another
bounding volume however.
In the hypergraph, bounding nodes and volumes will show up under the mesh or joint that they
surround.
Bounding nodes are created in the same way as volumes, and behave the same. You cannot
control their size in Maya. You can set the handle size (one of the bounding node's attributes in
the attribute editor) to make it easier to see. The handle size just sets the size of the node in Maya
and is not exported. The size of the bounding node after export will always be just big enough to
contain all the bounding volumes underneath it in the Hypergraph hierarchy.
Bounding Volumes
Bounding volumes can be one of the following five options: box, sphere, cylinder, capsule, and
plane. After you have selected a transform node you can click on a type of bounding volume and
the bounding volume will automatically be sized to fit around the object that is being bounded.
If you choose to, it is also possible to resize the bounding volume just like a normal piece of
geometry.
For more information on the bounding volume tool make sure you take a look at the Artist Guide
that is available on the intranet.
Location: //depot/sdks/pure3d/tools/commandline/bin/
The art asset management tool allows for the viewing of model related information through an
Access database. In addition to displaying information in Access it will also provide a means for
querying on fields in the data. In addition to viewing and querying the data through Access a
web interface is currently being built to allow for a secondary means of viewing the data. This
web interface will allow for easy viewing of the data by artists and programmers alike.
The database consists of six tables that provide information on file updates, tool history, meshes
and skins, p3d files, shaders, and textures.
The tool will be used on a nightly basis to create the database. After the first night, however,
only the changes (i.e. new files or changed files) will be taken into consideration rather than
rebuilding the entire database. This will allow for quicker updates of the database as the number
of files that it runs on increases. One point to note here is that the program will remove all data
pertaining to files that are deleted or don’t appear in the files that are processed on a given night.
One point to note is that the XBox works well with indexed primitives, but the Playstation2 does
not. This means that for the PS2 we must use a pure3d tool to de-index the primitives in the
pipeline to ensure maximum performance.
TBD
TBD
An error that needs to be checked for in this pipeline is identifying duplicate naming of p3d files
during the batch process.
6. TEXTURE PIPELINE
6.1 Description
The texture pipeline encapsulates the entire process from the initial creation of the textures to the
conversion of the files to p3d format and ending with the loading of the textures into the game.
Two aspects that are involved in this pipeline and are still being researched/analyzed are:
mipmapping and bilinear filtering.
- Provide a means for textures to be altered and tweaked so that their format is efficient
and workable for the game
- Provide a means for information/reports to be displayed for p3d and texture files
The users of this pipeline will be artists as well as those programmers who are interested in the
output provided by the pipeline.
This is discussed in the other pipeline sections (models and world builder).
All of the texture maps that are going to be used in the game will be contained in the
sourceimages directory. This is the directory that all artists should have their project
“sourceimages” path set to. This will prevent the problem of being unable to find texture files
because the “sourceimages” path is set incorrectly; the collection of all the texture maps means
that any artist should be able to load any art file without worrying about the “sourceimages”
path. Furthermore it is crucial that all artists are setup using the same drive, generally the D:
drive.
The collection of the texture maps also serves another purpose: that of unifying the look of the
game. With the textures collected in one place, it is easier for artists to peruse the textures. This
The sourceimages directory will have two folders, the ps2 folder and the xbox folder. This is
required because the texture use in the two consoles will be different. Artists will generally
create new textures targeted for the XBox platform, and then reduce their size or colour depth for
the PS2. Naming textures for the XBox and PS2 will be identical for easy straightforward
organization.
The sourceimages directory will also contain a psd folder that will store all source art created
from Photoshop. Naming should correspond to the final texture name in the XBOX/PS2
directory.
TBD
One way to determine the correctness of the data moving through the texture pipeline is to use
the texture profiler that can be found in Perforce under
//depot/sdks/pure3d/tools/commandline/TextureProfiler. The texture profiler will allow those
who have an interest whether or not there are any errors or problems with any of the textures to
be used.
TBD
6.2.7 Troubleshooting
- Naming collisions
There aren’t any quick fixes for these problems, but they are flagged in the texture profiler as
errors that will be brought to the attention of those that need to know about them.
Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
Lambie, Stephen and Sandie, Bert: Dark Angel Technical Art Specification
(//depot/docs/ArtTech/DATechnicalArtReqs.doc).
Texture files start off as one of the following: png, bmp, or tga. The texture files during the
course of the pipeline then get brought into p3d files. Textures in a p3d file are stored in a
texture chunk and information about them can be viewed in the p3dexplorer and/or p3dviewer.
build nis
-runs a makefile
follow ed by build.pl
and buildNis.pl
build art
-starts the process of
preparing art files to
be used in the game
build frontend
-runs a makefile and
scrbylst.pl
Step 1: To build the models and textures into the final, game ready format the batch file build
must be run with argument art.
Step 2: The build batch file then will run build fe and build nis to get the individual components
ready
Step 3fe: For build fe a makefile and perl script, scrbylst.pl, are run.
Step 3nis: For build nis a makefile is run as well as two scripts, build.pl and buildNis.pl, are run.
Step 4: The end result of this process is to have the art (models/textures) in the cd directory
ready to be run by the game.
The textures created can be compressed. When working with the XBox you can compress the
textures using the DxTn compression format. The DxTn compression format is a lossy
compression scheme so it is very important that artists preview their art and ensure that the
quality is not dropping dramatically. The level of compression can be set for textures
compressed in this format by using the convert2dxtn tool.
TBD
Textures are stored inside p3d files and as a result of this are loaded via the standard method for
loading p3d files.
Location: //depot/sdks/pure3d/tools/commandline/ntsccheck/texturelist.exe
The NTSC Color Check tool has been integrated into the Texture Profiler. It provides a listing
of all the invalid colors that are present in an image and recommended fixes for the invalid
colors. This tool has also been integrated into the Penthouse menu in Maya so that the artists can
run it as they work with textures. The results of this are immediate concrete feedback on the
textures that they are working with and control over what changes are made to the texture rather
than just automatically changing colors for them.
As it stands right now this category of tool has been deemed unnecessary, but there is the
possibility that in the near future something might come up that will require the use of something
like this so it is being noted here. If it were decided that a tool like this was required then we
would most likely use a third party tool.
Location: //depot/sdks/pure3d/tools/commandline/bin/texturelist.exe
This profiler provides reports on p3d and image files that are passed into the tool. The profiler
should be used to verify the contents of the files to ensure that all information that will be used in
the game is in the proper format. The reports display information on the following areas: texture
By using the –R argument on the command line for the tool any subdirectories that may be found
in the directory you passed as your input directory will be traversed as well.
The texture profiler also allows for more general information to be displayed at the end of the
report about overall texture statistics. The statistics compiled include the total number of
textures for each bit depth (4, 8, 16, 24, and 32), the number of textures with or without alpha
blending, the number of textures with mipmapping, and the sizes of the textures in memory and
file.
- i tells the profiler that the input files are images and not p3d files
- o info.txt provides the profiler with the name of the report file (info.txt)
6.3.4.3.1 Limitations/Recommendations
6.3.4.4 convert2dxtn
Location: //depot/sdks/pure3d/tools/commandline/bin/
The convert2dxtn tool will be used to convert all textures and images that are found in a p3d file
into DXTn image format. The DXTn format is a compressed format that is available in three
varieties (1, 3, 5) that affect the amount of compression. DXTn images are used for the XBox
exclusively so this tool will only be used when building art for this platform. The flag that will
be used most often with this tool is –f, which will allow you to specify the amount of
compression that you want to have for the DXTn image (1, 3, 5).
Location: //depot/sdks/pure3d/tools/commandline/bin/
The dxtnreplace tool will, like the convert2dxtn tool, be used when dealing with art for the
XBox. This tool gives us the ability to replace images in pure3d files with DXTn image chunks.
There are two flags that are most likely to be used for this tool (-i and -o). The –i flag allows
you to specify the path from which all dxtn images will be taken. The -o flag allows you to
specify the output file where the DXTn image chunks will be stored.
6.3.4.6 imgextract
Location: //depot/sdks/pure3d/tools/commandline/bin/
The imgextract tool will be used whenever we want to take images that are in p3d file and put
them back into separate files. This will probably not be used very often since all image files that
are found in p3d files will be stored separately at all times so it should not be necessary to extract
them. One instance where this tool is used is in the art asset management tool to extract images
from p3d files, but generally this will not need to be done. The important flags to remember
when using this tool are –t, -p, -1, -3, and –5. These flags allow you to specify the file format
that will be used for the image files that are created in the extraction process. The flags have the
following meanings: –t is tga, -p is png, -1 is for DXT1, -3 is for DXT3, and –5 is for DXT5.
6.3.4.7 imgrestore
Location: //depot/sdks/pure3d/tools/commandline/bin/
The imgrestore tool will be used whenever it is necessary to replace texture references in a p3d
file with real textures. The only option that is available for use with this tool is –o, which allows
you to specify the name of the new p3d file that will contain the real textures.
6.3.4.8 p3dcompress
Location: //depot/sdks/pure3d/tools/commandline/bin/
This tool allows for compression of files. It has been updated to allow for faster decompression
(55MB/s on the PS2) and slightly better compression. The downside is that the new compressor
is a lot slower than the old one.
tools/commandline/bin/p3dcompress
tools/commandline/bin/p3dps2
To load compressed files:
p3d/file.hpp
p3d/file.cpp
p3d/lzr.hpp
p3d/lzr.hpp
tools/gui/p3dexplorer
6.3.4.9 p3dimage
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dimage tool takes textures and images and uses them to create a p3d file that will hold
them in the proper format for use in the game. This tool is a very important part of the texture
pipeline as it takes the texture files that have been created by the artists and combines them into a
file format that can be used within the game. One important flag that can be used with this tool
is –i, which tells p3dimage that the files it is taking in are image files and not p3d files. A couple
of additional flags that are of interest are –O (optimization of the images through reduction in
bits per pixel if few enough colors are used), -b value allows you to change the bpp for the image
to the stated value, and finally –a allows you to avoid making changes to images with alpha.
6.3.4.10 p3dmipmap
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dmipmap tool is used to generate mipmaps for textures. This tool will be used when
artists or programmers come across a texture that needs mipmapping to avoid the shimmering
artifact. One important flag that you will use with this tool is –l, which allows you to set the
number of mipmap levels that you want. Another flag that goes hand in hand with –l is –m,
which allows you to set the minimum dimension of the mipmap to a certain value. The last flag
that may be of interest is –x, which allows you to remove n levels from a texture.
6.3.4.11 p3dps2
Location: //depot/sdks/pure3d/tools/commandline/bin/
The p3dps2 tool processes art for the PS2. It will flip the width and height for art where the
height is greater than the width and will convert textures and geometries to memory image
format if the flag is specified (-m). This tool will be used whenever art is being built for the PS2.
6.3.4.12 p3dxbox
Location: //depot/sdks/pure3d/tools/commandline/bin/
6.3.4.13 spltbmp
Location: //depot/sdks/pure3d/tools/commandline/bin/
The spltbmp tool splits a bitmap into several numbered textures. At this point in time it is
questionable as to whether or not it will be necessary to use this tool, but if it is required it is
available. The two main flags that should be noted are –x and –y, which respectively represent
the number of divisions along the x and y-axes.
When dealing with the XBox you need to be sure and try to avoid the use of 1024x1024 textures.
When making the decision on texture sizes make sure to use smaller textures like 256x256 8 bit
textures which should be the most commonly used size. The reason behind this is that textures
of the larger size, 1024x1024, consume a relatively huge amount of memory. Their size will
reduce the effectiveness of the texture cache unless they are used infrequently in a small area.
The XBox has a total of “N” MB of memory for textures, but this is complimented with the
DXTn compression that guarantees a 4:1 compression rate for 32 bit textures and 6:1 for 24 bit
textures.
When you are working with the Playstation2 you need to make sure that you try to use textures
that are 256x256 or smaller because textures that are bigger than this take up a relatively huge
amount of memory. The PS2 only has a total of up to 2 MB or less of memory to use for textures
(the PS2 has 4 MB of video RAM).
When you are working with textures for the Playstation2 remember that small texture chunks can
be swapped in and out of memory effortlessly without hiccups. This can allow artists to break the
2 MB texture limit. This is due to the fact that the PS2, while limited in actual memory for
textures, does allow for very fast texture swapping. The PS2 can upload ~5MB of textures per
frame at a frame rate of 60Hz
TBD
TBD
TBD
7. NIS PIPELINE
7.1 Description
The NIS pipeline is responsible for the creation, importing and exporting, and running of NISs
for the game.
The users of the NIS pipeline will be artists and animators who are working specifically on
models and related NIS materials. The programmers who are working with the NISs will also be
interested in the results and processes of this pipeline.
Maya:
There will be two types of Maya files. The first Maya file will be the original setup file of the
entire scene for the animator’s reference. This file will not be exported to the game. The other
type of Maya file, which will be exported, will contain a scene shot. There will be several of
these files for the various shots of the scene that will be taken. Naming convention for the NIS
scene reference file will identify the NIS version, location (descriptive) and setup to indicate the
file. Naming convention for NIS in-game file will identify the NIS version, location (using
alphabet) and the shot number. The naming convention is as follows:
All NISs are contained within the nis directory. The nis directory contains levela, etc. folder in
which multiple NIS folders exist identified by number. For example: nis1, nis2, nis3. These
folders will in turn contain a scenes folder and p3d folder. Within the scenes folder will exist a
main scene Maya file called nis1a_setup.mb, which the animators will use as the main source for
reference but will not be exported to game. If the NIS has multiple scenes, it will be indicated by
alphabetic ordering; for example: nis1a_setup.mb, nis1b_setup.mb. Next there will be multiple
Maya files separated by camera edits and shots for ease of management and re-edits for
animators. Naming conventions are laid out in Section 7.2.1. Only the camera animation,
character animation, and any other animations that are specific to the NIS sequence will be
exported. An example of the directory structure can be seen in Figure 18.
TBD
The NIS can be previewed using the p3dviewer to ensure that the NIS is correct before it is used
in the game. As an additional check, the NISs should also be run with the XBox and PS2
viewers on a NTSC device to ensure that they still look good.
One limitation that must be considered is the size of the NIS files. It is critical that every NIS
file must be 1.5MB or less.
One possibility that may be explored is the streaming of NISs on the XBox off of the hard drive.
7.2.7 Troubleshooting
TBD
Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
The files that are going to be used by this pipeline are Maya binaries, texture files, p3d files, and
seq files. The Maya binaries will come from the specification of the NIS in Maya and the
textures used in the sequence will be contained in the texture files. The Maya binaries and the
textures that they use will be used to create the p3d files that can later be used in the game.
Before the files go into the game, in the phase where all of the art is built, bundle files will also
be generated. The bundle file generation will take place in buildNis.pl. A description of bundles
and what they contain is specified in the General Information Section of this document.
NIS Pipeline
Create NIS in
Maya
Export to p3d
format and create
seq files
Use in Game
Step 1: The first step in the NIS pipeline is to create the files related to the NIS (models, textures,
sequence (.seq) files).
Step 2: After the NIS files have been created it is time to convert them into p3d format and create
the sequence (.seq) files.
Step 3: The next step is to verify the p3d files and the NISs in general. This verification step is
important because it ensures that the NIS is working properly before it goes into the game. By
ensuring that the NIS is working properly outside of the game we can guarantee that any
problems involved with its running in the game are probably with the code and not the art itself.
The tools that can be used to verify the files and NISs in general are p3dexplorer and p3dviewer
(quickviewer).
Step 4: After the verification step has been completed it is now time to build the NIS into the
playable format for the game. The building of the NISs is a subset of the build process that was
Step 5: The last step is to run the NISs in the game and ensure that they run properly.
7.3.3.1 Exporting
There are not any special export steps that need to be run for the NIS pipeline.
TBD
For the loading of NISs into the game the two NISs that will be used next are loaded into
memory and as an NIS finishes playing we unload it from memory and load a new one in.
Currently the two scripts that are run for processing the NISs are: build.pl and buildNis.pl.
These two scripts are located in //depot/build/art/nis.
The script buildNis.pl will search in a specified directory and create a text file with the name of
the directory that contains a list of the pure3d files that make up the NIS, in alphabetical order.
The other script build.pl will copy NIS pure3d files from the art folders to the cd folders. This
script will also check the timestamps of the pure3d files to see if they need to be copied. The
build.pl script calls the buildNis.pl script if there have been new additions to the directory or it is
necessary to update everything.
The initial pure3d files are stored in //depot/art/nis/levela/nis1/p3d. Once the processing has
taken place the files needed for the NIS are stored in //depot/cd/nis/levela/nis1.
An important file that is generated from the perl scripts is nis1.txt. This states all of the p3d files
that will be used for the NIS. In addition to the p3d files that are found in the directory there will
also be sequence (.seq) files. The sequence files are created manually by the programmer
working on the NISs and reflect the attributes of the NISs. The .seq files also allow you to
specify events that are to occur during the NIS and the frame of the NIS that they should be sent
on.
eventanim
{
name shot12 // Name of the event animation (matches the NIS)
framerate 30.0 // Frame rate of the animation
length 693 // Length of the event animation (matches the NIS)
cyclic 0 // 1 if the animation should be cyclic
count 1 // Number of events in this animation
event
{
name camera2
address camera
param 1
time 486
data
{
string pp_shotShape2
}
}
}
Two events that should be noted here are: subtitle and letterbox.
The subtitle event takes two parameters both of which are integers. The first parameter is used
to specify whether the subtitle is to be displayed or hidden (1 = display; 2 = hide). The second
parameter in the subtitle event allows you to specify the number of the subtitle that is to be
displayed/hidden.
The letterbox event is the other event of note and the format is as follows:
event
{
name <whatever>
address letterbox
param <on>
time <frame-to-start>
data
{
float <coverage>
int <doMove>
int <moveTime>
int <doFade>
int <fadeTime>
}
}
<doMove> = should it slide on, ala the previos NIS demo (1 = yes)
One platform dependent requirement is to ensure that the proper models and textures are used for
the system the game is being run on.
The current limitations of the NIS pipeline are that some of the necessary components are hacked
in. One area of note that is hacked that will need to be fixed is dealing with the levela directory
level.
It may be desirable to at some point to delete the geometries from the pure3d file in the
processing phase and just keep the animation information. Something else that could be
undertaken at some point is the cleaning up of the scripts and getting rid of areas of duplication
by making them leaner.
The initial groundwork has been laid out to get the buildNis.pl script to handle the outputting of
bundle files. As soon as the final format for bundles has been laid out the update of this script
file can be completed.
TBD
TBD
8. FMV PIPELINE
8.1 Description
The FMV pipeline looks after the movies played in the game from their initial creation through
the conversion process that differs depending on the target platform. Once the conversion has
taken place the files can be run on their specific platform using the files in the radmovie library.
- Conversion of movies to formats that are usable on the XBox and PS2
Both artists and programmers will use the FMV Pipeline during the course of the project. Artists
will use the pipeline to create assets that will then be converted into a format that can be used in
the game. Programmers will be interested in the format of the FMV data and how the process is
carried out.
The naming conventions for FMV will be broken down into two categories: XBox and PS2.
8.2.2 Instructions
Both the source and final in-game files should be checked into Perforce in the fmv directory.
To verify the correctness of your original data you can view the MPEG2 or AVI file that has
been created with a movie player.
Limitations that need to be considered the FMV pipeline are the size of the movies and the speed
at which the movies can be loaded.
8.2.6 Troubleshooting
TBD
The file format for the fmvs will be either .bik for XBox movies or .pss for PS2 movies.
FMV Pipeline
XBox Movie:
Convert AVI w ith
Bink
PS2 Movie:
Convert MPEG2
w ith ps2str
PS2 movies
- Use the ps2str tool to combine your mpeg2 and wav files into a PSS file
- Use Bink to take your avi and wav files into an XBox movie
- The movies are loaded into the game using the radmovie library
8.3.3.1 Exporting
The above figure displays the interface that is found when creating XBox movies using Bink.
Some of the more commonly used features of this interface and how to use them are as follows.
File name: Enter the filename that you want to work with here. You can use the pulldown at
the top to choose a directory with your mouse.
For example, if you just want to play a file, then just highlight it and click the "Play" button.
You can change the default playback parameters in the "Advanced play" window.
Bink it: This button opens the Bink compressor window where you can compress your movies
with our true-color Bink codec.
TBD
The importing/loading of the FMVs into the game will be done through the radmovie library.
The library will end up loading the file formats that we have saved our movies in (e.g. PSS) and
For the XBox we will be using third party movie player called Bink that is made by Radgames.
The cost associated with this will be approximately $5000 US per sku. It is possible that
Microsoft or another third party might develop something cheaper, but it is unlikely that
something along these lines will become available in time (or at all) to be useful to us. Bink
takes AVI and WAV files as input and combines them into a movie file that can be loaded on the
XBox. The process of exporting files from Bink is described in the exporting section.
For the PS2 Sony provides a converter tool that will convert a combination of MPEG2 and WAV
files to a PS2 format (PSS) that we will be using. The tool is called ps2str and is found in the
Sony libraries under usr\local\sce\tools\ps2str\. Sony provides us with the option to either create
movies using the PSS format or we could alternatively use the IPU format. Currently while there
is code support on Radicals part for both of the formats only the PSS approach has been
thoroughly tested. A possible area where it could be beneficial to use the IPU format is if it is
decided to have a movie playing on a texture in the game. The reason that IPU format would be
preferred for this type of movie playing is that it has very quick load times when compared to the
PSS format because it is not as compressed.
It is possible that the game could have textures that will play movies during the game. In order
to have this feature it would be necessary to have the movies running with the IPU format. This
code to run this format does exist in radmovie, but at this point in time it has not been tested.
This feature should be tested to ensure that it will be working in the near future.
The main extension that could be undertaken here is to ensure that the existing untested code for
the IPU format works and is available for use in the game if we choose to explore that route.
TBD
9.1 Description
The scripting pipeline is responsible for the seeing the scripts used for the various facets of the
game through from creation to their interpretation and use within the game. This pipeline deals
with a subsection of scripts that deal with NPC AI and game scripting (director, mission, and
character attribute scripting).
- Determine how scripts will be initially created, associated with the correct phase of the
game, and executed
The users of the scripting pipeline are game designers and programmers involved in handling the
NPC AI, and overall control scripts like mission and director.
TBD
9.2.2 Instructions
TBD
The scripts will be located in the ai directory. Further subdivisions of the ai directory into
subdirectories for improved organization may occur in the future. The final files will be stored
in the cd directory under the same ai directory.
In order to verify the correctness of the scripts they will have to be run in the game. It is still
being considered whether or not we should create some sort of syntax checker. If it is created
then this would be the only step of pre-game verification.
TBD
9.2.6 Troubleshooting
TBD
Scripting Flowchart
9.3.3.1 Exporting
TBD
TBD
9.3.4.1 Lua
We will be using Lua (www.lua.org) for AI, mission controls, and director scripts.
One limitation or potential risk in the scripting pipeline is the use of Lua. If all goes well Lua
should be a great asset for the team and allow the expanding of our scripting system over the one
that currently exists. However, Lua is new territory so there will be pitfalls that will exist and
extra work that will need to be done at times to get it to do what we want it to.
TBD
10.1 Description
The animation script pipeline is responsible for the process of script creation all the way through
to the interpretation and use of the scripts in the game. The scripts that this pipeline deals with
relate specifically to the animating of characters and are based largely on the work done by Hair
Club.
- Determine how scripts will be initially created, associated with the correct phase of the
game, and executed
The users of this pipeline will be the designers who are working on the scripting as well as any
programmers who are helping in the script creation aspect. The pipeline will also be of interest
to the programmers who are working on the loading of the animation scripts into the game.
The animation scripts will be created for characters and character types. This means that the
most intuitive naming scheme would be to have the name of the character included in the name
of the file. The table of character abbreviations in section 5.2.1 will be used with the prefix of
“anim”. The extension for these scripts will be “.ais”.
10.2.2 Instructions
TBD
The scripts will be located in the ai directory. Further subdivisions of the ai directory into
subdirectories for improved organization may occur in the future. The final files will be stored
in the cd directory under the same ai directory.
In order to verify the correctness of the scripts they will have to be run in the game. It is still
being considered whether or not we should create some sort of syntax checker. If it is created
then this would be the only step of pre-game verification.
TBD
10.2.6 Troubleshooting
TBD
Laurent Ancessi: Building the Motion Tree and Animation System (Hair Club Perforce).
The animation scripts that will be used for DA are basically identical to the ones used by Hair
Club. Below is a portion of a sample script used by Hair Club. There will be some syntax
additions and changes that will be noted here when/if they happen.
The partition priority portion of the script is used to blend different animations together. If the
lower body in one animation has priority over the lower body in the other animation then they
won’t be blended together and the higher priority lower body will be used. On the other hand, if
the two lower bodies have the same priority then they will be blended together. The priorities of
the different partitions depend on how fast the character is going and the movements the
different partitions are making.
#---------------------------------------------------------------
# Loading of the animation.
#---------------------------------------------------------------
An animation bank is associated with each character. This bank contains all the running partition
(animation and procedural animation) used by the character in every situation (NIS, fight…). A
running partition locomotion and upper body are enough to animate a character. By superposing
subtle secondary motion (secondary running partition), we will develop interesting animated
behavior.
A running partition is the combination of a partition definition name, a level of priority, where 0
is the highest level of priority, and an animation or procedural animation.
Several running partitions contribute independently to the skeleton pose. It’s a system of
paralleled threads. This system is resolved every frame and the level of priority of each running
partition is the main criteria. If a high priority running animation disappears, then another thread
of lower priority may become active and blending occurs (factor vary between [0-1]). The
The goal is to fire redundant running partition with different levels of priority. The system
resolves at every frame the active partitions: 1 running partition per partition definition. The
level of priority is the main criteria.
Grapple, upper_body, p0
Play Grapple
Grapple, locomotion, p1
RESOLVE SKELETON
Locomotion Idle
Time
A partition definition is a set of weighted joints. The format of a partition definition is:
SETUP_PARTITION [name partition]
{
SETUP_JOINT [name p3d joint] [weight]
SETUP_JOINT [name p3d joint] [weight]
….
}
The weight allows overlapping the partition definition (progressive blending of the running
partition).
SETUP_PARTITION "upper_body"
{
SETUP_JOINT "Spine1" 0.5
SETUP_JOINT "Spine2" 0.8
…
Upper partition
Locomotive partition
Important facts:
The partition definitions are not mutually exclusive. For a particular joint, the sum of all weight
(defined in all the partition definition of a characters) can exceed 1.
The final weight is computed with the current blending level and the weight associated with each
joint.
Script commands
LOAD_P3D [filename].
SET_BLEND_TIME [duration]
Set the blend time for all the following running partition setup (animation and procedural
animation). The value is in second.
Setup the animation to be used by the fighting tree (punch, kick, grapple…).
Register the animation in the locomotion tree. The direction of the motion root (8 directions) and
the speed (in m/s) are the main criteria to sort these animations.
Register the animation in the idle tree. The main criterion is the comparison [current gait
(position of the feet)-gait of the first frame in the animation]. The logic is simple: match the gait
and play the sequence.
Define a new procedural animation. The procedure name can be: flexible object, head tracker,
and world head tracker.
Setup a new partition definition. This definition will be referred by its name.
Setup a joint definition based on the p3d joint [name p3d joint]. A weight [weight] is associated
with this joint.
The 2 main primitives used by the fighting engine are: ANIMATION and PANIMATION to
fired respectively an animation and a procedural animation. These command are used in the fight
nodes and the default fight node.
A fight node is fired when the conditions associated with it are matched (context, controller
input…).
FIGHTNODE chef_grapple_lock
{
ANIMATION source 0 "AnimID_chef_amb_grapple_a" 1
ANIMATION target 0 "AnimID_chef_amb_grapple_b" 1
}
The default node is fired systematically in addition to the current fight node. The default node is
mainly used to control the secondary motions.
IMPORT FIGHTBANK defaultPre
FIGHTNODE chef
Scripting Flowchart
10.3.3.1 Exporting
TBD
When the animation script files are loaded into the game they are tokenized and put into a token
stream from which the necessary structures are later built.
TBD
TBD
11.1 Description
The fight script pipeline is responsible for the process of script creation all the way through to
the interpretation and use of the scripts in the game. The scripts that this pipeline deals with
relate specifically to the fight sequences that the characters can progress through and are based
largely on the work done by Hair Club.
- Determine how scripts will be initially created, associated with the correct phase of the
game, and executed
The users of this pipeline will be the designers who are working on the scripting as well as any
programmers who are helping in the script creation aspect. The pipeline will also be of interest
to the programmers who are working on the loading of the fight scripts into the game.
The fight scripts will be created for characters and character types. This means that the most
intuitive naming scheme would be to have the name of the character included in the name of the
file. The table of character abbreviations in section 5.2.1 will be used with the prefix of “fight”.
The extension for these scripts will be “.ais”.
11.2.2 Instructions
TBD
The scripts will be located in the ai directory. Further subdivisions of the ai directory into
subdirectories for improved organization may occur in the future. The final files will be stored
in the cd directory under the same ai directory.
In order to verify the correctness of the scripts they will have to be run in the game. It is still
being considered whether or not we should create some sort of syntax checker. If it is created
then this would be the only step of pre-game verification.
TBD
11.2.6 Troubleshooting
TBD
The fight tree script outlines the interdependency of the various nodes throughout the fight tree
and specifies the rules for traversal from one node to the next. This script format was created by
Hair Club and will be used almost as is for DA. The following is an excerpt from a fight tree
script used by Hair Club.
########################################################################
# DETONATA
########################################################################
FIGHTNODE detonata_flex_hair
{
PANIMATION source 0 -1 "AnimID_flex_hair"
}
FIGHTNODE detonata_grapple_throw_reversal
{
NAME "Detonata Grapple Throw Reversal"
FIGHTNODE sourgrapes_bugeye
{
CONDITION (target.character == "al")
# FACIAL_MOOD target 25 30 ouch 1.0
}
FIGHTBANK detonataGrappleBank
{
FIGHTNODE grapple_throw_kneehammer
{
NAME "Knee Hammer"
INHERIT detonata_flex_hair
CONDITION (input(defend_light))
FIGHTNODE grapple_throw_sourgrapes
{
NAME "Sour Grapes"
INHERIT detonata_flex_hair
CONDITION (input(kick_light))
Scripting Flowchart
11.3.3.1 Exporting
TBD
When the fight script files are loaded into the game they are tokenized and put into a token
stream from which the necessary structures are later built.
TBD
TBD
12.1 Description
The lighting pipeline is involved in the process of providing varying amount of light to objects
found in the game and more specifically to the textures on these objects. This pipeline will
provide the ability to preview and light textures under various circumstances as well as deal with
light sources. This section is still in the works as the lightmapping tool will not be completed
until the end of September.
Artists who are working on lighting and wish to preview their work will use the lightmaps
pipeline. Programmers will be interested in using the lightmaps pipeline to find out about
loading lighting information into the game. Programmers may also be interested in running the
pipeline to get lighting information.
TBD
12.2.2 Instructions
The following are instructions/guidelines that should be followed when handling lighting.
1. Use as much pre-lighting (CBV lighting) as possible. All static/world geometries should be pre-lit.
Rationale: Pre-lighting bakes colour values into the geometries vertices. It is faster for the graphics
hardware to “light” the polygons using the colour values in the vertex than it is to use real lights. This
frees up real lights for use with characters.
Figure 26: Setting custom polygon display options to show CBV lighting.
2. No lighting shall be applied to any exported world geometry. Lights shall only be placed in the scene
for the lightmapping tool to calculate the lightmaps and for previewing purposes. There is no limit of
the number of static lights in the scene. Dynamic objects will be handled separately.
Rationale: A lightmapping tool shall be used to light the scene based on the position of lights placed in
the scene.
TBD
TBD
TBD
12.2.6 Troubleshooting
TBD
Lambie, Stephen and Sandie, Bert: Dark Angel Technical Art Specification
(//depot/docs/ArtTech/DATechnicalArtReqs.doc).
TBD
12.3.3.1 Exporting
TBD
TBD
TBD
The lightmapping tool is currently being worked on by Pure3D and the estimated finish date is
the end of September.
- This tool will calculate lightmaps and allow for previewing of lighting in scenes
TBD
TBD
TBD
TBD
The pipeline is currently under the guidance of Mark James from Pure3D.
13.1 Description
This pipeline will be responsible for the handling of all of the language translation issues that are
found in the front-end text menus, the NIS dialogue, and any text found in the HUDs. The front-
end dialogue and any in-game quips will not be localized. In the NISs and the Logan
transmissions the localization will be attained by using subtitles while in the menu system it will
be done by replacing the text in question with the corresponding text in the appropriate language.
The languages that are currently to be supported are: English, French, Spanish, German, Italian,
and possibly some Asian languages that require two bytes per character. The use of subtitles
brings up several issues that will be discussed in Limitations and Recommendations.
One group of people who will use the localization pipeline will be the programmers who are
involved in porting the game from language to language (i.e. performing text bible work or
subtitle programming). Artists and translators who are also working on this localization related
art and language issues would also be users of this pipeline.
The localization pipeline will have to manage the text bibles for the game and the associated
language files that are generated from the text bibles. It is still being investigated at this time the
number of optimal text bibles that are necessary to ensure quick load times and minimized
memory requirements. One possible way to break up the text bibles would be by level, which
would entail the level number being stored at some point in the filename.
The text bibles and language files will be stored in the fe directory under Resource and then
TextBibles. This section will be filled out in greater detail as soon as the text bible breakdown is
decided upon.
To create the language files that are needed at runtime you need to run "bible txtbib". The
runtime handling of the language files is handled through Scrooby.
At this point the only file of importance for this pipeline is the text bible that will be stored with
all the other Scrooby files.
In order to verify whether the data is correct or not your will have to run the game itself with the
different languages.
The main issue for the localization in DA is the handling of the subtitles. The subtitles will use a
semi-transparent black rectangle with green text on top to provide some contrast while
minimizing the amount of the screen that is hidden from the user.
The subtitles will be located on the bottom of the screen and will consist of a piece of text
preceded by the name of the speaker.
A major issue that needs to be worked out with respect to the subtitles is the synchronization of
the subtitles with the scene that they are being displayed with and to some extent the sound that
is running at the same time. It is not necessary to have the text displaying at the same time the
words are being spoken as long as the subtitles stay in sync with the images the user is seeing.
One issue with subtitles is where they are located on the screen. Due to the constraints of
displaying text on a TV and the display issues we will be limited in the width of the subtitle and
will have constraints on the vertical position of our subtitle. At this point in time we do not
believe that this will be difficult to work around. For more information on why we are
constrained in where the subtitle can be placed on the screen see Appendix A.
The length of words in certain languages (e.g. German) will be another problem that will have to
be dealt with. How will the length of these words interact with the size of the subtitle and the
transition mechanism? An option to deal with this would be the alteration of Scrooby to handle
word wrapping so that words could be wrapped around onto an optional second line thus
avoiding subtitle length and transition conflicts.
One area of localization that we don’t need to worry about is in-game text cues. There will not
be any text in the environment, that is crucial to game play, that needs to be changed into
different languages.
TBD
TBD
Localization Pipeline
13.3.3.1 Exporting
To process the text bible you will first need to fill it up with all of the text that is going to use in
the game. This is followed by processing the text bible into a binary, memory-mapped file for
use in the game.
The localization data cannot be manipulated in such a way as to provide an optimized format.
In code, when you want a piece of text, you query the text bible by giving it the symbolic name,
and you get back the text for whatever language you asked for. The front-end and subtitles will
have this automatically handled because they are run through Scrooby.
An important point to note is that subtitles will be used for English as well as all other supported
languages. This is due to the fact that some people may be deaf and it also makes it easier to
treat English like any other language.
There are not any platform specific instructions or concerns in relation to localization.
TBD
TBD
14.1 Description
The sound pipeline will consist of the process of getting sounds from the sound composer
through to having them playing in the game. The pipeline will include any tools that are needed
to convert or manipulate the sound files.
- Sound Creation
This pipeline will be used by programmers who are involved in the use of the sound/music that is
created as well as the sound composers.
TBD
14.2.2 Instructions
TBD
TBD
TBD
A key point to remember is that the size of .wav files is directly proportional to the memory used
for pre-loaded samples (this does not matter for streams).
14.2.6 Troubleshooting
TBD
TBD
14.3.2 Dependencies
Many radsoundutil.hpp objects such as fades and connection objects require the radscript run-
time.
TBD
Snowboarding and Simpsons are using radscript 's scripts, tools, and powerful automated run-
time tuning features to define object construction and tweak attributes. The sound composers
will expect and insist that all projects use these tools for sound.
Location: //depot/sdks/radsound/tools/bin/wavtorsd.exe
The WavToRsd tool converts .wav files to all platform formats. It also has an option to recurse
through directories checking dates and converting all .wav files to a target directory of the same
structure.
The first parameter is the source .wav file that needs to be converted to a platform specific
format. The second parameter is the destination .rsd file where the sound will be placed after it
is been converted to the proper format. The next parameter can either be pcm (XBox,
GameCube) or vag (PS2) depending on the target platform. The fourth parameter allows you to
specify whether the sample should loop or not (loopon or loopoff). The next parameter is a
number that represents the chunk size.
Location: //depot/sdks/radscript/tools/bin/radTuner/radTuner.exe
Location: //depot/sdks/radscript/tools/bin/scriptgen/freewish.exe
FreeWish and hpp2typ generate type-information for the tools and scripting system. The type-
info describes interfaces (classes) in the game to allow scripting with no stubs, no extra memory
footprint, and run-time tuning of all game objects with no extra programming hooks or
programmer support.
Location: //depot/sdks/radscript/tools/bin/hpp2typ.exe
14.3.5.1 Exporting
TBD
TBD
There are two main approaches to sound based on the desired platform: PCM and ADPCM.
PCM is an uncompressed WAV audio format that is used for the GameCube, XBox, and in
Windows (Win32). For the XBox and the GameCube there is support for regular (non-Sony)
IMA ADPCM that gives a 32/9 (3.5555' to 1) compression ratio. The ADPCM is a lossy
compression format so PCM sounds a lot better, but the ADPCM format can be loaded faster.
For the PS2 you have to use VAG, which is Sony's ADPCM (adaptive differential pulse code
modulation) format that is played by the hardware and has a compression ratio of 3.5 to 1.
The tool wavtorsd.exe will be integrated as a plug-in into radscript's IDE in the very near future.
This has been a limitation, but when it reaches the new state it will provide design-time data
integrity for the game's sound resources and objects.
Another limitation, which is only for a short period of time, is that for the GameCube the
ADPCM format is not implemented yet but it will be very soon.
TBD
It is important to check the total size of all compressed sound files to ensure that they are inside
the total allowable size.
The tools and in-game aspects of the sound pipeline are being handled by FTech.
15.1 Description
The cloth pipeline is the means by which cloth and cloth-like objects can be created in Maya and
converted into a format that will allow for them to have the appropriate simulations carried out
on them in the game. The two types of cloth that can be represented are: pure cloth and simple
cloth (flexible objects based on bones). It is important to note here that while cloth objects are of
primary interest, the objects that can be created through this pipeline need not be cloth at all. It
is possible to use this pipeline for creating hair or a whip both of which can be simulated in a
realistic fashion. Another point that should be noted here is that the collision volumes are
automatically created. Collision spheres or capsules are automatically created on or between the
particles of the particle system generated from the flex or flexjoint. You should also note that
the cloth, as a mesh, is displayed as usual. The only difference between the cloth and any other
type of geometry that you might have is that the position and normals of vertices are recomputed
each frame for the purposes of the physics simulation.
- Provide an easy, understandable way for artists to create cloth or cloth-like objects with
Maya
- Provide all of the tools needed for the manipulation of cloth files and the creation of
supporting files
The users of the physics cloth simulation pipeline will be artists involved in creating the cloth
and programmers involved in creating and using the pipeline.
The naming conventions for cloth objects will follow the standards set out for models and
textures in the other pipelines.
The only parameters that can be tweaked by artists to effect the physics of the cloth are stiffness,
bending, and shearing. For each of these parameters there are two parts: strength and
dissipation.
The location of these files has been laid out in the other sections on models and textures.
To verify that the cloth is progressing correctly through the cloth pipeline a viewer similar to
p3dviewer will be made available by Martin Courchesne that we can use.
There are no restrictions on the number of bones that should be used in a flexible object other
than it is best to use the minimum amount required to attain good looking results. The ideal
number is influenced by the length and complexity of the object as well as the amount of
deformation expected.
A major issue that is being looked into is that cloth has only been done in a limited fashion on
the XBox and has not been tested on the PS2 at all.
15.2.6 Troubleshooting
TBD
TBD
The cloth is stored in a standard p3d file, but uses some additional chunk types for physics
objects.
Cloth Pipeline
h
l ot
Use Flex tool
kC
uic
Q
Create Maya
Geometry
Load p3d file and
Verify p3d
use cloth in the
file
game
Pr
ec
is ion
C l ot
h
Use Phobj or
Phobjman
Step 1: Create an object in Maya that will have cloth-like attributes in the game
Step 3: If you want to use quick (simple) cloth (cloth implemented with bones and joints) use the
Flex tool to create the p3d file with the appropriate information. If you want to use the precision
cloth then you need to use Phobj or Phobjman depending on whether you want a lot of
interactive help setting up your cloth (Phobjman goes step by step through the process).
Step 4: Verify the p3d file that you have created and ensure that the cloth is behaving properly.
This verification step can be undertaken by using a special viewer that is soon to be made
available. It is important to do this verification step before running the game with the cloth to
make it easier to track down the location of problems.
15.3.3.1 Exporting
There are two main aspects that are involved in the exporting process for this pipeline. The first
step to be taken is to export the geometry from Maya. We need to end up exporting the
geometry into a p3d format after we have finished creating the geometry in Maya and before we
run the phobj or flex tools. The next phase of the export process is to convert the regular p3d
files into p3d files where the geometry now consists of objects that can have physics calculations
run on them.
TBD
The importing and loading of the data into the game will follow the standard procedure since the
data is stored in a p3d file.
15.3.4.1 Flex
Location: //depot/sdks/pure3d/tools/commandline/bin/flex.exe
The flex tool adds flex chunks for simulating flexible object.
The flex tool allows you to process only a specific geometry by using the –g argument followed
by the name of the geometry. If you want to specify the start joint for a flexible skeleton branch
you can use the –s option followed by the start joint. Two other important arguments are –k and
–x, which respectively allow you to keep the existing flex chunks and write only the flex chunks
to the output file.
15.3.4.2 PhObj
Location: //depot/sdks/pure3d/tools/commandline/bin/phobj.exe
The PhObj tool adds physics and collision information to the geometry and skin present in the
P3D file.
The PhObj tool is nearly identical to the PhObjMan tool that is listed next. The only real
difference between the two tools is that the PhObjMan tool gives the user a more interactive
approach.
15.3.4.3 PhObjMan
Location: //depot/sdks/pure3d/tools/commandline/bin/phobjman.exe
The PhObjMan tool helps with adding phchunks into the p3d file interactively while allowing
the jointdef files and bat file to be save for use directly with the phobj tool next time.
The only platform specific instructions to be aware of are the same ones that you have to take
into account for the modeling and texture pipelines.
TBD
TBD
TBD
To use pure cloth will be a technical risk because while it will be available to us it is unknown in
terms of speed what it will be able to provide us. The flexible object cloth is available to use
almost for free in terms of speed. Another minor risk is the fact that the physics engine is
currently being overhauled so there will be some aspects of how the cloth is created and
interacted with that could change by September.
The tools and in-game aspects of the cloth pipeline is being worked on and guided by Martin
Courchesne.
16.1 Description
The World Builder Pipeline will be the location of tools related to level design and will allow for
rooms to be laid out and portals to be specified. This pipeline exists almost completely in Maya
and is an intermediary between the Model Pipeline and the game for world related material.
• Provide an easy means of importing DXF files from Sierra Home Architect Package
which is used by game and level designers to create the levels
• Provide an interface that allows for easy creation and placing of trigger volumes,
camera zones, and NPC generators and paths throughout the level
The users of this pipeline will be artists, level designers, and game designers, as it will directly
impact their work. It will also be of interest to rendering programmers and other programmers
who will rely on the output of World Builder.
All of the files generated by World Builder will be stored within the rdl directory (//depot/rdl).
The rdl directory will contain files for NPCs, camera zones, context sensitive moves, trigger
volumes, and special effects on a per level basis.
The naming convention for these different level files is going be:
TypeOfFile[1…n].rdl
The type of file will be either npc for non-player characters, camera for camera files, tv for
trigger volumes, sfx for special effects, or csm for context sensitive moves. The next portion of
the file name consists of number representing the level that the file is used with followed by .rdl.
TBD
TBD
TBD
16.2.6 Troubleshooting
TBD
Kurahashi, Juneko and Maruno, Yayoi: Dark Angel Art Directory Structure and
Nomenclature (//depot/docs/ArtTech/ArtDirStructure.doc).
All of the files generated by the World Builder will be in text format. The user will then be able
to open up these text files and edit them if they decide that they would like to do that. The
specific layout for the different types of text files has not been decided yet since the tool is still
be written. When the tool is done this section will updated to reflect the final formats.
Step 2: Use World Builder to define trigger volumes, camera zones, and NPC information
Step 4: Import the p3d file for use within the game
16.3.3.1 Exporting
The World Builder will export files that are in rdl format. RDL is just a simple text format and
by exporting it in a text format like this allows for editing of the scripts by using a text editor.
TBD
The files that are generated by the World Builder are in text format with rdl extensions. This
means that the loading in the game is going to be slightly different than the standard p3d file
loading, but should still be done with a bundle format. What will take place in terms of loading
will not be finalized until the file formats have been finished.
This portion of the world builder has not been fully specified yet so the exact functionality
cannot be given at this time.
The World Builder tool will allow for the placement of NPC generators through out the world.
An NPC generator has coordinates for its location in the world, and also has slots for the various
NPCs that it can create. Each slot represents one type of NPC that can be generated and holds
values for the number of them that can be in the world at one time as well as the maximum
number that will be generated in total by that generator. If the maximum number that can be
generated is infinity then the NPC types in the other slots will never be generated.
Another point to be noted when dealing with NPCs is that they will have attributes that will be
editable in the World Builder as well as in text files that will be generated as part of the World
Builder Export. The following is a list of the available attributes.
Character attributes:
Aggression
Blocking
High Attack
Low Attack
Combo
Grapple
Reversal
Speed
Life
Recovery
Alert
C.O.V. (Cone of Vision)
This portion of the world builder has not been fully specified yet so the exact functionality
cannot be given at this time.
A tool will be provided to allow designers to specify NPC Paths. Using this path, the designer
will be able to place path control vertices on the floor. Visual feedback will be provided in Maya
by connecting the control vertices. At the moment, the intent is to provide straight-line connect-
the-dots type of path. If the need arises for curved paths, the path algorithm used in the Factions’
World Builder will be used.
The designers will have the ability to place different shaped trigger volumes around the level.
Triggers can be of the following types:
• NIS trigger (if the player collides with this trigger, an NIS will play)
• Context-sensitive AI trigger (if the player collides with this trigger, an event will be sent
to the AI)
• Stairway trigger (if the player collides with this trigger, the player will start or stop
navigating stairs – depends on whether it indicates the top or bottom of the stairway)
Cameras will be placed in the level using zones. Each zone will be outlined as a trigger volume.
A camera path will be specified using control vertices and attached to the volume. Whenever a
player enters a new trigger volume, the camera AI will switch the camera to the one attached to
the new volume. The trigger volumes should overlap such that the camera does not snap between
two cameras at a trigger volume. Emphasis is placed on the player entering a volume as opposed
to exiting the old volume.
• The designer will be able to specify a tracking type for the camera, such as stationary
tracking, stationary non-tracking, and side-scrolling.
For this particular pipeline there are no specific instructions that need to be considered on a
platform-to-platform basis.
TBD
TBD
TBD
640x480
(40,30)
544x408
Safe Area
(600,450)
Some general comments about outputting video to a standard television are listed below (note
that many of these do not apply to HDTV).
17.1.1 Colors
• Check illegal colors – a set of guidelines/tools will be provided which verify if colors are
NTSC suitable.
• TVs do not display the entire image being received from the video game system – an area
around the edge of the screens is obscured – this is referred to overscan.
• Always review the positioning of text and important information on the Tv to make sure
it is clearly visible.
• The area not safe frame for display of text encompasses the edges on sides, top and
bottom to about 10 to 15% percentage of the overall screen size.
• [XBox specific] The alpha version of the XBox development kit outputs the TV signal
off center. This will be fixed in beta and final versions or the XBox.
• Computer monitors use progressive scanning that updates every horizontal line on the
screen; this is drastically different than what a TV does.
• Interlaced flicker – this is caused by only half of the typical 525 lines on a TV being
drawn in a one-frame period that is called interlaced scanning.
• Flicker Reduction: Avoid fine vertical detail if possible. For example, a single-high pixel,
horizontal white line on a black background causes the worst flicker.
• Flicker Reduction: Avoid areas that have a large bright area with a large dark area below
it.
• Flicker Reduction: Menu screens with too much detail may be the worst flicker
offenders.
• Full scene anti-aliasing will remove jaggies, help with issues such as chroma crawl, and
other undesirable artifacts.
1. PAL – the flickering can be worse due to a refresh rate of only 50 KHz as compared to 60
KHz for NTSC. The vertical resolution is also higher. PAL has 512 lines compared to
NTSC’s 448 lines.
3. Test on many different TVs – low-end to high-end as features such as comb filter or S-Video
connectors make a large difference in the picture quality.
18. APPENDIX B: WHEN YOUR MAYA FILES ARE BLOWING OUT OF PROPORTION:
These steps should be performed fairly often, to keep the file size under control…
• Delete Construction History: Edit -> Delete All By Type -> History
• Delete hidden geometry: its definitely not needed if its not displayed, and I don’t know
whether the exporter actually exports it or not when its hidden. During construction of
arenas, levels, characters there might be some reference geometry that is added to the
scene. This should be all deleted once the level is built. It is usually easy enough to find
hidden geometry in the Outliner window, but you might also want to try Display -> Show
-> All from Maya’s main menu bar.
• Delete Intermediate objects that are not connected to anything in the Hypergraph. These
might be hard to find, but in the hypergraph they will look like this:
After clicking on the button that will show the hypergraph, you should be able to see that the
node is disconnected from the rest of the graph. Like so:
If you use image planes with your cameras, Maya will attach tons of nodes to the camera nodes
of the scene. This is viral, in that every time you open the file, more nodes are added and it will
quickly bring Maya down. This might be fixed in Maya 3.0, but I don’t know for sure. To delete
these nodes, in the hypergraph window, select Options -> Display -> Shape Nodes (so that there
is a check next to it). Select the cameras and their respective shape nodes, and then show
dependencies (as above). If you see something like this, you are suffering from that problem…
• Note that I deleted about 1000 image planes to get something that I could meaningfully
capture in a screen grab.
• Delete unused materials in the Hypershader window, by using the Edit -> Delete Unused
Nodes in the windows own menu bar.
18.2 After the Maya file is final and is ready to be exported to the game…
or, if its not been fixed by regular maintenance as stated above… Be careful with this procedure
as you may loose critical information if you do not select the right nodes out of the hypergraph.
Never save over an original file which would be the only copy of the data…
• Select all the top nodes in the hypergraph that you want to be saved (Note: if you have a
skinned character you must make sure that the bind pose is selected from the hypergraph;
if you are using Trax the character set must be selected). Here is an example with a
skinned sphere and Trax:
• In the export selection option box make sure that all are checked (animation, history,
expressions, textures, etc.), like so:
• Export the scene to a new Maya binary file, without overwriting the original file.
• Open the new file in Maya, without saving the file that you just messed around with.
When tri-stripping is used in the most optimal fashion, the example shown below requires 9
vertices to draw the 8 triangles. If the 8 triangles were not tri-stripped then each would require 3
vertices each and hence 24 vertices would be required. Therefore, the memory savings required
to only store 9 vertices as opposed to 24 and the subsequent savings in processing only 9 vertices
are the concrete benefits of using tri-stripping.