FreeSpace Wiki - User contributions [en]

Blender to POF Conversions

2011-03-10T07:54:30Z

VA: Oops.

==Important Links & Video Tutorials:==
[[Blender]] [[POF Constructor Suite 2]] [[POF to Blender Conversions]] [[Collada Importer]] 
Rga_Noris has started creating video tutorials on the Blender -> POF conversion process which explains it step by step: [http://www.hard-light.net/forums/index.php?topic=75005.0 Thread link]

==Getting a Collada-capable PCS2 version:==
# [http://www.cse.unsw.edu.au/~samm/pcs2.7z Download the main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://www.cse.unsw.edu.au/~samm/dlls.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like. (Old link, Optional)
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too. (Old link, Optional)

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions#Correcting for the Blender DAE Importer's slight bug:]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. However, you can set Blender's Collada exporter to do this for you on exporting - that way, you can keep your blendfile in quads. 
If you do want to triangulate something manually, use Ctrl+T to triangulate selected. 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
With the bottom-most button "Apply modifiers", you can apply all modifiers on exporting - if you're on an older version of Blender, you have to do this by hand, or you'll end up with half your model or something. Do consider updating in that case. 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game. 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ).

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one Empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

(Note: The following image was taken when the key phrase was 'insg' rather than 'insig' as it is now. Use 'insig' not 'insg'!)
 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

===Esarai's Solution to Unapplyable Empties===
Occasionally, Blender experiences a glitch where its program-defined 'Empty Object' cannot be applied. Applying an object is done by pressing ctrl+a. It makes the current scale of the object 1 on all axises, and sets its rotation to 0 on all axises. Occasionally, Blender fails to set the rotation to 0 and the scale to 1 after pressing ctrl+a, causing those values to be carried into the dae file. PCS2 treats the current orientation of an object as it's original orientation, and then applies any rotation or scaling data to the object, causing all objects to be scaled and rotated twice as much as they should be. If you notice this occurring with empty objects, you must ensure you are modeling all parts of your ship at the dimensions and rotations they are supposed to appear with in-game (this can be problematic for ships greater than 3 km in length as Blender will have trouble occluding faces not visible in the 3D view, making selecting the appropriate face difficult). These issues can be avoided by creating a stand-in for the empty objects. To do this, create a new mesh object. What kind of object does not matter. Create it and delete all geometry data within the object (enter editmode, select all vertices, and delete them. The object will appear as a pink dot now). This object, while not technically an "empty object," can function as one, and can always be applied.

Just as an example: Say you were to rotate a cuboid turret 45 degrees about the z-axis, select the whole turret setup and associated helper hierarchy and press 'ctrl+a' to apply it. You'll know you are encountering this glitch if the turret now has zero angle rotation on all axises and the scale has been reset to 1, but the helper Empties still have non-one scale and/or non-zero rotation values. In PCS2, these values will be applied to the helpers, and your turret firepoints may end up several kilometers from the weapon barrels. 

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2011-03-10T07:51:49Z

VA: Link to Rga's video tutorial thread. Hopefully these will eventually explain everything this document does! :)

==Important Links:==
[[POF to Blender Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]
Rga_Noris has started creating video tutorials on the Blender -> POF conversion process which explains it step by step: [http://www.hard-light.net/forums/index.php?topic=75005.0 Thread link]

==Getting a Collada-capable PCS2 version:==
# [http://www.cse.unsw.edu.au/~samm/pcs2.7z Download the main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://www.cse.unsw.edu.au/~samm/dlls.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like. (Old link, Optional)
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too. (Old link, Optional)

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions#Correcting for the Blender DAE Importer's slight bug:]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. However, you can set Blender's Collada exporter to do this for you on exporting - that way, you can keep your blendfile in quads. 
If you do want to triangulate something manually, use Ctrl+T to triangulate selected. 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
With the bottom-most button "Apply modifiers", you can apply all modifiers on exporting - if you're on an older version of Blender, you have to do this by hand, or you'll end up with half your model or something. Do consider updating in that case. 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game. 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ).

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one Empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

(Note: The following image was taken when the key phrase was 'insg' rather than 'insig' as it is now. Use 'insig' not 'insg'!)
 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

===Esarai's Solution to Unapplyable Empties===
Occasionally, Blender experiences a glitch where its program-defined 'Empty Object' cannot be applied. Applying an object is done by pressing ctrl+a. It makes the current scale of the object 1 on all axises, and sets its rotation to 0 on all axises. Occasionally, Blender fails to set the rotation to 0 and the scale to 1 after pressing ctrl+a, causing those values to be carried into the dae file. PCS2 treats the current orientation of an object as it's original orientation, and then applies any rotation or scaling data to the object, causing all objects to be scaled and rotated twice as much as they should be. If you notice this occurring with empty objects, you must ensure you are modeling all parts of your ship at the dimensions and rotations they are supposed to appear with in-game (this can be problematic for ships greater than 3 km in length as Blender will have trouble occluding faces not visible in the 3D view, making selecting the appropriate face difficult). These issues can be avoided by creating a stand-in for the empty objects. To do this, create a new mesh object. What kind of object does not matter. Create it and delete all geometry data within the object (enter editmode, select all vertices, and delete them. The object will appear as a pink dot now). This object, while not technically an "empty object," can function as one, and can always be applied.

Just as an example: Say you were to rotate a cuboid turret 45 degrees about the z-axis, select the whole turret setup and associated helper hierarchy and press 'ctrl+a' to apply it. You'll know you are encountering this glitch if the turret now has zero angle rotation on all axises and the scale has been reset to 1, but the helper Empties still have non-one scale and/or non-zero rotation values. In PCS2, these values will be applied to the helpers, and your turret firepoints may end up several kilometers from the weapon barrels. 

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2011-02-17T16:26:48Z

VA: /* Insignia: */ Note on pic.

==Important Wiki Page Links:==
[[POF to Blender Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]

==Getting a Collada-capable PCS2 version:==
# [http://www.cse.unsw.edu.au/~samm/pcs2.7z download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://www.cse.unsw.edu.au/~samm/dlls.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like. (Old link, Optional)
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too. (Old link, Optional)

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions#Correcting for the Blender DAE Importer's slight bug:]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ).

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one Empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

(Note: The following image was taken when the key phrase was 'insg' rather than 'insig' as it is now. Use 'insig' not 'insg'!)
 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

===Esarai's Solution to Unapplyable Empties===
Occasionally, Blender experiences a glitch where its program-defined 'Empty Object' cannot be applied. Applying an object is done by pressing ctrl+a. It makes the current scale of the object 1 on all axises, and sets its rotation to 0 on all axises. Occasionally, Blender fails to set the rotation to 0 and the scale to 1 after pressing ctrl+a, causing those values to be carried into the dae file. PCS2 treats the current orientation of an object as it's original orientation, and then applies any rotation or scaling data to the object, causing all objects to be scaled and rotated twice as much as they should be. If you notice this occurring with empty objects, you must ensure you are modeling all parts of your ship at the dimensions and rotations they are supposed to appear with in-game (this can be problematic for ships greater than 3 km in length as Blender will have trouble occluding faces not visible in the 3D view, making selecting the appropriate face difficult). These issues can be avoided by creating a stand-in for the empty objects. To do this, create a new mesh object. What kind of object does not matter. Create it and delete all geometry data within the object (enter editmode, select all vertices, and delete them. The object will appear as a pink dot now). This object, while not technically an "empty object," can function as one, and can always be applied.

Just as an example: Say you were to rotate a cuboid turret 45 degrees about the z-axis, select the whole turret setup and associated helper hierarchy and press 'ctrl+a' to apply it. You'll know you are encountering this glitch if the turret now has zero angle rotation on all axises and the scale has been reset to 1, but the helper Empties still have non-one scale and/or non-zero rotation values. In PCS2, these values will be applied to the helpers, and your turret firepoints may end up several kilometers from the weapon barrels. 

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Subsystem

2011-02-14T08:09:06Z

VA: /* $Flags: */ - added new "no aggregate" flag

{{Fileversion|6921}}

*All subsystems ship can have must be defined in ships model file (.pof).

{{Table3610|
*[[Animation_Code|Animation Code]] can be applied to the subsystems that consist of submodels, like multi-part turrets.}}

==$Subsystem:==
*The name of the subsystem as defined in .pof file, % of ship's total hitpoints the subsystem has and rotation time (360 degrees) for multi-part turrets. Note: Assinging zero to the %-hitpoint entry causes the subsystem to be without hitpoints, like fighterbays on some capital ships.
*Syntax: '''''String''''', '''''Float''''', '''''Float''''', name of the subsystem followed by the subsystem hitpoints as % of ships hitpoints and seconds per 360 degree turn. Subsystem name must be the same as described in model file (.pof).
{{Table3610|
*Entries can be left empty in which case game uses default values}}
**Example: communications, 5, 0.0

===$Alt Subsystem Name:===
{{Table3610|
*Defines the alternate name for the subsystem. This name is shown for example in the targeting window when subsystem is targeted.
*Syntax: '''''String'''''}}
{{Table3611|
*Option to use pipe character '<nowiki>|</nowiki>' to force line breaks into the alt subsystem name}}

===$Alt Damage Popup Subsystem Name:===
{{Table3611|
*Defines the alternate name for the subsystem when it is displayed on the '''damaged systems''' popup.
*Syntax: '''''String'''''}}

===$Armor Type:===
{{Table3610|
* '''REQUIRES ADDITIONAL TABLE'''. Defines armor type used for the subsystem. If subsystem armor type is not defined ships armor type is used instead.
* Syntax: '''''String''''', as defined in [[armor.tbl]]}}

===$Default PBanks:===
*Defines default primary weapon for the turret
*Syntax: ( '''''"String"''''' )
**Example: ( ''"Subach HL-7"'' )

===$PBank Capacity:===
{{Table3610|
*Defines ammunition capacity of turrets ballistic primary weapon.
*Syntax: ( '''''Integer''''' )}}

===$Default SBanks:===
*Defines default secondary weapon for the turret
*Syntax: ( '''''"String"''''' )

===$SBank Capacity:===
*Defines ammunition capacity of turrets secondary weapon.
*Syntax: ( '''''Integer''''' )

===$Engine Wash:===
*All engines may use information concerning the engine wash. Engine washes are usually used only with larger vessels.
*Syntax: '''''String''''', name as defined in Engine Wash section in [[ships.tbl]]
**Example: ''Default1000''

===$AliveSnd:===
{{Table3610|
*Specifies a sound to play from the subsystem while it is not destroyed.
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===$DeadSnd:===
{{Table3610|
*Specifies a sound to play from the subsystem while it is destroyed.
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===$RotationSnd:===
{{Table3610|
*Does nothing for now
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===$Turret Base RotationSnd:===
{{Table3611|
*Defines the sound which is played when the turrets base rotates
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===$Turret Gun RotationSnd:===
{{Table3611|
*Defines the sound which is played when the turrets guns change their elevation
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===$Turret BaseSnd Volume:===
{{Table3611|
*Defines the multiplier for the sound volume for turret base rotations
*Syntax: '''''Float'''''}}

===$Turret GunSnd Volume:===
{{Table3611|
*Defines the multiplier for the sound volume for turret guns change their elevation
*Syntax: '''''Float'''''}}

===$AWACS:===
*Sets this subsystem's effective AWACS range. (AWACS reveals stealthed ships, cuts through nebula fog.)
*Syntax: '''''Float''''', the maximum range of the AWACS

===$Maximum Barrel Elevation:===
{{Table3611|
*Defines the maximum barrel elevation for the turret
*Basically 'inverse FOV'.
*Syntax: '''''Integer''''', from 0 to 90}}

===$Turret Base FOV:===
{{Table3611|
*Defines the FOV of the turret's base.
*Syntax: '''''Integer''''', from 0 to 359}}

===$Turret Reset Delay:===
{{Table3611|
*Defines the time after losing the target before the turret begins to reset itself
*Syntax: '''''Integer''''', in milliseconds}}

===$Turret Optimum Range:===
{{Table3611|
*Defines the optimum range for the turret
*Syntax: '''''Float'''''}}

===$Turret Direction Preference:===
{{Table3611|
*Defines the turrets preference to keep targeting targets based how far the turret should turn instead of nearest target
*The higher the value the higher the preference to keep targeting targets close to previous targets direction
*Syntax: '''''Integer''''', from 0 to 100, 0 disables the preference setup}}

===$Target Priority:===
{{Table3611|
*Defines the target priorities, and their order for the turret
*Syntax: '''''String list'''''}}

===$ROF:===
{{Table3613|
*Defines the modifier applied to the turret rate of fire (ROF).

====+Use firingpoints====
*Modifies (multiplies) the rate of fire by the number of firingpoints the turret has.

====+Multiplier:====
*Checked only if ''+Use firingpoints'' has not been defined
*If set to larger than 0 the value acts as multiplier
*If set to 1.0 the feature is disabled
*If set to equal to or smaller than 0 it as if ''+Use firingpoints'' option would have been enabled
*Syntax: '''''Float'''''}}

===$Flags:===
{{Table3610|
*Can be used to sets additional subsystem related properties
*Syntax: ( '''''"String" "String"''''' )
*List of available flags:

===="untargetable"====
*Subsystem cannot be targeted

===="carry no damage"====
*Damage caused to the subsystem will not carry over to the parent ship

===="use multiple guns"====
*Enables the turret to fire all equipped weapons, picking a not-in-use firing point at each trigger. Not to be confused with 'Salvo mode'.

===="fire down normals"====
*Forces the turret to fire along the turret normals - regardless of the swarm setting.

===="check hull"====
*Forces the firing turret to check against the parent model if valid line of sight exists between the firingpoint and the target.}}

{{Table3611|
===="fixed firingpoints"====
*Forces the firing turret to retain the firingpoints of their weapons. Maximum number of weapons is the same as maximum number of weapons in turret (3 primary, 4 secondary)

===="salvo mode"====
*Forces the firing turret to use only the first weapon defined for it but fires it simultaneously from all the firing points. Not to be confused with 'use multiple guns'

===="no subsystem targeting"====
*Prevents the firing turret from targeting targets subsystems - instead forces the turret to fire randomly at the targets hull.

===="fire on target"====
*Prevents the turret from firing unless the turret barrels (firingpoints) and targets are aligned.

===="reset when idle"====
*Forces the turret to reset to its initial position if it has no targets.

===="carry shockwave"====
*Forces the turret to carry damage caused by shockwaves to the hull regardless of other flags.}}

{{Table3613|
===="allow landing"====
*Defines the subsystem as something on which player can attempt to land on

===="target requires fov"====
*Prevents turret from accidentally selecting target out of it field of view (fov) when acquiring targets

===="fov edge checks"====
*If the predicted target point of the turret falls outside of the field of view this flag but according to ship radius and dot product the target should still be partially visible then this flag attempts to turn the turret to the edge of the FOV closest to the targeted position and allow it to fire along that direction.

===="no replace"====
*Tells game not to use the replacement submodel (-destroyed) when the subsystem loses all of it's hitpoints.

===="no live debris"====
*Prevents the subsystem from releasing live debris pieces when destroyed

===="ignore if dead"====
*When subsystem has been destroyed prevents homing weapons from attempting to hit the now destroyed submodel and instead tells them to home on the main hull of the target

===="allow vanishing"====
*Allow subsystem to be destroyed from the ship without sound or graphical effects

===="damage as hull"====
*Treats subsystem as if it were hull when applying damage.

===="starts locked"====
*Turret starts locked and won't shoot until you use a turret-free or turret-free-all SEXP on it.

===="no aggregate"====
*Freespace keeps track of a ships overall functionality (such as if a ship is sensorless, disarmed or disabled) via a total hitpoint count of the associated subsystems. For example if a ship has three engines with 100HP each, the 'engines' count will be at 300HP. Shooting at any of the subsystems with the keyword 'engine' in them will decrement this total, and when it is at 0 then the ship becomes disabled.
*This flag tells FS to ignore the associated subsystem and not count it towards those totals. For example, if a ship had three 100HP engines with one set to 'no aggregate' then the 'engines' count will be 200HP. Shooting the 'no aggregate' engine will not decrement the 'engines' count, and so in other words the status of this engine is irrelevant to whether or not the ship is disabled. In the same way when applied to a turret, the turret's status is irrelevant to whether the ship is disarmed or not.

}}

===[[Animation Code]]===
{{Table3610|
*Option for animating the submodels}}

==Case Specific Entries==

===Turret===
*All turrets require information concerning the weapon mounted to the turret. The entry can be either '''$Default PBanks''' for turret primaries (including beams) or '''$Default SBanks''' for turret secondaries
{{Table3610|
*[[Animation_Code#Setting_Turret_Angle|Animation Code]] can be used with multi-part turrets.
*Multiple defined weapons will all fire but the targetting is handled by the first weapon in the list. '''Multiple beams are not possible'''. All weapons alternate between the firingpoints of the turret so turrets do not need to have more than one weapon defined no matter how many barrels or firingpoints they have.}}

====Example====

<pre>
$Subsystem: turret01, 1.0, 1.0
$Default PBanks: ( "Terran Turret" )
</pre>

===Engine===

====Example====

<pre>
$Subsystem: engine01, 5.0, 0.0
$Engine Wash: Default1000
</pre>

[[Category:Tables]]

Blender to POF Conversions

2010-06-02T11:14:24Z

VA: Possibly temporarily moved the note about empties down to the bottom due to confusion. Will PM Esarai for clarification!

==Important Wiki Page Links:==
[[POF to Blender Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]

==Getting a Collada-capable PCS2 version:==
# [http://sourceforge.net/projects/alliance/files/POF%20Constructor%20Suite/2.0.3/PCS2_2.0.3_2008-05-15.exe/download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like.
# [http://the158th.hard-light.net/spicious/libcollada14dom21.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too.

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions#Correcting for the Blender DAE Importer's slight bug:]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ).

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one Empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

===Esarai's technique regarding empties===
Do note that the Empty object cannot have any data applied to it. This means that if you are to rotate or scale it, you will not be able to 'apply' those changes, and that scale value will be carried into the dae and pof files, causing very strange distortions of your firepoints. If you do use Empties, you must ensure your model is at 1:1 scale ratio with in-game appearance, or that you are going to model at that scale. If you find that working on smaller scales and then scaling the entire model up is easier (and avoids the strange geometry drawing errors blender experiences with models several km long), a better alternative is to create a new plane, enter edit mode, select all vertices and delete them. This creates an object that will function like an Empty, but can be "applied," allowing you to commit scale and rotation changes without having to realign all the normals appropriately, and will allow you to scale and apply the entire model, helpers included.

Just as an example: Say you were to rotate a cuboid turret 45 degrees off of forward, select the whole turret setup and associated helper hierarchy and press 'ctrl+a' to apply it. You'll notice that the turret now has zero angle rotation on all axises and the scale has been reset to 1, but the helper Empties still have their scale and rotation values. In PCS, we will see these values applied to the helpers, and your turret firepoints may end up several kilometers from the weapon barrels. This can be avoided if you use no-geometry mesh objects as described above. 

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-08-01T11:49:25Z

VA: More specific link

==Important Wiki Page Links:==
[[POF to Blender Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]

==Getting a Collada-capable PCS2 version:==
# [http://sourceforge.net/projects/alliance/files/POF%20Constructor%20Suite/2.0.3/PCS2_2.0.3_2008-05-15.exe/download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like.
# [http://the158th.hard-light.net/spicious/libcollada14dom21.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too.

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions#Correcting for the Blender DAE Importer's slight bug:]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

POF to Blender Conversions

2009-08-01T11:46:56Z

VA: The counterpart to the Blender to POF conversions!

==Important Wiki Page Links:==
[[Blender to POF Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]

==Getting a Collada-capable PCS2 version:==
# [http://sourceforge.net/projects/alliance/files/POF%20Constructor%20Suite/2.0.3/PCS2_2.0.3_2008-05-15.exe/download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like.
# [http://the158th.hard-light.net/spicious/libcollada14dom21.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too.

==Exporting the DAE out of PCS2:==
Open PCS2, and then go to File -> Open and locate the POF file you want to convert to DAE and open up in Blender. Once it has opened successfully, save it by going to File -> Save and change the file type to DAE.
 
By default PCS2 will save your DAE with 'helpers' (Empties as Blender knows them by) that represent almost all the POF data. Unfortunately Blender has a lot of trouble with long helper names (such as subobject properties) being truncated. This limits the usefulness of importing the POF data in the first place, and it is usually much simpler not to export this data and either import it from the old version of the POF once you convert it back, or rebuild it entirely in PCS2.
 
To tell PCS2 to export DAEs without any helpers, go to Options -> Preferences and UNCHECK "Export helpers to DAE". If you just want everything except the troublesome subobject properties, CHECK "Export helpers to DAE" and UNCHECK "Export properties as helpers".
 
Incidentally you do not need to worry about mirroring any DAE axes if you noticed those three checkboxes to the right of the aforementioned ones. Those are to correct for other DAE importers in other 3d applications, but Blender should get these axes the right way round.

==Recommended Blender DAE Import Settings:==
In Blender, to import an existing DAE, go to File -> Import -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaImporterSettings.jpg]] 

==Correcting for the Blender DAE Importer's slight bug:==
There is a small bug in the DAE import script in Blender where it tends to create at least one extra scene besides the original scene no matter what your importer settings are. (And some settings other than the previously recommended ones currently cause the import to fail)
 
To switch between active scenes use this dropdown menu:
 [[Image:BlenderSceneDropdownMenu.jpg]] 
Usually after a DAE import it will look like this:
 [[Image:BlenderSceneFixes.jpg]] 
 So in more detail:
# Select "Scene" from the dropdown menu. Your scene will probably switch back to the default Blender scene with the cube, camera and lamp.
# Press the black X on the right hand side of the Scene dropdown list and confirm to delete it.
# Do the same for "Scene.001"
# KEEP "Scene001" as this is the scene with your imported model in it. I like to rename it back to "Scene" just in case but I don't think this is nessecary.
 
NOTE: If you ever find you have components of ship spread over multiple scenes, selecting the wayward objects and pressing Ctrl + L -> Make link to scene -> selecting the desired destination scene will allow you to reunite them with the rest of your ship.

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-08-01T11:05:25Z

VA: Common Links

==Important Wiki Page Links:==
[[POF to Blender Conversions]], [[Blender]], [[POF Constructor Suite 2]], [[Collada Importer]]

==Getting a Collada-capable PCS2 version:==
# [http://sourceforge.net/projects/alliance/files/POF%20Constructor%20Suite/2.0.3/PCS2_2.0.3_2008-05-15.exe/download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like.
# [http://the158th.hard-light.net/spicious/libcollada14dom21.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too.

==Recommended Blender DAE Import Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Important Note for those who imported an existing FS2 model via DAE:===
Unfortunately due to a bug in the import script in Blender, imported DAE models are always imported into a new scene, but during DAE export only the first scene is looked in. The fix is an easy one - see [[POF to Blender Conversions]] for more information.

===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

File:BlenderSceneFixes.jpg

2009-08-01T10:50:05Z

VA: Demonstrates the steps needed to correct the scene list bug caused by importing a DAE into Blender.

Demonstrates the steps needed to correct the scene list bug caused by importing a DAE into Blender.

File:BlenderSceneDropdownMenu.jpg

2009-08-01T10:48:51Z

VA: Shows the location of the scene dropdown menu in Blender.

Shows the location of the scene dropdown menu in Blender.

File:BlenderColladaImporterSettings.jpg

2009-08-01T08:05:16Z

VA: The recommended import settings when opening up a DAE file in Blender

The recommended import settings when opening up a DAE file in Blender

Blender to POF Conversions

2009-07-31T00:24:57Z

VA: Added section on how to GET a collada capable PCS2

==Getting a Collada capable PCS2 version:==
# [http://sourceforge.net/projects/alliance/files/POF%20Constructor%20Suite/2.0.3/PCS2_2.0.3_2008-05-15.exe/download The main PCS2 installer package] Install this first so you have the correct DLLs in place in your PCS2 directory.
# [http://scoobydoo.freespacemods.net/Completed/Misc/pcs2.exe The DAE capable PCS2 EXE itself] Place this in your PCS2 directory, backing up the previous one if you like.
# [http://the158th.hard-light.net/spicious/libcollada14dom21.7z Dependency 1: The libcollada DLL file] Place this in your PCS2 directory.
# [http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en Dependency 2: The Microsoft VC2008 SP1 Runtime] You might already have this installed from some other program, but if not you'll need this installed too.

==Recommended Blender Export Settings:==
In Blender, once you are ready to export, go to File -> Export -> Collada 1.4(DAE) and it is advisable to use the following options:
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the DAE file into PCS.

==Importing the DAE into PCS2:==
Open PCS2, and then go to File->Open and locate your ready-to-open DAE file. Depending on the complexity of your model this could take a fraction of a second to a minute or so. Also remember that once this import is complete, you will still need to save the POF file somewhere, and it is during this part of the process that most errors occur. It is strongly advised that you do not begin adding POF data to a converted model until after it has successfully saved as POF first.

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-07-11T13:05:39Z

VA: /* Single-part Turrets: */ illustrated the .XXX thing with a second turret in the example

==Recommended Export Settings:==
Once you are ready to export, go to File -> Export -> Collada 1.4(DAE)
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the .dae file into PCS.

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
| |
| |-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
| |
| |-firepoints01
| | |
| | |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| | |-firepoint2
| |
| |-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| | |
| | |-Path07-01
| | |-Path07-02
| |
| |-properties01
| |
| |-$fov=180
| |-$name=laser_turret
| |-$special=subsystem
|
|-turret02
|
|-helper02 (NOTE: The number after 'helper' is really just there for your own organisation)
| (ie. helper02 is for turret02)
|-firepoints02
| |
| |-firepoint1.001 (NOTE: the .001 part is just there to keep each object name unique in Blender)
| |-firepoint2.001 (The importer will disregard everything after the '.' so don't worry about it)
|
|-path08 (NOTE: Each turret will require it's own approach path, but these can be generated in PCS2)
| |
| |-Path08-01
| |-Path08-02
|
|-properties02
|
|-$fov=180.001
|-$name=laser_turret.001
|-$special=subsystem.001

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-07-11T12:49:29Z

VA: /* Insignia: */

==Recommended Export Settings:==
Once you are ready to export, go to File -> Export -> Collada 1.4(DAE)
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the .dae file into PCS.

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here, but the NAME is important because the Collada importer in PCS2 will know to ignore it and not put it on the texture list for the ship), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-07-11T12:47:45Z

VA: /* Insignia: */

==Recommended Export Settings:==
Once you are ready to export, go to File -> Export -> Collada 1.4(DAE)
 [[Image:BlenderColladaExporterSettings.jpg]] 

Be aware that selecting the option "Only Export Selected" will cause the Collada exporter to drop all hierarchy information. This will cause extreme pain when importing the .dae file into PCS.

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

It should be noted that when making a ship with more than one turret in Blender, you will need more than one empty object named "firepoint01." Because of how blender handles duplicate objects, it is impossible for it to have two objects with the same name, and as such pastes a .xxx (object.001, object.002, and so on) on the end of the object name to keep them separate. This additional tag is nothing to be worried about, as the system will disregard anything past the '.' .

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As the XX indicates, you can create insignia that will appear on LODs too, which is a good idea or else in-game your insignia will suddenly vanish when the ship moves away and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender

2009-05-15T04:21:18Z

VA: Updatified

'''Blender''' is a free, open source 3D modelling program that has been in continual development for the past several years. Though not as commonly used in the community as 3D Studio Max and Caligari [[trueSpace]], Blender does have a solid support base on the net and has been used successfully to create many models in FS2, including many of the HTL upgrades of Volition models. 

With PCS2 ([[POF_Constructor_Suite_2]]) and the Collada supporting version ([[Collada_Importer#How_to_Get_Collada_Support]]), Blender has become a one-stop tool for creating FS2 models. (Ignoring whatever 2D application you use for creating textures!) For information about how to set up your model for conversion via DAE, see: [[Blender_to_POF_Conversions]] 

Blender is available for most common operating systems, such as Microsoft Windows, MacOS, Linux, FreeBSD and even Pocket PC. Even though Blender is free, it is arguably as powerful as many commercial 3D software tools, given certain restrictions.

==Mini-Tutorial-Feature-Guide-Thing!==

Ok, what I'll do here is write up an overall guide on how things work with blender. I won't handle all the ins and outs of getting a model textured and into FS just yet - that's a much bigger job. Just stick with learning to build ship meshes for now.

===Interface Stuff===

Right, when you start up Blender, you'll see your start screen with the 3d window being the big main one, and another window with a control panel along the bottom. This can be completely customised to suit whatever viewing needs you have. For example, I have a dual screen setup, and I use my left monitor as ONLY a 3d window, and my right hand screen with my control panel down the bottom and usually the UV mapping window above that. 

The active window is whichever one the cursor is hovering over - so you can't for example rotate the 3d view unless your cursor is over that window. 
You can scale these windows however you want, and can merge or split them by hovering your mouse over the boarder between them and middle-clicking. You can change what each windows function is by clicking the square drop down icon in the top/bottom left of each window. 
Have a quick play with that to see how it works.

====View controls====
You can use the mouse, num-pad or a combination of both. The arrow keys on the num-pad (8, 4, 6 and 2) will snap rotate the view in that direction in set increments. The numbers 7, 1 and 3 will snap the view to top, front and side respectively, and if you want to view from the other side (ie, from the bottom, back or other side), hold ctrl while pressing the number. (Eg, to view from the bottom, you'd hold ctrl and press 7) 

The mouse pretty much just uses the middle mouse button and scroll to control the view. To rotate, just middle click somewhere in the 3d window and drag it around. Holding shift before middle click will pan the view, and ctrl will zoom (though it's easier to use the scroll wheel here). 

The final two things to note about views are that blender can display your model from a perspective viewpoint or an orthogonal one. Num-pad 5 toggles this setting, and the "." key will centre and zoom the view on whatever it is you've got selected (works with whole objects, verts, and just about anything else) 

====Modes====

Onto the editing part - Blender has a couple of different 3d window modes to it. Object mode is the default one - and it will allow you to select your various objects in the scene. To edit something in edit mode, you'll first need to have it selected (pink) in object mode. 

You can find the rest of the modes by clicking the 'Object Mode' dropdown box which is towards the middle of the 3d window's control bar (not the control panel). Of these, edit mode is the only one you should worry about at this stage - and you should also note that to quickly get in and out of edit mode, just press tab. 

===Editing Stuff===

====Selections====

Ok, Edit mode mainly works on whatever you've selected. Normally, this will be vertices because the wire-frame mesh editing is one of blenders strongest points, but it can quite easily be faces or edges too. To change what type of thing you want to select, you'll find the verts, edges and face select modes towards the right of the 3d windows control bar. 

Let's just use verts for now, and we'll only fiddle with the default cube in the scene to demonstrate some of the other functions. 
You can select verts/edges/faces in a number of ways, but the most common ones are to 1) press b and click+drag a box around it, 2) hold shift and right click next to all the bits you want (they'll turn yellow when selected), or if you want to select a number of verts that are attached by edges to each other, 3) right click one vert, hold ctrl and tap the num-pad + key, and this will add any verts to the scene that are directly connected to the ones you've already got selected. 

Another handy thing is the a key. It will toggle whether all or no verts are selected. If you've got none selected, it will select all of them. If you've got some selected, it will deselect them. 

====Editing Functions====

Ok, once you've made your selection (just select the 4 verts that make up one side of the cube for now), you can do just about anything with it. The main things you'll need to know about here though are the Grab, Rotate, Scale and Extrude functions. (each one is activated by tapping the associated first letter of the words.) 

So, tap g to grab our selection, and begin moving it around with your mouse. Something to keep in mind here is that when doing it like this, blender will ONLY edit things according to the plane at which the selection is viewed. In other words and in this case, your camera will affect the 'plane' along which your selected object can be moved. Eg, if you press g while in top view, you'll only be able to move the object along the 'ground' plane. 

On to what you can do while you've got your object grabbed - there's a lot. To cancel the move, you can right click at any time and it will snap back to it's original position. 
*To snap it between pre-set grid increments, hold Ctrl.
*To perform tiny free movements, hold shift.
*To perform tiny snap movements, hold shift and Ctrl.
*>>(most importantly)>>To constrain it so it will only move along any one axis, just tap the axis letter (once for the global axis, twice for local, thrice to de-constrain it).
*To move around one pixel at a time, tap the arrow keys.

You can do a couple of other things too, but you won't need them for now.
Now - most of the above controls work when in Scale (s) and Rotate (r) too - so it gives you whatever degree of control over your selection that you want. 

Extrude (e) is a bit different - it will basically, duplicate your selection, but attach it by edges to the original ones. You should note though that this is context sensitive. What this means is that if you only have one vert selected and press e, it will extrude only that vert, no questions asked. However, if blender detects an edge between two verts, or a face between 3 or 4, it will pop up a little menu when you press e. This will allow you to extrude the piece in exactly the way you wanted - ie, as a face, edges or individual verts. Have a play with this on the cube to see what it does. 
The extrude button basically allows you to grow your ships out of whatever you start with, so it's a very important one. 

====Editing Menus====

If you ever get confused, need to find a shortcut or something, press the space bar when over the 3d window. It will pop up a menu that is able to access most of blenders editing functions (the remaining lot are in the 'Weird' w menu), and it will list the shortcuts for each one too. 

Also through this menu you can access the add menu, where you can add more primitive shapes at your blender-cursors location. (The blender cursor is that black crosshair with the red and white striped circle through it. You place it by left-clicking somewhere, and centre it by pressing Shift+c) Keep in mind that any objects you create through this menu will be aligned with your view plane again, so it can sometimes get ugly. 

And finally, to delete your selection, press x, and it will give you an option for exactly what it is about your selection you want deleted. 

==External Links==
*[http://www.blender.org/ Official Blender site containing current version downloads.]
*[http://wiki.blender.org/index.php/Doc:Manual A useful wiki-based guide detailing the commands and controls for Blender]
*[http://www.blender.org/education-help/video-tutorials/ Video tutorials for getting started.]
*[http://filmmakeriq.com/general/featured/555-blender-tutorials.html 555 different Blender tutorials from all over the net]
*[http://www.hard-light.net/forums/index.php/topic,61061.msg1241903.html#msg1241903 Water roughly explains UV mapping in Blender]

[[Category:Tools]]

Blender to POF Conversions

2009-05-15T03:57:49Z

VA: /* Recommended Export Settings: */ How to ACTUALLY perform the export

==Recommended Export Settings:==
Once you are ready to export, go to File -> Export -> Collada 1.4(DAE)
 [[Image:BlenderColladaExporterSettings.jpg]] 

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As you may be able to tell, you can create insignia that will appear on LODs too which is a good idea to do or else it will suddenly vanish when the ship moves out a way and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-05-15T03:40:41Z

VA: /* Textures: */ Formats noted.

==Recommended Export Settings:==
 [[Image:BlenderColladaExporterSettings.jpg]] 

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

Format-wise, FS can accept TGA, PCX, JPG and DDS. However it is VERY highly recommended (almost a requirement) that you use DDS formats for final releases due to their efficiency. For more information about textures and their usage, see [[Texturing#Texture Types]]

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As you may be able to tell, you can create insignia that will appear on LODs too which is a good idea to do or else it will suddenly vanish when the ship moves out a way and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-05-15T03:34:04Z

VA: Went through and added loads of piccies. Should be easier to follow now. :)

==Recommended Export Settings:==
 [[Image:BlenderColladaExporterSettings.jpg]] 

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.
 [[Image:BlenderShipOrientation.jpg]] 

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
 [[Image:BlenderShipDimensions.jpg]] 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s. 
 [[Image:BlenderApplyScaleOrientation.jpg]] 

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
 [[Image:BlenderTriangulatingSelectedFaces.jpg]] 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid: 
Faces that occupy the same plane in 3d space, as this will cause bad Z-fighting in-game 
 [[Image:BlenderErrorSamePlane.jpg]] 
Faces that exactly overlap onto each other 
 [[Image:BlenderErrorCoCentricFaces.jpg]] 
Faces that are formed between 3 verts in a row (ie, 0 area faces) 
 [[Image:BlenderErrorHoles.jpg]] 
Shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason. 
 [[Image:BlenderErrorShatteredGeometry.jpg]] 

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired.
 [[Image:SelectNonManifold.jpg]] 
Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.) 
A quick point here on the usage of the mirror modifier:
 [[Image:BlenderMirrorModifierSetup.jpg]] 
Basically the modifier will create a mirrored copy of your selected object, and will mirror it about that objects centre on the axes you select.

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'. [[Image:BlenderSmoothgroups1.jpg]]
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'. [[Image:BlenderSmoothgroups2.jpg]]
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'. [[Image:BlenderSmoothgroups3.jpg]]

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)
 [[Image:BlenderTextureSetup.jpg]] 

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 
 [[Image:BlenderLODs.jpg]] 
These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.
 [[Image:BlenderTransparencySetup.jpg]] 
What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

 [[Image:BlenderDebrisSetup.jpg]] 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

 [[Image:BlenderSinglePartTurretSetup.jpg]] 

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 
 [[Image:BlenderMultiPartTurretAxes.jpg]] 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

 [[Image:BlenderMultiPartTurretSetup.jpg]] 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

 [[Image:BlenderShieldSetup.jpg]] 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As you may be able to tell, you can create insignia that will appear on LODs too which is a good idea to do or else it will suddenly vanish when the ship moves out a way and the LOD clicks over. 

Insignia should not be children of anything. 

 [[Image:BlenderInsigniaSetup.jpg]] 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

File:BlenderShipOrientation.jpg

2009-05-15T03:06:37Z

VA: A guide on how to align your ship from the top-down blender view.

A guide on how to align your ship from the top-down blender view.

File:BlenderColladaExporterSettings.jpg

2009-05-15T03:05:50Z

VA: Recommended export settings for DAE models.

Recommended export settings for DAE models.

File:BlenderShipDimensions.jpg

2009-05-15T03:05:00Z

VA: A guide on which dimensions are which. 1 Blender unit = 1 FS metre.

A guide on which dimensions are which. 1 Blender unit = 1 FS metre.

File:BlenderShieldSetup.jpg

2009-05-15T03:04:10Z

VA: How to set up shields.

How to set up shields.

File:BlenderApplyScaleOrientation.jpg

2009-05-15T03:03:39Z

VA: How to apply scale and orientation for selected objects to avoid problems during conversion.

How to apply scale and orientation for selected objects to avoid problems during conversion.

File:BlenderSinglePartTurretSetup.jpg

2009-05-15T03:02:46Z

VA: How to set up single-part turrets with firepoints.

How to set up single-part turrets with firepoints.

File:BlenderMultiPartTurretSetup.jpg

2009-05-15T03:02:17Z

VA: How to set up multi-part (rotating) turrets with firepoints.

How to set up multi-part (rotating) turrets with firepoints.

File:BlenderTriangulatingSelectedFaces.jpg

2009-05-15T03:01:26Z

VA: How to triangulate objects.

How to triangulate objects.

File:BlenderMirrorModifierSetup.jpg

2009-05-15T03:00:41Z

VA: How to set up the mirror-modifier to halve your modelling workload.

How to set up the mirror-modifier to halve your modelling workload.

File:BlenderErrorSamePlane.jpg

2009-05-15T03:00:01Z

VA: An illustration of the error where two faces occupy the same plane, causing Z fighting in game.

An illustration of the error where two faces occupy the same plane, causing Z fighting in game.

File:BlenderInsigniaSetup.jpg

2009-05-15T02:59:04Z

VA: How to set up insignia objects.

How to set up insignia objects.

File:BlenderErrorCoCentricFaces.jpg

2009-05-15T02:57:26Z

VA: An illustration of the error where two faces of the same dimensions are occupying the same location.

An illustration of the error where two faces of the same dimensions are occupying the same location.

File:BlenderMultiPartTurretAxes.jpg

2009-05-15T02:56:30Z

VA: An illustration of where the axes or object centres should be placed when making multi-part (rotating) turrets.

An illustration of where the axes or object centres should be placed when making multi-part (rotating) turrets.

File:BlenderDebrisSetup.jpg

2009-05-15T02:55:42Z

VA: How to set up debris objects.

How to set up debris objects.

File:BlenderErrorHoles.jpg

2009-05-15T02:55:04Z

VA: An illustration of the error where holes or faces alike can appear to be an edge.

An illustration of the error where holes or faces alike can appear to be an edge.

File:BlenderErrorShatteredGeometry.jpg

2009-05-15T02:54:24Z

VA: Illustration of the error known as shattered geometry.

Illustration of the error known as shattered geometry.

File:SelectNonManifold.jpg

2009-05-15T02:52:28Z

VA: How to select potentially problematic edges using the select non-manifold function.

How to select potentially problematic edges using the select non-manifold function.

File:BlenderSmoothgroups1.jpg

2009-05-15T02:51:35Z

VA: How to set up smoothgroups part 1.

How to set up smoothgroups part 1.

File:BlenderSmoothgroups2.jpg

2009-05-15T02:51:12Z

VA: How to set up smoothgroups part 2.

How to set up smoothgroups part 2.

File:BlenderSmoothgroups3.jpg

2009-05-15T02:50:50Z

VA: How to set up smoothgroups part 3.

How to set up smoothgroups part 3.

File:BlenderLODs.jpg

2009-05-15T02:50:10Z

VA: How to set up LODs for DAE conversion.

How to set up LODs for DAE conversion.

File:BlenderTransparencySetup.jpg

2009-05-15T02:49:34Z

VA: How to set up transparencies like cockpit glass.

How to set up transparencies like cockpit glass.

File:BlenderTextureSetup.jpg

2009-05-15T02:48:45Z

VA: How to assign textures to faces.

How to assign textures to faces.

Blender to POF Conversions

2009-05-15T02:22:35Z

VA: /* Single-part Turrets: */

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s.

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid faces that exactly overlap onto each other, faces that are formed between 3 verts in a row (ie, 0 area faces), shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason.

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired. (Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.)

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'.
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'.
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'.

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 

These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.

What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' ALL NAMES ARE CASE SENSITIVE!!!!)
|
|-firepoints01
| |
| |-firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-firepoint2
|
|-path07 (NOTE: path and properties are probably best left off and done in PCS2)
| |
| |-Path07-01
| |-Path07-02
|
|-properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As you may be able to tell, you can create insignia that will appear on LODs too which is a good idea to do or else it will suddenly vanish when the ship moves out a way and the LOD clicks over. 

Insignia should not be children of anything. 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

[[Category:Modding]]
[[Category:PCS2 Cooperative Authoring]]

Blender to POF Conversions

2009-03-08T06:18:46Z

VA: All the autogeneration features of Blender->DAE conversions

==General requirements for the Blender scene:==
===Orientation:===
For those who can understand it: 
:Stern to Bow axis = Freespace Positive Z axis = Blender Positive Y axis
:Starboard to Port axis = Freespace Positive X axis = Blender Negative X axis
:Belly to Topside axis = Freespace Positive Y axis = Blender Positive Z axis

For those who don't: 
:Go to a top down view of the scene with Numpad-7. You should be looking down at the topside of your ship, with the ships bow pinting up your screen.

===Scale:===
1 Blender unit = 1 Freespace meter, so scale your model to the exact in-game dimensions you want it to be.
To do this, press N to bring up the Transform Properties window and pay attention to the DimXYZ section bottom right. Those are the dimensions of the selected object in Blender units. 
To avoid potential problems with scale and orientation during conversion, you want the RotXYZ and ScaleXYZ fields to read 0,0,0 and 1,1,1 respectively - which you can achieve by pressing Ctrl+A->"Scale and Rotation to ObData" for the selected objects. Doing this will basically hold that object still while setting those fields to 0s and 1s.

===Geometry:===
As far as I have been able to tell, all geometry the PCS2 Collada importer will accept must be fully triangulated. (Ctrl+T to triangulate selected object) 
All mirror or edgesplit modifiers must be applied before exporting or they won't work and you'll end up with half your model or something. ;) 
Messy geometry will ''usually'' convert correctly anyway, but I would suggest making it a point of pride to produce clean meshes that will ''definitely'' convert. That is, avoid faces that exactly overlap onto each other, faces that are formed between 3 verts in a row (ie, 0 area faces), shattered faces where all or parts of a face are completely detached from surrounding geometry for no good (eg, smoothing) reason.

An excellent error checking tool in blender is the 'select non-manifold' function, which highlights holes in the mesh. To use it, select the object you wish to investigate, enter edit mode and toggle A until you have nothing selected. Set your mode to edge mode (Ctrl + Tab->'Edges' or press the edge icon at the bottom of the 3d View panel) and go to the Select menu in the 3d View panel and click Non-Manifold. All edges that form the perimeter of a hole will be selected, so you can identify areas that should be repaired. (Note: When used with the mirror modifier, this function will select all the edges that form the place where the mirrored side will attach to the 'real' side. This is normal so don't worry about it there.)

===Smoothing:===
Blender does not use smoothgroups as they are seen in other modelling programs, but it has something pretty close and just as effective. It involves a Three-stage process:
# Select the edges that will make up the perimeter of the area you want to be smoothed (ie, the area you want to become a single smoothgroup) and press Ctrl+E->'Mark Sharp'.
# Use Ctrl+E->'Loop to Region' to select the faces that are inside that perimeter and set them to be smoothed by either the 'Set Smooth' button in the editmode button panel or Ctrl+F->'Shade Smooth'.
# Outside of edit mode, add an Edge Split modifier set only to 'From Marked as Sharp'.

If you apply this modifier before the final export, these smoothgroups will survive the conversion intact and can GREATLY enhance the apeal of an in-game model.

===Textures:===
The PCS2 Collada importer will read textures from whatever images are assigned to each face of an object in Blenders UV editor (NOT from the materials button panel!) 
As such, assuming you have UV mapped the model and have an associated texture ready, select all the faces of the model that use that texture and in the UV/Image Editor view open up that image. (If it's loaded already it will be in the drop down list, if not go to Image->Open)

===Levels Of Detail:===
LODs are lower detail duplicates of the main mesh used when the ship is so far away from the player that rendering it at full detail would be a big waste of your graphics card's resources. While not a requirement (FS will work fine without them), it's standard practice to include at least two lower LODs as well as the main hull. 

The main lod object should be named ''''detail0'''' (case sensitive), first LOD ''''detail1'''' second ''''detail2'''' and so on. Don't use more than 4 LODs in total as the LODs themselves will become a waste of memory. 

These LODs should not be parented to any other object as they're basically the top of the hierarchy of the model. Also, they should all have their object centres set to the origin of 0,0,0. 

Example:
detail0
|-<subobjects of detail0>
detail1
|-<subobjects of detail1>
detail2
|-<subobjects of detail2, though by this stage there shouldn't be any>

===Nameplates/Cockpit Glass:===
Transparent objects are handled quite badly by FSO at the time of writing, and so the following technique is basically a hack to get around that. 

If you have anything that requires transparency as a part of the hull or any subobject, you must:
# Select all faces that will need to be transparent. (For cockpits this means all the polys that would be the glass, and for nameplates it means just the floating nameplate rectangle polys)
# Detach these faces from the mesh they're a part of so they form their own mesh.
# Assign them the texture if nessecary. (For cockpit glass just give it any old image called 'glass' and for nameplates give it any old image called 'nameplate'. Both these textures exist in the 3.6.10 MediaVPs and so will be used on your model with no further worry about it. If you need some other form of transparency you'll have to make your own transparent texture and use that.)
# Name the object in the form of ''''<Object the transparent polys came from>-trans''''. So for example, the glass or nameplate would be called 'detail0-trans', because they were pulled off the main hull.
# Parent the transparent polys object to whatever object they originally came from. (Select the transparent object, then the parent object and press Ctrl+P->'Make Parent' ) For glass or a nameplate this would of course be detail0.

What basically happens is that PCS2 will re-attach the transparent polys to their parent object last in the list, which lets Freespace draw them last of all and so correctly transparent. 

Example:
detail0
|
|-radardish
| |
| |-radardish-trans
|
|-detail0-trans (nameplate)

===Debris:===
Debris chunks are the pieces that hurl themselves in all directions when a ship explodes. A ship that has no debris will have nothing left at all when it explodes which is really boring! I would recommend constructing full-ship-volume debris for the best explosion effects, as it means that when it explodes the ship essentially just cracks apart and drifts off, which looks much cooler than nothing or a piece here or there. 

Anyway, to make debris objects ready for conversion they should be named ''''debrisXX'''' where XX starts at 01 and can go up to 99, though typically any more than about 20 is excessive.. 

Example:
detail0
detail1
detail2
debris01
debris02
debris03 etc

===Single-part Turrets:===
All turrets should be named with the word ''''turret'''' or ''''gun'''' in them so FS knows to treat them differently to normal subobjects. Beyond that they can be called whatever you like, though standard practice is just ''''Turret01'''', ''''Turret02'''' etc. 

NOTE: Many people myself included much prefer to set up turret firepoints, paths and properties in PCS2 after the conversion, where it's a bit easier and less likely to break during conversion. 

To set up the firepoints of a turret in blender, you'll need to use Empties (also known as helpers). (To create an empty, just press Ctrl+A->'Empty' ) 

The basic layout for empties is to have a parent empty attached to each subobject, and then several empties attached to it for things like firepoints, path and properties, looking like this: 

Example:
detail0
|
|-turret01
|
|-helper01 (NOTE: This top level empty must begin with the word 'helper' )
|
|-Firepoints01
| |
| |-Firepoint1 (NOTE: The orientation of these empties is important - the turret will fire down their Z axis)
| |-Firepoint2
|
|-Path07
| |
| |-Path07-01
| |-Path07-02
|
|-Properties01
|
|-$fov=180
|-$name=laser_turret
|-$special=subsystem

===Multi-part (rotating) Turrets:===

Multi-part turrets consist of two parts: the Base and the Arm. Since the arm needs to inherit the rotation of the base it's attached to, you need to parent it to the base (ie, select arm, base and press Ctrl+P->'Make Parent' ). Note that each turret can only have ONE arm object, but within that object you might have three separate pieces of geometry or so to form three barrels. The turret base should be parented to the LOD it is associated with - typically detail0. 

As multi-part turrets need to rotate in-game, they need to have careful attention paid to where their object centres are, or they could spin right off the ship or something equally stupid looking. Place the centres at the points where each piece (arm and base) of the turret would pivot around. Turrets on the topside of the ship must face forwards while turrets on the belly must face backwards. 

'''All''' turret arms must point straight up out of their base or they will not rotate correctly. 

As with single part turrets, the naming must include ''''turret'''' or ''''gun'''' in it somewhere so FS knows to treat it differently, and standard practice is to call the base ''''Turret01-base'''' and the arm ''''Turret01-arm''''. Also again it is easier to set up turret data in PCS2 after conversion (Setting the turret axis rotation MUST be done in PCS2 in the subobjects field after conversion or else your turrets won't work at all) 

Setting up firepoints, paths and properties in Blender is the same as for single part turrets.. 

Example:
detail0
|
|-Turret01 (single part turret)
|
|-Turret02-base
|
|-Turret02-arm
|
|-helper02
|
|-firepoints02
| |
| |-firepoint02-01
| |-firepoint02-02
|
|-path07
| |
| |-path07-01
| |-path07-02
|
|-properties02
|
|-$fov=180
|-$name=main%turret (The % will be converted to a space automatically)
|-$special=subsystem

===Subobjects/Modeled Subsystems:===

These are just done like single part turrets if they don't need to rotate and like multi-part turrets if they do (like radar dishes). You can have an empty system as with turrets if you like, but again this is better done post-conversion. 

To make destroyed models for modeled subsystems or turrets, create a model of the wrecked subsystem and put it in the position it will be in when that subsystem is destroyed. Name it ''''<Subobject name>-destroyed'''' and Freespace will only make it appear when that subobject has been destroyed. Ie, ''''Turret01-destroyed''''. 

As with rotating multi-part turrets, rotating subobjects axis rotation must be set up in PCS2 after conversion. 

Example:
detail0
|
|-radardish
|-radardish-destroyed

===Regular Subsystems:===

Subsystems are done by placing empties, and then scaling them up to the diameter of the desired subsystem. As with turrets, they can have their properties of '$special=subsystem' added (in the same hierarchy - ie, children of the helper, as seen with the turrets) either in Blender or preferably in PCS2 after conversion. 

To name them correctly, simply call them ''''subsystemcommunications'''' or ''''subsystemweapons'''' etc. Subsystems should not be children of anything. 

Example:
detail0
detail1
detail2
subsystemweapons
|
|-helper
|
|-path03
| |
| |-path03-01
| |-path03-02
|
|-properties
|
|-$special=subsystem

===Gun/Missile ports:===

For fighters and bombers, you can set up gun and missile points by creating empties representing the gun/missile banks, with children empties representing the individual firing points contained in that bank. 

So for example, you would have the parent empty ''''gunbank01'''' with children ''''gunbank01-01'''' and ''''gunbank01-02'''' representing the locations and orientations (down the emtpies' Z axis) of the two individual firing points in that bank. Gun and missile banks should not be children of anything. 

Example:
detail0
|
|-gunbank01 (This will create a gunbank with two firepoints on it)
|
|-gunbank01-01
|-gunbank01-02

===Shields:===

Shields are usually made of only 80 polygons and must be fully triangulated, enveloping the entire model. Name the object ''''shield''''. Shields should not be children of anything. 

Example:
detail0
detail1
detail2
shield

===Insignia:===

Squadren Insignia should be treated similarly to nameplates in terms of making them on a set of faces that floats just above the hull. 

UV map them and apply a texture called 'insignia' (it's a good idea to use an actual insignia texture here), and call them: ''''insigLODXX-YY'''', where XX is the LOD number and YY is the number of this particular insignia (for if you have more than one). As you may be able to tell, you can create insignia that will appear on LODs too which is a good idea to do or else it will suddenly vanish when the ship moves out a way and the LOD clicks over. 

Insignia should not be children of anything. 

Example:
detail0
detail1
detail2
insigLOD01-01 (This and the one below will '''actually''' be assigned to detail0. The two last ones will be assigned to detail1)
insigLOD01-02
insigLOD02-01
insigLOD02-02

===Docking Points:===

Docking points consist of '''two''' individual docking points, an associated path and properties. You can do all of this in PCS2 after conversion where it's a lot easier, but if you really want to you can do it in Blender too: 

Make two dockpoints (''''dockpoint01-01'''' and ''''dockpoint01-02'''') the children of a parent ''''dockpoint01'''' empty (which should not be the child of anything). The first point is the location and outwards normal of dockpoint01, and the second defines the 'front' of the dockpoint so that docking ships know which end is the front of the ship. 

Dockpoints can have paths and properties set up as with single part turrets, though dockpoints need 4 path verticies instead of the usual two, and can take the property of ''''$name=<dockport name>''''. 

Example:
detail0
detail1
detail2
dockpoint01
|
|-dockpoint01-01
|-dockpoint01-02
|
|-helper
|
|-path09
| |
| |-path09-01
| |-path09-02
|
|-properties
| |
| |-$name=DockingPort

===Engine Glows:===

These can be done in one of two ways:
# Just basic thrusters involves an empty called ''''thrusters'''' representing the glow bank, and children empties that represent the location and scale of the individual thruster glows. Here ''''thrusters'''' should not be the child of anything. 

Example:
detail0
detail1
detail2
thrusters
|
|-thruster01-01
|-thruster01-02

# Linked to an engine subsystem. Here the setup is the same as in 1), but ''''thrusters'''' is set as the child of the helper of the engine subsystem that is meant to be providing these particular engine glows. This way, when that particular engine subsystem is destroyed, only the glows linked to it are removed. 

Example:
detail0
detail1
detail2
subsystemengine
|
|-helper
|
|-path04
| |
| |-path04-01
| |-path04-02
|
|-properties
| |
| |-$special=subsystem
|
|-thrusters
|
|-thruster01-01
|-thruster01-02

===Glow Points:===

These involve a parent empty that must begin with the name ''''glowbank'''', and be the child of whatever subobject the glowpoints are attached to. Any children of ''''glowbank'''' will define the location and scale of individual glowpoints. They also use a helper->properties setup as seen previously, taking only the texture name the glowpoint to be drawn there in-game, such as: ''''properties''''->''''$glow_texture=yellowglow''''. 

Blinking settings can only be done in PCS2 after conversion, and in fact the entire glowpoint making process can be done there too. 

Example:
detail0
|
|-helper
|
|-glowbank01
| |
| |-glowpoint01-01
| |-glowpoint01-02
| |-glowpoint01-03
|
|-glowbank02
|
|-glowpoint02-01
|-glowpoint02-01

===Eyepoint:===

The eyepoint can again be done after conversion, but in Blender it is handled simply with a lone empty named ''''eyepoint01'''' that is not the child of anything. The Z direction of the empty indicates the direction it's facing in. 

Example:
detail0
detail1
detail2
eyepoint01

Ships.tbl

2008-08-10T05:34:28Z

VA: Added expected units for debris settings

{{TableVersion|4562|4499}}


==General Format==
*Ship.tbl is formed of several different sections.
*All sections beginning with <nowiki>#</nowiki> need <nowiki>#</nowiki>End before the next section.
**<nowiki>#</nowiki>'''Default Player Ship'''
***Defines the default player ship in the game and also in the FRED. If in a mission appears a ship that has not been properly included to tables then game replaces the ship with the Default Player Ship.
**<nowiki>#</nowiki>'''Engine Wash Info'''
***Includes all the definitions of all engine washes used in the game.
{{Table37|
:*<nowiki>#</nowiki>'''Ship Templates'''
:**Includes entries for ship templates}}

:*<nowiki>#</nowiki>'''Ship Classes'''
:**Includes entries for every ship and also defines their attributes that are used in the game
:**Is discussed in detail at [[Ships.tbl#Table_Options|Table Options]] section.
:*'''$Player Ship Precedence'''
:**Player Ship Precedence is used in ship selection when a ship specified by the mission designer is not available to the player. The next ship on the list is used in its place (assuming that ship is allowed for the player)

==Default Player Ship==
*Defines the default ship in the game.
*Syntax: ''Name'', name of ship model as defined in [[Ships.tbl#Table_Options|Table Options]].

==Engine Wash==
*Defines the engines washes
*First entry must be named 'default'

===$Name:===
*Defines the name of the engine wash.
*Syntax: '''''String'''''

===+nocreate===
{{Table36|
*In [[Modular Tables]] name can be followed by line '''+nocreate''' that prevent game from creating an incomplete entry by leaving the entry unread unless it already exists (either in ship.tbl or in earlier parsed *-shp.tbm files) by the time the *-shp.tbm is read.}}

===$Angle:===
*Defines the angle from the engine where the engine wash exists
*Syntax: '''''Float''''', degrees

===$Radius Mult:===
*Defines engine wash multiplier
*Syntax: '''''Float'''''

===$Length:===
*Defines the length of the engine wash
*Syntax: '''''Float''''', meters

===$Intensity:===
*Defines the strength of the engine wash
*Syntax: '''''Float''''', blast effect

===Example===

$Name: Default
$Angle: 10.0
$Radius Mult: 1.2
$Length: 400
$Intensity: 1.0

==Ship Template Options==
{{Table37|
*Example of template usage [[Ship_Templates]] in which both [[GTB Artemis]] variants have been defined using a single template}}

===$Template:===
{{Table37|
*Defines the name of template
*Syntax: '''''String''''', name}}

===+Use Template:===
{{Table37|
*Another template can be used as template for the current template
*Syntax: '''''String''''', name}}

==Ships Table Options==

===$Name:===
*Model name that is used also in game. It is also used as name for the whole ship entry.
*Syntax: '''''String'''''', name

===+nocreate===
{{Table36|
*In [[Modular Tables]] name can be followed by line '''+nocreate''' that prevent game from creating an incomplete entry by leaving the entry unread unless it already exists (either in ship.tbl or in earlier parsed *-shp.tbm files) by the time the *-shp.tbm is read.}}

===+Use Template:===
{{Table37|
*Sets the table entry to use template based on an existing table entry instead of creating totally new one
*Syntax: '''''String''''', name of the template}}

===$Short name:===
*Shortened model name, for FRED, Usually more descriptive than the real name.
*Syntax: '''''String''''''

===$Species:===
*Defines species (Terran, Vasudan or Shivan). Determines many things, including the color of the engine glow, the flyby sound effects, the briefing icon and the support ship.
{{Table36|
*More species have been enabled, and all of these have to be defined in [[species_defs.tbl]].}}

*Syntax: '''''String''''', name of the species
**Example: ''Terran''

===Technical description===
List of descriptive terms for techroom and ship selection screens. Number after the quotes refers to [[tstrings.tbl]]

====+Type:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Maneuverability:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Armor:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Manufacturer:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Description:====
*Syntax: XSTR("'''''String'''''", integer)
*Requires '''$end_multi_text''' after the entry
*Example:
::XSTR("", -1)
::$end_multi_text

====+Tech Description:====
*Syntax: XSTR("'''''String'''''", integer)
*Requires '''$end_multi_text''' after the entry
*Example:
::XSTR("", -1)
::$end_multi_text

====+Length:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Gun Mounts:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

====+Missile Banks:====
*Syntax: XSTR("'''''String'''''", integer)
*Example: XSTR("", -1)

===$Cockpit POF file:===
{{Table36|*Filename of the cockpit model file
*Syntax: '''''String.pof''''', model filename}}

===+Cockpit offset:===
{{Table36|*Defines the offset of the cockpit model
*Syntax: '''''Vector''''', three '''floats''', x-axis, y-axis, z-axis, respectively}}

===$POF file:===
*Filename of the model file (.pof) at data/models folder
*Syntax: '''''String.pof''''', model filename

===$Texture Replace:===
{{Table36|
*'''+old:'''
*Defines the texture to be replaced
**Syntax: '''''String''''', filename
*'''+new:'''
*Defines the new texture
**Syntax: '''''String''''', filename}}

===$POF target file:===
*Optional hud targeting model
*Syntax: '''''String.pof''''', model filename

===$POF target LOD:===
{{Table36|
*Defines the LOD (Level-Of-Detail) of target model used in the HUD targetbox
*Syntax: '''''Integer'''''}}

===$Detail distance:===
*Defines the distance where the change between different Levels-Of-Details (LODs) occurs
*Take notice that these are base values. Model detail in Detail options, (within game press F2), applies a multiplier to these values. ''(We need a coder to post here the multiplier values that each level sets)''.
*Syntax: '''''(Detail Distances)''''' , list of '''integers''' (same amount as LODs), distances from the model in meters
**Example: ''(0, 80, 300, 900)''

===$ND:===
*No Dim field field was used in FreeSpace for ship lights. Use of glowmaps is preferred to the $ND entry. Only noticeable in Glide or Software mode.
*Syntax: '''''Color''''', red, green, blue respectively, value from 0 to 255
**Example: ''42, 42, 224''

===$Show damage:===
*No known function. Best left alone to avoid possible compatibility issues.
*Syntax: '''''Boolean''''', yes or no, usually yes

===$Impact:===
{{Table36|
*'''+Damage Type:'''
**Defines the damage type of the collision
**Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

===$Impact Spew:===
{{Table36|
*Used to define the impact particle spew
*'''+Max particles:'''
**Defines the maximum number of particles spewed
**Setting to zero causes model to generate no particles at all
**Syntax: '''''Integer'''''}}

{{Table37|
*In 3.7 impact spew earlier entry has been replaced with full particle emitter
*'''+Texture:'''
**Defines the texture used for the particle
**Syntax: '''''String''''', filename
*'''+Relative Position:'''
**Defines the relative position of the particle
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Velocity:'''
**Defines the relative velocity of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Normal:'''
**Defines the relative normal of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Normal Variance:'''
**Syntax: '''''Float''''
*'''+Min Radius:'''
**Syntax: '''''Float''''
*'''+Max Radius:'''
**Syntax: '''''Float''''
*'''+Min Speed:'''
**Syntax: '''''Float''''
*'''+Max Speed:'''
**Syntax: '''''Float''''
*'''+Min Lifetime:'''
**Syntax: '''''Float''''
*'''+Max Lifetime:'''
**Syntax: '''''Float''''
*'''+Min Particles:'''
**Syntax: '''''Integer''''
*'''+Max Particles:'''
**Syntax: '''''Integer''''}}

===$Damage Spew:===
{{Table36|
*Used to define the damage particle spew
*'''+Max particles:'''
**Defines the maximum number of particles spewed
**Setting to zero causes model to generate no particles at all
**Syntax: '''''Integer'''''}}

{{Table37|
*In 3.7 damage spew earlier entry has been replaced with full particle emitter
*'''+Texture:'''
**Defines the texture used for the particle
**Syntax: '''''String''''', filename
*'''+Relative Position:'''
**Defines the relative position of the particle
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Velocity:'''
**Defines the relative velocity of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Normal:'''
**Defines the relative normal of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Normal Variance:'''
**Syntax: '''''Float''''
*'''+Min Radius:'''
**Syntax: '''''Float''''
*'''+Max Radius:'''
**Syntax: '''''Float''''
*'''+Min Speed:'''
**Syntax: '''''Float''''
*'''+Max Speed:'''
**Syntax: '''''Float''''
*'''+Min Lifetime:'''
**Syntax: '''''Float''''
*'''+Max Lifetime:'''
**Syntax: '''''Float''''
*'''+Min Particles:'''
**Syntax: '''''Integer''''
*'''+Max Particles:'''
**Syntax: '''''Integer''''}}

===$Debris:===
{{Table36|
*'''+Damage Type:'''
**Defines the damage type of the debris
**Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}
{{Table37|
*'''+Min Lifetime:'''
**Defines the minimum lifetime of the debris (Default value is a random number)
**Syntax: '''''Float,''' Seconds
*+Max Lifetime:
**Defines the maximum lifetime of the debris
**Syntax: '''''Float,''' Seconds
*+Min Speed:
**Defines the minimum speed of the debris
**Syntax: '''''Float,''' Meters/second
*+Max Speed:
**Defines the maximum speed of the debris
**Syntax: '''''Float,''' Meters/second
*+Min Rotation speed:
**Defines the minimum rotational speed of the debris (Default is (6 to 10)/Ship-radius)
**Syntax: '''''Float,''' Radians/second
*+Max Rotation speed:
**Defines the maximum rotational speed of the debris
**Syntax: '''''Float,''' Radians/second}}

===$Density:===
*This defines how hard you hit something. If you set it very high, a collision will severely damage your ship, and push the lower density object away; the higher the numbers are, the harder they will hit and the farther they will be pushed. Setting a density of 10 on a fighter with 180 hitpoints will cause the fighter to immediately explode if it collides with, say, an asteroid.
*Syntax: '''''Float''''', usually 1

===$Damp:===
*Damp affects how quickly you will accel/decel to your target velocity. Higher damp means slow acceleration and deceleration. The lower this number, the faster the ship responds. For example, specifying a value of 0.0 means there is no damping, in other words, people would say, "this has no physics, like Wing Commander." The more damping, the harder to control, but the more smoothly it moves.
*Syntax: '''''Float'''''

===$Rotdamp:===
*Same thing, but for rotational movement.
*Syntax: '''''Float'''''

===$Banking Constant:===
{{Table37|
*Defines a factor for how much roll is added during a yaw. Set as 1 for full roll and 0 is no roll. Default is 0.5.
*Syntax: '''''Float'''''}}

===$Max Velocity:===
*Defines maximum velocities with standard energy settings on x (left/right), y (up/down), and z (forward) -axis (respectively). z -axis velocity defines the maximum forward velocity.
*Syntax: '''''Vector''''', three '''floats''', x-axis, y-axis, z-axis, respectively, meters per second
**Example: ''0.0, 0.0, 80.0''

===$Rotation time:===
*Defines rotation times around the x, y, and z -axis. Number is seconds it takes to complete rotate a ship (360 degrees) around the given axis
*Syntax: '''''Vector''''', three '''floats''', seconds per 360 degree turn around x-axis, y-axis, z-axis, respectively
**Example: ''3.0, 2.6, 5.0''

===$Rear Velocity:===
*Defines rear velocity
*Syntax: '''''Float''''', meters per second

===$Forward accel:===
*Number of seconds needed from full stop to maximum velocity
*Syntax: '''''Float''''', seconds

===$Forward decel:===
*Number of seconds needed from maximum velocity to full stop
*Syntax: '''''Float''''', seconds

===$Slide accel:===
*Same for sliding as the $Forward accel: is for for normal movement.
*Syntax: '''''Float''''', seconds

===$Slide decel:===
*Same for sliding as the $Forward decel: is for for normal movement.
*Syntax: '''''Float''''', seconds

===$Glide:===
{{Table36|
*Allows gliding in game, i.e. turning the ship's facing without changing its direction.
*Syntax: '''''Boolean''''', yes or no}}

===+Max Glide Speed:===
{{Table36|
*Defines the maximum glide speed if the glide has been enabled
*Syntax: '''''Float'''''}}

===$Autoaim FOV:===
{{Table36|
*Defines the field of view for autoaim
*Syntax: '''''Integer'''''}}

===$Warpin type:===
{{Table36|
*Allow an animation to be defined as a warpin effect.
*Can be defined as:
**''Default''
**''BTRL''
**''Homeworld''
**''Hyperspace''
*Syntax: '''''String'''''}}
{{Table37|
*Can be defined as:
**''Default''
**''BTRL''}}

===$Warpin speed:===
{{Table36|
*Sets the speed at which the ship warps in for '''default''' warpin effect
*Sets the time that the ships warp in (not the animation itself) takes for '''BTRL''' type warpin effects
*Syntax: '''''Float''''', meters per second or miiliseconds}}

===$Warpin time:===
{{Table36|
*Defines the effect duration
*Syntax: '''''Float''''', seconds}}

===$Warpin radius:===
{{Table36|
*Defines the effect radius
*Syntax: '''''Float''''', meters}}

===$Warpin animation:===
{{Table36|
*Defines the animation used as the warpin effect.
*Syntax: '''''String''''', filename}}

===$Warpout type:===
{{Table36|
*Allow an animation to be defined as a warpout effect.
*Can be defined as ''BTRL'' or ''default''.
*Syntax: '''''String'''''}}

===$Warpout speed:===
{{Table36|
*Sets the speed at which the ship warps out for '''default''' warpout effect
*Sets the time that the ships warp out (not the animation itself) takes for '''BTRL''' type warpout effects
*Syntax: '''''Float''''', meters per second or milliseconds}}

===$Warpout time:===
{{Table36|
*Defines the effect duration
*Syntax: '''''Float''''', seconds}}

===$Warpout radius:===
{{Table36|
*Defines the effect radius
*Syntax: '''''Float''''', meters}}

===$Warpout animation:===
{{Table36|
*Defines the animation used as the warpout effect.
*Syntax: '''''String''''', filename}}

===$Player warpout speed:===
{{Table36|
*Sets the speed at which the player warps out from the game
*Syntax: '''''Float'''''}}

===$Expl inner rad:===
*Radius at which the full explosion damage is done
*Syntax: '''''Float''''', meters

===$Expl outer rad:===
*Maximum radius at which any damage is done
*Syntax: '''''Float''''', meters

===$Expl damage:===
*Amount of damage done inside the inner radius
*Syntax: '''''Float''''', damage

===$Expl blast:===
*The intensity of the blast effect when you're within the outer radius
*Syntax: '''''Float''''', blast effect

===$Expl Propagates:===
*This decides whether the ship explodes into debris immediately, or whether it has the many small explosions before breaking apart slowly
*Syntax: '''''Boolean''''', yes or no

===$Shockwave Damage Type:===
{{Table36|
*'''REQUIRES ADDITIONAL TABLE'''. Defines the damage type used for the ship explosions
*Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

===$Shockwave Speed:===
*Speed shockwave expands at, 0 means no shockwave
*Syntax: '''''Float''''', meters per second

===$Shockwave count:===
*Defines the number of shockwaves to spawned
*Syntax: '''''Integer'''''

===$Shockwave model:===
{{Table36|
*Defines the textured model used as the ship's 3D shockwave
*Syntax: '''''String.pof''''', model filename}}

===$Shockwave name:===
{{Table36|
*Defines the name of the animation to used for the 2D shockwave
*Syntax: '''''String''''', filename}}

===$Weapon Model Draw Distance:===
{{Table36|
*Distance that external weapons are shown, ie. missiles and such.
*Syntax: '''''Float''''', meters
**Default: ''200''}}

===Primary Weapons===

====$Allowed PBanks:====
*List of allowed primary weapons in brackets (weapon name marked with quotes).
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the primary weapon banks '''can optionally''' be given their own list of allowed weapons, in which case each bank has its own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Allowed Dogfight PBanks:====
*Primary weapons for multiplayer dogfights.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the primary weapon dogfight banks '''can optionally''' be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Default PBanks:====
*Defines default primary weapons for each of the primary weapon banks
*Syntax: '''''( "String" "String" )''''', names of the weapons

====$PBank Capacity:====
{{Table36|
*Defines ammunition capacity of primary weapon banks. In brackets, different weapon banks separated by commas.
*Syntax: '''''( Integer, Integer )'''''}}

====$Show Primary Models:====
{{Table36|
*Defines the use of weapon models for primary weapons. In brackets, different weapon banks may have different definitions
*Syntax: '''''( Boolean Boolean )''''', yes or no
**Example: ''( YES YES )'' - Note the spaces on the insides of the brackets.}}

===Secondary Weapons===

====$Allowed SBanks:====
*Same for secondary weapons.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the secondary weapon banks can be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Allowed Dogfight SBanks:====
*Same for secondary weapons.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the secondary weapon dogfight banks can be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Default SBanks:====
*Defines default primary weapons for each of the primary weapon banks
*Syntax: '''''( "String" "String" )''''', names of the weapons

====$SBank Capacity:====
*Defines ammunition capacity of secondary weapon banks. In brackets, different weapon banks separated by commas.
*Syntax: '''''( Integer, Integer )'''''

====$Show Secondary Models:====
{{Table36|
*Defines the use of weapon models for secondary weapons. In brackets, different weapon banks may have different definitions
*Syntax: '''''( Boolean Boolean )'''''
**Example: ''(YES YES)''}}

===$Shields:===
*Determines the shield strength
*Syntax: '''''Float''''', total shield strength

===$Shield Color:===
*RGB value for shield color
*Syntax: '''''Color''''', red, green, blue respectively, value from 0 to 255
**Example: ''100, 100, 255''

===$Power Output:===
*The amount of energy available. The higher the output, the faster your weapons recharge.
*Syntax: '''''Float'''''

===$Shield Regeneration Rate:===
{{Table36|
*Repair rates for shields at percent per second
*Syntax: '''''Float''''', multiplier of total shield hitpoints recharged each second. ('''NOT A PERCENTAGE''', 0.02 equals 2% recharged per second)
**Default: ''0.02''}}

===$Weapon Regeneration Rate:===
{{Table36|
*Regeneration rates for primary guns at percent per second
*Syntax: '''''Float''''', multiplier of total gun energy recharged each second ('''NOT A PERCENTAGE''', 0.04 equals 4% recharged per second)
**Default: ''0.04''}}

===$Max Oclk Speed:===
*Can also be '''$Max Overclock Speed:'''
*Maximum velocity with all energy diverted to engines
*Syntax: '''''Float''''', meters per second

===$Max Weapon Eng:===
*Can also be '''$Max Weapon Energy:'''
*The maximum amount of energy you can store in your primary weapons bank.
*Syntax: '''''Float'''''

===$Hitpoints:===
*How much damage the ship can take
*Syntax: '''''Float''''', hitpoints
**Default: ''100''

===$Hull Repair Rate:===
{{Table36|
*Repair rates for hull at percent per second
*Syntax: '''''Float''''', multiplier of hitpoints repaired per second, '''NOT A PERCENTAGE''', 0.01 equals 1% recharged per second}}

===$Subsystem Repair Rate:===
{{Table36|
*Repair rates for sybsystems percent per second
*Syntax: ''Value'', multiplier of total subsystem hitpoints repaired per second, '''NOT A PERCENTAGE''', 0.01 equals 1% recharged per second}}

===$Armor Type===
{{Table36|
*'''REQUIRES ADDITIONAL TABLE'''. Defines armor type used for the ship
*Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

===$Flags:===
*See [[Ships.tbl#Ships.tbl_flags|below]]
*Syntax: '''''( "String" "String" )''''', names of the flags assigned to the ship
**Example: ( "fighter" "in tech database" )

===$AI Class:===
*Default AI class
*Syntax: '''''String''''', name of the AI class as defined in [[ai.tbl]]

===$Afterburner:===
*Defines if the ships has afterburner
*Syntax: '''''Boolean''''', yes or no
*'''+Aburn Max Vel:'''
**Syntax: '''''Vector''''', three '''floats''', x-axis, y-axis, z-axis, respectively, meters per second
*'''+Aburn For accel:'''
**Defined only for the forward acceleration. In same format as $Forward accel:
**Syntax: '''''Float''''', seconds
*'''+Aburn Fuel:'''
**Amount of afterburner fuel the ship has
**Syntax: '''''Float''''', fuel
*'''+Aburn Burn Rate:'''
**Rate the fuel is consumed when afterburner is engaged (in units per seconds)
**Syntax: '''''Float''''', fuel units per second
*'''+Aburn Rec Rate:'''
**Rate the fuel is restored.
**Syntax: '''''Float''''', fuel units per second
{{Table36|
*'''$Trails:'''
**Allows afterburner trails to be used
**'''+Bitmap:'''
***Texture used to draw the afterburner trail
***Syntax: '''''String''''', filename
**'''+Width:'''
***Width of afterburner trail at the beginning of it (ie. the thruster end)
***Syntax: '''''Float''''', meters
**'''+Alpha:'''
***Transparancy of the trail, value from 1 (non-transparent) to 0 (totally transparent)
***Syntax: '''''Float'''''
**'''+Life:'''
***How long the trail will last
***Syntax: '''''Float''''', seconds}}

===$Countermeasure Type:===
{{Table36|
*Defines the weapon used as a countermeasure. Weapon does not have to be included in the countermeasure section of the weapons.tbl, but it has to have "countermeasure" flag in that case.
*Syntax: '''''String''''', name of the weapon as defined in [[weapons.tbl]]}}

===$Countermeasures:===
*Number of countermeasures that can be loaded to the ship
*Syntax: '''''Integer'''''

===$Scan time:===
*Time it takes to scan the ship
*Syntax: '''''Integer''''', milliseconds

===$EngineSnd:===
*Engine sound used for the ship with number referring to sounds.tbl
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]

===$Closeup_pos:===
*How the model will show at techroom. The position of the camera relative to the model in the tech room and the target box view
*Syntax: '''''Vector''''', three '''floats''', x, y and z values respectively

===$Closeup_zoom:===
*How the model will show at techroom. How far the camera's zoomed in, defines camera's FOV.
*Syntax: '''''Float''''', radians

===$Topdown offset:===
{{Table36|
*Specifies how high the camera is above the center point of a ship in topdown camera views, or 2D missions.
*Syntax: '''''Float''''', meters}}

===$Shield_icon:===
*This .ani file must be at data/hud and included to the hud.tbl.
{{Table36|
*Reference to the hud.tbl is no longer needed.}}

*Syntax: ''Filename''

===$Ship_icon:===
*The icon used in ship selection.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: ''Filename''

===$Ship_anim:===
*The glowing green grid animation used in ship selection.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: '''''String''''', filename

===$Ship_overhead:===
*The overhead view used in the weapons loadout.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: '''''String''''', filename

===$Score:===
*Points awarded for destroying the ship
*Syntax: '''''Float'''''

===Customized Thruster Effects===
{{Table36|
*'''Defines the primary thruster glow - the one visible only from behind'''
**'''$Thruster Bitmap 1:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Normal:''' under the '''$Thrustglows:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 1a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Afterburner:''' under the '''$Thrustglows:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster01 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''
*'''Defines the secondary glow type-effect for thrusters - the feathery trail like haze behind the main glow'''
**'''$Thruster Bitmap 2:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Sec_Normal:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 2a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Sec_Afterburn:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster02 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''
**'''$Thruster02 Length factor:'''
***Defines the length multiplier for the trail type (secondary) glowpoint thrusters
***Replaces the older '''$Thruster01 Length factor:'''
***Syntax: '''''Float'''''
*'''Defines the tertiary glow type-effect for thrusters - the one visible from all directions'''
**NOTE: The rotation of this effect is jittered, which can look quite bad with certain types of effects.
**'''$Thruster Bitmap 3:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Ter_Normal:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 3a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Ter_Afterburn:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster03 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''}}

===$Thruster Particles:===
{{Table36|
*Defines the alternative particle thruster
*'''$Thruster Particle Bitmap:''' OR '''$Afterburner Particle Bitmap:'''
**Name of the animation used for particle thrusters, up to '''three''' can be defined for both '''standard''' thrusters and '''afterburners''' (6 in total). Afterburner particles require at least 1 existing particle thruster entry.
**Syntax: '''''String''''', filename
*'''$Min Radius:'''
**Defines the minimum radius of new particles
**Syntax: '''''Float''''', meters
*'''$Max Radius:'''
**Defines the maximum radius of new particles
**Syntax: '''''Float''''', meters
*'''$Min created:'''
**Defines the minimum amount of particles created
**Syntax: '''''Float'''''
*'''$Max created:'''
**Defines the maximum amount of particles created
**Syntax: '''''Float'''''
*'''$Variance:'''
**Value that describes the randomness of particle generation, values close to 0 will cause particles to spew very close to the thrusters normal while values close 1 will cause some particles to be spewed even to opposite direction
**Syntax: '''''Float'''''}}

===$Stealth:===
*Defines: Ship behaves as a stealth-ship: non-targettable, and not on radar.
{{Table36|
This field is deprecated, and mods using 3.6.8 and above should use the "stealth" flag.}}

===$Max decals:===
{{Table36|
*Defines: Maximum number of weapon decals on a ship
*Syntax: '''''Integer''''', maximum number of decals on ship
**Default: 50 for anything below cruiser size, 100 for anything below superdestroyer/installation size, 300 for anything above destroyer size, 10 for everything else.}}

===$Trail:===
*These are the origins of the white contrails that appear in the nebula missions. Ship may have multiple trails.
*'''+Offset:'''
**The position of the contrail's head
**Syntax: '''''Vector''''', three '''floats''', x, y and z values respectively, relative to the center point of the model
*'''+Start Width:'''
**The width of the contrail's head
**Syntax: '''''Float''''', meters
*'''+End Width:'''
**The width of the contrail's tail
**Syntax: '''''Float''''', meters
*'''+Start Alpha:'''
**The opacity of the contrail's head
**Syntax: '''''Float''''', value between 0 and 1
*'''+End Alpha:'''
**The opacity of the contrail's tail
**Syntax: '''''Float''''', value between 0 and 1
*'''+Max Life:'''
**How long the contrail remains
**Syntax: '''''Float'''''', seconds
*'''+Spew Time:'''
**Syntax: '''''Integer'''''
*'''+Bitmap:'''
**The image to use for the contrail.
**Syntax: '''''String''''', filename

===$Thruster:===
{{Table36|
*Defines maneuvering thrusters. Ship may have multiple $Thrusters defined.
*'''+Index:'''
**Defines the index number of the manoeuvring thruster defined in this entry
**Syntax: '''''Integer'''''
*'''+Used for:'''
**Defines the maneuver that triggers the maneuvering thruster
**List of maneuvers: Bank right, Bank left, Pitch up, Pitch down, Roll right, Roll left, Slide right, Slide left, Slide up, Slide down, Forward, Reverse
**Syntax: '''''String'''''}}
{{Table37|
*'''+Flags:'''
**Flags that modify thruster behavior. As of now, only "no scale" exists, which causes all thrusters to be displayed at the same size regardless of thrust amount.
**List of flags: no scale
**Syntax: ("'''''String'''''"), names of the flags}}
{{Table36|
*'''+Position:'''
**Defines thruster location
**Syntax: ( '''''Float''''' '''''Float''''' '''''Float''''' ), position from the ships center point, x, y, z axis respectively
*'''+Normal:'''
**Defines the direction where the thruster points to
**Syntax: ( '''''Float''''' '''''Float''''' '''''Float''''' ), direction of the thrusters normal, x, y, z axis respectively
*'''+Texture:'''
**Defines the graphic that will be used for trail, rendered like beams
**Syntax: '''''String''''', filename
*'''+Radius:'''
**Defines the radius of cylinder
**Syntax: '''''Float''''', meters
*'''+Length:'''
**Defines the length of thruster trail
**Syntax: '''''Float''''', meters
*'''+StartSnd:'''
**Defines the sound played when the thruster is started
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]
*'''+LoopSnd:'''
**Defines the sound played when the thruster is continuously used
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]
*'''+StopSnd:'''
**Defines the sound played when the thruster is shutting down
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===[[Subsystems|$Subsystem:]]===

==Ships.tbl flags==

==="no_collide"===
*Defines ship as non-collideable, ie. everything will go through it

==="player_ship"===
*Makes it possible to player to fly the ship

==="default_player_ship"===
*Makes this ship as a default part of the loadout options in FRED

----

===Ship Type===
*Flags in this section are used to define the type of the ship
*Use only one '''ship type''' flag per table entry
{{Table36|
*New ship types can be defined in [[objecttypes.tbl]]}}

===="repair_rearm"====
*Alternate name for "support"

===="support"====
*Defines the ship as repair and rearm vessel and sets AI behaviour accordingly
*Only one such vessel can be defined per species

===="cargo"====
*Defines ship as a cargo crate and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="fighter"====
*Defines ship as a fighter and also sets the AI behaviour
*In FS1/FS2 only ships flagged as fighters or bombers can accept the full set of player orders

===="bomber"====
*Defines ship as a bomber and also sets the AI behaviour
*In FS1/FS2 only ships flagged as fighters or bombers can accept the full set of player orders

===="transport"====
*Defines ship as a transport and also sets the AI behaviour

===="freighter"====
*Defines ship as a freighter and also sets the AI behaviour

===="capital"====
*Defines ship as a capital ship and also sets the AI behaviour

===="supercap"====
*Alternate name for "super cap"

===="super cap"====
*Defines ship as a super capital ship and also sets the AI behaviour

===="drydock"====
*Defines ship as a drydock and also sets the AI behaviour

===="cruiser"====
*Defines ship as a cruiser and also sets the AI behaviour

===="navbuoy"====
*Defines ship as a navbuoy and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="sentrygun"====
*Alternate name for "sentry gun"

===="sentry gun"====
*Defines ship as a sentrygun and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="escapepod"====
*Alternate name for "escape pod"

===="escape pod"====
*Defines ship as a escapepod and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="corvette"====
*Defines ship as a corvette and also sets the AI behaviour

===="gas miner"====
*Defines ship as a gas miner and also sets the AI behaviour

===="awacs"====
*Defines ship as a AWACS and also sets the AI behaviour

===="knossos"====
*Alternate name for the "Knossos device"

===="knossos device"====
*Defines ship as a Knossos and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="stealth"====
{{Table36|
*Defines ship as a stealth-ship: non-targettable, and not on radar.}}

===="no type"====
*Does ???

----

==="ship copy"===
*Defines the ship as a copy of another model

==="in tech database"===
*Includes ships description to the tech database from the beginning of the campaign

==="in tech database multi"===
*Includes the ship to multiplayer tech database

==="dont collide invisible"===
*Defines invisible textures as non-collideable (For example, a hangar entrace)

==="big damage"===
*Limits the damage made to the ship by non-huge weapons.

==="no_fred"===
*Ship will not appear in FRED.

==="ballistic primaries"===
{{Table36|
*Enables the ship to use ballistic primaries
*No longer needed, game handles it automatically}}

==="flash"===
{{Table36|
*Makes a flash when a ship dies}}

==="surface shields"===
{{Table36|
*Shots that impact the hull are applied to shields, regardless of if the ship has a shield mesh.}}

==="show ship"===
{{Table36|
*Enable rendering the ship even when the ship is a player ship
*Will result in the player's ship model being rendered, when in cockpit mode}}

==="generate icon"===
{{Table36|
*Creates a HUD icon from the model itself}}

==="gun convergence"===
{{Table36|
*Enables ship to use the firing points' normals in defining the direction where the weapon fire}}

==="no primary linking"===
{{Table37|
*Prevents ships from linking primary weapons}}

==Player Ship Precedence==
*Syntax: ( '''''"String" "String"''''')
===Example===

<pre>
$Player Ship Precedence: (
"GTF Ulysses"
"GTF Hercules"
"GTB Medusa"
"GTB Ursa" )
</pre>

==Sample==

<pre>
#Default Player Ship

$Name: GTF Ulysses

#End

#Engine Wash Info

$Name: Default
$Angle: 10.0
$Radius Mult: 1.2
$Length: 400
$Intensity: 1.0

#End

#Ship Classes
$Name: GTF Ulysses
$Short name: TFight
$Species: Terran
+Type: XSTR("Space Superiority", -1)
+Maneuverability: XSTR("Excellent", -1)
+Armor: XSTR("Light", -1
+Manufacturer: XSTR("Triton / Mekhu", -1)
+Description: XSTR( " ", -1)
$end_multi_text
+Tech Description: XSTR("Descriptive text", -1)
$end_multi_text
+Length: 16 m
+Gun Mounts: 4
+Missile Banks: 1
$POF file: fighter01.pof
$Detail distance: (0, 80, 300, 900)
$ND: 42 42 244
$Show damage: YES
$Density: 1
$Damp: 0.1
$Rotdamp: 0.35
$Max Velocity: 0.0, 0.0, 70.0
$Rotation time: 3.0, 2.6, 5.0
$Rear Velocity: 0.0
$Forward accel: 2.0
$Forward decel: 1.5
$Slide accel: 0.0
$Slide decel: 0.0
$Expl inner rad: 25.0
$Expl outer rad: 55.0
$Expl damage: 15.0
$Expl blast: 1000.0
$Expl Propagates: NO
$Shockwave Speed: 0.0
$Allowed PBanks: ( "Subach HL-7" "Prometheus R")
$Allowed Dogfight PBanks: ( "Subach HL-D" "Prometheus D" )
$Default PBanks: ( "Subach HL-7" "Prometheus R" )
$Allowed SBanks: ( "Rockeye" "Tempest" )
$Allowed Dogfight SBanks: ( "Tempest D" "Hornet D" )
$Default SBanks: ( "Harpoon" )
$SBank Capacity: ( 40 )
$Shields: 380
$Shield Color: 100 100 255
$Power Output: 2.0
$Max Oclk Speed: 94.0
$Max Weapon Eng: 80.0
$Hitpoints: 180
$Flags: ( "player_ship"
"default_player_ship"
"fighter"
"in tech database")
$AI Class: Captain
$Afterburner: YES
+Aburn Max Vel: 0.0, 0.0, 150.0
+Aburn For accel: 0.7
+Aburn Fuel: 300.0
+Aburn Burn Rate: 50.0
+Aburn Rec Rate: 25.0
$Countermeasures: 25
$Scan time: 2000
$EngineSnd: 128
$Closeup_pos: 0.0, 0.0, -22
$Closeup_zoom: 0.5
$Shield_icon: shield-f01
$Ship_icon: iconfighter01
$Ship_anim: ssfighter01
$Ship_overhead: loadfighter01
$Score: 8
$Trail:
+Offset: -7.75 -2.8 0.75
+Start Width: 0.25
+End Width: 0.05
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 1.0
+Spew Time: 60
+Bitmap: Contrail01
$Trail:
+Offset: 7.75 -2.8 0.75
+Start Width: 0.25
+End Width: 0.05
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 1.0
+Spew Time: 60
+Bitmap: Contrail01
$Subsystem: communication, 10, 0
$Subsystem: navigation, 10, 0
$Subsystem: weapons, 20, 0
$Subsystem: sensors, 10, 0
$Subsystem: engines, 35, 0

#End

$Player Ship Precedence: (
"GTF Ulysses")
</pre>

[[Category:Tables]]

POF Constructor Suite

2008-04-03T23:54:00Z

VA: Note about duplicate faces

'''POF Constructor Suite''', or '''PCS''', is a program created by Kazan, and is one of the two main pieces of software used in the creation and editing of POF files (the other being [[ModelView]]). This program is capable of converting truespace .COB files into POF files. POF fils are the model file format that Freespace can read and use in-game. Additionally, the POF format contains data solely for Freespace 2. This data includes the center of the object, dockpoints, eyepoints, engine glows, primary and secondary gunpoints, mass, fighter insignias, paths, shields, subsystems, textures, turrets, subobjects and FS_Open glowpoints.

[[POF Constructor Suite 2]] is an up coming major update to this application, coded by Kazan and Bobboau.

==Download Links==

'''====> The latest build of PCS can be downloaded [http://www.ferrium.org/misc/PCS_1.3.6_b73_20060408.zip here]'''

'''====> Bobboau's Auto-Facet build (explained below) of PCS can be downloaded [http://www.hard-light.net/forums/index.php/topic,18798.0.html here]'''

===The Auto-Facet build & smoothing explained===

''Note: The Auto-Facet build should ONLY be used for converting. For all actual POF editing, use the latest standard version.''

Bobboau's Auto-Facet build is a slightly older PCS build (1.3.41) that has a single difference from the standard PCS version. Where the standard PCS will either completely smooth geometry or leave it completely faceted depending on the material settings in Truespace, the Auto-Facet build will, as it's name suggests, apply an auto-facet instead.

The image below illustrates the differences between the three types of smoothing: (left to right) Faceting, Auto-Facet and Smooth shading.

[[Image:SmoothTypes.jpg]]

The settings needed to achieve each type of smoothing in each build are as follows:
 
====Faceting====
''Standard Build:''
In Truespace, set the smoothing to either Faceted or Smooth. (Both settings achieve a faceted type of shading) Setting it to Auto-facet with an angle value of 0 will also achieve faceted smoothing.

''Auto-Facet Build:''
Set the smoothing to Faceted. Again, setting it to Auto-facet with an angle value of 0 will also achieve faceted smoothing.
 
====Auto-Faceting====
''Standard Build:''
(Unable to achieve as far as I have been able to tell)

''Auto-Facet Build:''
Set the smoothing to auto-faceted and enter in an appropriate angle value.(You may need to experiment to find the ideal angle. They range between 0 and 120)
 
====Smoothing====
''Standard Build:''
In Truespace, set the smoothing to auto-faceted.

''Auto-Facet Build:''
(Unable to achieve as far as I have been able to tell. Setting the auto facet value to 120 gives poor and buggy smoothing)

 
==Using PCS==

===Getting Started===

When you start PCS, you will notice another window has opened. This is a render window of whatever model is open - you can see where things are, what your ship looks like etc.

If you do want to be able to see your model in PCS, keep in mind that the render window will be taxing on your system. It will usually consume 100% of your CPU's runtime, often choking other applications including PCS itself in some cases. (This will be fixed with Kazan's upcoming release of PCS2, which has a model viewing window integrated into it in the same way ModelView32 does.)

Additionally, getting PCS to display textures is unpredictable at best. They will usually display as a solid white object. For just viewing and some pof editing, [[ModelView]]32 is generally a better choice. At least until PCS2 is out anyway.

 
===Conversion Settings===

Setting up the Options screen is quite important, because it tells PCS the default directories for things like models, maps, and cobs/scns. To get to it, go to Conversion > Options. A small options window will appear.

*In the 'Default Model Directory' section, select the COB/SCN type from the drop down list and set it to the path to which you have installed Truespace, or wherever you save all your cob or scene files from.
*Select POF from the drop down list and set it to wherever you want PCS to find your FS2 model files (this will be the default folder PCS will save files to and open files from. (Typically "C:\Games\Freespace2\data\models")
*The scaling factor refers to how many FS meters to turn EACH trueSpace meter into during cob->pof conversions. This should usually be set to 20, but it can be anything you want really. (This is the setting you can fiddle with to fix the "'''Too many polygons in same average location!'''" error. For more information on this, read the tips section at the bottom of this page.)
*The Texture Path field seems to be only partially functional. Setting it to your root FS2 directory (typically "C:\Games\Freespace2") allows you to view some textures, but I haven't found all that much of a pattern to it.

 
===COB to POF Conversions===

''This is a general guide to converting only. For a more complete guide to getting a ship in-game, have a look at [http://homepage.ntlworld.com/karajorma/FAQ/shipmods.html Karajorma's Turreting Tutorial]''

 
Let's suppose you already have your COB or SCN file modelled and waiting in Truespace. You want to see how it works in-game. 
You should now be ready to do your first model conversion. Go to Conversion > COB to POF. Select your model (if it's a SCN file, tell PCS to look for SCN files instead of COB). Hit OK.

If all goes well, depending on the complexity of your model and the power of your CPU, the conversion process may take anywhere from an instant to 10 minutes. Assuming it fits the geometry and hierarchy requirements of the Freespace 2 engine (and PCS), a message box shows up with general model and conversion information. This means the model has been successfully converted, and is now waiting to be saved. Do that first. (If you converted using the Auto-Facet build, save and switch over to using the standard version now)

For information on the geometry requirements as well as how to fix the common problems, go to [http://underworld.fortunecity.com/pacman/106/fs2mods/shipcreationguide/creatingstablegeometry.html IPAndrews tutorial] for TS or to its [http://underworld.fortunecity.com/pacman/106/fs2mods/shipcreationguide/ main page] 

 
===POF to COB conversions===

The opposite of COB to POF conversions, this feature allows you to convert a Freespace POF file into a COB file - for use in things like renders, or just general model editing. From the COB format, you can convert it to just about any other 3d model format for use in just about any 3d program. 
To do this, just open up the POF file you want to convert, go to Conversions > POF to COB, and decide on a place (and filename) to save your new COB to.

Remember that when you convert from POF to COB, all the centres of everything in the model are ignored, an annoying bug in PCS that should get fixed with Kazans PCS 2.

This means that though your objects will still be in the right places, their centers and the lights glued to them will be at 0,0,0, meaning that in all likelihood, nothing will rotate correctly. If you plan to reconvert back to POF after some editing, you'll need to manually fix the centres of all affected objects.

==POF Editing==
Before you can create a fully working Freespace model, you must add POF data to your new POF file. This is the data that controls things like the center of the model, dockpoints, eyepoints, engine glows, primary and secondary gunpoints, mass, fighter insignias, paths, shields, subsystems, textures, turrets, subobjects and FS_Open glowpoints. (You'll recognise most of these as the various tabs in PCS' main window)

A brilliant guide on each of these 'chunks' can be found here; in [http://freespace.volitionwatch.com/blackwater/fstut/fstut_index01.htm Bobboau's PCS tutorial].

 
==Tips / Common Problems==

#If PCS gives a "'''You forgot to group those objects!'''" error message during COB > POF conversions, it just means that you need to glue a local light to the main hull object in Truespace. (This usually only occurs when PCS encounters a piece of geometry not glued to anything, such as a test hull for conversion or a forgotten bit just lying about your workspace)
#If PCS gives a "'''Too many polygons in same average location!'''" error, it can mean one (or more) of three things:
##There is a duplicate of one of the objects in the SCN in the EXACT same position as another of the EXACT same shape and size. To fix it, just find the duplicate object and delete or move it.
##There is a duplicate face somewhere within the one subobject. This is usually a case of bad or unstable geometry somewhere in the model and should be fixed by hand. Look for things like polygons that shimmer as you rotate your view around them, as this is a sign that two polygons are fighting to be on top of each other in the Zbuffer. This commonly happens in very small hard to edit parts of geometry depending on your modelling techniques.
##Your object is too small in TS for PCS to be able to clearly tell the difference between two polygon locations during conversion. (This is a common problem for fighters and bombers because of how small they will appear in TS in order to fit the standard conversion ratio of 20 FS meters to each TS meter.) To fix this, scale the whole ship up in TrueSpace to the size you want it to appear as in Freespace - meter for meter. Then, before converting, set PCS's scaling to 1 rather than 20 and convert. This should fix it by effectively giving PCS more accuracy when it gets to really small numbers. The up-scaling of your model is counteracted by telling PCS that one TrueSpace meter should equal one Freespace meter, so you don't end up with cruiser sized fighters and the like.
#Only the latest versions of PCS (those above 1.1) have correct collision detection calculations during conversion. Older versions will often have problems such as weapons fire going through them, suns showing through them or even other ships going through them.
#If PCS crashes during the conversion, or spits out any other sort of error, there is a problem with the model's geometry and/or hierarchy. If you don't understand the error and a search on HLP doesn't return anything helpful, post your question in the [http://www.hard-light.net/forums/index.php/board,8.0.html Freespace Modding] section of HLP.
#In the Misc menu, there is a "Global data import" function. This is a very handy tool that will import all pof data from one model file into the one that is open. Very useful if you completely POF a particular ship and then notice that you forgot something before conversion. You can simply re-convert and then import all the data you painstakingly entered.
#PCS is unable to view or edit the '''moment of inertia''' (MOI) data. This is the data (a tensor) that controls how the model physically rotates and reacts to kinetic impacts. PCS sets it all to 0 upon conversion, which will prevent your model from spinning around when hit at all. Currently, the only way to edit this data is in [[ModelView][32. The best way to set it is to find a similar sized standard craft and use it's values here.
#If you have any other questions/problems, ask in the [http://www.hard-light.net/forums/index.php/board,8.0.html Freespace Modding]forum, but don't forget to search first, since chances are the problem has been encountered before.

[[Category:Tools]]

Ships.tbl

2008-03-20T09:32:13Z

VA: Customized Thruster Effects - Clarifications on Glow Types

Revision information.. 
::'''3.6.x branch:''' 2.336.2.79
::'''3.7 branch:''' 2.436


==General Format==
*Ship.tbl is formed of several different sections.
*All sections beginning with <nowiki>#</nowiki> need <nowiki>#</nowiki>End before the next section.
**<nowiki>#</nowiki>'''Default Player Ship'''
***Defines the default player ship in the game and also in the FRED. If in a mission appears a ship that has not been properly included to tables then game replaces the ship with the Default Player Ship.
**<nowiki>#</nowiki>'''Engine Wash Info'''
***Includes all the definitions of all engine washes used in the game.
{{Table37|
:*<nowiki>#</nowiki>'''Ship Templates'''
:**Includes entries for ship templates}}

:*<nowiki>#</nowiki>'''Ship Classes'''
:**Includes entries for every ship and also defines their attributes that are used in the game
:**Is discussed in detail at [[Ships.tbl#Table_Options|Table Options]] section.
:*'''$Player Ship Precedence'''
:**Player Ship Precedence is used in ship selection when a ship specified by the mission designer is not available to the player. The next ship on the list is used in its place (assuming that ship is allowed for the player)

==Default Player Ship==
*Defines the default ship in the game.
*Syntax: ''Name'', name of ship model as defined in [[Ships.tbl#Table_Options|Table Options]].

==Engine Wash==
*Defines the engines washes
*First entry must be named 'default'

===$Name:===
*Defines the name of the engine wash.
*Syntax: '''''String'''''

===+nocreate===
{{Table36|
*In [[Modular Tables]] name can be followed by line '''+nocreate''' that prevent game from creating an incomplete entry by leaving the entry unread unless it already exists (either in ship.tbl or in earlier parsed *-shp.tbm files) by the time the *-shp.tbm is read.}}

===$Angle:===
*Defines the angle from the engine where the engine wash exists
*Syntax: '''''Float''''', degrees

===$Radius Mult:===
*Defines engine wash multiplier
*Syntax: '''''Float'''''

===$Length:===
*Defines the length of the engine wash
*Syntax: '''''Float''''', meters

===$Intensity:===
*Defines the strength of the engine wash
*Syntax: '''''Float''''', blast effect

===Example===

$Name: Default
$Angle: 10.0
$Radius Mult: 1.2
$Length: 400
$Intensity: 1.0

==Ship Template Options==
{{Table37|
*Example of template usage [[Ship_Templates]] in which both [[GTB Artemis]] variants have been defined using a single template}}

===$Template:===
{{Table37|
*Defines the name of template
*Syntax: '''''String''''', name}}

===+Use Template:===
{{Table37|
*Another template can be used as template for the current template
*Syntax: '''''String''''', name}}

==Ships Table Options==

===$Name:===
*Model name that is used also in game. It is also used as name for the whole ship entry.
*Syntax: '''''String'''''', name

===+nocreate===
{{Table36|
*In [[Modular Tables]] name can be followed by line '''+nocreate''' that prevent game from creating an incomplete entry by leaving the entry unread unless it already exists (either in ship.tbl or in earlier parsed *-shp.tbm files) by the time the *-shp.tbm is read.}}

===+Use Template:===
{{Table37|
*Sets the table entry to use template based on an existing table entry instead of creating totally new one
*Syntax: '''''String''''', name of the template}}

===$Short name:===
*Shortened model name, for FRED, Usually more descriptive than the real name.
*Syntax: '''''String''''''

===$Species:===
*Defines species (Terran, Vasudan or Shivan). Determines many things, including the color of the engine glow, the flyby sound effects, the briefing icon and the support ship.
{{Table36|
*More species have been enabled, and all of these have to be defined in [[species_defs.tbl]].}}

*Syntax: '''''String''''', name of the species
**Example: ''Terran''

===Technical description===
List of descriptive terms for techroom and ship selection screens. Number after the quotes refers to [[tstrings.tbl]]

====Example====

<pre>
+Type: XSTR("", -1)
+Maneuverability: XSTR("", -1)
+Armor: XSTR("", -1)
+Manufacturer: XSTR("", -1)
+Description: XSTR("", -1)
$end_multi_text
+Tech Description: XSTR("", -1)
$end_multi_text
+Length: 20 m
+Gun Mounts: 4
+Missile Banks: 1
</pre>

===$POF file:===
*Filename of the model file (.pof) at data/models folder
*Syntax: '''''String.pof''''', model filename

===$Texture Replace:===
{{Table36|
*'''+old:'''
*Defines the texture to be replaced
**Syntax: '''''String''''', filename
*'''+new:'''
*Defines the new texture
**Syntax: '''''String''''', filename
}}

===$POF target file:===
*Optional hud targeting model
*Syntax: '''''String.pof''''', model filename

===$POF target LOD:===
{{Table36|
*Defines the LOD (Level-Of-Detail) of target model used in the HUD targetbox
*Syntax: '''''Integer'''''}}

===$Detail distance:===
*Defines the distance where the change between different Levels-Of-Details (LODs) occurs
*Take notice that these are base values. Model detail in Detail options, (within game press F2), applies a multiplier to these values. ''(We need a coder to post here the multiplier values that each level sets)''.
*Syntax: '''''(Detail Distances)''''' , list of '''integers''' (same amount as LODs), distances from the model in meters
**Example: ''(0, 80, 300, 900)''

===$ND:===
*No Dim field field was used in FreeSpace for ship lights. Use of glowmaps is preferred to the $ND entry. Only noticeable in Glide or Software mode.
*Syntax: '''''Color''''', red, green, blue respectively, value from 0 to 255
**Example: ''42, 42, 224''

===$Show damage:===
*No known function. Best left alone to avoid possible compatibility issues.
*Syntax: '''''Boolean''''', yes or no, usually yes

===$Impact:===
{{Table36|
*'''+Damage Type:'''
**Defines the damage type of the collision
**Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

{{Table37|
*'''+Damage Type:''' does not exist in 3.7 branch}}

===$Impact Spew:===
{{Table36|
*Used to define the impact particle spew
*'''+Max particles:'''
**Defines the maximum number of particles spewed
**Setting to zero causes model to generate no particles at all
**Syntax: '''''Integer'''''}}

{{Table37|
*In 3.7 impact spew earlier entry has been replaced with full particle emitter
*'''+Texture:'''
**Defines the texture used for the particle
**Syntax: '''''String''''', filename
*'''+Relative Position:'''
**Defines the relative position of the particle
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Velocity:'''
**Defines the relative velocity of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Normal:'''
**Defines the relative normal of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Normal Variance:'''
**Syntax: '''''Float''''
*'''+Min Radius:'''
**Syntax: '''''Float''''
*'''+Max Radius:'''
**Syntax: '''''Float''''
*'''+Min Speed:'''
**Syntax: '''''Float''''
*'''+Max Speed:'''
**Syntax: '''''Float''''
*'''+Min Lifetime:'''
**Syntax: '''''Float''''
*'''+Max Lifetime:'''
**Syntax: '''''Float''''
*'''+Min Particles:'''
**Syntax: '''''Integer''''
*'''+Max Particles:'''
**Syntax: '''''Integer''''}}

===$Damage Spew:===
{{Table36|
*Used to define the damage particle spew
*'''+Max particles:'''
**Defines the maximum number of particles spewed
**Setting to zero causes model to generate no particles at all
**Syntax: '''''Integer'''''}}

{{Table37|
*In 3.7 damage spew earlier entry has been replaced with full particle emitter
*'''+Texture:'''
**Defines the texture used for the particle
**Syntax: '''''String''''', filename
*'''+Relative Position:'''
**Defines the relative position of the particle
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Velocity:'''
**Defines the relative velocity of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Relative Normal:'''
**Defines the relative normal of the particle emitter
**Syntax: '''''Vector'''', three '''floats''', x-axis, y-axis, z-axis, respectively
*'''+Normal Variance:'''
**Syntax: '''''Float''''
*'''+Min Radius:'''
**Syntax: '''''Float''''
*'''+Max Radius:'''
**Syntax: '''''Float''''
*'''+Min Speed:'''
**Syntax: '''''Float''''
*'''+Max Speed:'''
**Syntax: '''''Float''''
*'''+Min Lifetime:'''
**Syntax: '''''Float''''
*'''+Max Lifetime:'''
**Syntax: '''''Float''''
*'''+Min Particles:'''
**Syntax: '''''Integer''''
*'''+Max Particles:'''
**Syntax: '''''Integer''''}}

===$Debris:===
{{Table36|
*'''+Damage Type:'''
**Defines the damage type of the debris
**Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

{{Table37|
*'''+Damage Type:''' does not exist in 3.7 branch
*'''+Min Lifetime:'''
**Defines the minimum lifetime of the debris
**Syntax: '''''Float''''
*+Max Lifetime:
**Defines the maximum lifetime of the debris
**Syntax: '''''Float''''
*+Min Speed:
**Defines the minimum speed of the debris
**Syntax: '''''Float''''
*+Max Speed:
**Defines the maximum speed of the debris
**Syntax: '''''Float''''
*+Min Rotation speed:
**Defines the minimum rotational speed of the debris
**Syntax: '''''Float''''
*+Max Rotation speed:
**Defines the maximum rotational speed of the debris
**Syntax: '''''Float''''}}

===$Density:===
*This defines how hard you hit something. If you set it very high, a collision will severely damage your ship, and push the lower density object away; the higher the numbers are, the harder they will hit and the farther they will be pushed. Setting a density of 10 on a fighter with 180 hitpoints will cause the fighter to immediately explode if it collides with, say, an asteroid.
*Syntax: '''''Float''''', usually 1

===$Damp:===
*Damp affects how quickly you will accel/decel to your target velocity. Higher damp means slow acceleration and deceleration. The lower this number, the faster the ship responds. For example, specifying a value of 0.0 means there is no damping, in other words, people would say, "this has no physics, like Wing Commander." The more damping, the harder to control, but the more smoothly it moves.
*Syntax: '''''Float'''''

===$Rotdamp:===
*Same thing, but for rotational movement.
*Syntax: '''''Float'''''

===$Max Velocity:===
*Defines maximum velocities with standard energy settings on x (left/right), y (up/down), and z (forward) -axis (respectively). z -axis velocity defines the maximum forward velocity.
*Syntax: '''''Vector''''', three '''floats''', x-axis, y-axis, z-axis, respectively, meters per second
**Example: ''0.0, 0.0, 80.0''

===$Rotation time:===
*Defines rotation times around the x, y, and z -axis. Number is seconds it takes to complete rotate a ship (360 degrees) around the given axis
*Syntax: '''''Vector''''', three '''floats''', seconds per 360 degree turn around x-axis, y-axis, z-axis, respectively
**Example: ''3.0, 2.6, 5.0''

===$Rear Velocity:===
*Defines rear velocity
*Syntax: '''''Float''''', meters per second

===$Forward accel:===
*Number of seconds needed from full stop to maximum velocity
*Syntax: '''''Float''''', seconds

===$Forward decel:===
*Number of seconds needed from maximum velocity to full stop
*Syntax: '''''Float''''', seconds

===$Slide accel:===
*Same for sliding as the $Forward accel: is for for normal movement.
*Syntax: '''''Float''''', seconds

===$Slide decel:===
*Same for sliding as the $Forward decel: is for for normal movement.
*Syntax: '''''Float''''', seconds

===$Glide:===
{{Table36|
*Allows gliding in game, i.e. turning the ship's facing without changing its direction.
*Syntax: '''''Boolean''''', yes or no}}
{{Table37|
*'''+Max Glide Speed:'''
**Defines the maximum glide speed if the glide has been enabled
**Syntax: '''''Float'''''}}

===$Warpin type:===
{{Table36|
*Allow an animation to be defined as a warpin effect.
*Can be defined as ''BTRL'' or ''default''.
*Syntax: '''''String'''''}}

===$Warpin speed:===
{{Table36|
*Sets the speed at which the ship warps in for '''default''' warpin effect
*Sets the time that the ships warp in (not the animation itself) takes for '''BTRL''' type warpin effects
*Syntax: '''''Float''''', meters per second or miiliseconds}}

===$Warpin time:===
{{Table36|
*Defines the effect duration
*Syntax: '''''Float''''', seconds}}

===$Warpin radius:===
{{Table36|
*Defines the effect radius
*Syntax: '''''Float''''', meters}}

===$Warpin animation:===
{{Table36|
*Defines the animation used as the warpin effect.
*Syntax: '''''String''''', filename}}

===$Warpout type:===
{{Table36|
*Allow an animation to be defined as a warpout effect.
*Can be defined as ''BTRL'' or ''default''.
*Syntax: '''''String'''''}}

===$Warpout speed:===
{{Table36|
*Sets the speed at which the ship warps out for '''default''' warpout effect
*Sets the time that the ships warp out (not the animation itself) takes for '''BTRL''' type warpout effects
*Syntax: '''''Float''''', meters per second or milliseconds}}

===$Warpout time:===
{{Table36|
*Defines the effect duration
*Syntax: '''''Float''''', seconds}}

===$Warpout radius:===
{{Table36|
*Defines the effect radius
*Syntax: '''''Float''''', meters}}

===$Warpout animation:===
{{Table36|
*Defines the animation used as the warpout effect.
*Syntax: '''''String''''', filename}}

===$Player warpout speed:===
{{Table36|
*Sets the speed at which the player warps out from the game
*Syntax: '''''Float'''''}}

===$Expl inner rad:===
*Radius at which the full explosion damage is done
*Syntax: '''''Float''''', meters

===$Expl outer rad:===
*Maximum radius at which any damage is done
*Syntax: '''''Float''''', meters

===$Expl damage:===
*Amount of damage done inside the inner radius
*Syntax: '''''Float''''', damage

===$Expl blast:===
*The intensity of the blast effect when you're within the outer radius
*Syntax: '''''Float''''', blast effect

===$Expl Propagates:===
*This decides whether the ship explodes into debris immediately, or whether it has the many small explosions before breaking apart slowly
*Syntax: '''''Boolean''''', yes or no

===$Shockwave Damage Type:===
{{Table36|
*'''REQUIRES ADDITIONAL TABLE'''. Defines the damage type used for the ship explosions
*Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

===$Shockwave Speed:===
*Speed shockwave expands at, 0 means no shockwave
*Syntax: '''''Float''''', meters per second

===$Shockwave count:===
*Defines the number of shockwaves to spawned
*Syntax: '''''Integer'''''

===$Shockwave model:===
{{Table36|
*Defines the textured model used as the ship's 3D shockwave
*Syntax: '''''String.pof''''', model filename}}

===$Shockwave name:===
{{Table36|
*Defines the name of the animation to used for the 2D shockwave
*Syntax: '''''String''''', filename}}

===$Weapon Model Draw Distance:===
{{Table36|
*Distance that external weapons are shown, ie. missiles and such.
*Syntax: '''''Float''''', meters
**Default: ''200''}}

===Primary Weapons===

====$Allowed PBanks:====
*List of allowed primary weapons in brackets (weapon name marked with quotes).
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the primary weapon banks '''can optionally''' be given their own list of allowed weapons, in which case each bank has its own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Allowed Dogfight PBanks:====
*Primary weapons for multiplayer dogfights.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the primary weapon dogfight banks '''can optionally''' be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Default PBanks:====
*Defines default primary weapons for each of the primary weapon banks
*Syntax: '''''( "String" "String" )''''', names of the weapons

====$PBank Capacity:====
{{Table36|
*Defines ammunition capacity of primary weapon banks. In brackets, different weapon banks separated by commas.
*Syntax: '''''( Integer, Integer )'''''}}

====$Show Primary Models:====
{{Table36|
*Defines the use of weapon models for primary weapons. In brackets, different weapon banks may have different definitions
*Syntax: '''''( Boolean Boolean )''''', yes or no
**Example: ''( YES YES )'' - Note the spaces on the insides of the brackets.}}

===Secondary Weapons===

====$Allowed SBanks:====
*Same for secondary weapons.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the secondary weapon banks can be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Allowed Dogfight SBanks:====
*Same for secondary weapons.
*Syntax: '''''( "String" "String" )''''', names of the weapons
{{Table36|
*Each of the secondary weapon dogfight banks can be given their own list of allowed weapons, in which case each bank has it's own bracketed entry.
*Syntax: '''''( "String" "String" ) ( "String" "String" )'''''}}

====$Default SBanks:====
*Defines default primary weapons for each of the primary weapon banks
*Syntax: '''''( "String" "String" )''''', names of the weapons

====$SBank Capacity:====
*Defines ammunition capacity of secondary weapon banks. In brackets, different weapon banks separated by commas.
*Syntax: '''''( Integer, Integer )'''''

====$Show Secondary Models:====
{{Table36|
*Defines the use of weapon models for secondary weapons. In brackets, different weapon banks may have different definitions
*Syntax: '''''( Boolean Boolean )'''''
**Example: ''(YES YES)''}}

===$Shields:===
*Determines the shield strength
*Syntax: '''''Float''''', total shield strength

===$Shield Color:===
*RGB value for shield color
*Syntax: '''''Color''''', red, green, blue respectively, value from 0 to 255
**Example: ''100, 100, 255''

===$Power Output:===
*The amount of energy available. The higher the output, the faster your weapons recharge.
*Syntax: '''''Float'''''

===$Shield Regeneration Rate:===
{{Table36|
*Repair rates for shields at percent per second
*Syntax: '''''Float''''', multiplier of total shield hitpoints recharged each second. ('''NOT A PERCENTAGE''', 0.02 equals 2% recharged per second)
**Default: ''0.02''}}

===$Weapon Regeneration Rate:===
{{Table36|
*Regeneration rates for primary guns at percent per second
*Syntax: '''''Float''''', multiplier of total gun energy recharged each second ('''NOT A PERCENTAGE''', 0.04 equals 4% recharged per second)
**Default: ''0.04''}}

===$Max Oclk Speed:===
*Can also be '''$Max Overclock Speed:'''
*Maximum velocity with all energy diverted to engines
*Syntax: '''''Float''''', meters per second

===$Max Weapon Eng:===
*Can also be '''$Max Weapon Energy:'''
*The maximum amount of energy you can store in your primary weapons bank.
*Syntax: '''''Float'''''

===$Hitpoints:===
*How much damage the ship can take
*Syntax: '''''Float''''', hitpoints
**Default: ''100''

===$Hull Repair Rate:===
{{Table36|
*Repair rates for hull at percent per second
*Syntax: '''''Float''''', multiplier of hitpoints repaired per second, '''NOT A PERCENTAGE''', 0.01 equals 1% recharged per second}}

===$Subsystem Repair Rate:===
{{Table36|
*Repair rates for sybsystems percent per second
*Syntax: ''Value'', multiplier of total subsystem hitpoints repaired per second, '''NOT A PERCENTAGE''', 0.01 equals 1% recharged per second}}

===$Armor Type===
{{Table36|
*'''REQUIRES ADDITIONAL TABLE'''. Defines armor type used for the ship
*Syntax: '''''String''''', name of the armor as defined in [[armor.tbl]]}}

===$Flags:===
*See [[Ships.tbl#Ships.tbl_flags|below]]
*Syntax: '''''( "String" "String" )''''', names of the flags assigned to the ship
**Example: ( "fighter" "in tech database" )

===$AI Class:===
*Default AI class
*Syntax: '''''String''''', name of the AI class as defined in [[ai.tbl]]

===$Afterburner:===
*Defines if the ships has afterburner
*Syntax: '''''Boolean''''', yes or no
*'''+Aburn Max Vel:'''
**Syntax: '''''Vector''''', three '''floats''', x-axis, y-axis, z-axis, respectively, meters per second
*'''+Aburn For accel:'''
**Defined only for the forward acceleration. In same format as $Forward accel:
**Syntax: '''''Float''''', seconds
*'''+Aburn Fuel:'''
**Amount of afterburner fuel the ship has
**Syntax: '''''Float''''', fuel
*'''+Aburn Burn Rate:'''
**Rate the fuel is consumed when afterburner is engaged (in units per seconds)
**Syntax: '''''Float''''', fuel units per second
*'''+Aburn Rec Rate:'''
**Rate the fuel is restored.
**Syntax: '''''Float''''', fuel units per second
{{Table36|
*'''$Trails:'''
**Allows afterburner trails to be used
**'''+Bitmap:'''
***Texture used to draw the afterburner trail
***Syntax: '''''String''''', filename
**'''+Width:'''
***Width of afterburner trail at the beginning of it (ie. the thruster end)
***Syntax: '''''Float''''', meters
**'''+Alpha:'''
***Transparancy of the trail, value from 1 (non-transparent) to 0 (totally transparent)
***Syntax: '''''Float'''''
**'''+Life:'''
***How long the trail will last
***Syntax: '''''Float''''', seconds}}

===$Countermeasure Type:===
{{Table36|
*Defines the weapon used as a countermeasure. Weapon does not have to be included in the countermeasure section of the weapons.tbl, but it has to have "countermeasure" flag in that case.
*Syntax: '''''String''''', name of the weapon as defined in [[weapons.tbl]]}}

===$Countermeasures:===
*Number of countermeasures that can be loaded to the ship
*Syntax: '''''Integer'''''

===$Scan time:===
*Time it takes to scan the ship
*Syntax: '''''Integer''''', milliseconds

===$EngineSnd:===
*Engine sound used for the ship with number referring to sounds.tbl
*Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]

===$Closeup_pos:===
*How the model will show at techroom. The position of the camera relative to the model in the tech room and the target box view
*Syntax: '''''Vector''''', three '''floats''', x, y and z values respectively

===$Closeup_zoom:===
*How the model will show at techroom. How far the camera's zoomed in, defines camera's FOV.
*Syntax: '''''Float''''', radians

===$Topdown offset:===
{{Table36|
*Specifies how high the camera is above the center point of a ship in topdown camera views, or 2D missions.
*Syntax: '''''Float''''', meters}}

===$Shield_icon:===
*This .ani file must be at data/hud and included to the hud.tbl.
{{Table36|
*Reference to the hud.tbl is no longer needed.}}

*Syntax: ''Filename''

===$Ship_icon:===
*The icon used in ship selection.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: ''Filename''

===$Ship_anim:===
*The glowing green grid animation used in ship selection.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: '''''String''''', filename

===$Ship_overhead:===
*The overhead view used in the weapons loadout.
{{Table36|
*Ship model is used by default to generate the image.}}

*Syntax: '''''String''''', filename

===$Score:===
*Points awarded for destroying the ship
*Syntax: '''''Float'''''

===Customized Thruster Effects===
{{Table36|
*'''Defines the primary thruster glow - the one visible only from behind'''
**'''$Thruster Bitmap 1:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Normal:''' under the '''$Thrustglows:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 1a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Afterburner:''' under the '''$Thrustglows:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster01 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''
*'''Defines the secondary glow type-effect for thrusters - the feathery trail like haze behind the main glow'''
**'''$Thruster Bitmap 2:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Sec_Normal:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 2a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Sec_Afterburn:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster02 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''
**'''$Thruster02 Length factor:'''
***Defines the length multiplier for the trail type (secondary) glowpoint thrusters
***Replaces the older '''$Thruster01 Length factor:'''
***Syntax: '''''Float'''''
*'''Defines the tertiary glow type-effect for thrusters - the one visible from all directions'''
**NOTE: The rotation of this effect is jittered, which can look quite bad with certain types of effects.
**'''$Thruster Bitmap 3:'''
***Defines the effect for the standard drives. Overrides [[Species_defs.tbl]] line '''+Ter_Normal:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster Bitmap 3a:'''
***Defines the effect for the afterburner. Overrides [[Species_defs.tbl]] line '''+Ter_Afterburn:''' under the '''$ThrustAnims:''' entry.
***Syntax: '''''String''''', filename
**'''$Thruster03 Radius factor:'''
***Defines the radius multiplier
***Syntax: '''''Float'''''}}

===$Thruster Particles:===
{{Table36|
*Defines the alternative particle thruster
*'''$Thruster Particle Bitmap:''' OR '''$Afterburner Particle Bitmap:'''
**Name of the animation used for particle thrusters, up to '''three''' can be defined for both '''standard''' thrusters and '''afterburners''' (6 in total). Afterburner particles require at least 1 existing particle thruster entry.
**Syntax: '''''String''''', filename
*'''$Min Radius:'''
**Defines the minimum radius of new particles
**Syntax: '''''Float''''', meters
*'''$Max Radius:'''
**Defines the maximum radius of new particles
**Syntax: '''''Float''''', meters
*'''$Min created:'''
**Defines the minimum amount of particles created
**Syntax: '''''Float'''''
*'''$Max created:'''
**Defines the maximum amount of particles created
**Syntax: '''''Float'''''
*'''$Variance:'''
**Value that describes the randomness of particle generation, values close to 0 will cause particles to spew very close to the thrusters normal while values close 1 will cause some particles to be spewed even to opposite direction
**Syntax: '''''Float'''''}}

===$Stealth:===
*Defines: Ship behaves as a stealth-ship: non-targettable, and not on radar.
{{Table36|
This field is deprecated, and mods using 3.6.8 and above should use the "stealth" flag.}}

===$Max decals:===
{{Table36|
*Defines: Maximum number of weapon decals on a ship
*Syntax: '''''Integer''''', maximum number of decals on ship
**Default: 50 for anything below cruiser size, 100 for anything below superdestroyer/installation size, 300 for anything above destroyer size, 10 for everything else.}}

===$Trail:===
*These are the origins of the white contrails that appear in the nebula missions. Ship may have multiple trails.
*'''+Offset:'''
**The position of the contrail's head
**Syntax: '''''Vector''''', three '''floats''', x, y and z values respectively, relative to the center point of the model
*'''+Start Width:'''
**The width of the contrail's head
**Syntax: '''''Float''''', meters
*'''+End Width:'''
**The width of the contrail's tail
**Syntax: '''''Float''''', meters
*'''+Start Alpha:'''
**The opacity of the contrail's head
**Syntax: '''''Float''''', value between 0 and 1
*'''+End Alpha:'''
**The opacity of the contrail's tail
**Syntax: '''''Float''''', value between 0 and 1
*'''+Max Life:'''
**How long the contrail remains
**Syntax: '''''Float'''''', seconds
*'''+Spew Time:'''
**Syntax: '''''Integer'''''
*'''+Bitmap:'''
**The image to use for the contrail.
**Syntax: '''''String''''', filename

===$Thruster:===
{{Table36|
*Defines maneuvering thrusters. Ship may have multiple $Thrusters defined.
*'''+Index:'''
**Defines the index number of the manoeuvring thruster defined in this entry
**Syntax: '''''Integer'''''
*'''+Used for:'''
**Defines the maneuver that triggers the maneuvering thruster
**List of maneuvers: Bank right, Bank left, Pitch up, Pitch down, Roll right, Roll left, Slide right, Slide left, Slide up, Slide down, Forward, Reverse
**Syntax: '''''String'''''}}
{{Table37|
*'''+Flags:'''
**Flags that modify thruster behavior. As of now, only "no scale" exists, which causes all thrusters to be displayed at the same size regardless of thrust amount.
**List of flags: no scale
**Syntax: ("'''''String'''''"), names of the flags}}
{{Table36|
*'''+Position:'''
**Defines thruster location
**Syntax: ( '''''Float''''' '''''Float''''' '''''Float''''' ), position from the ships center point, x, y, z axis respectively
*'''+Normal:'''
**Defines the direction where the thruster points to
**Syntax: ( '''''Float''''' '''''Float''''' '''''Float''''' ), direction of the thrusters normal, x, y, z axis respectively
*'''+Texture:'''
**Defines the graphic that will be used for trail, rendered like beams
**Syntax: '''''String''''', filename
*'''+Radius:'''
**Defines the radius of cylinder
**Syntax: '''''Float''''', meters
*'''+Length:'''
**Defines the length of thruster trail
**Syntax: '''''Float''''', meters
*'''+StartSnd:'''
**Defines the sound played when the thruster is started
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]
*'''+LoopSnd:'''
**Defines the sound played when the thruster is continuously used
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]
*'''+StopSnd:'''
**Defines the sound played when the thruster is shutting down
**Syntax: '''''Integer''''' or '''''String''''', name or identification number of the sound as defined in [[sounds.tbl]]}}

===[[Subsystems|$Subsystem:]]===

==Ships.tbl flags==

==="no_collide"===
*Defines ship as non-collideable, ie. everything will go through it

==="player_ship"===
*Makes it possible to player to fly the ship

==="default_player_ship"===
*Makes this ship as a default part of the loadout options in FRED

----

===Ship Type===
*Flags in this section are used to define the type of the ship
*Use only one '''ship type''' flag per table entry
{{Table36|
*New ship types can be defined in [[objecttypes.tbl]]}}

===="repair_rearm"====
*Alternate name for "support"

===="support"====
*Defines the ship as repair and rearm vessel and sets AI behaviour accordingly
*Only one such vessel can be defined per species

===="cargo"====
*Defines ship as a cargo crate and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="fighter"====
*Defines ship as a fighter and also sets the AI behaviour
*In FS1/FS2 only ships flagged as fighters or bombers can accept the full set of player orders

===="bomber"====
*Defines ship as a bomber and also sets the AI behaviour
*In FS1/FS2 only ships flagged as fighters or bombers can accept the full set of player orders

===="transport"====
*Defines ship as a transport and also sets the AI behaviour

===="freighter"====
*Defines ship as a freighter and also sets the AI behaviour

===="capital"====
*Defines ship as a capital ship and also sets the AI behaviour

===="supercap"====
*Alternate name for "super cap"

===="super cap"====
*Defines ship as a super capital ship and also sets the AI behaviour

===="drydock"====
*Defines ship as a drydock and also sets the AI behaviour

===="cruiser"====
*Defines ship as a cruiser and also sets the AI behaviour

===="navbuoy"====
*Defines ship as a navbuoy and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="sentrygun"====
*Alternate name for "sentry gun"

===="sentry gun"====
*Defines ship as a sentrygun and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="escapepod"====
*Alternate name for "escape pod"

===="escape pod"====
*Defines ship as a escapepod and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="corvette"====
*Defines ship as a corvette and also sets the AI behaviour

===="gas miner"====
*Defines ship as a gas miner and also sets the AI behaviour

===="awacs"====
*Defines ship as a AWACS and also sets the AI behaviour

===="knossos"====
*Alternate name for the "Knossos device"

===="knossos device"====
*Defines ship as a Knossos and also sets the AI behaviour
*In FS1/FS2 ships that are marked with this flag cannot accept any player orders

===="stealth"====
{{Table36|
*Defines ship as a stealth-ship: non-targettable, and not on radar.}}

===="no type"====
*Does ???

----

==="ship copy"===
*Defines the ship as a copy of another model

==="in tech database"===
*Includes ships description to the tech database from the beginning of the campaign

==="in tech database multi"===
*Includes the ship to multiplayer tech database

==="dont collide invisible"===
*Defines invisible textures as non-collideable (For example, a hangar entrace)

==="big damage"===
*Limits the damage made to the ship by non-huge weapons.

==="no_fred"===
*Ship will not appear in FRED.

==="ballistic primaries"===
{{Table36|
*Enables the ship to use ballistic primaries
*No longer needed, game handles it automatically}}

==="flash"===
{{Table36|
*Makes a flash when a ship dies}}

==="surface shields"===
{{Table36|
*Shots that impact the hull are applied to shields, regardless of if the ship has a shield mesh.}}

==="show ship"===
{{Table36|
*Enable rendering the ship even when the ship is a player ship
*Will result in the player's ship model being rendered, when in cockpit mode}}

==="generate icon"===
{{Table36|
*Creates a HUD icon from the model itself}}

==="gun convergence"===
{{Table36|
*Enables ship to use the firing points' normals in defining the direction where the weapon fire}}

==="no primary linking"===
{{Table37|
*Prevents ships from linking primary weapons}}

==Player Ship Precedence==
*Syntax: ( '''''"String" "String"''''')
===Example===

<pre>
$Player Ship Precedence: (
"GTF Ulysses"
"GTF Hercules"
"GTB Medusa"
"GTB Ursa" )
</pre>

==Sample==

<pre>
#Default Player Ship

$Name: GTF Ulysses

#End

#Engine Wash Info

$Name: Default
$Angle: 10.0
$Radius Mult: 1.2
$Length: 400
$Intensity: 1.0

#End

#Ship Classes
$Name: GTF Ulysses
$Short name: TFight
$Species: Terran
+Type: XSTR("Space Superiority", -1)
+Maneuverability: XSTR("Excellent", -1)
+Armor: XSTR("Light", -1
+Manufacturer: XSTR("Triton / Mekhu", -1)
+Description: XSTR( " ", -1)
$end_multi_text
+Tech Description: XSTR("Descriptive text", -1)
$end_multi_text
+Length: 16 m
+Gun Mounts: 4
+Missile Banks: 1
$POF file: fighter01.pof
$Detail distance: (0, 80, 300, 900)
$ND: 42 42 244
$Show damage: YES
$Density: 1
$Damp: 0.1
$Rotdamp: 0.35
$Max Velocity: 0.0, 0.0, 70.0
$Rotation time: 3.0, 2.6, 5.0
$Rear Velocity: 0.0
$Forward accel: 2.0
$Forward decel: 1.5
$Slide accel: 0.0
$Slide decel: 0.0
$Expl inner rad: 25.0
$Expl outer rad: 55.0
$Expl damage: 15.0
$Expl blast: 1000.0
$Expl Propagates: NO
$Shockwave Speed: 0.0
$Allowed PBanks: ( "Subach HL-7" "Prometheus R")
$Allowed Dogfight PBanks: ( "Subach HL-D" "Prometheus D" )
$Default PBanks: ( "Subach HL-7" "Prometheus R" )
$Allowed SBanks: ( "Rockeye" "Tempest" )
$Allowed Dogfight SBanks: ( "Tempest D" "Hornet D" )
$Default SBanks: ( "Harpoon" )
$SBank Capacity: ( 40 )
$Shields: 380
$Shield Color: 100 100 255
$Power Output: 2.0
$Max Oclk Speed: 94.0
$Max Weapon Eng: 80.0
$Hitpoints: 180
$Flags: ( "player_ship"
"default_player_ship"
"fighter"
"in tech database")
$AI Class: Captain
$Afterburner: YES
+Aburn Max Vel: 0.0, 0.0, 150.0
+Aburn For accel: 0.7
+Aburn Fuel: 300.0
+Aburn Burn Rate: 50.0
+Aburn Rec Rate: 25.0
$Countermeasures: 25
$Scan time: 2000
$EngineSnd: 128
$Closeup_pos: 0.0, 0.0, -22
$Closeup_zoom: 0.5
$Shield_icon: shield-f01
$Ship_icon: iconfighter01
$Ship_anim: ssfighter01
$Ship_overhead: loadfighter01
$Score: 8
$Trail:
+Offset: -7.75 -2.8 0.75
+Start Width: 0.25
+End Width: 0.05
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 1.0
+Spew Time: 60
+Bitmap: Contrail01
$Trail:
+Offset: 7.75 -2.8 0.75
+Start Width: 0.25
+End Width: 0.05
+Start Alpha: 1.0
+End Alpha: 0.0
+Max Life: 1.0
+Spew Time: 60
+Bitmap: Contrail01
$Subsystem: communication, 10, 0
$Subsystem: navigation, 10, 0
$Subsystem: weapons, 20, 0
$Subsystem: sensors, 10, 0
$Subsystem: engines, 35, 0

#End

$Player Ship Precedence: (
"GTF Ulysses")
</pre>

[[Category:Tables]]

Asteroid.tbl

2008-03-07T09:54:25Z

VA: Whoops, broke syntax

Revision information.. 
::'''3.6.x branch:''' 2.35.2.11
::'''3.7 branch:''' 2.46

==General Format==
*Asteroid.tbl is used to define all asteroids and debris pieces in-game.
*'''#Asteroid Types'''
*Asteroid and debris data
*'''#End'''
*'''$Impact Explosion:'''
**Defines the effect used when weapon strikes at asteroid
**Syntax: ''Filename''
*'''$Impact Explosion Radius:'''
**Defines the radius of the effect
**Syntax: ''Value'', (meters)

==Asteroid and Debris Data==
*Used to define asteroid types and their physical characteristics
*First three entries are different sized asteroids, small medium and large respectively
*Next three are debris pieces for the 1st species in the [[species_defs.tbl]]
*And so on in series of three

===$Name:===
*Defines the name of asteroid or debris object

===$POF file1:===
*Defines the name of the model file (.pof) used for asteroid or debris model
*Syntax: '''String.pof''', filename

===$POF file2:===
*'''''Note: This does not work for debris chunks. The game will always only use POF file1.'''''
*Defines the name of the alternate asteroid or debris model of the set size
*Syntax: '''String.pof''' or '''none''', filename

===$POF file3:===
*'''''Note: This does not work for debris chunks. The game will always only use POF file1.'''''
*Defines the name of the alternate asteroid model
*If the object in question is has '''$POF file2:''' set as ''none'' then this entry is not needed
*Syntax: '''String.pof''' or '''none''', filename

===$Detail distance:===
*Definies the distance where the change between different Levels-Of-Details (LODs) occurs
*Syntax: ( '''Integer list''' ), comma separated '''integers''', one for each LOD
**Example: (0, 30, 80, 150)

===$Max Speed:===
*Defines the maximum velocity of the asteroid
*Syntax: '''Float''', meters per second

===$Damage Type:===
{{Table36|
*Defines the damage type of the asteroid explosion. '''REQUIRES ADDITIONAL TABLE FILE'''.
*Syntax: '''String''', name of the damage type as referenced in [[armor.tbl]]}}

{{Table37|
*3.7 branch lacks '''$Damage Type:''' option}}

===$Expl inner rad:===
*Radius at which the full explosion damage is done
*Syntax: '''Float''', meters

===$Expl outer rad:===
*Maximum radius at which any damage is done
*Syntax: '''Float''', meters

===$Expl damage:===
*Amount of damage done inside the inner radius
*Syntax: '''Float''', damage

===$Expl blast:===
*The intensity of the blast effect when you're within the outer radius
*Syntax: '''Float''', blast effect

===$Hitpoints:===
*Defines the hitpoints of the asteroid or debris piece. Hitpoints are modified downward by skill level.
*Syntax: '''Float''', hitpoints

==Sample==
*Single asteroid entry fos retail FS2 table

<pre>
#Asteroid Types

$Name: Small Asteroid
$POF file1: ast03.pof
$POF file2: asta03.pof
$POF file3: astb03.pof
$Detail distance: (0, 30, 80, 150)
$Max Speed: 60.0
$Expl inner rad: 0.0
$Expl outer rad: 0.0
$Expl damage: 0.0
$Expl blast: 0.0
$Hitpoints: 23

#End

$Impact Explosion: ExpMissilehit1
$Impact Explosion Radius: 20.0
</pre>

[[Category:tables]]

Asteroid.tbl

2008-03-07T09:52:23Z

VA: Note about debris fields only using the first pof file defined

Revision information.. 
::'''3.6.x branch:''' 2.35.2.11
::'''3.7 branch:''' 2.46

==General Format==
*Asteroid.tbl is used to define all asteroids and debris pieces in-game.
*'''#Asteroid Types'''
*Asteroid and debris data
*'''#End'''
*'''$Impact Explosion:'''
**Defines the effect used when weapon strikes at asteroid
**Syntax: ''Filename''
*'''$Impact Explosion Radius:'''
**Defines the radius of the effect
**Syntax: ''Value'', (meters)

==Asteroid and Debris Data==
*Used to define asteroid types and their physical characteristics
*First three entries are different sized asteroids, small medium and large respectively
*Next three are debris pieces for the 1st species in the [[species_defs.tbl]]
*And so on in series of three

===$Name:===
*Defines the name of asteroid or debris object

===$POF file1:===
*Defines the name of the model file (.pof) used for asteroid or debris model
*Syntax: '''String.pof''', filename

===$POF file2:=== (Note: This does not work for debris chunks. The game will always only use POF file1.)
*Defines the name of the alternate asteroid or debris model of the set size
*Syntax: '''String.pof''' or '''none''', filename

===$POF file3:=== (Note: This does not work for debris chunks. The game will always only use POF file1.)
*Defines the name of the alternate asteroid model
*If the object in question is has '''$POF file2:''' set as ''none'' then this entry is not needed
*Syntax: '''String.pof''' or '''none''', filename

===$Detail distance:===
*Definies the distance where the change between different Levels-Of-Details (LODs) occurs
*Syntax: ( '''Integer list''' ), comma separated '''integers''', one for each LOD
**Example: (0, 30, 80, 150)

===$Max Speed:===
*Defines the maximum velocity of the asteroid
*Syntax: '''Float''', meters per second

===$Damage Type:===
{{Table36|
*Defines the damage type of the asteroid explosion. '''REQUIRES ADDITIONAL TABLE FILE'''.
*Syntax: '''String''', name of the damage type as referenced in [[armor.tbl]]}}

{{Table37|
*3.7 branch lacks '''$Damage Type:''' option}}

===$Expl inner rad:===
*Radius at which the full explosion damage is done
*Syntax: '''Float''', meters

===$Expl outer rad:===
*Maximum radius at which any damage is done
*Syntax: '''Float''', meters

===$Expl damage:===
*Amount of damage done inside the inner radius
*Syntax: '''Float''', damage

===$Expl blast:===
*The intensity of the blast effect when you're within the outer radius
*Syntax: '''Float''', blast effect

===$Hitpoints:===
*Defines the hitpoints of the asteroid or debris piece. Hitpoints are modified downward by skill level.
*Syntax: '''Float''', hitpoints

==Sample==
*Single asteroid entry fos retail FS2 table

<pre>
#Asteroid Types

$Name: Small Asteroid
$POF file1: ast03.pof
$POF file2: asta03.pof
$POF file3: astb03.pof
$Detail distance: (0, 30, 80, 150)
$Max Speed: 60.0
$Expl inner rad: 0.0
$Expl outer rad: 0.0
$Expl damage: 0.0
$Expl blast: 0.0
$Hitpoints: 23

#End

$Impact Explosion: ExpMissilehit1
$Impact Explosion Radius: 20.0
</pre>

[[Category:tables]]

Animation Code

2008-02-25T09:56:51Z

VA: Note about the '$triggered:' subobject property

Revision information.. '''''Ship.cpp''''' 
::'''3.6.x branch:''' 2.336.2.73
::'''3.7 branch:''' 2.427

Known commonly as Bob's animation code as the code was written by Bobboau. Enables submodels defined in [[ships.tbl]] or in any related modular table to be animated in game. Animation code is included to the subsystem entry in similar manner as with [[Animation_Code#Setting_Turret_Angle|multipart turrets]]

==Important Note: "$triggered:" Subobject Property==
For any animated subobject other than turrets, you must have "$triggered:" written in the subobject properties field of that subobject for the model file (POF) that you wish to animate.

==$Animation:==
{{Table36|*Animation classes are defined in submodels description
*Syntax: '''String''', animation ''class''
*'''Available animation types:'''
**Triggered}}

===Animation Type===
{{Table36|
*Animation type defines when the animation is used
*Currently supported animation types:
**'''initial'''
***Animation code is started when the mission begins. Unlike other animation types this requires only '''angle''' to be set
**'''docking'''
***Animation code is started when ship starts docking
**'''docked'''
***Animation code is started when ship is docked
**'''primary_bank'''
***Animation code is started when a primary bank is selected (armed)
**'''secondary_bank'''
***Animation code is started when a secondary bank is selected (armed)
**'''door'''
***Animation code starts when ship launches or retrives others through it's fighterbay.
**'''afterburner'''
***Animation code is started when ships afterburner is engaged
**'''turret firing'''
***Animation code is started when selected turret is firing
**'''scripted'''
***Animation code is started when it is triggered with scripts (see [[scripting.tbl]])
*Syntax: '''$type:''' ''Type''}}

===Animation Sub-Type===
{{Table36|
*Optional more accurate descriptor for the animation type
*'''primary bank''' or '''secondary bank'''
**Syntax: '''+sub_type:''' ''Value'', 0 is the 1st weapon bank, 1 is the 2nd weapon bank, etc.
*'''turret firing'''
**Syntax: '''+sub_type:''' ''Value'', model number of the turret that triggers the animation. NOTE: This feature currently does not work on multipart turrets.
}}

===Animation Code===

====Initial type====
{{Table36|
*'''+delay:'''
**Defines how long til the trigger starts.
**Syntax: '''Integer''', milliseconds
*'''+absolute angle:''' OR '''+relative angle:'''
**Defines the rotation degrees with three floats that give the x, y, and z. Absolute means in world terms; relative means relative to the ship. So a 90 degree angle on the ship would always be straight up in relative degrees; it would vary depending how the ship was rotated in absolute degrees.
**Syntax: '''Vector''', three ''floats'' in degrees, x, y, z respectively
**Example: ''90,180,0''
*'''+velocity:'''
**Defines subobject rotation speed, in relative terms. Defined with x, y and z floats.
**Syntax: '''Vector''', three ''floats'', x, y, z respectively
*'''+acceleration:'''
**Defeines acceleration speed of subobject rotation. Defined with three floats, x, y and z
**Syntax: '''Vector''', three ''floats'', x, y, z respectively
*'''+time:'''
**Defines time for object to rotate, move, whatever.
**Syntax: '''Integer''', milliseconds}}

====Other types====
{{Table36|
*'''+delay:'''
**Defines how long til the trigger starts.
**Syntax: '''Integer''', milliseconds
*'''+reverse_delay:'''
**Defines how long til the trigger starts.
**Syntax: '''Integer''', milliseconds
*'''+absolute angle:''' OR '''+relative angle:'''
**Defines the rotation degrees with three floats that give the x, y, and z. Absolute means in world terms; relative means relative to the ship. So a 90 degree angle on the ship would always be straight up in relative degrees; it would vary depending how the ship was rotated in absolute degrees.
**Syntax: '''Vector''', three ''floats'' in degrees, x, y, z respectively
**Example: ''90,180,0''
*'''+velocity:'''
**Defines subobject rotation speed, in relative terms. Defined with x, y and z floats.
**Syntax: '''Vector''', three ''floats'', x, y, z respectively
*'''+acceleration:'''
**Defeines acceleration speed of subobject rotation. Defined with three floats, x, y and z
**Syntax: '''Vector''', three ''floats'', x, y, z respectively
*'''+time:'''
**Defines time for object to rotate, move, whatever.
**Syntax: '''Integer''', milliseconds
*'''$Sound:''' (Does not work with 'initial' animations)
**Defines sounds that are played with the animation
**'''+Start:'''
***Defines the sound that is played when animation starts
***Syntax: '''Integer'''
**'''+Loop:'''
***Defines the sound that is played when animation is going on
***Syntax: '''Integer'''
**'''+End:'''
***Defines the sound that is played when animation stops
***Syntax: '''Integer'''
**'''+Radius:'''
***Defines the distance from the submodel where the sound is audible
***Syntax: '''Float''', meters}}

==Animation Examples==

===Setting Turret Angle===
*Animation code can be used to set multipart turrets barrel angle at the beginning of the mission
*'''Animation Class''' = triggered
**The only one available
*'''Animation Type''' = initial
**As we want the barrels to align themselves at the beginning of the mission
*'''Animation Code'''
**'''+relative_angle:''' is good for this purpose
**Notes about angles:
***First value is used to determine the turret's barrels deviation from the turrets normal. So barrel elevation in degrees is ( 90 - the first value ).
***Second value is used to determine the turret facing. With ''0'' the turret facing is in the normal setting and with ''180'' turn the turret completely around. Do note that turrets on the underside of the model normally face backwards, so to get these turrets pointing forwards the second value has to be set to 180.

====Examples====

<pre>
$Subsystem: turret02,0.833,1.0
$Default PBanks: ( "Terran Turret" )
$animation: triggered
$type: initial
+relative_angle: 90,180,0
</pre>

<pre>
$Subsystem: DockingClaw1, 0, 1.0
$Flags: ( "untargetable" )
$animation: triggered
$type: docking ;;The claw opens on approach
+sub_type: 0 ;;The number of the associated dock (works with multidocking)
+delay: 0
+relative_angle: 0,0,90
+velocity: 0,0,10
+acceleration: 0,0,5
+time: 2000
$animation: triggered
$type: docked ;;The claw closes once docked
+sub_type: 0
+delay: 0
+relative_angle: 0,0,-90
+velocity: 0,0,10
+acceleration: 0,0,5
+time: 2000
</pre>

[[Category:Tables]]