FreeSpace Wiki - User contributions [en]

Total conversions

2009-03-17T21:56:31Z

DaBrain:

FreeSpace 2 Open engine has lot of potential and it has been used to create various '''total conversions''' that basically replace all the files related to original FreeSpace 2 with their own files. Due to terms set in the release of the FreeSpace 2 source code in 2002 none of the total conversions using FreeSpace 2 Open engine may be used for commercial purposes.

==Released total conversions==

===[[Beyond the Red Line]]===

[[Image:Btrl logo 250x100.jpg]]

Beyond the Red Line is a total conversion based on the Battlestar Galactica (Reimagined) TV series.

*'''Current release:''' ''Playable demo''

===[[The Babylon Project]]===

[[Image:TBP logo 255x112.jpg]]

The Babylon Project is a total conversion using the scenery from Babylon 5 universe. It features multiple campaigns and over a hundred models based on designs from the Babylon 5 universe.

*'''Current release:''' ''3.4 FINAL''

===[[Wing Commander Saga]]===

[[Image:Wcs logo 160 128.jpg]]

The Wing Commander Saga is a total conversion combining the FreeSpace 2 engine with the universe from the Wing Commander.

*'''Current release:''' ''Prologue''

==Other total conversions==

===[[The Apocalypse Project]]===

===[[Starfox: Shadows of Lylat]]===

Shadows of Lylat is a total conversion based on the Starfox video game series.

[[Image:SoL.gif]]

*'''Release Date:''' 2009, chapter 1 release

===[[Fate of the Galaxy]]===

[[Image:FotGOnTop.jpg|300px]]

Fate of the Galaxy is a total conversion based on the Star Wars universe.

*'''Release Date:''' Late 2008/Early 2009: first playable demo

===[[Halo for Freespace]]===

Bringing the Halo universe to FreeSpace 2!

===[[Fringespace]]===

This project is designed to duplicate, as closely as possible, the "feel" of Tachyon: The Fringe, within the Freespace2_Open game engine as well as an attempt to update the visuals and the playing experience for Tachyon fans.

[[Image:Fs_logo_sm.jpg]]

[[Category:Main]]

Styxx's POF Conversion plugin for 3D Studio Max

2007-05-07T20:01:47Z

DaBrain:

Still a work in progress, Styxx has created a Freespace 2 model exporter plugin for 3D Studio Max versions 4 through 6. Available here: [[http://www.hard-light.net/forums/index.php/topic,26260.0.html]] There is no model importing function; to import POFs into Freespace 2 for reference or editing, it is necessary to convert them to COBs and then use Truespace or another program to convert them to a 3DS or other file.

Despite being available for well over a year, not many people actually know how to make this plugin work correctly. To that end, the following is intended to be a complete walkthrough of using the plugin to create a simple ship that makes use of all of the plugin's features.

Please note that this is not a tutorial for actually creating models. There are plenty of Max tutorials out there that have far better information in them than what can be provided here. It is, however, a guide to getting a model out of 3ds Max and into the Freespace 2 object format, POF, with minimal complications. If this is your first model we recommend you explore the functions of [[ModelView]]'s POF editor and the various View functions in FRED to get a feel for what goes into a Freespace model.

This tutorial is for the current exporter version as of November 13, 2003.

To start off, load all of the components of your model into a single Max scene file, and make sure that everything is unlinked so that you have no hierarchy to start off with. If you have already set up a hierarchy, go back and unlink it, as having things grouped too early may cause trouble later. From here, preparing the model for conversion involves a specific sequence of actions.

==Naming Convention==
Ideally, you should be following these conventions while building your model, but before you convert you should double check that all of these are correct. One by one, select each subobject and assign it a conversion name. Most subobjects require specific naming conventions:
===LODs===
Level of detail (LOD) objects are named "detail-0", "detail-1", etc, where detail-0 is the parent geometry for LOD0, detail-1 is the parent for LOD1, and so on. Do not skip levels.
===Debris===
Debris chunks are similarly named "debris-0", "debris-1", ... debris-n, where n is one less than the total number of debris chunks. Again, do not skip numbering, as the converter parses these in order and will break if a number is missed.
===Turrets===
Turrets are named "turretXX", where XX is a number between 01 and 99 that corresponds to the turret number that this model represents. If you have additional LODs for turrets (for example, the prominant triple-barreled turrets on the [[Orion]]) name them "turretXXa" for LOD0, "turretXXb" for LOD1, etc.
* Turret barrels are named "turretXX-arm", where turretXX is the name of the turret's base. Barrels (and any other object consisting of more than one connected element) should be one object, not several, so attach multiple barrels together with the attach tool.
===Shields===
The shield mesh should be named "shield" (and similarly, any and all geometry not supposed to be a sheild should not be named "shield"). Models should only have one shield.
===Other Subobjects===
* Geometry that's acting as a 'standard' Freespace subsystem should be named according to the final subsystem name. A physical Comm system would be "communications", a physical hangar would be "fighterbay", and so on.
* Geometry representing non-standard displaying subsystems should be given the name you want them to appear with. If this subobject geometry is to appear on the lower LODs it should be named "SUBOBJECTa" for LOD0, "SUBOBJECTb" for LOD1, etc. where SUBOBJECT is the desired subobject name.
* Hidden subobjects should be given a name that's meaningful to their function, such as "hangardoor" for a hangar door.
* Live debris, the ugly chunks of stuff left over when a turret or other subsystem is destroyed, are specified by naming the subobject for the destroyed component the same as the healthy version but with an added "-destroyed" on the end, like 'turret03a-destroyed'.
* For all other subsystems, any name is valid as long as Freespace can parse it from the POF chunk (so no Cylinder,3) but remember that what you name the subobject will be what it is called in the POF itself. No subobject should ever be converted with its Max-generated default name.

==Geometry Preparation==
Once your objects are named, you need to set them up so that they appear and behave properly in the game.
* All faces on all geometry '''except the shield''' must have a texture assigned to them. Missing this on as little as a single face will cause the plugin to crash. Shields never have textures assigned to them.
* Scale your scene to the size you want it to appear in-game. This may vary depending on your current Units settings, so once you do a test export, a little math should help you find the desired scale.
* Orient everything so that the front of the ship points towards the top of the screen in 'top' view mode.
* Change all your model geometry to 'Editable Poly' mode, as the converter seems to work best with poly models.

===Pivots===
* Position the primary model where it is supposed to be in the converted file so that its pivot point is at the origin. If you were converting the [[Colossus]], you would put the model in such a location that the middle of its rear engines, the point about which it rotates in-game, at (0,0,0).
* When the ship is in the exact place you want it, select the 'Hierarchy' tab, click 'Affect Pivot Only' and make sure that the pivot is at location 0,0,0. The location of the pivot on the root geometry for a level of detail MUST be at the origin, and this is important, so '''do not skip this step.'''
* Position all turrets and other subobjects where you want them in relation to the detail-X object that they will be attached to (this will usually be detail-0), making sure to follow Freespace conventions in terms of turret orientation. Topside multipart turrets should face forward with their barrels pointing straight up, multipart turrets on the bottom of the ship should face towards the ship's rear and their barrels should point straight down. Default resting positions can be assigned in tables, so don't try to do anything fancy with these in the model.
* When these subobjects are in the positions you want them, one by one select your debris clumps and rotating subobjects (turret bases, turret arms, radar dishes etc.), select the 'Hierarchy' tab, click 'Affect Pivot Only' and move the pivots to their rotation points. Turret arms should pivot at their bases.

===Transparent Faces===
Glass, transparency-blended nameplates, and other transparent textures should come last in the model. An easy way to accomplish this is to select all faces that use the material of your glass texture, detach them from the model, re-attach them with the attach tool, select the faces near the edge (all faces in the model may be appropriate) and perform a vertex weld with a threshold of 0.01. This will move the transparent faces to the end of the model's face list and will ensure proper rendering in-game.
* If you have a single map that is partially transparent, do this on the specific faces that will end up transparent.
* All transparent textures should be part of the root geometry (detail-0), without exception. Faces behind transparent textures, such as a pilot, are more likely to work correctly when these faces are a seperate subobject.

===Properties===
Assign properties to physical subobjects. Turrets are the most common case, but rotating subobjects like radar dishes and geometry representing a game subsystem like engines also need some extra data. To assign text properties to an object, open the object properties dialogue (right-click on the object, and select properties) and go to the 'User Defined' tab.
* All objects that will be subsystems will need "$special=subsystem" added to their user-defined properties tabs.
* Turrets (turret bases) should have "$fov=XXX" where XXX is the field of view for the turret and "$name=gunturret" added at the end. (Field of view is like a cone extending out from the turret's firing point normal, between 0 and 360 degrees. Most button turrets have a FOV between 100 and 180.)
* Other subsystems also need the "$name=somename" field, but only turrets require "gunturret". Rotating objects need "$rotate=X" where X is rotation time in seconds. Negative values indicate reverse rotation.

===Reset X-Form===
This is the step that has given people the most trouble. Now would be a good time to make a backup of the scene, so that you can restore to the un-rigged state if something goes wrong.
* Select all objects in the scene and open the Utilities tab. Select the "Reset X-Form" tool in the rollout that appears. Click the button of the same name to reset the transforms on all objects in the scene.
* If something in the scene moves in a strange way when you perform this action, there was still hierarchy set up in the scene so load up the backup and unlink the object(s) that moved from whatever they are attached to with the schematic editor. Then update the backup and try Reset X-form again, repeating as necessary.
* If you're having difficulty using the Reset X-Form tool, there is an alternate way to reset the pivot. Create a sphere with its pivot point where you want the subobject's pivot to be, Attach your subobject to it, delete the sphere's geometry and rename the resulting object appropriately.

====Test Exporting====
At this point it is recommended that you attempt an export with only "detail levels", "debris objects", and "glows" checked. "Glows" won't do anything yet, but the converter crashes if it is not selected. If it converts and everything is in the right place afterwards, then the geometry is sound and you can be sure that later errors were not caused by geometry issues. See the converting section for details and debugging info.

==Points, Lines and Dummies==
If you prefer editing all subsystem, turret, gun/missile point, dockpoint, engine glow, and glowpoint data in PCS, you can safely skip this section. However, as this is perhaps the greatest strength of the MAX converter, it is strongly recommended that you actually use these features. (Insignias don't work properly, so this tutorial will not address them.) Here you will create invisible objects that will define the model's in-game properties.

===Turrets and Weapons===
* To define a turret's firing points, place Point helper objects in the scene at the desired location for these points. It's a good idea to name these points something meaningful (if it's a firepoint for turret03, perhaps call it "turret03fp") so that you can figure out what goes where when rigging.
* To define a weapon bank, create a container dummy object. The dummy must take the name "gunbank-X", if it is to be a gun bank, or "missilebank-X" if it is to be a missile bank. X in both of these is the number of the bank, so start with zero and work your way up for both. The count of gunbanks is not related to the count of missilebanks, so start both at 0 and don't skip numbers. The location of the container dummy does not matter, so it can be dropped down anywhere. However, to prevent serious oddities in conversion, it is strongly recommended to define '''all''' dummy objects in either a top-down or perspective view. That rule applies to more than just weapon banks as well.
* To define a weapon bank's firing points, create point helper objects where each specific firepoint should be. Naming them something representative of their bank is helpful if you do multiple banks at a time.

===Subsystems===
* To define the standard subsystems used in FS2, create a dummy object at the location and with the size of the special point you want to create. This point should have a name starting with '$' and should be named what you want the point to display as otherwise.
* To define an engine glow, place dummies centered where the engine glows should be and set their size to the size of the glow.

===Paths and Docks===
Create your paths using the create line tool and modify the editable splines to suit each path you want in the model. Paths are always defined TOWARD the ship, so the first point (where you first click when you start an editable spline with the create line tool) should be the most distant from the ship, and the last the closest. All editable splines will become paths on conversion, but name them according to the Freespace convention anyway. Typically, the paths needed for a 'complete' model are paths for each subsystem (main subsystems and turret subobjects) so it's usually a good idea to know in advance where things like the weapons subsystem will be defined.
* Turret and subsystem paths are fine with just two points. These paths should be named "$pathXX" where XX is a number.
* Fighterbay paths normally have 3, 4, or more points. Fighterbay paths should be named "$bayXX" where XX is a number.
* Dock paths should have at least 4 points. Dock paths must have "dock" in the name, so "$dockXX" is preferable. Dock paths should also have "$name=somename", where somename is the display name of the dock in FRED, added to their user-defined properties tab. The final point of a docking path should come very close to the first dockpoint.
* To define a docking point, place one point helper where you want the dockpoint, and place a second point helper a short distance away towards the 'top' of the dock. If you want an [[Argo]] to dock in a certain alignment, the second point should be above the first from the orientation of the Argo.

===Glowpoints===
Glowpoints are very similar to gun/missile banks in setup, except that instead of point helpers for each point, they use dummys. The size of each individual dummy will determine the size of the glowpoint it creates.
* Glow banks are specified with a container dummy helper (which has multiple dummy helpers attached to it as children) with the name "glow-X" where X is the number of the glow bank (start with 0 and don't skip numbers).
* The string "$glow_texture=texturename" should be placed into the user properties tab for the parent helper.

==Rigging the Scene==
Now that all geometry and paths are set up properly, it's time to start putting things together. Setting up the hierarchy can be done in two ways: through the Schematic view, or in the scene itself.
* If you're using the Schematic view and you can't make out anything, try zooming in; Max does a particularly poor job of initially displaying a large number of objects in this view. Objects are connected in a hierarchy with the Link tool. To link one object to another, select the link tool, click on the to-be child object and drag to the intended parent.
* If you're linking objects together in the main scene, be sure to Hide whatever objects you're not working on. To link units together, select the Link tool, click on the to-be child object and drag to the intended parent geometry. You can also select the child geometry, select the Link tool, then use the Select By Name tool to link to an object. Select By Name also has an option to 'Display Subtree' showing you your hierarchy at a glance.

The connection hierarchy is essential to making the game display your model correctly. Child objects cannot be rendered if their parent is not rendered, so keep this in mind when setting up your hierarchy groupings. Child objects also rotate with their parents, so if you are setting up an animated model you must keep this in mind. In general, all subobjects that the game can access as a submodel get assigned as direct children of detail-0, with the possible exception of some weird model animations you might want to do. Turret barrels, however, are '''always''' children of their base, even if you don't intend to use autogeneration to set the turret up for you. It's usually a good idea to link subobjects like turrets together before linking the object itself to the main LOD.

===Subassemblies===
* The standard button turrets consist of the turret geometry, with the turret path and the firepoint(s) attached as children.
* Multipart turrets are assembled with the turret base as the parent and with the firepoint(s), path, and barrels all attached as children.
* Multipart turrets on LODs consist of the turret base with the barrels attached as a child.
* Attach all firepoints for a particular weapon bank to the container dummy helper as children.
* Glows associated with an engine subsystem should be linked to that subsystem as children.
* For docking points, attach the two dockpoints, in their creation order, to the dock path as children. The dock point normals will be set as the direction from the dockpoints to the first point in the path, which is often wrong, but this must be corrected after conversion using an external POF editor such as PCS.

===Final Assembly===
* Attach each turret base, physical subsystem, and extra subobjects intended to be direct subobjects of detail-0 to their parent LOD.
* Additional LODs should be set up the same way. Low-detail turret or subobject counterparts should be linked to their appropriate LOD. LODs should themselves be at the top level of the scene, not attached to any other piece of geometry or helper.
* All paths not assigned to a turret or subobject (subsystem paths for non-geometry subsystems, fighterbay paths, and dock paths) should be at the root level of the scene.
* Debris pieces be at the scene root as well, not attached to any parent object.
* The shield mesh (if one is being used) should also be at the top level of the scene.

==Converting==
Converting is a relatively simple process in comparison to actually setting everything up. It is, however, not foolproof and actually quite failure prone. It should be as simple as doing a file->export, choosing Freespace 2 POF as your export filetype, and selecting only the components that you actually have in your scene. The only exception is the glows box, which must ALWAYS be checked or a crash will result.

===What can go wrong===
The simple answer is a lot. The usual result is that 3DS Max will crash while exporting, sometimes leaving behind a half-finished POF. By looking at this POF you may be able to narrow down the problem area.
* Did you skip a number in any sequence that requires a -X at the end? Debris is the most common place for this to occur now, though there are other places that it may also come up.
* Does your model have polygons on any mesh other than the shield that have no texture?
* Did you try to convert with the glow box is unchecked? There isn't any good reason why this happens.

Finally, the converter will occasionally crash for no reason whatsoever, so always save before you convert and load it up and try again if it fails once. Failing twice in a row is usually indicative of a real problem.

If the converter doesn't crash but your model is behaving incorrectly, go thorough this tutorial again and ensure that all the steps have been followed.

==Known issues==
There are still some things that the POF converter cannot do properly.
* It makes a mess out of the header; the mass values are about two orders of magnitude higher than they would be for an equivalent stock model. The Moment of Inertia is also a complete mess and doesn't output anything useful. Both of these values should be changed before the model is used in game. Unfortunately, if glowpoints were used, there is not a good mainstream way to correct the MoI data without losing the glow chunk, and PCS won't import glows, so you're sort of stuck unless you are willing to copy it by hand.
* The converter miscalculates the radius of the model by approximately a factor of 2, which creates some strange behavior during subspace warps and when viewing externally from the model. Again, there is not a good way to correct this, so it may just be something you have to live with.
If these problems become issues, please contact the user StratComm through the HLP PM system for assistance.

''Note: A new version of the exporter is in development.''

[[Category:Modding]]

Modelling

2007-04-16T23:39:39Z

DaBrain:

=Modelling basics=
The community currently uses a wide range of modelling programs, from Blender to Lightwave to 3D Studio Max and others. Converters to the .POF format, as used by Freespace 2 is available via a plug in for 3D Studio Max or via the Pof Construction Suite program for .cob (Truespace) files. Any models to be made need to be converted to one of these two formats.

==Limits and Guidelines for Model Making==
===SCP Team Recommendations===
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key, for fighters and bombers you should only need a single 512 x 512 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. These format files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

===Polygon Counts===

Whilst there is no fixed limit to the number of polygons you can use on a model, and opinions vary from person to person, the writer finds the following approximate Polygon counts a good guide to work by.

'''Fighters/Bombers''' - Less than 6000 Polygons

'''Cruisers/Freighters''' - 6000-12000 Polygons

'''Corvettes''' - 14000-18000 Polygons

'''Destroyers''' - 20000-24000 Polygons

'''Juggernauts''' - 24000 Polygons upwards

Though this list should not, by any means, be used as a rule, different modders work to different guidelines.

Note that [[Detail box]] models should not be counted directly to the overall number of polygons.

==Sub-Objects==
The first thing that needs to be understood about Freespace models is the hierarchy they need to be placed in to make sure that conversion is a success. Each Freespace model is made up of several sub models (which can also use more than one material each) or groups. How these groups are arranged will directly affect how the final model works in-game. Don’t panic, it’s not as scary as it sounds.

The most important parts of your ship you need to make sure are at least one individual sub-onjects are :-

{|
| '''Main Hull''' || The main 'Body' of the ship, will only explode when the ship is destroyed.
|-
| '''Turrets''' || Any static or rotating turrets, rotating turrets need 2 sub-models. Different sub-object for each turret, e.g. Turret01, Turret02 etc. In the case of rotating turrets, I use Turret01-base and Turret01-arm etc.
|-
| '''Subsystems''' || Destroyable sub-objects or any other eye-candy. These have the widest range of uses and feature in more advanced features. Different sub-object for each sub-system e.g. Radar01, Reactor01 etc.
|-
| '''Debris''' || The wreckage of the ship released after it is destroyed. Different sub-object for each item of Debris, e.g. Debris01, Debris02 etc.
|-
| '''LODS''' || The Level Of Detail models for the main Hull and for so-desired Turrets and/or Subsystems.
|}

Some Sub-Models can be further enhanced using the ships.tbl expansions such as [[Animation Code]]. Always bear in mind what you want your ship to do whilst you are modelling it.

In addition the the lods, it is possible to add further detail models to you ship using the [[Detail box]] feature.

[[Category:Modding]]

''Update ongoing by Flipside''

Texturing

2007-04-15T11:26:55Z

DaBrain:

==General==

Properly texturing a model is perhaps one of the easiest aspects of modeling to actually do, but possibly the hardest to do well. There are two types of texturing methods, tiling and mapping, each with its own distinct advantages and disadvantages. I am not qualified to explain mapping (also called texture wrapping or unwrapping), as this is by far the more difficult of the two to do well. This form of map is most commonly used on fighters, although some capships (many FS1 cruisers, as well as distinct ships like the Lucifer) make use of full mapping. The advantage comes in a form-fitted map, that has each piece distinctly textured to reflect the designer's intentions as to what function each section should serve. However, especially with the older 256x256 maps, large scale mapping can be blurry and inconsistant if extreme care is not given to the construction of a map. Mapping a ship also requires you to be able to create techy maps in a photoshop-like program, and there really isn't an effective substitute.

Texture tiling: This method is simple, and (besides being the primary capital ship texturing method used by Volition) produces a consistantly crisp and consistant hull if applied correctly. When constructing a model, the choice between mapping and tiling generally comes early; anything with large flat or gradually curved expanses can easily exceed the optimal resolution for wrapped textures and makes tiling extremely noticable. As a general rule of thumb, don't create large expances of unbroken hull and you won't have this problem. If you can't get around it, though, try to split the section into two or more horizontal or vertical sections that can be mapped with similar textures or otherwise find a way to break overly repeated textures up. Using a varient of the same texture (such as ~C~Tile1 and ~C~Tile5 from the stock FS2 textures) can work really well here. Once your model is ready to texture, you must provide UV coordinates for each polygon so that the game renderer knows how to display your textures. I start out usually by applying a box UV map to the whole object, and then work from there. This comes with the advantage of lining everything up for tiled textures, but can create some odd seaming effects around 45 degree facings. I then go back and planar map (TS5) or unwrap (3ds Max) any parts that require special attention, such as engines, viewports, corners, etc. so that they fit the scheme I want. I would advise against spherical, cylindrical, or shrinkwrap UV map options, as they tend to create unstable normals (in TS) and almost always create an unexpected "pole" effect around the ends which is difficult to rectify. For a step-by-step walkthrough, I would strongly suggest taking your modeling program of choice and just playing with it. See what you can come up with. And that's all of the texture section until someone who is better at it than I am comes along and fixes this page up.

==SCP Team Recommendations==
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key. For fighters and bombers you should only need a single 1024 x 1024 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. The DXT formats of these files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures, or gradients)
*DDS format consists of multiple types. If the texture needs an alpha channel, use DXT5 compression, otherwise use DXT1c compression. (DXT1c uses way less memory. DXT1a can also be used like DXT1c because its alpha channel is ignored -[[Texturing#Alpha_Channel_management|See below]]-. Both prevent the 'mirror' effect as the game uses a fixed amount of environmental reflectiveness.)
**Tip: See if the program you use to compress has a High Quality option. With the nvdxt cmdline program, the switch is: -quality_highest
*Other alternatives to TGA -- in cases where DXT compression is unacceptable (noticable errors/artifacts) -- are u888, u8888, or u1555. u888 is 24 bit color and u8888 is 32 bit color (24 bit plus 8 bit alpha map), just like the types of TGA. The file doesn't get any smaller than TGA, but it can now have mipmaps (see Models). u1555 is 15-bit color, usually best for files that used to be PCX.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

==Texture Types==
Freespace 2 SCP uses mostly .DDS and .TGA format images. These can also be linked together to form animated maps (see later). Also, .PCX files are commonly found as they were the original format of Freepsace 2 Textures.

''Please read important info about texture format priority in the [[Command-Line_Reference#-mod| help for -mod command line flag]]''.

===Texture naming conventions===
Whilst the textures on your models can be called anything, there are certain naming conventions in creating effects textures such as glow-maps or specularity, basically the naming convention works as follows.

'''TextureName.xxx''' – This is the colour map for the material. It should be mapped out to the models UV Map. This can use an alpha map for transparency.

'''TextureName''-glow''.xxx''' – This is the glow map for the model. It simulates the effect of ‘portholes’ or other glowing part of the ship. Using the same UV Map, and a black background, make any flat lighting effects you want on the ship on this texture. These are different from Glow-points, which are points on the model and are covered later.
'''NOTE:''' Glow maps do not use the alpha channel. So using a 32-Bit format like DXT5 will waste memory. It is recommended to use DXT1 for glow maps.

'''TextureName''-shine''.xxx''' – This is the Specular map of the model, once again using the UV’s for the model, colour in all the parts of the surface which are metallic, using whatever colour you want the shininess to be. The brighter the colour, the shinier it will be.
'''NOTE:''' Shine maps can also have an alpha map. This alpha map is used to define the level of ‘reflection’ when environment mapping is operating.

'''TextureName''-trans''.xxx''' – This enables the transparency for the map of the model, once again using the UV’s for the model. Map in question can also be set as ''-shine'' or ''-glow'' map (for example '''TextureName''-trans-glow''''').

NOTE : When creating Shine-maps, if the map does not have any environment mapping (reflection effect) then the Spec-map should be saved in DXT1c format with no Alpha-map. This will improve performance for maps that do not use environemt mapping (environment mapping is different to Specular, which helps give a metallic 'effect' to the material).

===Animated Textures===
Freespace 2 SCP also supports two kinds of animated file format. The first is the standard .ANI extension as used by Freespace Retail, you can convert these using the AniBuilder program from the Descent Tools package. The Second format is the new .eff file. This allows multiple single images to be chained together into an animated texture.
All .EFF image files must be in the same format, but can be in any format Freespace SCP supports, and must have an underscore and their Frame number added onto their name as a 4-digit number starting at 0000, for example RunningLights_0000.DDS, RunningLights_0001.DDS etc.
Now simply create a new text file for your animated texture with the same Base name as your texture and a .EFF extension (in this case, RunningLights.EFF) and simply enter the following text.

'''$Type:''' XXX - Defines the type of file being used, can be DDS, TGA, PCX or others

'''$Frames:''' XX - Defines the number of Frames in the total (looping) animation.

'''$FPS:''' XX - The Frame Per Second speed of the animation.

This file should be saved in the textures folder of your project alongside the images themselves.

===Effect textures===
Textures are also used in weapon bitmaps, explosions, background nebulas and planets, glow points and so on.

General considerations about ship textures also apply here. As an example, Media VP compilations have changed explosion .ANI clips by .EFF (.DDS) ones.

===Alpha Channel management===
With the exception of -shine maps, where the alpha channel sets the environmental reflectiveness, the alpha channel is normally used to set the transparency level of the texture. The way it behaves is:

* '''Bitmap formats with no alpha channel'''. The black pixels of the texture are transparent. Any other colour is shown. Of course, this rule doesn't apply to ship textures where you can have black shown pixels.
* '''DXT1a DDS textures'''. They have 1 bit alpha channel, (DXT1c ones don't have alpha channel), but this channel is ignored. They behave as textures without alpha channel.
* '''Other formats with alpha channel'''. Pixel transparency is controlled by the alpha channel value. Black (0 value) is transparent and white is fully opaque.

Modelling

2007-04-15T11:07:44Z

DaBrain:

=Modelling basics=
The community currently uses a wide range of modelling programs, from Blender to Lightwave to 3D Studio Max and others. Converters to the .POF format, as used by Freespace 2 is available via a plug in for 3D Studio Max or via the Pof Construction Suite program for .cob (Truespace) files. Any models to be made need to be converted to one of these two formats.

==Limits and Guidelines for Model Making==
===SCP Team Recommendations===
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key, for fighters and bombers you should only need a single 512 x 512 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. These format files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

===Polygon Counts===

Whilst there is no fixed limit to the number of polygons you can use on a model, and opinions vary from person to person, the writer finds the following approximate Polygon counts a good guide to work by.

'''Fighters/Bombers''' - Less than 6000 Polygons

'''Cruisers/Freighters''' - 6000-12000 Polygons

'''Corvettes''' - 14000-18000 Polygons

'''Destroyers''' - 20000-24000 Polygons

'''Juggernauts''' - 24000 Polygons upwards

Though this list should not, by any means, be used as a rule, different modders work to different guidelines.

Not that [[Detail box]] models should not be counted directly to the overall number of polygons.

==Sub-Objects==
The first thing that needs to be understood about Freespace models is the hierarchy they need to be placed in to make sure that conversion is a success. Each Freespace model is made up of several sub models (which can also use more than one material each) or groups. How these groups are arranged will directly affect how the final model works in-game. Don’t panic, it’s not as scary as it sounds.

The most important parts of your ship you need to make sure are at least one individual sub-onjects are :-

{|
| '''Main Hull''' || The main 'Body' of the ship, will only explode when the ship is destroyed.
|-
| '''Turrets''' || Any static or rotating turrets, rotating turrets need 2 sub-models. Different sub-object for each turret, e.g. Turret01, Turret02 etc. In the case of rotating turrets, I use Turret01-base and Turret01-arm etc.
|-
| '''Subsystems''' || Destroyable sub-objects or any other eye-candy. These have the widest range of uses and feature in more advanced features. Different sub-object for each sub-system e.g. Radar01, Reactor01 etc.
|-
| '''Debris''' || The wreckage of the ship released after it is destroyed. Different sub-object for each item of Debris, e.g. Debris01, Debris02 etc.
|-
| '''LODS''' || The Level Of Detail models for the main Hull and for so-desired Turrets and/or Subsystems.
|}

Some Sub-Models can be further enhanced using the ships.tbl expansions such as [[Animation Code]]. Always bear in mind what you want your ship to do whilst you are modelling it.

In addition the the lods, it is possible to add further detail models to you ship using the [[Detail box]] feature.

[[Category:Modding]]

''Update ongoing by Flipside''

Detail box

2007-04-10T13:18:20Z

DaBrain:

=Places to use the feature=

The detail box feature can be used for multiple purposes. It should mainly be used to add details to big ships on close-ups.
It's an addition to the lod system and works quite similar. The rendering of an object depends on the distance to it.
This allows you to create ultra detailed models with less worrying about he polygon count, as only the objects close to you will be rendered.

=Using detail boxes in 3d Studio Max=

The detail box models have to be separate models. They can not be part of the main mesh.
Creating the actual 'detail box' can be done by simply adding it to the 'User Defined' Tab.

-Right click on the the model you want to be used as detail box model.

-Select 'Properties'.

-Add this to the 'User Defined' values:

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

These models have to be linked to one lod (detail-0) or a subobject of it. They'll move with the object they are linked to. So they'll appear on rotating objects if they are linked to them.

=Using detail boxes in PCS=

Make sure that all models you want to use as detail box models are separate objects before you convert your model. Also make sue that the models are linked to one of the lods (probably lod-0) or one of the subobjects if needed.

-Open the model in PCS

-Go to the 'SubObjects' tab

-Select the object you want to use a detail box for

-Add this to 'Properties':

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

=Detail box values=

You can define the type, shape, and size of the detail box.

''$detail_box: x'' Sets up the type of the detail box. "1" is a detail box which renders the object when you fly into it, while "-1" will render it when your on the outside of it only.

''$box_min: x,x,x'' -and-

''$box_max: x,x,x'' Define the size and the shape of the detail box in x,y,z direction.

Example:
$detail_box: 1

$box_min: -1200,-1200,-1200

$box_max: 1200,1200,1200
(For medium sized details)

=Notes=
-You can use the inner and outer box with the same values for two different models, as lod system.

-The 'model' setting in the FS2 options has a direct influence on the detail box sizes. Making it smaller on low sttings, so the details will appear later when you move to an object.

[[Category:Modding]]

Modelling

2007-04-10T09:58:47Z

DaBrain:

=Modelling basics=
The community currently uses a wide range of modelling programs, from Blender to Lightwave to 3D Studio Max and others. Converters to the .POF format, as used by Freespace 2 is available via a plug in for 3D Studio Max or via the Pof Construction Suite program for .cob (Truespace) files. Any models to be made need to be converted to one of these two formats.

==Limits and Guidelines for Model Making==
===SCP Team Recommendations===
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key, for fighters and bombers you should only need a single 512 x 512 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. These format files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

===Polygon Counts===

Whilst there is no fixed limit to the number of polygons you can use on a model, and opinions vary from person to person, the writer finds the following approximate Polygon counts a good guide to work by.

'''Fighters/Bombers''' - Less than 2000 Polygons

'''Cruisers/Freighters''' - 3000-6000 Polygons

'''Corvettes''' - 7000-9000 Polygons

'''Destroyers''' - 10000-12000 Polygons

'''Juggernauts''' - 12000 Polygons upwards

Though this list should not, by any means, be used as a rule, different modders work to different guidelines.

==Sub-Objects==
The first thing that needs to be understood about Freespace models is the hierarchy they need to be placed in to make sure that conversion is a success. Each Freespace model is made up of several sub models (which can also use more than one material each) or groups. How these groups are arranged will directly affect how the final model works in-game. Don’t panic, it’s not as scary as it sounds.

The most important parts of your ship you need to make sure are at least one individual sub-onjects are :-

{|
| '''Main Hull''' || The main 'Body' of the ship, will only explode when the ship is destroyed.
|-
| '''Turrets''' || Any static or rotating turrets, rotating turrets need 2 sub-models. Different sub-object for each turret, e.g. Turret01, Turret02 etc. In the case of rotating turrets, I use Turret01-base and Turret01-arm etc.
|-
| '''Subsystems''' || Destroyable sub-objects or any other eye-candy. These have the widest range of uses and feature in more advanced features. Different sub-object for each sub-system e.g. Radar01, Reactor01 etc.
|-
| '''Debris''' || The wreckage of the ship released after it is destroyed. Different sub-object for each item of Debris, e.g. Debris01, Debris02 etc.
|-
| '''LODS''' || The Level Of Detail models for the main Hull and for so-desired Turrets and/or Subsystems.
|}

Some Sub-Models can be further enhanced using the ships.tbl expansions such as [[Animation Code]]. Always bear in mind what you want your ship to do whilst you are modelling it.

In addition the the lods, it is possible to add further detail models to you ship using the [[Detail box]] feature.

''Update ongoing by Flipside''

Modelling

2007-04-10T09:58:22Z

DaBrain:

=Modelling basics=
The community currently uses a wide range of modelling programs, from Blender to Lightwave to 3D Studio Max and others. Converters to the .POF format, as used by Freespace 2 is available via a plug in for 3D Studio Max or via the Pof Construction Suite program for .cob (Truespace) files. Any models to be made need to be converted to one of these two formats.

==Limits and Guidelines for Model Making==
===SCP Team Recommendations===
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key, for fighters and bombers you should only need a single 512 x 512 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. These format files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

===Polygon Counts===

Whilst there is no fixed limit to the number of polygons you can use on a model, and opinions vary from person to person, the writer finds the following approximate Polygon counts a good guide to work by.

'''Fighters/Bombers''' - Less than 2000 Polygons

'''Cruisers/Freighters''' - 3000-6000 Polygons

'''Corvettes''' - 7000-9000 Polygons

'''Destroyers''' - 10000-12000 Polygons

'''Juggernauts''' - 12000 Polygons upwards

Though this list should not, by any means, be used as a rule, different modders work to different guidelines.

==Sub-Objects==
The first thing that needs to be understood about Freespace models is the hierarchy they need to be placed in to make sure that conversion is a success. Each Freespace model is made up of several sub models (which can also use more than one material each) or groups. How these groups are arranged will directly affect how the final model works in-game. Don’t panic, it’s not as scary as it sounds.

The most important parts of your ship you need to make sure are at least one individual sub-onjects are :-

{|
| '''Main Hull''' || The main 'Body' of the ship, will only explode when the ship is destroyed.
|-
| '''Turrets''' || Any static or rotating turrets, rotating turrets need 2 sub-models. Different sub-object for each turret, e.g. Turret01, Turret02 etc. In the case of rotating turrets, I use Turret01-base and Turret01-arm etc.
|-
| '''Subsystems''' || Destroyable sub-objects or any other eye-candy. These have the widest range of uses and feature in more advanced features. Different sub-object for each sub-system e.g. Radar01, Reactor01 etc.
|-
| '''Debris''' || The wreckage of the ship released after it is destroyed. Different sub-object for each item of Debris, e.g. Debris01, Debris02 etc.
|-
| '''LODS''' || The Level Of Detail models for the main Hull and for so-desired Turrets and/or Subsystems.
|}

Some Sub-Models can be further enhanced using the ships.tbl expansions such as [[Animation Code]]. Always bear in mind what you want your ship to do whilst you are modelling it.

In addition the the lods, it is possible to add further detail models to you ship using the [[Detail Box]] feature.

''Update ongoing by Flipside''

Detail box

2007-04-10T01:01:24Z

DaBrain:

=Places to use the feature=

The detail box feature can be used for multiple purposes. It should mainly be used to add details to big ships on close-ups.
It's an addition to the lod system and works quite similar. The rendering of an object depends on the distance to it.
This allows you to create ultra detailed models with less worrying about he polygon count, as only the objects close to you will be rendered.

=Using detail boxes in 3d Studio Max=

The detail box models have to be separate models. They can not be part of the main mesh.
Creating the actual 'detail box' can be done by simply adding it to the 'User Defined' Tab.

-Right click on the the model you want to be used as detail box model.

-Select 'Properties'.

-Add this to the 'User Defined' values:

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

These models have to be linked to one lod (detail-0) or a subobject of it. They'll move with the object they are linked to. So they'll appear on rotating objects if they are linked to them.

=Using detail boxes in PCS=

Make sure that all models you want to use as detail box models are separate objects before you convert your model. Also make sue that the models are linked to one of the lods (probably lod-0) or one of the subobjects if needed.

-Open the model in PCS

-Go to the 'SubObjects' tab

-Select the object you want to use a detail box for

-Add this to 'Properties':

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

=Detail box values=

You can define the type, shape, and size of the detail box.

''$detail_box: x'' Sets up the type of the detail box. "1" is a detail box which renders the object when you fly into it, while "-1" will render it when your on the outside of it only.

''$box_min: x,x,x''

''$box_max: x,x,x'' Defines the size and the shape of the detail box in x,y,z direction.

Example:
$detail_box: 1

$box_min: -1200,-1200,-1200

$box_max: 1200,1200,1200
(For medium sized details)

=Notes=
-You can use the inner and outer box with the same values for two different models, as lod system.
-The 'model' setting in the FS2 options has a direct influence on the detail box sizes. Making it smaller on low sttings, so the details will appear later when you move to an object.

Detail box

2007-04-10T00:58:51Z

DaBrain: New page: =Places to use the feature= The detail box feature can be used for multiple purposes. It should mainly be used to add details to big ships on close-ups. It's an addition to the lod system...

=Places to use the feature=

The detail box feature can be used for multiple purposes. It should mainly be used to add details to big ships on close-ups.
It's an addition to the lod system and works quite similar. The rendering of an object depends on the distance to it.
This allows you to create ultra detailed models with less worrying about he polygon count, as only the objects close to you will be rendered.

=Using detail boxes in 3d Studio Max=

The detail box models have to be separate models. They can not be part of the main mesh.
Creating the actual 'detail box' can be done by simply adding it to the 'User Defined' Tab.

-Right click on the the model you want to be used as detail box model.

-Select 'Properties'.

-Add this to the 'User Defined' values:

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

These models have to be linked to one lod (detail-0) or a subobject of it. They'll move with the object they are linked to. So they'll appear on rotating objects if they are linked to them.

=Using detail boxes in PCS=

Make sure that all models you want to use as detail box models are separate objects before you convert your model. Also make sue that the models are linked to one of the lods (probably lod-0) or one of the subobjects if needed.

-Open the model in PCS

-Go to the 'SubObjects' tab

-Select the object you want to use a detail box for

-Add this to 'Properties':

''$detail_box: x

$box_min: x,x,x

$box_max: x,x,x''

=Detail box values=

You can define the type, shape, and size of the detail box.

''$detail_box: x'' Sets up the type of the detail box. "1" is a detail box which renders the object when you fly into it, while "-1" will render it when your on the outside of it only.

''$box_min: x,x,x''

''$box_max: x,x,x'' Defines the size and the shape of the detail box in x,y,z direction.

Example:
$detail_box: 1

$box_min: -1200,-1200,-1200

$box_max: 1200,1200,1200
(For medium sized details)

=Notes=
-You can use the inner and outer box with the same values for two different models, as lod system.
-The 'model' setting in the FS2 options has a direct influence on the detail box sizes. Making it smaller on low sttings, so the details will appear later when you move to an object.

Modelling

2007-04-09T23:37:55Z

DaBrain:

=Modelling basics=
The community currently uses a wide range of modelling programs, from Blender to Lightwave to 3D Studio Max and others. Converters to the .POF format, as used by Freespace 2 is available via a plug in for 3D Studio Max or via the Pof Construction Suite program for .cob (Truespace) files. Any models to be made need to be converted to one of these two formats.

==Limits and Guidelines for Model Making==
===SCP Team Recommendations===
The new HT&L feature of Freespace 2 SCP has allowed a vast increase in the number of polygons that can be displayed at any one time, however, in order to keep gameplay smooth, the SCP team recommends the following rules when making models for use in Freespace 2.

'''Textures :-'''

1 : Use as few textures per model as is possible, optimization is the key, for fighters and bombers you should only need a single 512 x 512 map for the model. Capital ships can use more textures, but the less textures and the less memory they take up, the better.

2 : Unless it is absolutely vital, use the .DDS format for storing your images. These format files are compressed and are automatically decompressed by your video hardware, so they take up far less memory, thus improving performance. Freespace 2 also supports .TGA format files, but these should only be used where .DDS files are causing noticeable compression errors on your texture (this can happen most noticeably with semi-transparent textures.

3 : For highly detailed ships, it is better, from a memory point of view, to use one large texture than several smaller ones.

4 : ALWAYS use texture sizes that are a power of 2, i.e. 256, 512, 1024 or, at most, 4096. However older ATI cards can only use 2048² maps. So it is recommended to use this as maximum. You can have different ratios, such as 512x256, but always use these sizes.

'''Models :-'''

Remember that any Level of Detail models are going to be stored in memory, so use them sensibly. Freespace SCP now uses Mipmap technology, so you no longer need to create LOD’s for the textures, an old requirement of Freespace 2 modding. Whilst polygon count does not have as dramatic effect on performance as texture size does, it is, as always, best to optimize where possible.

===Polygon Counts===

Whilst there is no fixed limit to the number of polygons you can use on a model, and opinions vary from person to person, the writer finds the following approximate Polygon counts a good guide to work by.

'''Fighters/Bombers''' - Less than 2000 Polygons

'''Cruisers/Freighters''' - 3000-6000 Polygons

'''Corvettes''' - 7000-9000 Polygons

'''Destroyers''' - 10000-12000 Polygons

'''Juggernauts''' - 12000 Polygons upwards

Though this list should not, by any means, be used as a rule, different modders work to different guidelines.

==Sub-Objects==
The first thing that needs to be understood about Freespace models is the hierarchy they need to be placed in to make sure that conversion is a success. Each Freespace model is made up of several sub models (which can also use more than one material each) or groups. How these groups are arranged will directly affect how the final model works in-game. Don’t panic, it’s not as scary as it sounds.

The most important parts of your ship you need to make sure are at least one individual sub-onjects are :-

{|
| '''Main Hull''' || The main 'Body' of the ship, will only explode when the ship is destroyed.
|-
| '''Turrets''' || Any static or rotating turrets, rotating turrets need 2 sub-models. Different sub-object for each turret, e.g. Turret01, Turret02 etc. In the case of rotating turrets, I use Turret01-base and Turret01-arm etc.
|-
| '''Subsystems''' || Destroyable sub-objects or any other eye-candy. These have the widest range of uses and feature in more advanced features. Different sub-object for each sub-system e.g. Radar01, Reactor01 etc.
|-
| '''Debris''' || The wreckage of the ship released after it is destroyed. Different sub-object for each item of Debris, e.g. Debris01, Debris02 etc.
|-
| '''LODS''' || The Level Of Detail models for the main Hull and for so-desired Turrets and/or Subsystems.
|}

Some Sub-Models can be further enhanced using the ships.tbl expansions such as [[Animation Code]]. Always bear in mind what you want your ship to do whilst you are modelling it.

''Update ongoing by Flipside''

Talk:Modelling

2007-04-09T23:34:49Z

DaBrain: New page: '''Time to update the poly and texture values?''' Less than 2k polies for a fighter? And using a 512² map for it? That seems pretty outdated. I'm not sure about all values, but 10k for t...

'''Time to update the poly and texture values?'''

Less than 2k polies for a fighter? And using a 512² map for it?
That seems pretty outdated. I'm not sure about all values, but 10k for the lod 0 of a fighter shouldn't really be a problem anymore.
And 1024² seems to be more the standard for fighter textures. Some mods start going even higher already.

Total conversions

2007-04-09T23:24:59Z

DaBrain:

FreeSpace 2 Open engine has lot of potential and it has been used to create various total conversions that basically replace all the files related to original FreeSpace 2 with their own files. Due to terms set in the release of the FreeSpace 2 source code in 2002 none of the total conversions using FreeSpace 2 Open engine may be used for commercial purposes.

==Released total conversions==

===[[Beyond the Red Line]]===

[[Image:Btrl logo 250x100.jpg]]

Beyond the Red Line is a total conversion based on the Battlestar Galactica (Reimagined) TV series.

*'''Current release:''' ''Playable demo''

===[[The Babylon Project]]===

[[Image:TBP logo 255x112.jpg]]

The Babylon Project is a total conversion using the scenery from Babylon 5 universe. It features multiple campaigns and over a hundred models based on designs from the Babylon 5 universe.

*'''Current release:''' ''3.4 Beta''

===[[Wing Commander Saga]]===

[[Image:Wcs logo 160 128.jpg]]

The Wing Commander Saga is a total conversion combining the FreeSpace 2 engine with the universe from the Wing Commander.

*'''Current release:''' ''Prologue''

==Other total conversions==

===[[The Apocalypse Project]]===

===[[Starfox: Shadows of Lylat]]===

Shadows of Lylat is a total conversion based on the Starfox video game series.

[[Image:SoL.gif]]

*'''Release Date:''' 2007/2008, chapter 1 release

===[[Star Wars Conversion]]===

[[Category:Main]]

File:SoL.gif

2007-04-09T23:23:52Z

DaBrain: Shadows of Lylat logo

Shadows of Lylat logo

Shadows of Lylat

2007-04-09T23:21:10Z

DaBrain: Removing all content from page

Shadows of Lylat

2007-04-09T23:20:43Z

DaBrain: New page: Image:http://www.game-warden.com/starfox/SF3.gif

[[Image:http://www.game-warden.com/starfox/SF3.gif]]