Vehicles import tutorial (by Mikhayl)
________________
Here's Part 1 & 2. Part 3 coming soon
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
Resource Unpacker and
Object Editor-A 3D studio that supports export in .x format
-notepad or similar
-JSGME :
http://www.users.on.net/~jscones/software/products-jsgme.htmlTips 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: ModellingThat'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 PolycountThe 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 settingsIn 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.jpg1.3 Interiors and sub-versionsIt'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 architectureModels 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 linksHere 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 pointsThis 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 texturesThere'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 settingsModels
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 LODsThe 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