Oblivion/Oblivion 201 - Meshes and Data
Meshes, Their Data, and You
Information herein is gathered from Oblivion .nifs, in v188.8.131.52. The info may be valid for other games, or at
the very least, as reference if you are working with .nifs from another game.
Many of you will be working with meshes, so here's a practical guide for doing so.
Starting with the hierarchy, we have the root node. Depending on what type of model we're working towards, be
it a piece of architecture, armor, a weapon, etc, it will be attached as a child to this node.
The root node also needs to have some extra data attached. Prn and BSX flags are common.
Prn: This ExtraData block defines which node on an actor to attach, if no skindata is present. Creatures also
use these to attach static pieces to their skeletons. In the case of weapons, the proper Prn needs to be set
for the type of weapon it is, otherwise the character animation won't grab the weapon.
Shields: Bip01 L ForearmTwist
For Hair Bip01Head
One-Handed weapons: SideWeapon
Bows and Two-Handed weapons: BackWeapon
Torches and similar: Torch
Lots of idleobjects for special animations seem to just use "Weapon" "Bip01 R hand" or "Bip01 L hand". Check
the idleobject you are replacing for the proper setting, or inside the animation .kf.
Many of Bethesda's files have UPB attachments. (User Property Buffer) These don't seem to be used by Oblivion.
For Havok blocks, look up another guide for now, as those are not covered here yet.
[Finessing Physics] @ TESCS wiki
niTriShape and niTriStrip
These two nodes signal the start of a mesh in the hierarchy.
Block details for a shape node are basically the same as a regular niNode. Flags should be set to Continue, and
you can rename it as you please. (Has Shader has no apparent use for oblivion). Here you can link Data, Extra
Data, Properties, and a skinInstance block. You can use the "Hidden" flag to make a shape invisible in
Shapes are standard polymeshes: They define the structuring of the mesh to be rendered.
Strips are similar, but triangles are ordered into strips of triangles. No real noticable visible difference,
except that strips get rendered differently, and more optimal. If you have ever gone into wireframe view in
Oblivion and wondered at theodd triangles and lines jumping all over, especially on architecture geometry; The
stripping process will create invisible triangles to disconnected strips to ensure one connected strip, and that
is what you see.
- Strip a mesh when you can. In most cases, a strippified mesh will improve performance, and a mesh broken
down into logical segments and each of those stripped will perform even better. There are some cases where a
TriShape must be used, such as hair or heads, and sometimes special FX meshes.
-rClicking on a TriShape node gives you the option to Mesh>Strippify. On a triStrip, you get
Mesh>Triangulate. -If you are pasting a mesh over another, they need to be of the same type; You can't
paste a triStripsData over a triShapeData to replace it.
-Properties are directly attached by rClick-ing a shape, and do Node>Attach Property. This automatically links
the newly created property in the appropriate slot. If you need to link/unlink a property, do so via the
"Properties" array in the TriShape node.
Mesh>Prune Redundant Triangles: Not sure on the exacts here. Likely to be useful in cleaning a troubled
mesh, or covering for modelling oversights? I assume that it removes same-space triangles.
Mesh>Remove Doublicate Vertices': Some smoothing methods duplicate vertices in-place. This removes the
Mesh>Remove Unused Vertices: Another troubleshooting attempt, for cleaning off unused/unconnected
Mesh>Face/Smooth Normals: I cover the nature of normals shortly, but you can re-seat normals back to their
face position, and then Smooth them. Actual smoothing depends the mesh and how it is constructed. you need to
Update Tangent Space after altering the normals this way.
Mesh>Update Tangent Space: This updates or creates tangent space for the mesh, and places this data into a
BinaryExtraData block attached to the shape. This step is needed for any mesh that will have a normal map
Texture>Export Template: This will export a wireframe .tga image of the UV mapping for the selected
shape. If you are doing retextures for a mesh, this is the easiest way to get a template to work from. UV
coordinates define what parts of the texture file correspond to which parts of a mesh.
Texture>Edit UV This opens a new window that will allow you to make changes to the UV mapping for the
-- On the subject of injecting meshes and it's importance
Currently, we have exporters for Blender, Maya and 3ds max. Many other modelling applications can be used, many
of those can export to .obj (see manuals or plugins for details) to inject into a nif file. The only two big
limitations are: .objs can't have vertex colors, or oblivion's specific SkinData, used for rigging to skeletons.
But In some cases, exporting a skinned mesh via .obj can work well to your advantage!
Clothes/armor/body parts, and heads have data for skinning, but you can make changes in a 3d app without having
to re-do all this. The .obj format will maintain Vertex Order when going back and forth. You can safely make
changes to a shape, and put it back into the .nif with no messing around with skinning.
<<important>> By maintaining vertex order, I mean that you cannot do any action that would change
this order. One can scale, move, and rotate, but not weld or separate, for example.
Example: You're merging two pieces of armor, but the pauldrons clip the breastplate, and you wish they didn't.
-rClick the shape for the pauldrons, and OBJ>Export. Do the same for the breastplate shape, so you have
reference to work with, or make changes to the breastplate if needed.
-Import these into your 3d app. (refer to manual)
-Use the tools available there to move the pauldrons into the desired shape. Don't forget to Apply the
transformations and clear node history (if used) when you're done.
-If you only changed the pauldrons, export those back out to .obj.
-Back in nifskope, rClick the pauldron's triShape, and do .OBJ>Import. Nifskope will give a warning about .obj
not having skindata, but that's ok, we're professionals. (The trishape already has our skindata, we just moved
the vertices, so the skining work stil applies)
-Again, if you edited the breastplate too, import that over the breastplates' triShape.
If all went well, your changes should be apparent in the render view! If any triangles are stretched way out or
otherwise distorting, then you lost vertex order during modelling. Somewhere along the way, you (or the 3d app)
did something to alter the order, weld, separate, cleanups, inserting or deleting faces, edges or verts,
polysmooth, extrude, bevel, chamfer and so on: These all add or remove vertices from the mesh and cannot be
used for this excersize.
It may be possible that your 3d app is messing it up for you. Make a scanthrough of the import/export options
available for doing .objs for possible clues. Some apps have an option to auto-weld everything when importing,
which is obviously a problem.
big tip: Check these things first before spending hours doing real work! Once you get the .obj into your
app, export it right away without making any changes; and take it back into nifskope- This will let you know
right off if you need to examine program-specific settings.
Shape and Strip Data
This is the actual meat of a mesh, it's attached to the parent shape via the "Data" value.
-rClicking the triShapeData in the block list also yields an option to flip the UVs in a number of ways.
-We also have Mesh>Update Center/Radius. In some cases, the radius was miscalculated during export. In-game,
these meshes will "dissapear" if they aren't very close to the center of the screen. Use this option to correct
Num Vertices: Defines how many vertices are used in the Vertex list. (if you change this number, you'll
have to make a change to "normals" to see a change in current Nifskope) Has Vertices: y/n. kinda obvious :) If you're having export problems, this might be something to look at.
Selecting the Vertices array in block details to display them in the render view. Selecting an indivudual from
the list highlights it. Coordinates in XYZ can also be edited.
You can rClick the Vertices list and do "Normalize", but I can't think of a proper example of using this.
Num UV Sets 2: I'm not aware of any oblivion meshes that use more than one UV set, but this would
assumedly define how many sets of UV configs to use.
UV Sets: The big array of UV coordinates. Again, UVs are the part of the mesh that tell the renderer
which portions of the texture to use. The 3d mesh exists here in 2d, and the modeller unwraps these uv
"shells" to prep the model for texturing. This is useful to check to see if it exists or not for
troubleshooting. (In some cases, the UV coordinates were never exported from the 3d app, which will need
correcting before moving on.)
Center/Radius: Defines the center of the shape. Radius is similar. These are used by the engine to
determine when or when not to render something. When a mesh is completely offscreen, for example.
Has Vertex Colors: y/n. Turning this on (if it was off) will default all values to white. (array>update
on the Vertex Color list to make the change, as usual)
Vertex Colors: The big array of vert colors! As with the other arrays here, selecting the list will display the points on the mesh, and selecting an
individual highlights it in the Render View. You can edit values by hand, or use the Color Wheel Icon. Values
are RGBA, and alpha is only visible if an AlphaProperty is present.
A VertexColorProperty also needs to be attached to the shape for these to be used. Use the mode "amb_dif" for
both values, with a flag "40" Setting their mode to emissive will make the mesh emit light.
Vertex colors are used in a wild number of ways in Oblivion. Foremost, for shading; take a look at Oblivion's
static meshes, such as architecture, or furniture. Turn on/off textures in the Render settings to see them
without a texture, or flip "Has Vertex Colors" on/off to see the mesh without the vertex colors, and how the
shading interacts. Grass meshes use vertex colors to control how much they sway. Vert colors can be set to be
emissive, control specularity, control/refine special effects, control alpha transparency, and more that we may
They've used a Radiosity or Occlusion method to define shadows on many of their meshes. Doing this to their
meshes can really make them pop out by adding the impression of shadows at little cost to the game performance.
Try looking up Ambient Occlusion, Final Gather, Radiosity, Global Illumination, baking, or prelighting for your
3d app for more information.
Has Normals: y/n. States whether or not the mesh has normals.
Normals: XYZ rotations for each normal. Also, clicking on the Normals list will cause Nifskope to render
the normals, and selecting an individual from the list will highlight that normal on the mesh. They appear as
lines leading away from their sources. If you have problems with some faces being backwards, you will see that
the normals point in the opposite direction (from the desired direction, that is.)
Each vertex has a "Normal". Normals define how light reacts to the mesh. By default, vert normals are "set to
face" - They point away from the polygon perpendiclarly. When viewing this polygon straight on, it will show
the most light. As you rotate this polygon, it reflects less light to you, to help determine the "depth" of the
scene. Also, having all normals set to face results in hard, chiselled edges between every polygon- the kind of
thing we associate with older-model low-poly 3d graphics.
We can give the model a smoother look by altering each vertex normal. If we need to fix this in nifskope, you
can do rClick>Mesh>Smooth Normals. This is an operation usually easier done in a 3d modelling app, where
greater control over what gets smoothed is available. This method applies smoothing to the entire shape, and
only unwelded edges will retain their "hardness" (Say you have a simple cube, and all the vertices are welded
together: the smoothing will affect all the edges, the cube now looks a little funny. If the vertices are
unwelded, the faces are free-floating of each other, but still in the same positions: Smoothing now won't alter
the hard edges of the cube.)
- The Normal map works with a pixel shader to alter how normals react on a per-pixel basis. It is a method of
making a mesh appear to have more geometry and detail than it actually does.
Also on a related note, Bethesda's creatures are excellent examples of how normals and normal maps can really
bring a model into shape. Check out any of their fleshy beasts, use Render>Settings to turn on/off the normal
map shading to see the model without a normal map applied. The shading becomes very apparent.
The Extra Data
BinaryExtraData, which is generated by rClicking on the trishape node, and doing Mesh>Update Tangent Space.
This data block is needed for rendering the mesh, and is the base for which the normal maps bend the
normals. Clicking on this data block will cause nifskope to display the vertex normals for your mesh. When
making a new mesh, The first thing I do in nifskope, is do the tangent space, apply a flat gray texture, which
has a flat normal map (which has a white alpha channel). Then I Set the material settings to nearly black,
except I crank specular up to white. Rotating the model around, I can easily check that all my normals are in
the right direction. If you have an ugly seam, that causes a diamond pattern, or a zig-zaggy non-smooth face,
check with the normals view on. You'll probably see that normals are bent crookedy. This can be caused by
overlapping UVs, or duplicated vertices. To get a smooth normal here, you can do the following in your 3d
editor and export again: Make sure the offending vertices are joined. In some cases, flipped UVs will cause the seams. This can be fixed by unwrapping the uvs fully, or by splitting
the vertices along the seam, and then re-averaging the resulting normals. (this may not be the best advice, but
You can also check the Normals Array in the ShapeData. Highlighting any normal in the list will also highlight
it in the render view. use the arrow keys to go down through the list until you hit the offendor, and edit the
value by hand until satisfied.
Triangles: Lists all the triangle connections.
For a triStrip, The data works more or less the same, except now we don't have triangles. Instead, we have:
Num Strips: Shows you how many strips the shape is made up of. This was generated by the stripper code.
Strip Lengths: How many points are in each strip.
Has Points: y/n, should be yes already, nifskope did it for you if you stripped a trishape.
'Points: From nifskope: "The points in the triangle strips. Size is the sum of all entries in Strip
We also have an option to rClick the triStrip, and Mesh>Unstitch Strips. This will separate the strips into
smaller ones with no sophistication.
Most .nifs can have multiple shapes in them, and I recommend doing so. Each shape can only have one material
and one texture affecting it, which is one reason for using multiple shapes. For many effects, architecture,
and some armors, you may need to use more than one texture. Again, keep in mind, that the numbering of a node
is something to pay attention to. Two trishapes using the same texturingProperty will both reference the same
numbered property. You will have to change one to use a different one, this is done easy by
Spells>Optimize>Unique Properties. Conversely, you can re-use properties between different shapes. Say you've
rClicked on a shape, Node>Attach Property>NiAlphaProperty to your first shape. You could then go do your second
shape, Edit the Properties list - Increment it by one. Update the property array, and then enter the node
number for the alphaProperty to link it. Now both shapes share the same alpha property.
If you have a large number of disconnected shapes that need to share properties, it may be best to use them in
an array. Ex: I had rigged up a sword that used 7 small billboards each act as a seperate "light" effect. I
started a new BillboardNode attached to the root node, and attached the alphaProperty right to this new node.
In this case, all the meshes, being children of a node that had alpha transparency on it, behaved with
Texturing and Materials
I've covered both these in more detail in the Breakdown guide, so please check there for more information.
Many weapons also feature a sheath that sits on the characters' side at all times, and the weapon is put into it
when sheathed. This is done by having a second NiNode attached to the root node. It has been renamed to "Scb"
This "Scb" node has the mesh for the sheath attached to it. The game engine uses this node to attach the sheath
portion to the appropriate place on the actor who has the item equipped.
Many effects or other low-visibility have a node named "EditorMarker" Which has a square mesh attached. This is
to make selecting and moving these objects in the Construction set possible. Anything attached to these nodes
(should) not not be rendered in-game.