Difference between revisions of "OXP howto model"
m (some fun for modellers) |
m (more blurp about exporting models) |
||
| Line 13: | Line 13: | ||
== Optimize == | == Optimize == | ||
| − | Optimizing models and | + | 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 === | === 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 | + | 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. | ||
| Line 33: | Line 33: | ||
===Tessalation is evil === | ===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 | + | 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]]. |
| − | == Export the model == | + | == Export the model == |
to obj( mtl texture) and convert to *.dat format. | to obj( mtl texture) and convert to *.dat format. | ||
| + | [[Image:Obj2dattex.png|none|left|400px|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 (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). | |
| + | * 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). | ||
| + | |||
| + | Please note that the [[Oolite_Converters|converter scripts]] need Python 2.6 or higher (but won't work with 3.x!!). | ||
| − | |||
| − | |||
| − | |||
| − | |||
== Edit [[shipdata.plist]] == | == Edit [[shipdata.plist]] == | ||
| Line 61: | Line 62: | ||
One important thing to remember about subentities is that they cannot have sub-sub-entities. | One important thing to remember about subentities is that they cannot have sub-sub-entities. | ||
The other is that [[Shipdata.plist#frangible|frangibility]] is defined for the main entity, not seperately for every SE. | The other is that [[Shipdata.plist#frangible|frangibility]] is defined for the main entity, not seperately for every SE. | ||
| + | |||
| + | |||
| + | == Links == | ||
| + | * [[List_of_software|List of software]] | ||
| + | * [[Oolite_Converters|Converter scripts]] | ||
[[Category:Oolite]] | [[Category:Oolite]] | ||
Revision as of 18:28, 2 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 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.
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 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.oxp.
Export the model
to obj( mtl texture) and convert to *.dat format.
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).
- Copy the
Obj2DatTex.py(orObj2DatTexNorm.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.
