ModelView

Originally part of the Descent Network's FS Toolkit, Modelview 32, written by Heiko Herrmann, along with POF Constructor Suite (or PCS), is one of the principal tools used in the creation, editing, or viewing of POF files, the model format used by FreeSpace and FreeSpace 2. Though not as versatile as PCS, and no longer actively maintained (the latest High Limits version dates from 2007), many find its user interface easier to understand, and more intuitive. It was also coded expressly as a POF viewer, with the POF editing functions almost secondary. PCS was coded principally as a POF editor, and its viewer is less well integrated into the program.

The most recent modifications to the Modelview program allow higher poly models to be loaded and edited. Instructions on installing this higher poly version (the community standard) are below.

Installing Modview

Download this archive and follow the installation instructions inside.

How to edit a POF with Modview

Newer versions of Modelview include a POF editor, as well as a simple POF viewer. To begin editing, click the "POF-Editor" button on the far-right of your toolbar. If it's not there, you don't have the latest version. (see above)

Some features like Dockpoint and Path editing are not implemented. You have to use the PCS to set these. Also note that thrusters in Modview are only partially implemented - you can edit existing ones, but you can't delete them or create new ones.

FreeSpace Coordination system for models

It is imperative you be familiar with the coordination system of FreeSpace 2, in order to add additional features to your model such as turret or fighter weapon firing points, thruster glows, dockpoints, paths, shields and subsystems.

Modelview is the best way to learn how this system works since it uses a WYSIWYG viewing pane. The axis directions are as follows:

X-axis:	Right & Left	Width of your ship
Y-axis:	Up & Down	Height of your ship
Z-axis:	Forward & Back	Length of your ship

The numbers you enter for the coordinates of anything in Modview are in-game meter units. Normally, the coordinates of 0,0,0 are the model's center (the point around which the model rotates).

Finally, a normal is a vector of something - a direction. It defines where something is pointing or facing by using the same coordinate system everything else uses. The easiest way to think of it is to pretend the center of your object-to-be-orientated is your new origin (0,0,0 location), and you enter what is effectively a new location in 3D space where you want it to point at or face.

For example, if you wanted something to point straight up you would give the normal coordinates of 0,1,0. In front would be 0,0,1, to the left would be -1,0,0. (Oh, and you can use numbers other than 1 or 0. ;) )

A Note About Textures

If you're using Modview and FS_Open, chances are, you won't be able to see all or most textures. This is because FSO now uses the DDS format for textures, whilst Modview still uses only 256 colour PCX images. If Modview does not find any PCX images, it will complain that the model has none there.

The best way I've found to circumvent this is to create a dummy 'root' FreeSpace directory with a "data\maps" directory inside it. In that maps folder you put copies of all textures you want modview to be able to see, and batch-process them in something like IrfanView to turn them all into 256 colour PCXs. While clumsy, it does work and lets you see all your models.

Model

In this pane you can edit

The Eyepoint 

Where the camera of the ship is placed.
It doesn't save properly though, so it's really only useful for checking that it's right after setting it properly in PCS

Texture Names 

The filenames of each and every texture used by your currently visible model Level Of Detail (LOD).
You can change the textures used in here also - just remember to enter the new filename without the file extension (such as .pcx or .dds).

The Mass of the Ship 

This affects how far ships are thrown in collisions and other similar tasks.
The best way to go about it is to find a standard ship of similar size or mass and copy the approximate value from there.

The Moment of Inertia 

This is what allows standard FS2 fighters to spin around a bit when hit by a beam.
If this is not set the fighter probably won't budge. For capships it defines how fast they're able to spin in various axes due to weapon hits or collisions.
Again, the best method is to find a similar sized standard craft and use its values here.

The Center of Mass 

It's just that. The centre of mass for the model (not neccesarily the same as the origin of the model)

Lights 

These lights aren't actually lights. I don't exactly know what they do, but they don't have any effect that's visible in game as far as I can tell. They are mainly useful as position-getters to find out where a certain part is in terms of its coordinates.

Techroom Center 

This is the point around which the ship will spin in the techroom view.

Submodels

Every piece of geometry on your ship that is not the hull or LODs, is some type of sub-model, or in other words, a child of a parent. Eg: a spinning radar dish is a submodel with the main hull as a parent object. This means that the radar dish is attached to the hull, which is usually what we want.

In the case of a multi-part turret, the arms are a submodel, with the base (another submodel) as a parent. The base in turn has the main hull as a parent. This means that the arms are attached to the base and so will follow its rotation as it spins. In turn, the whole turret will move with the ship as a whole. It's like the hierarchy of your fingers>hands>arms.

Though you can't actually change subobject parents or individual subobject centers, it is handy for checking that your hierarchy survived the COB->POF conversion intact and everything is still relating properly.

Submodel rotation is something you can edit here. Just say you want to have a radar dish on your ship that will spin all the time. If you already have the model with the radar set to be a child of the hull, you can get it to spin in game quite easily. First step is to allow it to rotate in the submodel pane we're in. Select the radar dish object, and check the "Rotates" checkbox in its properties. Then you decide what axis you want it to spin on. Z will mean it spins like helicopter rotors, Y would make it spin like a drill and X would make it spin like a paddle-steamer. :) It basically just refers to which axis it's going to spin along, but with the axes all mixed up. Experiment with each (click "Apply" and then "Rotate Parts" to see it spin) until you find the right one.

Once you have decided on a rotation axis, you can move on to the actual text properties box. To get a spinning radar, you would want to enter the following:

$special=subsystem
$name=Radar dish
$rotate=5.1

This sets the subobject to be a subsystem and calls it "Radar dish" in-game, and sets its rotation speed to 5.1. (note, this is reversed. The higher the value the slower it spins ;) ) As a final note, to get it working in-game, you would need to add

$Subsystem: radar01a-dish, 5, 0.0

to the subsystem list in the ships table entry. This is just the name of the sub-object, the percentage of hitpoints it has as a subsystem of the main hull and how fast it can rotat at max speed (turrets only).

To get turrets working, you would follow the same process as above with a few differences: For the base of a multi-part turret, it should be set to rotate along the Z axis and should have the following properties (which are identical to those of regular single-part crater turrets):

$special=subsystem
$fov=180
$name=Main Turret

This does the same thing as the radar properties, but the FOV refers for Field Of Vision in degrees (the cone in the direction of the turrets fire-point normal - more on this in the turrets section) the turret can shoot things in. Eg, a turret on a flat hull surface would have a FOV of 180 degrees, meaning it could shoot anything above it but not below it. A turret in a crater or indent would have a smaller FOV, since from a crater, it wouldn't be able to hit as much without shooting through the ship it's attached to.

It should also be noted here that FS currently does not check for this. Your ship will quite happily shoot through itself if the turrets FOV allows it, so be careful!

Finally, the arms of a multi-part turret should have nothing in their properties, and be set to rotate around the X axis. (they must also be facing forward on top and backwards on the bottom to rotate correctly)

Subsystems

These are the things that the player can target and destroy in-game. Click on the rectangle next to the red x. This creates a new subsystem with no radius or position. Set the size of the radius to a number which is high enough for you to see it easily. Fighter subsystems are usually only a couple of meters across, while cap-ship subsystems can be much larger.

You set a subsystem radius to define the 3D area that will have to be hit in order to destroy the subsystem 'beneath' it.

Now, start playing with the numbers. First, set its height - the Y coordinates. You can only change the position of your subsystems by changing their coordinates manually. Set it to the right place you want it to be. Do not place a subsystem inside or outside the hull plating of a ship since this would result in an unhittable subsystem. Try to have the center of the cubes of subsystems on the surface of the hull since this is the most optimal, but FS will basically set any polies it finds inside the radius to be part of that subsystem, and when they are hit, it will damage the subsystem. Standard subsystems on cap-ships include:

• $Communications
• $Engine
• $Navigation
• $Sensors
• $Weapons

The type of subsystem box refers to whether or not the subsystem is a normal visible & destroyable subsystem, or the special hidden "$Split 01" type. The $Split## types of subsystems refer to places that FS will snap the model when it is destroyed. Think of them as weak points in the structure that would logically break when the ship explodes, such as a thin neck.

Remember to add a table entry for any new subsystems in the ships.tbl

Shields

Can't really do much here but import the shield data from another model, remove them altogether or change the size along any of the three axes. Things like the strength and recharge rate of the shields are set in the tables instead.

Guns

The Guns section refers to the primary and missile fire points on fighters and bombers. They consist of a location and a normal, although the normal is ignored by the game - they always point forwards. The firing points of guns or missiles are arranged in banks. You may have noticed how the Herc 1 has two banks - one bank consists of 4 fire points and one of 2, giving it six firing points all up. The Erinyes has two banks of 4 each, giving it 8 all up. Each bank has one primary/secondary weapon assigned to it in the fighter loadout screen in-game.

It's best to have even numbers of firepoints on each side of the fighter in each bank, else it results in lopsided firing if the player fires only one weapon bank. Eg: if you want a fighter to have 4 firing points spread over two banks, it would be best to put one left & right pair of firing points in each bank, meaning each bank has one point on both sides.

You should also try not to put the fire points out too far laterally or vertically from the cockpit, since this can create problems actually hitting small targets with both shots.

Note that this is not always followed, even by Volition. The GTB Ursa has a highly unusual, asymetrical firing setup, as do several Shivan fighters and bombers.

Turrets

Turrets are probably what Modview does best. To make a turret work, you need to use this section in conjunction with the associated submodel properties and your ships entry in the ships.tbl file. If you define a turret in here, but don't give it any properties in one or both of the other two areas, it won't be seen as a turret in-game.

To define a turret here, you create a new one and then tell it which bits of geometry to use for itself. For multipart turrets, the "Associated submodel" refers to the base geometry, while the "Rotational submodel" refers to the arms. For single-part turrets, the turret's one object takes both places.

The next step is to define the normal - where the turret points in its default rest position (along with all its fire points). This must always be straight up or down for multipart turrets.

The fire points are identical to gun firing points, but you've already done the normal. Here you only need to enter the places you want the weapon to shoot from (you can have at most 3, else it crashes the game).

Finally, to complete your turret, you also need to enter a line in your ships entry in the ships table such as:

$Subsystem: Turret02a, 1.875, 3.0
    $Default PBanks: ( "Terran Huge Turret" "Terran Huge Turret" "Terran Huge Turret" )

What this does:

"Turret02a" 

The model the turret uses as the turret (the base of mulitpart turrets)

"1.875" 

The percentage of hitpoints it has of the main hull hitpoint count

"3.0" 

How fast it can turn (the bigger this is, the slower it turns)

On the second line: the "P" in PBanks tells the game to use a primary weapon ("S" is for secondary/missile turrets), followed by which weapon to use in each firing point on the turret (I'm pretty sure it only uses the first one for all of them though), so if you have 3 firing points (like this Orion's main gun) define three weapons for it to use.

Thrusters

Since this has only been half-implemented, it's a bit useless. You can only change the location, size and direction of existing thruster glows, but not make new ones or delete old ones.

Anyway, "Prop" refers to the engine subsystem this glowbank is attached to, usually "$engine_subsystem=$Engine" which tells the game it is attached to the "$Engine" subsystem, so if that subsystem is destroyed the engine glows will go out.

The glowpoint positions refer to where you want a thruster plume to appear, the normal refers to where it is pointing and the radius refers to how wide the glow is. Simple as that :)