Final Documentation

Man Vs. Unman
Final Project
Yazan Mohammad Doofesh
20080043
Princess Sumaya University for Technology
Faculty of Computer Graphics and Animation

Table of Contents
1 Game overview ....................................................................................................................... 4
1.1 Story ................................................................................................................................. 4
1.2 Storyboard ........................................................................................................................ 4
1.3 Game Genre...................................................................................................................... 4
1.4 Target audience ................................................................................................................ 5
1.5 Location and Environment............................................................................................... 5
2 Character design...................................................................................................................... 6
2.1 Playable Character............................................................................................................ 6
2.2 Supporting Characters...................................................................................................... 6
2.3 Enemies.......................................................................................................................... 11
3 Game Play and Game Mechanics ......................................................................................... 13
3.1 Game Play Elements ...................................................................................................... 13
3.2 Challenges ...................................................................................................................... 17
3.3 AI.................................................................................................................................... 18
3.4 Scoring ........................................................................................................................... 18
4 Aesthetic Elements................................................................................................................ 19
4.1 Visual Components ........................................................................................................ 19
4.2 Music and Sound Effects................................................................................................ 19
4.3 Cinematic Effects ........................................................................................................... 19
4.4 User Interface ................................................................................................................. 19
5 Tools ..................................................................................................................................... 20
5.1 Source............................................................................................................................. 20
5.1.1 Setup Process .......................................................................................................... 20
5.1.2 Maya in Source Settings ......................................................................................... 27
5.1.3 The Scripts .............................................................................................................. 36
5.1.4 Source SDK and Compilers.................................................................................... 43
5.1.5 Source Filmmaker................................................................................................... 44
5.1.6 Source Render......................................................................................................... 49
5.2 Maya............................................................................................................................... 49
5.2.1 Modeling................................................................................................................. 50
5.2.2 Texturing/UV Mapping .......................................................................................... 50

5.2.3 Skinning.................................................................................................................. 50
5.2.4 Rigging.................................................................................................................... 50
5.2.5 Animating ............................................................................................................... 50
5.3 Mudbox .......................................................................................................................... 50
5.4 Unity 3D......................................................................................................................... 51
5.5 Sony Vegas 10 pro ......................................................................................................... 51

1 Game overview
1.1 Story
//What is the story in brief?
The game story is based on the simple concept of overcoming obstacles to reach a goal.
The story undergoes and evil scientist (Dr. Rombie) who creates the Zombie Plague and
Machine (robot) apocalypse as a mean to destroy the members of team fortress. The team
members (introduced in the cut scenes created by SFM) are controlled by the player in the game
(created/built with Unity). Their objective is to escort the nuclear briefcase cooperatively to the
base of Dr. Rombie‟s lab to destroy the apocalypse/plague factory.
Each player of TF will have to escort the briefcase through a map of obstacles that they can
encounter based on their special ability as I shall cover later on.
1.2 Storyboard
Images?
Ross Halbie was an ordinary human researcher at bio-steam labs until one day the accident
happened. Ross was exposed to radioactive material that destroyed most of his body structure
and tissue that the labs had to replace most of his lost organs with mechanical and biological
cloned substitutes. Ross survived in the end, with a more bitter life. His colleagues routinely
would whisper behind his back on how he seemed to be somewhat like a hybrid robot-zombie in
his state, they even called him Rombie as they seemed to have forgotten his real name over time.
Being cast out of a normal life seeing that he isn‟t normal anymore; Rombie decided to join The
Team as a last hope of finding a purpose to his life, but alas, he was yet rejected once more. This
rejection was the last that Rombie would ever take, especially from the nine that he looked up to
all his life. Rombie wanted to show the world who he is, they wanted him to be the hybrid, then
so he shall be, he dedicated his days perfecting the twin apocalypse to bring down the world of
arrogant humans to show them how steel and undead flesh can change the world to a place where
the different are respected and recognized.
The Team responds but only too late, Rombie has already deployed a group of zombified clones
and robots programmed to their specialties aiming to destroy them. Their task is simple yet
difficult, the must deliver the nuclear briefcase to the core of the apocalypse factory and bring an
end to Rombie‟s apocalyptic schemes and army.
1.3 Game Genre
What and why

Action RPG third person shooter later converted to a first person shooter game in late
development stages to have a better and easier camera for gameplay and development. These
games have a higher number of players. Also, this game is TF2 inspired, so not much can be
changed in an attempt to outstyle Valve and their designs.
1.4 Target audience
Describe.
The best thing that Valve provided the community with was the target audience and content
creator mix that devastated all titles and standards for content creator and viewer. With SFM,
gamers can now create animated movies with high quality just like a professional animator
would with other software. Simply put, there is no specific target audience, let it all be mixed and
this content, like any other should be aimed to those who would like it or appreciate it.
1.5 Location and Environment
Describe
The reference maps on Source: some of these maps were made by the community, others were
published by Valve themselves and they are available for free to use within game lobbies, SFM
editing, or other purposes, simply, they are free.
The Map location will be used from the Angry Bots free sample game provided with
the Unity 3 game engine, some additions and changes will be made unless time is
found to make a new map from scratch.
The map fits the theme of a lab for Rombie’s plans to take place there, where the
team infiltrates different sectors to deploy the bomb.

2 Character design
2.1 Playable Character
From the SFM point of view: We get a brief look of the characters in action.
From the Game (Unity3d) point of view: The scout is our main character for his optimal
combat style that suits most RPG and/or FPS or TPS players.
We also have the Heavy and Pyro as role leaders in the game final prototype for this
project.
2.2 Supporting Characters
1) The Scout:
Basic Traits: The scout will rely on his speed to bypass obstacles that will test that attribute.
He will be the first assumed role (this might change based on the game plan)
Scout:
Uses speed for fast maneuvers.
Shotgun as primary weapon, effective against both enemies.
Iron Baseball bat for melee.
Low health, due to weak physical build.
2) The Soldier:
The soldier carries a bazooka since its his favorite weapon, and will cause havoc with it, simply a
classic role that will be maintained in my game. He may have an extremely powerful weapon,
but his targets are limited to a small group.
Soldier:

Slow, yet powerful, due to heavy weapon.
Bazooka as primary weapon, very effective against both enemies.
Iron shovel as melee.
Medium health.
3) The Pyro:
The pyro’s job is simple: burn everything. Due to his extreme and effective power against
zombies, it will be kept in mind that a robot’s metal coat is resistant to flame unlike a zombies
flesh.
Pyro:
Medium speed, low range, powerful attack.
Flamethrower is devastating against zombies, but will need a little time to damage robots,
since the heat may not penetrate metal, it might disrupt their circuitry.
Flaming axe for melee.

Medium health.
4) The Heavy:
What the heavy lacks in speed, he makes up for it with the power of his machine gun; it can take
many targets at a time, as well as suppress an enemy robot and zombie alike.
Heavy:
Very slow, yet very powerful.
Machine gun can fire 200 devastating rounds that can crop zombies and robots alike.
Uses fists for melee.
High health due to powerful physical attributes, yet is extremely slow due to heavy
weight and weaponry of choice.
5) Spy:
Master of disguise, he could infiltrate the enemy ranks, and cloak himself with their color and
attributes, no zombie sense nor robot sensor can make him out unless he attacks. His stealth is
also a bonus, but despite all these abilities, he cannot fight but one target at a time with his
stealth stab.
Spy:

Medium speed, low combat profile.
Uses a magnum pistol when exposed, with minimal damage to both enemies.
Uses the spy knife to kill any enemy with one stab as long as stealth is on.
Low health, since he is not a combat expert.
6) The Demoman:
A grenade launcher may be slow to use against a robot, but might as well be effective against a
group of zombies, therefore the melee alternative exists; the demoman can use his claymore
sword to attack enemies at close range and in vast numbers.
Demoman:
Medium speed, good power.
Melee expert, one to two hits can take out any robot or zombie.

Note: if melee is enabled in gameplay for the other characters, the grenade launcher will
become the Demoman‟s main weapon.
Medium health, close range and demolitions expert. (Might be the one to plant the
nuclear device).
7) The Sniper:
Basic Traits: The sniper never engages in direct combat, he instead prefers to keep his distance
from the target, and can take any with a single shot from afar. If however the targets get close
enough, the sniper can engage in a melee.
The Sniper will either be used to support other characters with a hotkey within the game or
assume his own role to eliminate several targets within his section of the map.
Sniper:
One shot – one kill. Can be called once ever few minutes of cool down time.
8) The Engineer:
Specializes in creating defensive turrets, due to that and the nature of the game, the role of the
engineer is not yet fully determined, but a draft is made so as to make his role as a support
character when needed by other players.
Engineer:

Can be called to deploy his famous turrets to help any character in difficult situations
when the enemy might overrun them. Also depends on a cool down time.
9) The Medic:
In the original TF2 game, the medic assumes both the assault and healing traits; however, due to
the nature of the extensive action in the choice of characters, the medic’s role will be shortened
to cover only healing and resurrecting roles as support.
Medic:
The medic invented the uber-charge gun that can render a character invulnerable for a
short period of time, however when the charge is depleted, the medic has to retreat to
refill the uber-charge.
2.3 Enemies
Describe.

For every TF2 character there is an equivalent character as a zombie or robot as follows:
Scout Zombie & Scout Robot.
Demoman Zombie & Demoman Robot.
Soldier Zombie & Soldier Robot.
Medic Zombie & Medic Robot.
Spy Zombie & Spy Robot.
Engineer Zombie & Engineer Robot.
Pyro Zombie & Pyro Robot.
Heavy Zombie & Heavy Robot.
Sniper Zombie & Sniper Robot.
Zombies:
All zombie characters aim for an extremely close range proximity for attacking, therefore
they have no weapons except their teeth. Zombies want to attack the living, so they are
naturally non-aggressive towards their robot allies.
Robots:
All robots are programmed to destroy the living, therefore their targets will not include
dead zombies.
Zombies and robots will differ in health depending on their specialty, for example Heavy
typed enemies will have more health than the rest, just like the human team does. Which
makes the scout types the weakest yet fastest.
Another addition might be made if time is found: Support type zombies and robots might
The Zombies:
Phase 1: the classic Half-Life zombie was used at first in the introduction scene, but later on
phase 2 was implemented.
Phase 2: I purchased “Gary’s Mod” tool from the Steam store when there was a sale on the
program for 75% off. This enabled me to acquire a new set of Zombie models designed in the
TF2 Zombified character style.
Zombie Scenes were replaced with models of original TF2 characters, but Zombified

The Robots:
These robots were created to impersonate the specialties of the TF in appearance members
(Just like the Zombies, but in this case Robots!), and skill.
3 Game Play and Game Mechanics
3.1 Game Play Elements
Describe.
This is the technical report on the Unity3D elements:

Classes Hierarchy
1) Player Controller Prefab, which contains:
a) Main Camera
b) Player Controls Class; which contains:
i) Movement
ii) Shooting
(1) Using Main Weapon
(2) Using Secondary Weapon
(3) Using Throwables, if applicable
iii) Switching Weapons
iv) Special abilities; which are:
(1) Healing
(2) Sniper Shot (instant kill)
c) Player Stats Class; which contains:
i) Class Type; which are:
(1) Scout
(2) Heavy
(3) Pyro
ii) Current Weapons; which are:
(1) Shotgun
(2) Machine Gun
(3) Flamethrower
(4) Bat
(5) Fists
(6) Axe
iii) Health
iv) Movement Speed
d) Camera Controller Class, which contains:
i) Aiming
ii) Camera Movement
iii) Camera Position
e) Player States; which contains:
i) In Cutscene
ii) Alive
iii) Dead

Enemy Class Hierarchy
1) Zombie Class Prefab, which contains:
a) Enemy States; which contains:
i) Chasing
ii) Attacking
iii) Dead
iv) Wandering
b) Unit Stats; which are:
i) Damage Power
ii) Speed
iii) Health
iv) Detection Range
2) Robot Class Prefab, which contains:
a) Enemy States; which contains:
i) Chasing
ii) Attacking
iii) Dead
iv) Wandering
i) Damage Power
ii) Speed
iii) Health
iv) Detection Range
v) Range
3) Turret Class Prefab, which contains:
a) Enemy States, which contains:
i) Idle
ii) Shooting
iii) Dead
i) Projectile
ii) Attack Speed
iii) Health
iv) Rotation Speed

Player Class Hierarchy
1) Scout Class, which contains:
a) Weapons
b) Current Weapon
c) Health
d) Speed
2) Heavy Class, which contains:
a) Weapons
b) Current Weapon
c) Health
d) Speed
3) Pyro Class, which contains:
a) Weapons
b) Current Weapon
c) Health
d) Speed
Weapons Class Hierarchy
1) Shotgun Class, which contains:
a) Weapon Type, which contains:
i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
d) Weapon Projectile
2) Machine Gun Class, which contains:
i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
3) Flamethrower Class, which contains:

i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
4) Axe Class, which contains:
i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
5) Bat Class, which contains:
i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
6) Fists Class, which contains:
i) Primary
ii) Secondary
b) Weapon Damage
c) Weapon Capacity
3.2 Challenges
Describe.
The game will test the players skills and capabilities in real time action combat against the
classic zombies and their new allies the robots. This mix of enemy characters creates a unique set
of enemy team that makes the game exciting with so much to provide in challenging opponents.

As for my challenges, the whole project idea was a challenge to convert Maya to Source, as well
as researching about a software that was recently made and in beta phase for quite a long time.
The technical details will be described in the Source section of this document.
3.3 AI
Describe.
Human team is controlled by player, no AI required, only in some exceptions movie/animation
driven to fulfill story purposes.
Zombie characters will have a basic chase without evade A* algorithm. Robots will have chase
and evade A* algorithm to reflect their smarter capabilities (please check section 3.1 for further
technical details on the game assets regarding AI).
3.4 Scoring
Describe.
On zombie or robot kill, and on time finishing without the time limit.
Scoring System: on every kill, and on time ratio.

4 Aesthetic Elements
4.1 Visual Components
Describe.
Main menu; to navigate throughout the game interface.
Player Stats; such as health, location, ammo, and other indicators.
The cut scene shall reflect minor story elements needed to describe two major points:
The first is the startup scene which is styled in random-action shot sequence that gives the
overall yet inaccurate idea of the source world.
The second is the visual cut scene that shall describe character interaction in-game or on game
completion to give a sense of accomplishment within the game.
4.2 Music and Sound Effects
Describe.
Valve has been generous enough to provide all their sound file resources for TF2 and other
previous games like Half Life, this contributes to the massive 14gb of media files within the
Steam folder for SFM. The library is so massive, one can almost never go through all the files
even for a final project such as mine. Better yet, these files are easily extracted from the
“Source” source folder and then placed in the Unity asset files.
These files contain theme music, sound effects for zombies, and player vocals capable of being
extracted as phonemes to be added to Source TF2 models to enable feature-film quality lip-sync.
Which is an attribute that makes Source the number one game engine yet in this feature against
others such as and not inclusive to: Unity, Unreal, and CryEngine.
For more about phonemes, please check the external Source documentation from Valve on this
feature. I did not intend to focus on it in my project for its simplicity.
4.3 Cinematic Effects
Describe.
SFM has a built in in-Engine tweak from SFM that can add effects to the scene that give results
that compete heavily with Adobe After Effects software, which means I did not have to use it at
all in my project for special effects!
4.4 User Interface
Describe.
The user interface in the game is simple, classic, and friendly with an easy navigation tree that no
gamer will find confusing.

5 Tools
5.1 Source
Describe
Source Filmmaker: This is a tool that enables us to access the Source Game Engine to acquire
assets from the Orange Box game series (counter Strike and Half-Life Series/up to 12 games)
and other games released by Valve such as Portal, this explains the extensive size of SFM
download that reaches up to 12GB as a basic installation on Steam
Steam: A communication platform that enables players to access the Steam community, there, a
user can purchase games, connect with the Steam community, and gain support for the games
they‟ve purchased. Steam also manages the multiplayer servers and support forums, as well as a
cloud sync system for every player to preserve their games and statistics as well as their own
data page and account info.
Source technical Details and Conversion process to Autodesk Maya
5.1.1 Setup Process
Source tools can be accessed via Steam client application; these tools include: Source
SDK (which can be used to view source models and develop mods for Source games
such as Half Life), and Source Filmmaker where I will import the models and their files
(such as those for animation, collision models which are also known as the physics mesh,
the phoneme files, blend shapes better known in SFM as model attributes).
This is the detailed process of how I was able to convert a Maya file and export from
within Maya to a Source file via scripts and script editors as well as Maya plugins and
support software from Valve themselves for model compiling and viewing. I have been
working on this conversion from early July 2012 till the making of this documentation in
late April 2013, and so far I have not encountered a source or a person willing to explore
nor explain the full details of this conversion, except very few who later gave up on the
idea due to its extreme complexity. One animator at Microsoft named Randall Glass was
kind enough to point me in the right direction, his work involved animating on Maya and
rendering the final product on SFM. His only published work was titled “Scout vs. Witch
- a tale of boy meets ghoul” which is popular on YouTube.
Before we start, there are a few key points that one must keep in mind before linking
these two vastly different platforms: Please note that the animation overview system is

slightly foreign between Maya and Source. Maya will use frames to create an animation
sequence, whereas Source will use seconds instead. When using conversion scripts, you
will realize that both will be converted to the codeword “time”; as in saying “frame 1” or
“second 1” becomes “time 1” in script, which makes the animation conversion possible.
As for the textures, the only material that both platforms recognize is the “Phong E”
shader. Many will argue that it is an old shader and Maya has better capabilities with all
available materials, this is debatable as to two major factors: In Source the environment is
built so as to keep everything in the environment best suited to make the environment as
best looking as possible. Textures have a cartoonish effect to them, in my first attempts, I
was able to import models without texture due to a fault I later fixed in the model
exporters from Maya. Models are basically exported as connected vertexes, and the
texture file is defined between them to reflect the UVs upon them.
Source views the model differently, a model created on Maya has to have “inverted
normals” to be able to be seen on source, or else it would be rendered invisible. Also, the
up axis has to be set to the Y axis, that‟s why most models imported from Source to
Maya will seem to be lying on the ground unless the options are changed in Maya to suit
the Source environment.
It is very important to consider the size of the model before importing to Source! Source
uses the centimeter (cm) unit to determine the size of a model, therefore we should switch
the working units under linear option to cm. This is due to the fact that there is no scaling
inside Source!!! Therefore a model has to reach its final simulated size in Maya before
being imported, if a problem occurs, the whole model has to be compiled again to change
the size outside Source. This is because some things in the Source Engine have not been
updated due to its old age.
I will first explain here the process of converting models from Maya to Source. Since
importing models from Source to Maya is easy with the aid of “Valve” who have been
kind enough to supply any SFM user with the game models and their compiled versions
for free!
I will use a helmet model as an example to demonstrate all the steps within the
conversion process.

Fist we set up our project file for Maya, this time, we do not require all the default files as
we usually do when creating a Maya scene. The important files are setup according to the
community made exporter "Half Life 2 exporter v.2.5 for Maya 4-8 by Prall". This
exporter contains a set of scripts that can be used to overwrite existing scripts in Maya to
set up the correct SMD exporting capability. SMD files are a form of text files readable
in LUA script that define the models vertexes and their attributes such as effector joints
and UVs along with their texture files; all of this is written in a format that can be
converted in Source SDK compiler that is activated on Steam client. I would like to point
out that since July 2012 I have used this exporter which was designed for older Source
games and engine versions when SFM was launched, therefore there was a mjor
complication in compatibility that I had to fix on my own with minimum help from the
community where most people gave up on the topic, not that there were many interested
in converting models from Maya to Source since, I daresay, every other alternative is
easier (a few examples are Blender and Softimage Mod tool that has a special version
made to handle source models and built in compilers that make the work much more
efficient and quick). Recently (April 13th
2013) I found an update to Prall‟s SMD
exporter that makes it compatible with 64bit versions of Maya, although I was able to fix
this problem alone with no reported success from the community of amateurs nor
professionals, and above that I was able to fix the GUI for the exporter with a very simple
bypass after understanding a few basic scripting techniques for Maya mel scripts within
the script editor.
The project folder must contain the hierarchy a folder called "scenes", one called
"model_sources" and also one called "materialsrc". The materialsrc should also contain a
folder called "models". This is the standard hierarchy in Source models and their
materials within the games and SFM, which seems to be rather organized in their unique
way, one does not get lost there as long as they have the name of the model, and Source
SDK organizes the view with its “Model Viewer” application/option.

To break down these folders:
1) Materialsrc contains the textures, which are preferable to be in the TARGA (.tga)
format.

2) Model_sources will contain the important compiling (.qc) files and reference
(.smd) files. Their functionalities are explained in detail further in this
documentation.

We begin the conversion process by creating or importing our own model on Maya. The
first thing to do here is to assign the Phong E material and make sure that the normals are
inverted and visible. A texture file has to be assigned to the model, and we should keep
its name saved for further use, since this texture is in a format unreadable to Source, but it
will be used to spread the UV coordinates for a duplicate texture that can be read in
Source. Our model must be split upon two layers; the “reference” layer which contains
the original model, and the “physics” layer which contains the collision model (this may
sound a bit strange to animators, but keep in mind that SFM was built on a game engine,
so a collision model is expected to exist, but will not be used at all when rendering an
animated movie). We can ignore this step, by using the help of Source SDK to compile a
model for SFM settings only, but this will still depend on TF2 engine (Source MP
Engine) for settings and model attributes, therefore keeping the physics mesh will not
harm us for the time being, especially that we are rendering a movie that has zero

requirement for a collision model. Note that when model creation is complete, all history
must be deleted.
Figure: Source SDK interface.
The Source SDK is used to view models within the Steamapps folder within the Steam
client main folder; this is the directory where all Source files are located. The official
files are separated from the custom ones which are under the folder “usermod” in the case
of SFM, this folder will not update with the rest of the game whenever an update is
available on Steam, and nor shall it upload its content to the users cloud files as the
application preferences do automatically whenever the program is closed.
In the meantime we shall leave SDK to a later stage to review our work once our model
has been compiled and imported to the Source directory.

5.1.2 Maya in Source Settings
Here is the helmet model in Maya 2011 64 bit version which has the preferences set for a
source model:
The same model in Maya 2013 64 bit version which uses default Maya preferences:

Notice in the 2011 figure, we have two layers for the model. One must be names
“references” which contains the basic mesh/model, and the second is “physics” layer
which contains a duplicate of the reference model. “Reference” layer is the one that has
the Phong E material assigned to its model. In the skeleton model below the joints are
separate from both, but are assigned to the reference model.
There is an animation sequence up to frame 700, so we could notice that when the
sequence plays, the model in the reference layer will move while the physics one will
remain still in the original location, this will not appear inside SFM since the physics
model is invisible and will not even render a proper collision model, unless we want to
import this model to a Source game mod, which is an entirely different story. Since I
have mentioned the use of physics models, it is preferred for those who want to create a
gaming model to keep the poly count heads up display to make sure they don‟t exceed a
number of polys so as not to create a heavy load on the game, not that Source engine
can‟t handle it, it can handle quite the heavy models. In my independent research, I was
able to import an exported TF2 model from SFM to Maya, the drawing of the vertexes
takes quite some time. The option of importing SMD files is provided with the Prall
script and/or its update which we can use to import the high-poly models from the default
Source directory C:Program Files
(x86)Steamsteamappsusernamesourcesdk_contenttfmodelsrcplayerpyropartssmd
In this case, I am importing the Pyro SMD.

Pyro in the early stage of importing/building:
Halfway done…

Nearly done…
Then an option to fix the orientation to either Maya or source settings:
Then we have the final model.

The previous model took two minutes to import on an I7 device, consuming up to 4GB of
Ram! It also contains an astonishing 4.2k triangle count.
Now back to our skeleton model.
In this snapshot, the physics model remains still in the origin, while the reference layer
performs an animation.

Membership assignment is important to enable control over the model in Source, we
access this attribute by right-clicking the reference or physics layer and select
“membership”. The reference and physics should look like this, by selecting the mesh
and group for each:
One note before we continue is that the TARGA texture must be of a size of the power of
two: (e.g. 256*256, 512*512, 256*512, etc.). Also, the physics mesh has to have its edges
smoothed, again, this is only needed when we are creating a model for a game mod and
its not a necessary step for an SFM model.
Once we have all of this checked and set up, we can go ahead and compile the SMD file!
Below is the preview for exportation.

This is the main SMD exporter interface menu.
This is the optimal and near default settings that should be made, except for one box
which has no effect. The “Compile generated QC file” option cannot render the model on
its own. We have to do it manually.

The paths tab explains why we created two folders in the hierarchy previously, this is
where the SMD and QC files will be exported as well as the Textures which in our case
consist of a TARGA image file.

This screen is near useless unless we are not using our own textures; as long as we have
an assigned texture file, these materials will not be noticeable inside SFM. They are made
for gaming models and their properties. We can notice this choice in the QC file later
when we edit it with our choice of text editor software.

In this screen, I have set up some of the different animation sequences available for
demonstration. In this case we have the “idle”, “run” and “idletwo” animation sequences,
where “idletwo” is just an alternative animation to “idle”. I simply included the necessary
frames, and add them to the list. Customization is easy here.
Now we click the “Full Compile” button and the compiling process won‟t take long.
5.1.3 The Scripts

Here are the resulting files.
To edit these files, preferable choices by the community are Notepad++ and Context. In
my case we will use Context, because it has a built in functionality that enables it to use
the Source compiler on the QC file to read the SMD and extract the model attributes to
create a Source MDL file. This sounds difficult, it isn‟t, the only problem here is that
there is no way to check for compiling errors! Sometimes it took me hours and the model
didn‟t compile just because of a misplaced comma or a wrong format of quotations, since
I got some of my codes online; the format of the quotations will be „‟ instead of ” or
otherwise. This is frustrating at first because I would go back and retrace or redo all the
steps from Maya.
Before we can use Context, we have to set it up to understand how we need our models to
be compiled.
Here is the Context file for our model that I‟ve written with LUA script:

$modelname "skeleton.mdl"
$scale 1.0
$surfaceprop "default"
$keyvalues { "prop_data" { "base" "Cardboard.Small" } }
$body "Body" "skeleton"
$sequence idle "skeleton_idle" loop fps 30
$sequence run "skeleton_run" loop fps 30
$sequence idletwo "skeleton_idletwo" loop fps 30
$collisionmodel "skeleton_phy.smd"
{
$mass 1
$concave
}
Previously I have described how Source uses centimeters to accurately size a model, and
how there is no scaling within Source itself. We can manipulate the model size with this
script and turn around that, but the downside to this substitute is that we have no visual of
the model, and it‟s assumed that our model is made to its wanted size and dimensions
before compiling. In the case of the helmet for example, I used the code to scale it rather
than Maya because it has a rather spherical shape that‟s easy to imagine and measure
with our mind without the need of a visual representation on the screen.
We define the animations (or sequences as we should address them from now on, as
Source would differentiate between a “sequence” file and an “animation” file) with the
$sequence command, notice the names of the sequences are the same as in the exporter
window.
$mass is more concerning for game models, we will not need it even for SFM.

The beginning of the SMD file will contain the joints and their names, later on it will
assign them to vertexes which go along with a texture for every group of them.
Further on in the code; the triangles and their textures:

Now that our QC file and SMDs are in the same directory, a problem I faced for a very
long time was the texture file name, instead of having the same name, Prall‟s exporter
would export the texture file as “debug/default” for some reason, which made my model
seem textureless in SFM, therefore it appeared as a black and purple checkerboard texture
instead of the original. So I would replace the “default” with the texture name in this case
it is the TGA file.
Time to set up Context, this next screen is how we set up Context to send the SMD files
to the “studiomdl.exe”, using the code within the QC file that is currently open

In case Source SMD was not running, the compiler will fail, giving us the following
statement:
> Executing: C:Program Files (x86)ConTEXTConExec.exe "C:Program Files
(x86)Steamsteamappsdoodeshsourcesdkbinep1binstudiomdl.exe"
"C:UsersYazanDocumentsmayaprojectsHelmetToSourcemodel_sourceshelmet.qc"
SteamStartup() failed: SteamStartup(0xf,0x0018F170) failed with error 108: The local
Steam Service is not running
> Execution finished.
Whereas when the compiler runs successfully, we will find our MDL files and texture
files in the source directory within the Team Fortress files. The resulting statement will
simply show us the progress of rendering and direct us to the output directory.

The models will be exported to
C:Program Files (x86)Steamsteamappsusernameteam fortress 2tfmodels
And the textures will be exported to
C:Program Files (x86)Steamsteamappsdoodeshteam fortress 2tfmaterialsmodels

5.1.4 Source SDK and Compilers
Now that Source SDK is running in the background, we can run the program and choose
“Model Viewer” with the Source Engine MP active to the Team Fortress 2 Settings or
SFM, from the dropdown menu.
Once we‟ve run the program, we select File -> Load Model and browse for our model
name, in the next screen we can see a model loaded from Half Life 2 with all the
properties and preview animations in the lower half of the window, there we can preview
all the collision models, and textures, plus their alternatives(yes, we can use multiple
texture files for the same model, its simply by assigning a different material and editing
the compiler script), in my case I did not load multiple texture because I did not find the
need to do so. In the case of TF2, each character was either assigned to team RED or
team BLUE, hence the multiple textures.

After checking that the model is fully detectable and textured, we can now go ahead and
run the Steam client, then select SFM
5.1.5 Source Filmmaker

This is the Steam application library interface; from there we can choose Source
Filmmaker under the software section of installed items.
Another example is the Source SDK, which can be found under the “tools” section.

Another way to access either program is by running SFM and a pop-up window will show up
asking us to choose either one, the default is SFM.
Click OK, and SFM loading settings screen will show up, where we get to choose either
an existing scene or create a new one.
If we are running the program for the first time, there are three ready scenes for the
official “meet the team series”, these include “meet the heavy”, “meet the soldier”, and
“meet the engineer”.

Once we create a new session, the main interface will load but without a map, and the
default time sequence that lasts 60 seconds as we can see below:
Before we continue with importing our model, I want to take this opportunity to explain
the UI of SFM and its functionalities then continue with the importing process.
Let‟s import a map to work on.
File -> Load Map then we select our map.
Most of these maps take up to 2 minutes to load due to their complexity and large map
size environment. It takes up to 5 minutes to explore a map in one of the game characters
using the game world either within SFM or if we start the game from Steam (TF2).
Main elements of the SFM interface:
The Animation Set Editor
It contains the list of objects within the selected scene; such as models, light sources,
cameras, and images. Some are created by the + icon at the top, others are imported from
the game world if it was recorded to the current scene.
Next to it is the Element viewer, which has the capability to tweak the settings and
options for any attribute, model, or game world setting which renders it dangerous to new
users. It‟s not recommended by Valve to go there except by the guidance of their official
tutorials, since we could end up with an unrecoverable state for our scene.

The procedural section will be used in the animation; it will help us create an overlay
effect on the current scene, which I can demonstrate afterwards in the animation
capabilities of SFM.

5.1.6 Source Render
The pride of SFM against Maya; In the documentation of SFM under the rendering section, an
algorithm has been developed to render a single frame in the scene 4000 times faster than Maya,
at the loss rate of quality by 3-4% max. This is due to the correction algorithm in Maya that
calculates a single frame 4000 times for correction purposes. My project took exactly 6 minutes
to render versus an approximation floor of 180 hours on Maya!
5.2 Maya
3D studio software that draws and designs 3D models, with the ability to texture them and
animate. I used the 2011 version to support Source Models due to the fact that there are more
supported plugins on that version. As for Unity, I used 2013 to animate the game models,
especially those ones exported from Source, some of them reached half a million triangles which
makes them impossible to render inside Unity. Therefore, I had to export the model as an FBX
file to Mudbox, re-sculpt the model and lower the face count to a reasonable level that Unity can
handle. Then I would re-texture the destroyed UV maps and rig the character for Game
animation, which is somewhat different from the animation used in Maya and SFM to animate
movie Characters. All the detailed uses of Maya were described in the Source section of this
documentation.

5.2.1 Modeling
5.2.2 Texturing/UV Mapping
5.2.3 Skinning
5.2.4 Rigging
5.2.5 Animating
5.3 Mudbox
Mudbox is a tool provided by Autodesk to simplify the process of texturing models for a start.
Other tasks include exporting model maps such as the Normal or Bump map. In my project I
have used the program to Sculpt Rombie‟s model from a basic polygonal model created on
Maya. I have also sculpted the Scout Model and created the textures with the paint tool on
Mudbox, as well as exporting the Ambient map and Normal map, which I later applied in Maya
after rigging and animating.
The version of Mudbox that I‟m using is 2012 since it‟s the only one that worked unlike 2011
and 2013, which I think is due to issues relating to the GPU version and capabilities as well as
the model of my Lenovo PC which has a built in system of dual GPUs that cause a few problems
with other software as well.
Here is a screenshot of the exporting process for the model in Mudbox for demonstration
purposes.

5.4 Unity 3D
A game engine, not much like the Source engine, it has the capability of giving the user freedom
to define their own scripts, using scripting languages like JavaScript and C#. Within the time I
worked on my project, Unity updated from the 3 version to the fourth. I am currently working on
version 4.1.2.
In my project, my first phase was to create a translated version of a third person game available
for free on the Unity asset store, the difficulty persisted in consuming a lot of time in coverting
the JavaScript file to C# format so I can easily call and re-use the scripts with my own. After a
week of scripting, I deleted all my work due to some problems in C# itself; I did all the
conversion manually making sure along the way that there were no compiler errors in the script.
But it seems that where JavaScript can support creating a variable without declaring its type, I
had to improvise with a suitable one in C#. The overall scripting in C# within Unity is different
than that taken in Visual Studio, and is definitely different than that within the XNA framework.
I had to learn a whole new method of scripting for games.
After a week of wasted efforts, I decided to start with my own script, and I was successful with
creating a first person and third person camera scripts as well as a script that can interchange
between them.
5.5 Sony Vegas 10 pro
A very common video editing too recommended by the YouTube community, known for its
simple interface. I used this tool to render up the image sequence made by source into the final
video. No effects were added here, only informative text.

Final Documentation

More Related Content

What's hot (15)

Similar to Final Documentation (20)

Final Documentation