Difference between revisions of "OXP howto model"

From Elite Wiki
m (more blurp about exporting models)
m (formatting, typos, etc.)
Line 18: Line 18:
 
So let's stick with a simple example - a simple cone combined with a cube. When creating the UV-Map in Wings3D this map is really in no way optimized. Doing optimizations as postprocess is a real pain, believe me .-)
 
So let's stick with a simple example - a simple cone combined with a cube. When creating the UV-Map in Wings3D this map is really in no way optimized. Doing optimizations as postprocess is a real pain, believe me .-)
  
Let's say you have created a model in Wings3D (pic 1) and created the UV-Map (pic 2). You can see that Wings3D does some preparations for you, e.g. the UV information is taking place in the maps area and the polygons are separated (in chunks), based on the method you've used to create the UV-Map. It's a good starting point but far away from a optimum for a game.
+
Let's say you have created a model in Wings3D ('''pic 1''') and created the UV-Map ('''pic 2'''). You can see that Wings3D does some preparations for you, e.g. the UV information is taking place in the maps area and the polygons are separated (in chunks), based on the method you've used to create the UV-Map. It's a good starting point but far away from a optimum for a game.
  
 
=== Waisted texture informations ===
 
=== Waisted texture informations ===
You can see in a few OXPs background images in the UV-Maps (pic 3). This is just waisted texture information, results in bigger filesizes and and makes optimization tools pretty senseless. These tools are using Deflate, LZ77, RLE (Run-length_encoding) and other algorithms to optimize the texture information streams in the maps. Better use a solid color (black, grey or white).
+
You can see in a few OXPs background images in the UV-Maps ('''pic 3'''). This is just waisted texture information, results in bigger filesizes and and makes optimization tools pretty senseless. These tools are using Deflate, LZ77, RLE (Run-length_encoding) and other algorithms to optimize the texture information streams in the maps. Better use a solid color (black, grey or white).
  
 
=== Waisted faces ===
 
=== Waisted faces ===
Wings3D is a box-modeller and creating objects in Wings3D always results in closed objects. Result is that quite a few faces are just waisted (pic 4), because they are not visible at all, but still eating memory and processing time. This can easily go in a few thousands of faces when a lot of models are used in installed OXPs. Luckily there's a way as Wings3D provides a hole material. This is a special feature to reduce the amount of data when exporting the model as .obj as the faces won't appear in the exported model and UV-Map.
+
Wings3D is a box-modeller and creating objects in Wings3D always results in closed objects. Result is that quite a few faces are just waisted ('''pic 4'''), because they are not visible at all, but still eating memory and processing time. This can easily go in a few thousands of faces when a lot of models are used in installed OXPs. Luckily there's a way as Wings3D provides a hole material. This is a special feature to reduce the amount of data when exporting the model as .obj as the faces won't appear in the exported model and UV-Map.
  
 
=== Resort the map ===
 
=== Resort the map ===
The next step is to resort (and sometimes scale) the polys in the UV-Mapper. Best practice is to leave a little bit space between polys (pic 5). This is a lesson I had to learn with my models. I was always wondering why some artifacts appeard at the edges and why the mipmapping doesn't work properly.
+
The next step is to resort (and sometimes scale) the polys in the UV-Mapper. Best practice is to leave a little bit space between polys ('''pic 5'''). This is a lesson I had to learn with my models. I was always wondering why some artifacts appeard at the edges and why the mipmapping doesn't work properly.
  
 
=== Mipmapping ===
 
=== Mipmapping ===
To get it working properly expand the areas with real texture information by a few pixels (pic 6). Oolite will do the mipmapping (if its available) automagically.
+
To get it working properly expand the areas with real texture information by a few pixels ('''pic 6'''). Oolite will do the mipmapping (if its available) automagically. Mipmapping or Level of Detail (LOD) is a antialiasing technique to improve the quality when textures are minified / magnified. See [http://en.wikipedia.org/wiki/Mipmap Mipmap] for more infos.
  
===Tessalation is evil ===
+
===Tesselation is evil ===
And last but not least tessalation is evil. We can see it in a growing number of released OXPs, and it is really the worst case. Tessalation (pic 7) is a time eater for a game as it increases vertex and face counts a lot and often enough results in higher texture sizes. Oolite handles smooth groups and hard/soft edges so in most cases there is absolutely no need to raise v/f counts. A really simple example how to use the smoothing option in Oolite can be seen in the [[RVandGS|RVandGS.oxp]].
+
And last but not least tesselation (or subdivision) is evil if its used to smooth objects appearance. We can see it in a growing number of released OXPs, and it is really the worst case. Tesselation ('''pic 7''') is a time eater for a game as it increases vertex and face counts a lot and often enough results in higher texture sizes. Both are adding time to the setup of entities whenever they are spawned in the game. Oolite handles smooth groups and hard/soft edges so in most cases there is absolutely no need to raise v/f counts. A really simple example how to use the smoothing option in combination with materials entries in Oolite can be found in the [[RVandGS|RVandGS.oxp]].
 +
 
 +
===Details and Greebles===
 +
Another point to consider is if a detail has to be done in the model itself or if this can be placed in a [[Materials_in_Oolite#Important_concepts|normal map]].
  
  
Line 42: Line 45:
 
The picture above shows 3 simple steps to export the model and use one of the converter scripts to get the .dat file.
 
The picture above shows 3 simple steps to export the model and use one of the converter scripts to get the .dat file.
  
* If you have the Wings stuff ready for export (means a model with UV-Map), simply use the Wavefront (obj) exporter (see Step 1+2). You'll need to configure it as shown in Step 2. Once exported you have three files (.obj, .mtl and .png).
+
* If you have the Wings stuff ready for export (means a model with UV-Map), simply use the Wavefront (obj) exporter ('''Step 1+2'''). You'll need to configure it as shown in '''Step 2'''. Once exported you have three files (.obj, .mtl and .png).
 
* Copy the <code>Obj2DatTex.py</code> (or <code>Obj2DatTexNorm.py</code>) to your folder where the model is saved to.
 
* Copy the <code>Obj2DatTex.py</code> (or <code>Obj2DatTexNorm.py</code>) to your folder where the model is saved to.
* Open a shell and switch to the folder with the model (and script) and type in: <code>Obj2DatTex.py mymodel.obj</code> (Step 3).
+
* Open a shell and switch to the folder with the model (and script) and type in: <code>Obj2DatTex.py mymodel.obj</code> ('''Step 3''').
  
 
Please note that the [[Oolite_Converters|converter scripts]] need Python 2.6 or higher (but won't work with 3.x!!).
 
Please note that the [[Oolite_Converters|converter scripts]] need Python 2.6 or higher (but won't work with 3.x!!).
Line 65: Line 68:
  
 
== Links ==
 
== Links ==
* [[List_of_software|List of software]]
+
* [[List_of_software|List of software]] - useful tools.
* [[Oolite_Converters|Converter scripts]]
+
* [[Oolite_Converters|Converter scripts]] - helpers for models and plists.
 +
* [[Materials_in_Oolite]] - further infos about textures in Oolite.
  
 
[[Category:Oolite]]
 
[[Category:Oolite]]

Revision as of 10:25, 7 July 2012

Create your model

in Wings3D or a similar program. How you do this is up to your creativity, but following a few tutorials for Wings3D and Meshwork and the 'brickship tutorial' or 'Oogie ship' by Aegidian are highly recommended if you are not familiar with 3D modeling.

pic 1
pic 2
pic 3
pic 4
pic 5
pic 6
pic 7

If you've read the tutorials above it's time to think about a few more things.

Optimize

Optimizing models and textures for a game is no fun, specially if it's a model with lots of greebles and funny details.

Simple example

So let's stick with a simple example - a simple cone combined with a cube. When creating the UV-Map in Wings3D this map is really in no way optimized. Doing optimizations as postprocess is a real pain, believe me .-)

Let's say you have created a model in Wings3D (pic 1) and created the UV-Map (pic 2). You can see that Wings3D does some preparations for you, e.g. the UV information is taking place in the maps area and the polygons are separated (in chunks), based on the method you've used to create the UV-Map. It's a good starting point but far away from a optimum for a game.

Waisted texture informations

You can see in a few OXPs background images in the UV-Maps (pic 3). This is just waisted texture information, results in bigger filesizes and and makes optimization tools pretty senseless. These tools are using Deflate, LZ77, RLE (Run-length_encoding) and other algorithms to optimize the texture information streams in the maps. Better use a solid color (black, grey or white).

Waisted faces

Wings3D is a box-modeller and creating objects in Wings3D always results in closed objects. Result is that quite a few faces are just waisted (pic 4), because they are not visible at all, but still eating memory and processing time. This can easily go in a few thousands of faces when a lot of models are used in installed OXPs. Luckily there's a way as Wings3D provides a hole material. This is a special feature to reduce the amount of data when exporting the model as .obj as the faces won't appear in the exported model and UV-Map.

Resort the map

The next step is to resort (and sometimes scale) the polys in the UV-Mapper. Best practice is to leave a little bit space between polys (pic 5). This is a lesson I had to learn with my models. I was always wondering why some artifacts appeard at the edges and why the mipmapping doesn't work properly.

Mipmapping

To get it working properly expand the areas with real texture information by a few pixels (pic 6). Oolite will do the mipmapping (if its available) automagically. Mipmapping or Level of Detail (LOD) is a antialiasing technique to improve the quality when textures are minified / magnified. See Mipmap for more infos.

Tesselation is evil

And last but not least tesselation (or subdivision) is evil if its used to smooth objects appearance. We can see it in a growing number of released OXPs, and it is really the worst case. Tesselation (pic 7) is a time eater for a game as it increases vertex and face counts a lot and often enough results in higher texture sizes. Both are adding time to the setup of entities whenever they are spawned in the game. Oolite handles smooth groups and hard/soft edges so in most cases there is absolutely no need to raise v/f counts. A really simple example how to use the smoothing option in combination with materials entries in Oolite can be found in the RVandGS.oxp.

Details and Greebles

Another point to consider is if a detail has to be done in the model itself or if this can be placed in a normal map.


Export the model

to obj( mtl texture) and convert to *.dat format.

3 steps

The picture above shows 3 simple steps to export the model and use one of the converter scripts to get the .dat file.

  • If you have the Wings stuff ready for export (means a model with UV-Map), simply use the Wavefront (obj) exporter (Step 1+2). You'll need to configure it as shown in Step 2. Once exported you have three files (.obj, .mtl and .png).
  • Copy the Obj2DatTex.py (or Obj2DatTexNorm.py) to your folder where the model is saved to.
  • Open a shell and switch to the folder with the model (and script) and type in: Obj2DatTex.py mymodel.obj (Step 3).

Please note that the converter scripts need Python 2.6 or higher (but won't work with 3.x!!).


Edit shipdata.plist

Supply the in-game values relevant to your model.

Subentities

Entities can have sub-entities, which are defined by quaternions. There are several types of SE:

  • Model Entities: can be any model, with any properties.
  • Turrets: are a specialised model entity.
  • Flashers: blinking lights
  • Exhausts: although they are defined seperate from subentities, they can be regarded as subentities.

One important thing to remember about subentities is that they cannot have sub-sub-entities. The other is that frangibility is defined for the main entity, not seperately for every SE.


Links