224 lines
No EOL
10 KiB
HTML
224 lines
No EOL
10 KiB
HTML
<html>
|
||
<head>
|
||
<title>MOHAA - SDK</title>
|
||
</head>
|
||
|
||
<body>
|
||
<u><b><font size=+2>Exporting animated models from 3ds Max</font></b></u>
|
||
<br>
|
||
|
||
|
||
<p align = center>
|
||
<b><font size = -1>
|
||
Diagram 1-1
|
||
<br>
|
||
</font></b>
|
||
<img src="Exporting Animated Models/windmill.jpg">
|
||
</P>
|
||
<br>
|
||
|
||
|
||
<p>
|
||
<b><font size=+1>Prepping to Export</font></b><br>
|
||
<br>
|
||
Before exporting a model, some quality checks should be made to ensure fewer problems with the geometry.<br>
|
||
<br>
|
||
It is important to note that we work in centimeters, therefore creating or scaling objects to scale in cm is the best way to get a properly scaled end result. Object transforms should be reset before exporting as well; you will want to have all your objects at 100% of XYZ scale.<br>
|
||
<br>
|
||
Placing the objects pivot point at (0,0,0) is a good idea, as well as assuming that the pivot point will be the center point of contact with the game world. In this example of the windmill, I have placed the pivot at the center, bottom of the model and reset all the transforms. <br>
|
||
<br>
|
||
Exporting models that contain multiple objects is fine (just as the windmill does), however if you experience problems with sub-objects not being where they should be, you should check the individual object transforms, as this is often the cause of the problem.<br>
|
||
<br>
|
||
<br>
|
||
|
||
<b><font size=+1>Materials</font></b><br>
|
||
<br>
|
||
Multi-sub materials work fine, but each surface should be explicitly defined in its name box as shown. In this example the full name for some of the materials is not visible without scrolling.<br>
|
||
<br>
|
||
<br>
|
||
|
||
<center>
|
||
<b><font size = -1>
|
||
Diagram 1-2
|
||
<br>
|
||
</font></b>
|
||
<img src="Exporting Animated Models/mat_name.jpg">
|
||
</center>
|
||
<br>
|
||
<bR>
|
||
<b>Note that a model may not have more than 24 sub-materials.</b><br>
|
||
<br>
|
||
This particular example model has eleven sub-materials; this is an uncommon occurrence, as it is common that a model have only a few sub-materials. While it is not necessary for the <b><i>name</b></i> field to be the same name as the sub-object field, it is often helpful, as is naming the <b><i>name</i></b> and sub-object field to be the same as the shader that has been defined in engine. The <b><i>name</i></b> field is used during the export process, and ultimately is what the model<65>s surfaces are defined as.<br>
|
||
<br>
|
||
<b>Note that a single material may not have more than 1000 texture vertices assigned to it.<br></b>
|
||
<br>
|
||
An example of this rule is a model of something large and detailed like a train engine. The train engine may have a single monolithic texture map that is laid out for skinning the entire model, but the model itself is 2500 polys. With this high poly count it is likely the train<69>s texture UVs exceed 1000, and therefore the material definition must be broken up into separate materials for the sole purpose of properly compiling the model.<br>
|
||
<br>
|
||
Ultimately what this means is you would need to select half of the surfaces of the train and assign them to material ID 1, then select the remaining train surfaces and assign them to material ID 2. You would then need to create two materials that basically point to the same texture, but have their own unique sub-material name. So if material ID 1 points to train_skin_1 (which ultimately points to the texture train1.tga), then material ID 2 should point to train_skin_2 (which also points to the texture train1.tga). Depending upon the complexity of the model, and the potential surfaces a single texture needs to cover, you may have to create several <20>aliases<65> for the same texture. Later in the shader definition of the tiki file, you can point these two surfaces to the same shader, there is no need for multiple versions of the same shader ingame.<br>
|
||
<br>
|
||
<br>
|
||
|
||
<b><font size=+1>Exporting</font></b><br>
|
||
<br>
|
||
The file skelout.dle should be placed in your /3dsmax42/Plugins folder. If Max is open, you<6F>ll need to shut it down and restart. When the plugin is installed, open the model you wish to export. Go to <b>File|Export</b> and you will be presented with a dialog that looks like this:<br>
|
||
<br>
|
||
<center>
|
||
<b><font size = -1>
|
||
Diagram 1-3
|
||
<br>
|
||
</font></b>
|
||
<img src="Exporting Animated Models/export_dialogue.jpg">
|
||
</center>
|
||
<br>
|
||
<br>
|
||
Choose the MOHTA Skeleton export as shown above, and just type in the name of the file you wish to export. In this example, I am exporting windmill.skl.<bR>
|
||
<br>
|
||
After typing in a filename and hitting enter, you will see this dialog:<br>
|
||
<br>
|
||
|
||
<center>
|
||
<b><font size = -1>
|
||
Diagram 1-4
|
||
<br>
|
||
</font></b>
|
||
<img src="Exporting Animated Models/anim_export.jpg">
|
||
</center>
|
||
<br>
|
||
<br>
|
||
It<EFBFBD>s simple, Start defines the starting frame, and Stop defines the ending frame. Frame rate and Sample rate can be adjusted but it<69>s unnecessary in most cases, so leave them at 30 for most instances. After hitting OK the file will be exported to the location you specified. This file is an ASCII file that can be adjusted by hand if need be. It is often convenient to adjust material names in the .SKL file if they aren<65>t properly defined within Max.<br>
|
||
<br>
|
||
Before this asset is game ready we will need to compile the ASCII file to a Binary with the included tool skl_2_skx.exe. I<>ve included a batch file that will process a baseframe and an animation.<br>
|
||
<br>
|
||
rem ===Compile Baseframe===<br>
|
||
skl_2_skx windmill -baseframe -nolod<br>
|
||
<br>
|
||
rem ===Compile Animations===<br>
|
||
skl_2_skx windmill_still<br>
|
||
skl_2_skx windmill_turn<br>
|
||
<br>
|
||
There are many arguments for the skl_2_skx tool, but to have a functioning model you must create a baseframe for it. The baseframe contains Geometry, UV and Material information. It is important that you always re-export and recompile your baseframe when your model changes structurally (updated UVs, changed Material ID<49>s, updated geometry).<br>
|
||
<br>
|
||
The first command line will create a compiled binary named <b><i>windmill.skd</b></i> the second and third command lines (without any arguments) are setup for creating animations. In this example the files <b><i>windmill_still.skc</i></b> and <b><i>windmill_turn.skc</i></b> will be generated.<br>
|
||
<br>
|
||
<br>
|
||
|
||
<b><font size=+1>Tiki Files</font></b><br>
|
||
<br>
|
||
Continuing with the windmill example, we have the following tiki file. Each line is commented to indicate its necessity.<br>
|
||
<br>
|
||
|
||
<pre>
|
||
<i><font color=blue>
|
||
//token to identify the file as a TIKI
|
||
<font color=black>TIKI</font>
|
||
|
||
//setup section of the tiki, where scale, baseframe,
|
||
//path and materials are setup
|
||
<font color=black>Setup </font>
|
||
{
|
||
//everything in the game world should be scaled to
|
||
//0.54 for the cm conversion
|
||
<font color=black>scale 0.54</font>
|
||
|
||
//path that points to where the models data files are located
|
||
<font color=black>path models/animate/windmill</font>
|
||
|
||
//skelmodel allows you to specify what file is the model //baseframe
|
||
<font color=black>skelmodel windmill.skd</font>
|
||
|
||
//surface definintion (defined in max<61>s material setup)
|
||
//and which shader the game should use for that surface
|
||
<font color=black>surface wm_thatch_1 shader wm_thatch_1
|
||
surface wm_shadow_1 shader wm_shadow_1
|
||
surface wm_wind_blade shader wm_wind_blade
|
||
surface wm_Wood_Beam_1 shader wm_Wood_Beam_1
|
||
surface wm_brick_3_bot shader wm_brick_3_bot
|
||
surface wm_door_wood_2_bot shader wm_door_wood_2_bot
|
||
surface wm_door_wood_2_top shader wm_door_wood_2_top
|
||
surface wm_window_old shader wm_window_old
|
||
surface wm_windmill_sail shader wm_windmill_sail
|
||
surface wm_side1 shader wm_side1
|
||
surface wm_wind shader wm_wind
|
||
}</font>
|
||
|
||
//init section is not needed for this particular tiki, but is usually used to //define such things as particle systems that are used with this model
|
||
<font color=black>init
|
||
{
|
||
}</font>
|
||
|
||
|
||
//Animation Section
|
||
//NOTE! You absolutely must have an idle animation or the tiki will not //work in game. Even if the animation is a single frame animation that //appears to do nothing.
|
||
|
||
//Animations are named with aliases, then we point to the file that //contains the actual animation. You can create several aliases that //point to the same animation file if necessary.
|
||
|
||
//The client section I have within the <20>turn<72> animation has sound //attached to it that will play on the animation<6F>s 230th frame. There are //other valid commands that you can setup for use within the client //section of an animation. There are also other options for controlling //when the event occurs such as replacing the explicit frame 230 with a //command like <20>first<73>, <20>last<73>, <20>entry<72>, or any other valid frame number. //Refer to the client command list and tiki documentation for more //information.
|
||
|
||
<font color=black>animations
|
||
{
|
||
idle windmill_still.skc
|
||
|
||
turn windmill_turn.skc
|
||
{
|
||
client
|
||
{
|
||
230 sound safe_open
|
||
}
|
||
}
|
||
}</font>
|
||
|
||
</font>
|
||
</i>
|
||
</pre>
|
||
<br>
|
||
<b>It should be noted that the normal file structure for a tiki file is that the .TIK file resides in a directory above the directory that contains the data.</b> For example, our <i>windmill.tik</i> file should reside in:<br>
|
||
<br>
|
||
<b>/models/animate</b><br>
|
||
<br>
|
||
Whereas our actual data files (.skd, and .skc) for the model should reside in:<br>
|
||
<br>
|
||
<b>/models/animate/windmill</b><br>
|
||
<br>
|
||
<br>
|
||
|
||
<b><font size=+1>Seeing it ingame</font></b><br>
|
||
<br>
|
||
<br>
|
||
After prepping, exporting, compiling, and setting up your tiki, textures and shaders you should be ready to view your model ingame. Load up the game with the command line arguments:<br>
|
||
<br>
|
||
<b>Moh_spearhead.exe +set cheats 1 +set developer 1 +set thereisnomonkey 1</b><br>
|
||
<br>
|
||
Choose any level you see fit for viewing the model, and then pull down the console (tilde key), type in the command <b>pushmenu animate2</b>. The following dialog will be produced:<br>
|
||
<br>
|
||
|
||
<center>
|
||
<b><font size = -1>
|
||
Diagram 1-5
|
||
<br>
|
||
</font></b>
|
||
<img src="Exporting Animated Models/pushmenu_animate2.jpg">
|
||
</center>
|
||
<br>
|
||
<br>
|
||
Click the <b>spawn button</b> in this dialog and browse to your newly created tiki file. Your model should appear in game. You can then click the <b>PrevAnim</b> and <b>NextAnim</b> buttons to view the animations that have been set up in the tiki.<br>
|
||
<br>
|
||
If the model is textured in gray, or with weird colors, you probably have a mismatch in your surface definitions, your shader setup, or your texture files just can<61>t be found. Check the surface definition throughout your chain of files to verify things are as they should be.<br>
|
||
<br>
|
||
|
||
</p>
|
||
</body>
|
||
|
||
|
||
|
||
<p>
|
||
|
||
</p>
|
||
|
||
|
||
|
||
<pre>
|
||
<i><font color=blue>
|
||
|
||
</font>
|
||
</i>
|
||
</pre> |