|
|
This section covers how to set up a model in trueSpace for conversion into a .pof using PCS. It also covers modifying a .pof in PCS.
The .pof models format created by Volition is pretty powerful. The FS2 implementation of means you ships can have the following features:
A sub-object is a part of a FS2 model which are treated seperately by the FS2 engine. They are the most important principle in creating models for FS2. A .pof has a hierarchy of sub-objects. Each sub-object has a parent sub-object. When the FS2 engine does something to a parent sub-object (such as moving it, rotating it, or destroying it), this is also done to any child sub-objects lower in the hierarchy.
Special points or are points on a model defined as a location and a radius. Because they have a radius they can be used to define an area of a model.
Sub-systems are parts of the ship which can be attacked and damaged. Sub-systems must have an amount of hit points and relate to either a sub-object or a special point. If they relate to a sub-object then if the player shoots that sub-object geometry on the model then the subsystem is damaged. If the sub-system is set to relate to a special-point then the player has to shoot the area defined by the point and the radius to damage the subsystem. Only subsystems can rotate.
Converting a .cob to a .pof using PCS is easy. Go to the "Conversion" menu. Choose "COB to POF" and select the trueSpace .cob file you wish to convert. Once the conversion is done the resulting .pof will be loaded into PCS. You'll need to save it out using "File" menu, "Save POF As".
The size of the resulting ship in-game is determined by the conversion scaling factor. Go to the "Conversion" menu and choose "Options". The conversion scaling factor is the number of meters in-game for every unit in truespace.
For POF Constructor Set to recognise a sub-object you must have a trueSpace group set up which contains a local
light (or contains some group further down the hierarchy which contains a local light). To create a local light
in TS use the add local light tool (
).
Basically, to create a group drag a local light onto some geometry in trueView. For more information read the notes
on groups in creating your model using TS.
Provided you have your local lights terminating each branch of your hierarchy, the hierarchy of groups you create in trueSpace is preserved and becomes a hierarchy of sub-objects in the .pof. Each sub-object's name is derived from the corresponding trueSpace group name. Each sub-objects centre of rotation is taken from the corresponding trueSpace group's axis.
A model must have at least one sub-object for PCS to convert it.
It you have a branch of your hierarchy without a local light at the bottom,
Sub-objects also may be given a rotation axis and given the property "$rotate=XX" (where XX is a number) which tells the sub-object it will rotate 360o once every XX seconds.
The total poly count for a sub-object is the total off all the pieces of geometry in the trueSpace group. So if you have a trueSpace group with 2 pieces of geometry of 500p each the sub-object will have 1kp (busting the sub-object poly limit of 750p by 250p).
Special points are... well... special points on your ship. They are identified by a position and a radius. They are most frequently used to specify the positions of sub-systems. Creation of special points takes place in PCS. Load your .pof into PCS and click on the special tab. Then choose "add special". If the special point si to represent a sub-system ensure it has the "$special=subsystem" property.
Sub-systems are created by adding a table entry. The table entry goes after the $Score entry and looks like this.
$Subsystem: XX, YY, ZZ
Where XX is the name of the subsystem. YY is the amount of hit points the subsystem has as a percentage of the ship's total hit points. ZZ is the amount of time in seconds it takes the turret to rotate in 360o (obviously not applicable unless the sub-system is a turret).
$Subsystem: bridge, 30.0, 0.0 $Subsystem: weapons, 5.0, 0.0 $Subsystem: fighterbay, 10.0 ,0.0
The name of the sub-system is derived from the name of the sub-object or special point that represents the sub-system on the model. They must match. Entries for sub-systems without a matching sub-object or special point are ignored. If either a sub-object or special point is going to be used to represent a sub-system they must be given the "$special=subsystem" property. They can also have an optional "$name=whatever" property which determines the name that appears on the HUD when they target the sub-system.
To create a single part turret you need a sub-system called turretXX where XX is a number. You also need a turret entry in the .pof for your turret.
You need to click on the "Turret" tab. For "turret data" the parent object and "physical SOBJ parent" should both point to the turret sub-object. You need to give the turret a normal which defines which direction is the centre of the turret's firing arc. You also need to give it at least one fire point. The co-ordinates for the fire point are offset from the turret sub-object's centre of rotation.
PCS has an "auto-turret" facility which will auto-matically create turret entries for you. If you name the local light in your turret group "turretXX-fp_01" it will even create the fire-point data for you based on where you put the light. Name a local light "turretXX-fp_02" to give the turret a 2nd fire point, and so on.
Remember that like all sub-systems it must also have a ships.tbl entry. The ships.tbl entry should give it a default weapon loadout. $Default PBanks for primary turrets. $Default SBanks for secondary turrets.
eg:
$Subsystem: turret01a, 3.0, 2.0
$Default PBanks: ( "EA Medium Plasma Turret" )
Multi-part turrets are slightly more complicated. To create a multi part turret you need a sub-system called turretXX-base. Inside the coresponding turretXX-base sub-object you need a sub-object called turretXX-arms. The centre of rotation for the base is uses as the... hey... centre of rotation for the base. Same for the turret arms.
You need to click on the "Turret" tab. For "turret data" the parent object should point to the turret base sub-object and the "physical SOBJ parent" should point to the turret arms sub-object. You need to give the turret a normal which defines which direction is the centre of the turret's firing arc. The normal must point either directly upwards (Y = +1) or directly downwards (Y = -1). Otherwise the turret will rotate strangely. You also need to give it at least one fire point. The co-ordinates for the fire point are offset from the turret sub-object's centre of rotation.
PCS has an "auto-turret" facility which will auto-matically create turret entries for you. If you name the local light in your turret group "turretXX-fp_01" it will even create the fire-point data for you based on where you put the light. Name a local light "turretXX-fp_02" to give the turret a 2nd fire point, and so on.
Remember that like all sub-systems it must also have a ships.tbl entry. The ships.tbl entry should give it a default weapon loadout. $Default PBanks for primary turrets. $Default SBanks for secondary turrets.
To create a destroyed version of a sub-system you need sub-object called "subsystemname-destroyed". Where "subsystemname" is the name of the sub-system.
Geometry for your shield should probably surround your ship. Yes, I know it sounds obvious. It must be triangulated and textured with a plain monochrome colour (no texture maps). Then it must be placed in a sub-object inside the top level sub-object called shield. Shields do not have levels of detail.
To create a thruster plume you need a sub-object called thrusterXX. The thruster plume is scaled depending on the ship's thrust. The scaling is done from the axis. So the axis should really go somewhere near the start of the plume.
To create debris you need sub-objects called debris1, debris2, debris3, etc...
To create live-subsystem debris you need sub-objects called "debris-subsystemnameXX". Where "subsystemname" is the name of the sub-system and XX is a number. The number is to allow you to have multiple pieces of debris from one subsystem. The pull-down menus in FSMM2 for rotation and rotation axis must be set for the sub-system the debris is for. Although the "$rotation=somenumber" property does not need to be set for that sub-system (so it does not actually need to rotate).
FS2 handles levels of detail by switching to lower poly count geometry when ships are at longer distances. Most of Volition's FS2 ships have 4 levels of detail. LOD0 is the most detailed LOD (level of detail). LOD3 is the least detailed LOD. Your ships can have more or less LODs as you choose. The distances that the engine switches to the lower levels of detail are set in the ships.tbl file.
The key to getting LODs working is your hierarchy of sub-objects. Your top level group (and thus top level subobject) should contain your most detailed hull geometry, sub-system geometry sub-objects, and destroyed sub-system geometry sub-objects. The lower levels of detail (LOD1 etc...) are handled by creating sub-objects called detail1, detail2, and detail3 etc. detail1 contains your LOD1 hull geometry, sub-system geometry sub-objects, and destroyed sub-system geometry sub-objects.
The highest LOD should also contain sub-objects for your sheild, ship debris and live / sub-system debris. These only appear in the highest sub-object and as such they cannot have levels of detail.
| LOD0 | LOD1 | LOD2 | LOD3 | |
| Standard FS2 Fighter | 300 | 150 | 75 | 10 |
| Detailed FS2 Fighter | 500 | 250 | 100 | 10 |
| Small FS2 Cap Ship | 600 | 300 | 150 | 20 |
| Medium FS2 Cap Ship | 800 | 400 | 200 | 30 |
| Large FS2 Cap Ship | 1000 | 500 | 250 | 40 |
Freespace 2 relies heavily on table files. These table files are plain text files FS2 reads in order to determine how the game should work. You can change most aspects of the game by modifying the entries in table files. When you start FS2 it looks for table files in the directory data/tables. If it doesn't find a particular table file there it looks in the Volition package (.vp) archive root.vp. There is no table files is in data/tables by default so the versions in root.vp is always used, but you can extract the table files from root.vp using Descent Manager VPView32. You can edit them with any plain text editor. Such as Microsoft Notepad The table files for the Freespace 2 main campaign are stored in a Volition Package (VP) archive called root.vp .
ships.tbl is the table file which stores information about the ships in the game and their properties. You can add a table entry for your new ship early on. It does no harm being there. If you don't have a .pof file
A table entry for a sub-system does not mean that sub-system has to be present in the model. Sub-systems which
have table entries but do not appear in the model will simply be ignored. You will need to add table entries before
you can test your model's sub-systems. You may need to change your model's geometry to get them to work. There's
no point stabilising your model's geometry until you know you've finished changing it. That means getting the your
model's sub-systems working before you can stabilise it. Similarly, you may need to change your model's geometry
to stabilise it in the FS2 game engine. Changing a model's geometry can also corrupt any texturing you have done
on that model. So there's no point texturing your model until you've finished stabilising it.
There is a limit to the size of the ships.tbl file. The default file is already pretty close to that limit. Adding even a couple of new ships can take you over that limit and FS2 will refuse to load. If this happens you need to reduce the size of the file by taking out white space or even entries for ships you don't use.
