Styxx's POF Conversion plugin for 3D Studio Max - Revision history

T-Man: Minor correction in first paragraph; previous writer had put FS2 instead of 3DS max when describing importing method.

2010-03-13T18:07:52Z

Minor correction in first paragraph; previous writer had put FS2 instead of 3DS max when describing importing method.

TopAce at 14:53, 2 October 2008

2008-10-02T14:53:54Z

RazorsKiss: changed "turretXX" to "gunturret-X", and "turretxx-arm" to "barrel-X". The former do not work, and are not in the example scene bundled with the exporter.

2007-12-20T03:16:32Z

changed "turretXX" to "gunturret-X", and "turretxx-arm" to "barrel-X". The former do not work, and are not in the example scene bundled with the exporter.

Galemp: /* Geometry Preparation */ Added tip about Grouping to reorient the model.

2007-11-19T23:54:06Z

‎Geometry Preparation: Added tip about Grouping to reorient the model.

Mustang19: Freespace -> FreeSpace

2007-09-28T14:13:21Z

Freespace -> FreeSpace

DaBrain at 20:01, 7 May 2007

2007-05-07T20:01:47Z

67.102.62.205: /* Pivots */ Added that Debris should have local pivots.

2006-01-05T03:56:14Z

‎Pivots: Added that Debris should have local pivots.

128.235.249.80: Restructured format, removed redundancy, added misc information and checked grammar and spelling.

2005-12-09T21:53:02Z

Restructured format, removed redundancy, added misc information and checked grammar and spelling.

Show changes

TopAce at 19:44, 19 November 2005

2005-11-19T19:44:48Z

152.3.76.154: /* Things that still need improvement */

2005-11-13T20:22:54Z

‎Things that still need improvement

← Older revision		Revision as of 18:07, 13 March 2010
Line 1:		Line 1:
−	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.	+	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 3DS Max 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.		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.

@@ Line 43: / Line 43: @@
 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.
+* 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 separate subobject.
 ===Properties===

@@ Line 16: / Line 16: @@
 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.
+Turrets are named "gunturret-X", where - is a number between 0 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 "gunturret-Xa" for LOD0, "gunturret-Xb" 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.
+* Turret barrels are named "barrel-X", where gunturret-X 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.
+The shield mesh should be named "shield" (and similarly, any and all geometry not supposed to be a shield 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'.
+* 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 'gunturret-3a-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.
@@ Line 64: / Line 64: @@
 ===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 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 gunturret-3, perhaps call it "turret3fp") 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.

@@ Line 31: / Line 31: @@
 * 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.
+* Orient everything so that the front of the ship points towards the top of the screen in 'top' view mode. If you're having trouble keeping everything centered, try Grouping everything, setting the pivot point to the origin, rotating the group then un-grouping.
 * Change all your model geometry to 'Editable Poly' mode, as the converter seems to work best with poly models.

@@ Line 1: / Line 1: @@
-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.
+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.
+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.
@@ Line 21: / Line 21: @@
 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 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.
+* 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==
@@ Line 37: / Line 37: @@
 * 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.
+* 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.
@@ Line 73: / Line 73: @@
 ===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.
+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.
@@ Line 107: / Line 107: @@
 ==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.
+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===

@@ Line 124: / Line 124: @@
 * 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.
 [[Category:Modding]]

← Older revision		Revision as of 19:44, 19 November 2005
Line 91:		Line 91:
	===Things that still need improvement===		===Things that still need improvement===
	There are still some things that the POF converter cannot do properly. For one thing, 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. For another, the Moment of Inertia is 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. There is a third issue that most people rarely notice; 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 the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.		There are still some things that the POF converter cannot do properly. For one thing, 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. For another, the Moment of Inertia is 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. There is a third issue that most people rarely notice; 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 the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.
		+
		+	[[Category:Modding]]

← Older revision		Revision as of 20:22, 13 November 2005
Line 90:		Line 90:

	===Things that still need improvement===		===Things that still need improvement===
−	There are still some things that the POF converter cannot do properly. For one thing, 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. For another, the Moment of Inertia is 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. There is a third issue that most people rarely notice; the converter miscalculates the ~~raduis~~ 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 the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.	+	There are still some things that the POF converter cannot do properly. For one thing, 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. For another, the Moment of Inertia is 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. There is a third issue that most people rarely notice; 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 the radius problem becomes an issue, please contact the user StratComm through the HLP PM system for assistance.