Graviteam
May 19, 2013, 02:24:22 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Vehicles import tutorial  (Read 11058 times)
0 Members and 1 Guest are viewing this topic.
Iceman
Moderator
Oberstleutnant
*****
Posts: 138


*Graviteam* (Assistant Deputy Backup Courier)


« on: December 30, 2008, 07:15:50 PM »

Vehicles import tutorial (by Mikhayl)
________________
Here's Part 1 & 2. Part 3 coming soon  Smiley

Though most principles are valid for any object, the guide is really focused on tanks, especially the (coming soon) scripting part.
Any feedback and addition/correction be it for technical stuff or spelling is welcomed, at some point when it's complete enough I will make a .pdf version.

Tools needed

-Graviteam Ressource Unpacker and Object Editor : http://tanksim.org.ru/wfdownloads-viewcat.cid-16.htm (the first 2 in the list)
-A 3D studio that supports export in .x format
-notepad or similar
-JSGME : http://www.users.on.net/~jscones/software/products-jsgme.html

Tips before getting started

 • Try to use a clean install with only the required mod installed to avoid problems. If your mod is intended to work with Steel Panzer and Campaign Mod for example, then install only these two mods

 • Don't unpack unnessessary files, this can lead to some problems. Steel Fury allows multiple installs, I have a "modding" install in which all the .datapack files are unpacked so I can have a look at everything quickly if needed, but I test my mods only on a "normal" install as explained above.

Part 1: Modelling

That's the most important part, I'll not cover the actual modelling, only the Steel Fury specifics. There's some requirements for new models to be imported, you can't simply import any model.
Note that I'm using 3dsmax 2009 only so things might be slightly different for other 3D studios.

1.1 Polycount

The recommended triangle count (not polys) for vehicles is around 10.000 for the main LOD, 5000 for the 2nd LOD and 2500 for the 3rd LOD (I'll talk about LODs later). For interiors it's around 15.000 triangles, interiors have only one LOD.

However the game models are more like 20.000/25.000 triangles for the main LOD so there's some freedom here. From my very tiny experience I'd advise to start your model with 10k triangles in mind, and then polish the details. For example the stock Panzer IV has 37.000 triangles (that includes the 2 other LODs), but the spare track links alone are probably around 10.000 triangles.

Speaking of tracks, you don't need to model them. The game engine uses a code function to display a 2D track graphic that follows the movements of the wheels, this will be adressed in "Part 3 - Scripting".

Basically you can use the stock models as example to decide how detailed a given part should be. For example most wheels have 16 sides, smaller wheels 12 sides, most surface detail (rivets, plates) isn't represented in 3D, etc

1.2 Scene settings

In 3dsmax one default unit = 1 metre in Steel Fury
The world axis depends on the export settings as well and will probably be different depending on your 3D studio & exporter. Try to make a simple asymetric model pointing forward and see where it points in the SF Object Editor. Up on loading a *.go or *.x file you should always see the left side of the model (at least for the meshes in the "techn" folder).

Here's the scene settings I use and that works fine for me coupled with my export settings (check below in section 1.9):

Full size: http://i39.tinypic.com/28sc5jr.jpg

1.3 Interiors and sub-versions

It's very important to think about these from the very beginning of your new model. Multiple sub-versions can be imported in the same file, and then the scripting of the unit will determine which parts are hidden or shown for each version. For example you can load the Panzer IV in the SF Object Editor, you will see that it has two gun masks and two main guns overlapping.
At any rate it's fairly easy to separate different parts later on, but the earlier the better.

For interiors it's more critical. I will try to write a specific guide for interiors later (that is if I manage to finish one properly) but keep in mind that some things like the hatchs and guns are synchronized with their external counterpart, and that both exterior and interior are rendered together so you have to be careful not to have any part sticking in or out.
One example is for my hetzer, I started modelling it with only the exterior in mind and I thought I could model the interior only later. I took some shortcuts to model the gun mount, forgetting that on this tank this part is visible from inside. The result is that I'd have to remodel part of the exterior if I want to get the interior right.
So, I'd recommend to at least model the interior hull with the hatchs opening and eventually the moving parts of the guns, basically all the visual connections between the exterior and the interior.
If you don't plan to model an interior then you don't have to worry about it at all.

1.4 Model architecture

Models are broken down in several parts, for different purposes such as collision model and moving parts, and must be named accordingly. By observing existing models in the SF Object Editor you can get a quite precise picture of the whole thing.

There are basically 3 types of parts, we'll call them "fragments" (that's the name used by the game editor and scripts), which use different prefixes. I'll cover the first type here and the two other types in the 1.5 section.

 • d_**** fragments are for visual objects. For example "d_wheel_01", "d_light_02", "d_hatch_04" etc
Some visual objects use the "db_" prefix, usually that's only for hull and turret ("db_hull" and "db_head" ), and sometimes for the gun and gun mantlet as well ("db_gun" & "db_gun_mask"). I don't know the reason behind that, it's just that way.

1.5-Invisible fragments

 • p_**** fragments are for damage zones for systems and crew. For example "p_engine", "p_ammo", "p_driver" etc.
They are made of primitive boxes of the approximate size of the object they're supposed to represent. They can have complex shapes like "L" shapes but it's recommended to keep them simple boxes.

 • s_**** fragments are for several things such as camera viewports, crewmen positions, particle effect sources, markings etc. For example "s_camera_gunner_01", "s_trace_01" (source of a track mark on the ground), s_fire_01 (source for particle effect), "s_driver_out" (position of the driver when unbuttoned), "s_gun" (shell starting position + particle effect) etc.
These fragments are not actual objects, they are "dummies". Their size doesn't matter much, but try to make them 10cm/0.1units large. In 3dsmax there's no indication of the size of the dummies, so I just create a small box of the correct size and scale my dummy to match its size.

Here's where you find dummies in 3dsmax:


More detail on the different damage zones and dummies required will follow in "Part 2 - Import" and "Part 3 - Scripting", in the meantime you can take a look at a tank similar to the one you're modelling in the SF Object Editor to get and idea of the different elements needed.

1.6 Object links

Here I'm assuming that you have your model with most of its sub components and dummies.

First, the "linking" of the different parts. This is very easy, even more if you take an existing model as example.
In 3dsmax the "link" function is here:

To use it simply click on an object and drag the cursor to the object you want as parent.

Your "db_hull" object is the parent of all the other objects and dummies, which can have children themselves.
For example, all the "d_wheel_**" objects are linked to the hull and they have no children objects.
Another more telling example, the commander hatchs and the main gun are linked to the turret, which is in turn linked to the hull. So when the turret turns all its children follow. If you had the main gun linked to the hull then it would stay centered while the turret turns.

One simple test when you think you're done with the linking, select your hull and move it. If everything is linked properly all the objects and dummy should move along with the hull. Same for the turret, select it and make it rotate, and see if everything follows.

1.7 Pivot points

This part is very important at least for all the moving parts, hatchs, guns, wheels, turrets etc and dummies as well.

Here's where to change the pivot point of an object in 3dsmax:


There you have to make sure that your pivot point axis are correctly oriented, otherwise you will have very funky things in game, like a gun shell going 90° from where you're aiming, wheels turning like flipping coins, turrets rolling over and so on.

Here's the basic example with a wheel. Select one of your wheels, go to the "Pivot" menu, then select "affect pivot only", then click "center to object" if it's not already centered so that your wheel won't be wobbly, and then click on "align to world" so that your wheel will rotate on the proper axis.

The game engine makes the wheels rotate on the "lateral" axis which is the "x" axis on our scene. Here's what not to do:

here the pivot point "x" axis is corresponds to the "length" axis of our wheel. In game the wheel will flip like a coin, rotating around its own wrong "x" axis

Here's how it should be, after clicking on "align to world":


It's the same principle for other objects and dummies, except that for some objects like guns, turrets and hatchs, the pivot point isn't centered on the object, it's up to you to determine its position. Here's two examples of hatchs, they are oriented differently but their pivot point is the same.




Once the pivot point is set you can go back to normal object selection and move or rotate the object, the pivot point will remain the same. Make some tests and it becomes easy as pie.

1.8 UV-mapping, materials and textures

There's one important thing to keep in mind from the start, your vehicle can NOT use more than one material. A model with several materials will show OK in the SF Object Editor but in game all the objects will use the material used by the main object (db_hull here).
For example if your vehicle has a MG-34 mounted on it, its texture must be part of the main texture. If you assign it the existing "MG34" material with its separate texture it will only work in the Object Editor.

UV-mapping is as usual, since the textures are bump-mapped be careful when superposing different faces on the same part of the texture to avoid weird surface effect in game.

The textures are 2048*2048 with one "diffuse" texture and one bumpmap texture. For your "work in progress" textures you don't need the bumpmap, only the diffuse. The format doesn't matter, but the filename does. For example if you model a panther, just name your texture "PANTHER.tga" (in upper case) or whatever format you prefer for the moment. The name & upper case have to do with the scripting of the materials in game, I'll adress this in "Part 3 - Scripting".

Before exporting, select all your parts excepted the "p_****" and "s_****" fragments, and assign them a material using your texture with its simple name. This is to ensure that you don't need some tedious renaming when importing the model in the SF Object Editor.

1.9 Export settings
Models must be exported in .x format.
If you use 3dsmax I recommend the kW X-port plugin: http://www.kwxport.org/ (you must register to download it). I tried the Panda Soft exporter but IMO kW X-port is much better.

Here's a pic of the export settings I use, combined with my scene settings it exports my models just fine and ready to be imported in the SF Object Editor.



When your model is complete and all the objects and dummies are properly linked, you can select only the "db_hull" object and click "export selected", it will export it along with all the linked objects.

1.10 LODs

The LODs are based on your main model, that is, they must have the same architecture (links). However you don't need the damage zones nor the dummies for the LODs, excepted in some rare cases (look at the main gun of the StuG for example). Some objects can also be removed, just make sure that they're not the parent of an important part.

_______________
Big Thanks Mikhayl for this tutorial !
Original post here
« Last Edit: January 02, 2009, 07:24:52 AM by Iceman » Logged


дополнительный Помощник младшего Заместителя вспомогательного Курьера
Iceman
Moderator
Oberstleutnant
*****
Posts: 138


*Graviteam* (Assistant Deputy Backup Courier)


« Reply #1 on: January 02, 2009, 07:29:55 AM »

Part 2: Model import

2.1 Preparation and preliminary scripting

Now that we have a model ready to import, it's time to prepare things to allow us to test it in game.
The first step is to create a new mod folder for our playable unit, where we will put our imported model + its new textures + the script file needed for the new material.

Assuming that you're modelling a Panther, here's is the folder structure that you would need for now:


Your "New Unit" folder can be placed directly in your Steel Fury/MODS/ folder if you wish, but I'd recommend to place it on the desktop, and each time you want to test it in game, copy paste it in your Steel Fury/MODS/ folder, enable it, test it, when you're done testing disable it and resume work on the files on your desktop.

If you're modelling something else, just replace the "heavy" folder by "medium" or "light" for the textures, or even "spguns" or "apcs". Same in the "go" folder, you can change the "tank" folder for "apcs" or "spguns" or "trucks" etc to fill your needs.

Now we need to furnish our folders:

2.1a In game textures

If you look in the game texture folders (assuming they are unpacked from the various datapack files, otherwise they are hidden), you will see that there's 2 textures for each unit, "tbump_****_bump_c.dds" and "techn_****_c.dds".
So, open your texture, and save a copy of it as "techn_panther_c.dds". I use Gimp, usually I export my .dds images in dxt3 or dxt5 format (dxt1 doesn't support transparency). Whichever you choose, make sure your .dds texture is saved with mipmaps. If you open a game texture with Gimp you will have the main texture and several hidden layers with a scaled down copy of this texture, that's the equivalent of the LODs (if a unit is 1km away from you it's not necessary to have the full 2048*2048 texture loaded, the mipmaps are used instead).
If you don't have a bumpmap texture yet, just save a copy of your texture as "tbump_panther_bump_c.dds" for the moment.

2.1b Materials scripting

Now that we have the textures, we need to add the corresponding material so that the game knows it must use them. Go to Steel Fury/data/k42/loc_rus/config, and copy "matlib.engcfg" to the corresponding folder in your "New Unit" folder.
Open it with notepad, there you have the list of all the materials used in the game. Hit ctrl+F and try to find a material used by a unit similar to your new one, copy it and paste it at the end of the file. For instance let's copy the PZ4 material (here's the upper case from the work in progress texture) and edit it for your new unit as follow:

Quote
   PANTHER()
   {
      shader = editor;
      textures = panther, panther_bump, mudnburn;
      parent = TANK;

      diffuse = 1, 1, 1, 1;
      ambient = 0.301961, 0.301961, 0.301961, 1;
      emissive = 0, 0, 0, 0;
      specular = 0.996078, 0.996078, 0.996078, 1;

      power = 32;
      detail_tscale = 0;
      detail_scale = 0;
      bump_scale = 0.5;
      fresnel = 0;


   }// end of PANTHER

You can save and exit, your new material is now ready. Later on you will need to add new materials for an eventual interior texture, it's the same process, find a material for an existing interior, copy-paste it and modify it.
Something very important and very useful, the "//" are called "comments". The line written after a comment will not be read by the game, so you can use it to explain what you changed in a file so that another modder looking at it will easily understand. We will see a lot of these later in "Part 3 - Scripting".

2.2 How to use the SF Object Editor

The editor is fairly easy to use, most things have a small description when you mouse over.

Here's a short description of the most useful functions to import a model:


There is a tiny glitch, if you load a mesh and toggle on the "show frames" option, and then you load a different mesh, the frames are no longer shown. Simply toggle frames off and back on and it will fix it.

The tab on the right pops up when you put the mouse against the border of the screen, the "fragment" tab shows all the fragments of the model even the hidden ones. You can't select fragments from this tab.

The "select by name" button will pop up a list showing only the visible fragments of the model. Try to load the Panzer IV mesh, in the left tab near the bottom of the list you will see the different damage zones (p_****). If you look at the "select by name" list these fragments aren't here.

2.3 Importing models

This is straightforward, assuming that you made sure that you model has the proper architecture and material set.

First thing to do is to put a copy of your "New Unit" mod (at this point it's only textures + material) in your Steel Fury/MODS folder, and enable it with JSGME.

Now in the Object Editor, click on "File -> Import -> load from X...", and select your new model.
You should now see your textured model. If it's all red, it's because the material wasn't set properly in the model, make sure you followed the step 1.8. If your 3D studio porks the name of the material, you can change it manually in the SF Object Editor. Click on the "Select all" button, then go the right panel, click on the "materials" tab, browse until you find your new "PANTHER" material, and click the button with the two arrows (top left of the panel) to assign the material to all the selected objects.

full size: http://i41.tinypic.com/1hxfs2.jpg

Now toggle "show cage" on, then click on "select by name". Select all your "p_****" fragments (to select multiple objects just hold shift, then close the window), and click on the "hide" button.

Now go to "File -> Save as...", and save your model in "New Unit/Data/k42/loc_rus/go/techn/tanks/" or one of the other folders depending on your type of unit (apcs, spguns, trucks...). Keep the name simple and lower case, like "panther.go", "is2.go" etc

At this point your model will probably be missing a few things (or not) but nothing to worry about anyway, this will be covered in details in "Part 3 - scripting".

If you need to correct or add things to your model, simply re-export it from your 3D studio and repeat this step. Import from X, hide "p_****" fragments, and overwrite the previous "panther.go" file in your "New Unit" folder.

2.4 Importing LODs

The following is a copy/pasting from a post by Egorogr:

Quote
Another converting advice:
You can convert the whole model from .x to .go with all LODs by single operation. If you will name your LODs .x files like "nameL*", where "name" is the name of model and "*" is the number of LOD(i.e. "BT_7L1.x", "BT_7L2.x", "BT_7L3.x") and convert the first one by "F9", object editor will create several files: "nameL.go" and a number of "nameL*.go". The "nameL*.go" is just the .go version of the corresponding .x. And "nameL.go" consists of all LODs. So we need this one and we can delete others.
I'm not sure on the names for .x file here though, cause it seems that "nameL*.go" files are not needed for the game and should not be created during convertion.

Use Numpad "+" and "-" in the objects editor to cycle through LODs.

As of yet I haven't been able to make it work, "F9" doesn't seem to work at all for me. On the other hand, I don't have any proper LOD finished (low poly + proper architecture) so it doesn't help, I will post more on the subject as soon as I can make proper tests and see if it works for me.
_______________
Big Thanks Mikhayl for this tutorial !
Original post here
« Last Edit: January 02, 2009, 07:33:30 AM by Iceman » Logged


дополнительный Помощник младшего Заместителя вспомогательного Курьера
Iceman
Moderator
Oberstleutnant
*****
Posts: 138


*Graviteam* (Assistant Deputy Backup Courier)


« Reply #2 on: January 02, 2009, 07:32:22 AM »

Part 3: Scripting

Coming soon

3.1-Folders and files needed

3.2-Adding formations using new units to use in missions

3.3-Cloning an existing mission to test new units

3.4-Vehicle

3.5-Crewmen

3.6-Fake Interior

3.7-Interface

_______________
Big Thanks Mikhayl for this tutorial !
Original post here
Logged


дополнительный Помощник младшего Заместителя вспомогательного Курьера
Iceman
Moderator
Oberstleutnant
*****
Posts: 138


*Graviteam* (Assistant Deputy Backup Courier)


« Reply #3 on: May 27, 2009, 06:11:04 PM »

Short manual, Objects in Steel Fury :

from Andrey (Graviteam)

1) Convert model (+lods if exist) to X file format (text)
2) Rename files like this
mymodl1.X - for lod #1
mymodl2.X - for lod #2
mymodl3.X - for lod #3
...
mymod - your model name, l1, l2, l3 - lod suffix

3) Start editor - press F9 key - and change any file ..l1.x, ..l2.x etc

important! model must have 1 chunk - name it - "d_obj"

after conversion:
1) opened (automaticaly) text file with results (in russian)
- check is correct file names of lods (in top of file)
2) in directory with .X files - new converted files - with .go extensions
3) in editor - open .go file without lod number - only with l letter before ".go"
Ctrl+O - shortcut

after - file viewed in red
4) Select all chunks - Ctrl+Shift+A (shortcut)
5) Select Materials tab (right) - first tab - select object material - and press << button
6) Save new file - Ctrl+S shortcut - mymod.go - without ‘l‘ letter

chapter 2.1b Materials scripting


Code:
MYMOD() //always BIG letters in name
{
shader = editor;
textures = mymod, mymod_bump; //diffuse and spec/bump texture
parent = ;

diffuse = 1, 1, 1, 1; //diffuse modulate color
ambient = 0.301961, 0.301961, 0.301961, 1;//unused
emissive = 0, 0, 0, 0; //unused
specular = 0.996078, 0.996078, 0.996078, 1;//first number - specular level modulation

power = 32; //specular flare size
detail_tscale = 0;
detail_scale = 0;
bump_scale = 0.5;
//roughtness level 0 - flat, 2 - rought
fresnel = 0;

}// end of MYMOD
// - my comments
ok
textures - DDS format (2.1a chapter in manual)

Part 3 using

1) levelslevelsobj_cfg - objects description
You need unpacked configs

in objects directory - config files
posts.engcfg, fences engcfg etc
make copy one from it

Code:
object block:
mymod()
{
...//params
}
remove all from copied config (1 save)
and change params:
mesh - mesh name w/o extension - change to mymod

Code:
subblock: col_bounds - it is a collision primitives
col_bounds
{
d_obj, 0, 0, false;
}
your model chunk must have name - d_obj

for sandbags:
Code:
dynamic = false

Code:
center_mass = d_obj
important! don‘t miss ‘;‘ symbols in end of line
Code:
armor_map = armor_mapsobjsmyobj_armor.tga
myobj_armor.tga - A8R8G8B8 32 bit format TGA - all channels are identical - alpha channel is white - it is armor map - color level is a ‘steel equivalent‘ in mm
level 20 for example - has identical protection like homogeneus steel plate - 20 mm (not armor plate 20mm)
armor map maps to model like regular texture map - if you have make a hole - draw in armor map with black color

Part 4 work in polygon editor/generator

you need unpacked file levelsenvsshared.engcfg
1) find block ‘me_objects‘
2) add new line at end

Code:
//config file, object block name (object name), sprite in editor view
obj_cfgobjs.engcfg, block, barrage

3) sprites:
barrage
build
fence
post
object

4) Add this objects in polygon editor like zone properties
important! unpack and repack shared.engcfg to game data pack
if you don‘t do this - after creating new mission or polygon - game engine automaticaly unpacked this file from pack and replace your (changed) file

in short:
1) add material
2) convert mesh
3) make config
4) add to editor
Logged


дополнительный Помощник младшего Заместителя вспомогательного Курьера
lockie
Moderator
Generalfeldmarschall
*****
Posts: 1066


Email
« Reply #4 on: March 17, 2012, 01:17:04 PM »

I'd recommend to add to the block col_pts the next parameter s_gun, i.e.:
Code:
//points of contact with a ground
col_pts()
{
//chank, quantity og points, three signs
db_hull,  4,   1, 0, 1,   1, 0, -1,  -1, 0, 1,  -1, 0, -1;
db_head,  4,   1, 1, 1,   1, 1, -1,  -1, 1, 1,  -1, 1, -1;
s_gun,  1,   0, 0, 0;

}
In this way, it enables to decrease tanks bumping to each other.
Logged

I like shoot the bricks.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.8 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!