Difference between revisions of "OXP howto model"
(→Export the model) |
m (some fun for modellers) |
||
| Line 2: | Line 2: | ||
in Wings3D or a similar program. |
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 [http://oolite.aegidian.org/cyoship2/ 'brickship tutorial'] or [http://oolite.aegidian.org/cyoship/ 'Oogie ship'] by Aegidian are highly recommended if you are not familiar with 3D modeling. |
How you do this is up to your creativity, but following a few tutorials for Wings3D and Meshwork and the [http://oolite.aegidian.org/cyoship2/ 'brickship tutorial'] or [http://oolite.aegidian.org/cyoship/ 'Oogie ship'] by Aegidian are highly recommended if you are not familiar with 3D modeling. |
||
| + | |||
| + | [[File:Sv_textut_part_1_01.png|thumb|right|100px|pic 1]] |
||
| + | [[File:Sv_textut_part_1_02.png|thumb|right|100px|pic 2]] |
||
| + | [[File:Sv_textut_part_1_03.png|thumb|right|100px|pic 3]] |
||
| + | [[File:Sv_textut_part_1_04.png|thumb|right|100px|pic 4]] |
||
| + | [[File:Sv_textut_part_1_05.png|thumb|right|100px|pic 5]] |
||
| + | [[File:Sv_textut_part_1_06.png|thumb|right|100px|pic 6]] |
||
| + | [[File:Sv_textut_part_1_07.png|thumb|right|100px|pic 7]] |
||
| + | If you've read the tutorials above it's time to think about a few more things. |
||
| + | |||
| + | == Optimize == |
||
| + | Optimizing models and texture 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 really a 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. |
||
| + | |||
| + | ===Tessalation 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 normals 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]]. |
||
| + | |||
== Export the model == |
== Export the model == |
||
Revision as of 00:20, 1 July 2012
Contents
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.
If you've read the tutorials above it's time to think about a few more things.
Optimize
Optimizing models and texture 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 really a 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.
Tessalation 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 normals 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.oxp.
Export the model
to obj( mtl texture) and convert to *.dat format.
There's a cross platform command line script, Obj2DatTex.py (right click, save) that converts .obj to .dat - it needs python.org's python 2.6.x language installed in order to run.
Ensure you've got a copy of Obj2DatTex.py inside the same directory as the files you want to convert, then, using your computer command line:
cd <the directory/folder where the .obj file is> Obj2DatTex <name of the .obj file to convert>
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.
