[back]Prepping custom LWO models in Blender
smoothing and material set up

Navigation

• What's this all about?
• LWO have no smoothing
• Doom 3 renderbump and LWO files
• Blender materials and LWO texture paths
• Conclusion : anything else?

What's this all about? ^

In essence there are two main general problems associated with using LWO files for static game models;

• LWO have no 'smoothing' (smooth groups)
• LWO Material path problems

Both of these core issues need a work around solution so that Blender 3D created LWO models render correctly in the Doom 3 engine. This tutorial discusses the measures that need to be implemented for both of these problems to allow Blender 3D to export fully functional LWO custom game models.

LWO have no smoothing ^

Well not quite true, Lightwave does have smoothing but it doesn't work the same way as it does with other 3D applications, it's an 'angle' limit (a bit like Q3Map2's 'phong' shading) - all faces that are under a certain angle threshold from it's neighbour get included into a 'group'; as opposed to the more traditional simple 'polygon grouping' - a selection of faces sharing the same 'group' irrespective of it's angle or orientation to it's neighbour.

Because of this it means when LWO models are brought into Radiant (which ever variety that is) they often appear 'faceted' with visible edges and hard lines appearing all over a model (see image below).

This is caused by the game engine not reading the smoothing angle that can be set on the mesh - as with most things to do with game editing it's either all or nothing. As a result the game gets around this problem by using a setting in the material file to apply smoothing.

Doom 3 'renderbump' and LWO files ^

When looking at any of the original material files for a Doom 3 powered game, one thing that's immediately noticeable is the amount of 'junk' left in place; most noticeable is the 'renderbump' information which the engine references when processing high poly models for the production of normal maps. This bit;

renderbump -size 512 512 -colorMap -aa 1 -trace .125 [path]/[to]/candle_a_local.tga [path]/[to]/candle_a_hi.lwo

What isn't generally known is why that data is left in the material files, especially when associated with LWO files; the engine reads it as an instruction to apply a general smoothing over an entire model based on material assignment.

In other words, if you want your custom LWO model to have smoothing in game you need to add some 'renderbump' information to the material file.

The good thing is that what you add doesn't even need to be specific to models used for actual renderbumping, even if any were used, they can point to anything as the important part is the 'renderbump' parameter itself.

So having a basic material like this;

models/characters/donkey/skin_tan
{
   qer_editorimage models/characters/donkey/donkey_d.tga
   diffusemap models/characters/donkey/donkey_d.tga
}

Would need changing to;

models/characters/donkey/skin_tan
{
renderbump -size 512 512 -colorMap -aa 1 -trace .125 [path]/[to]/candle_a_local.tga [path]/[to]/candle_a_hi.lwo

   qer_editorimage models/characters/donkey/donkey_d.tga
   diffusemap models/characters/donkey/donkey_d.tga
}

Design note : There appears to be a 'minimum requirement' for the parameters needed to get smoothing to work because using 'renderbump' on it's own changes nothing on the model. However, adding 'renderbump -size 512 512' does, so it's possible that the rest of the text used in the renderbump command line is not actually required for the purpose of smoothing LWO models.

You should then find (after restarting or reloading the game/editor) that the model in questions has smoothing applied to it universally (with edges based on the UVWmap layout) when ever the 'renderbump' parameter appears in a material.

Design note : If you had two materials applied to a model, one with and one without 'renderbump', the one with would appeared smoothed in game; the one without won't, it'll be faceted.

Blender materials and LWO texture paths ^

Unlike ASE format models which can be editing in a text editor to correct material path 'errors', LWO files can't because they're a compiled binary format, which pretty much means editing or tampering with the file in the same way as you can do with ASE files will break them. This means LWO files need to be properly set up and exported at source.

There's a problem here though when using Blender 3D for this process. The Doom 3 engine material 'headers' - the bit you reference in a models material slot - are usually formatted for ease of use/reference, similar to the following;

models/characters/donkey/donkey_tan
{
   qer_editorimage models/characters/donkey/donkey_d.tga

       diffusemap models/characters/donkey/donkey_d.tga
       bumpmap models/characters/donkey/donkey_local.tga
       specularmap models/characters/donkey/donkey_s.tga
}

Design note : It's important to keep in mind that this isn't an actual file path in Doom 3 but a reference 'name'; it can be called anything but generally speaking it's written as a file path for production purposes - someone else looking at that path would know instantly where to look for the assets.

The problem with this type of path is that it's too long for use with Blender; the current LWO export script writes the game material path to the model based on the text written in the MA:[text] data block (see image opposite) which currently has a 19 character limit.

What this means is that the material reference needs to be truncated and shortened to fit within that 19 character limit in Blender as well as being duplicated for the material header used by the games material system; both have to match otherwise a "material not found" error occurs.

So the default path of;

models/characters/donkey/donkey_tan

Needs changing to (or similar);

models/c/d/d_tan

Anything in fact which brings the material name under the 19 character limit in Blenders MA: block; this is the important bit that's required to export correctly set up LWO models from Blender for use in Doom 3 powered games.

This then means a full (but basic) material goes from this;

models/characters/donkey/donkey_tan
{
   qer_editorimage models/characters/donkey/donkey_d.tga

       diffusemap models/characters/donkey/donkey_d.tga
       bumpmap models/characters/donkey/donkey_local.tga
       specularmap models/characters/donkey/donkey_s.tga
}

To this;

models/c/d/d_tan
{
   qer_editorimage models/characters/donkey/donkey_d.tga

       diffusemap models/characters/donkey/donkey_d.tga
       bumpmap models/characters/donkey/donkey_local.tga
       specularmap models/characters/donkey/donkey_s.tga
}

Design note : If more than one object is using the same texture set referenced in a material, it's easier and more 'optimal' to simply duplicate the the material and edit the header than it is to duplicate the assets.

As mentioned above in the design note, keep in mind this is not a real file path to the location of the assets - that's done further down the material file - it's simply a 'reference name' which is used to 'tag' textures referenced in a game material to all or part of a models mesh (so the game knows that 'X' material needs to be applied 'X' section of the model); the textures and models can sit in any folder (just as with any other assets) and so long as you reference their locations correctly in the material file or when loading the model into the editor you should find the mesh renders correctly textured.

Conclusion : anything else? ^

If you want to work with LWO files instead of ASE there is supposed to be one main advantage in doing so; LWO files support 'multi' materials.

Unlike ASE files, LWO files don't necessarily need to be split into separate mesh objects associated with each material assigned to a model; an ASE with 4 different textures would need to be broken into 4 different physical objects (which get combined into 'sub-objects' on export), LWO files doesn't which means you don't end up with forced smoothing edges where the different sections meet, as happens with ASE models.