Page History

...

Axis Notation and Scale

When building in a 3D editor, there are a few basics that must be known before you begin.

...

If you are working with models from 3rd party downloads, you may find that they're stored in a scale that is 1000x larger. This is commonly because they are working in millimeter scale for 3D printer software. In that case you will need to actually scale your models up or down before working them into NWN. Find how to do that using the help manuals for each 3D editor software.

Tileset

...

Related Resources

To do all the work needed to build a custom tileset, you'll need to understand where the data comes from during gameplay. Below are some filetypes, specific files, and what they do.

...

Tiles can make use of TGA and DDS textures. They can also make use of MTR material files, which can point to custom SHD shader files.

Tile Model Parts

Light Sources

Light sources on tiles are typically not actually lights. Lights outside of tiles use an actual light node, but tiles instead import a light and control its characteristics in other ways.

Tiles use a dummy node with a specific naming convention to force the position of a light. There are two types of lights that will respond to the toolset and NwScript commands.

Each light will be prefixed with the tile name, exactly as it appears in the aurorabase. Each light will then be suffixed with either "ml" or "sl" for mainlight or sourcelight respectively. And then that suffix will be followed by the light index, 1 or 2.

As example, the light from tile mainlight 1 from tile TTR01_B01_01 would be "ttr01_b01_01ml1".

Animations

Tiles can be animated using the following animation names.

...

Name

...

Expected Frame Length (at 30 FPS)

...

animloop1

...

50

...

Just like it sounds: this (and the below Day2Night) runs at the transition of night/day. Used for e.g. turning on night-time torches or lanterns, and for fading-in night time illuminated window meshes over ordinary daytime window meshes, using keying of alpha values on the night-time window mesh.

...

Aurorabase

This is the specially dummy node underlying every model. It contains information about the tile name and supermodel linking, is the base for its tree structure, and contains the list of animations on the tile.

Every tile must have an aurorabase. If it will be walkable with a WOK file, then it must have its Type set to "Tile".

The aurorabase node name must be the same as the filename for full proper functionality.

The aurorabase node name will be reuised in other parts, such as lights.

Light Sources

Light sources on tiles are typically not actually lights. Lights outside of tiles use an actual light node, but tiles instead import a light and control its characteristics in other ways.

Tiles use a dummy node with a specific naming convention to force the position of a light. There are two types of lights that will respond to the toolset and NwScript commands.

Each light will be prefixed with the tile name, exactly as it appears in the aurorabase. Each light will then be suffixed with either "ml" or "sl" for mainlight or sourcelight respectively. And then that suffix will be followed by the light index, 1 or 2.

As example, the light from tile mainlight 1 from tile TTR01_B01_01 would be "ttr01_b01_01ml1".

In modern tiles, all lights are parented to the aurorabase dummy node.

In some older custom content tiles, lights were instead parented to other nodes, which will likely cause them to no longer function correctly, or at all.

Animations

Animation details are stored on the aurorabase dummy node.

Tiles can be animated using the following animation names.

Animloops

Animloops control a subset of the tile parts. Some parts can be bound to animloop 1, 2 and 3 separately, and then can be enabled/disabled separately. This allows one tile to have many uses.

Day and Night Cycles

During the daytime, the Day animation will play. Likewise the Night animation will play at night.

At the transition hours set in the module, Night2Day and Day2Night animations will play which are intended to cover the 1 hour interval of change going from Day to Night and back again.

During transition animations, you can slide parts out of view, including those with self-illumination values, like glowing glass pane windows. You can also switch on source lights.

Door Placement Dummies

On some old tiles, you may find door placement dummies. These do not actually function in the toolset, and have no functional purpose in the game.

The door dummies usually keep the same position as listed in the SET file tile entry. So you can use the door dummy position to get the aurorabase-relative position of the door. The SET file door position will be equal to the position of the door dummy minus the position of the aurorabase. This is helpful for calculating the SET file door position when your tiles are all inside a single scene in your 3D modeling program.

Including your own non-functional door dummies can help future SET file writers get the proper door positions.

Walkmesh

This is a separate mesh not seen by the clients. It guides units through the tile while within the tile's bounds.

The walkmesh controls which triangles on the walkmesh are walkable and not walkable. It also stores which type of material is painted within the bounds of that triangle.

For material types and their walkable/not-walkable characteristics, see surfacemat.2da.

Walkmesh also controls things like water splashes, and tileset grass.

The walkmesh trimesh portion acts like a collisionmesh for camera bumping, blood spurting effects (splat and bounce emitter commands), and the like. The walkmesh AABB portion controls where units can walk.

The walkmesh node must be parented only by the aurorabase node.

There are many rules which apply to walkmesh construction, which can be very confusing:

1) A walkmesh should be very simple. A mesh polycount of 100 is a good limit.

While a walkmesh can be more complex, older software like GMax will run out of memory processing the walkmesh into an AABB structure before it finishes, crashing the program. It can also fail to report an error while making an AABB branch structure, and will then allow you to output broken walkmesh files.

To compile correct AABB structures for more complex walkmesh, use a 3D editor program that is at least 64 bit.

2) A walkmesh cannot have more than eight faces associated with any given vertex, if those faces are walkable.

Most non-walkable face types do not count toward that limit, though you should still keep them to a minimum of 8 per vertex for future builders that might change your walkmesh surface types.

3) A walkmesh walkable portion must be single-planar non-complex.

You cannot have multi-level walkable portions that actually work correctly. Any vertex from any face cannot therefore overlap any other walkable face. Non-walkable faces do not have this rule.

If you make multi-level walkable space in GMax, you will likely crash the exporter. In other programs, it may allows you to build the AABB structure, but units using that mesh will jump from level to level randomly.

4) A walkmesh walkable portion must point upward. Downward facing walkable portions can crash GMax exporter, and will lead to jerking and hopping of players in the game.

Some invalid walkmeshes seen by the engine will not load properly, setting the entire tile as walkable, 15 meters tall, and with walkmesh surface type 0 = invalid.

Other invalid walkmeshes will crash the toolset and engine, especially during model unload. Other faulty walmeshes have been known to leave a shadow copy of their AABB structure behind when painting terrain in the toolset.

Non-walkable portions can point down to produce ceilings, but if they ever get set to walkable it can crash the toolset and engine. It is a good idea to make a new surfacemat entry for ceilings.

5) Walkmesh must be a single model node. Supplying more than one AABB node in a model will have a lot of undesired consequences.

You can however split the AABB host mesh into multiple elements. This will throw warnings in NwMax, at least for GMax.

This method works very much like PWK overlays for placeable objects. Entry paths for sub elements will be run separately and more cheaply than making a more complex mesh.

All previous rules still apply. No overlap of walkable faces and vertices. Only 8 faces per vertex. Etc.

6) Avoid straight vertical edges. Straight vertical edges breaks the no-overlap rule. Even when one of the vertices are part of a non-walkable mesh, this can still crash the toolset or engine.

Any time you have a height change in the walkmesh, offset it on the XY plane at least 1 cm. on each axis.

7) A walkmesh should have its origin (aka pivot) set to the tile center (aka 0,0,0), sharing the exact position of the aurorabase node.

The walkmesh node cannot be scaled or rotated (must have any transforms reset).

If the tile is a raised tile, this rule still applies.

8) A walkmesh meant to allow travel off the tile must have an edge at exactly +/- 5 meters from the center of the tile. No decimal variation should be permitted.

Very small fractions of 3/1000 of a cm will still allow walking across the triangle most of the time. Longer gaps will make units stop at the edge and they will not be able to cross.

Tile A-Node

The tile A-node was used in early versions of Pre-EE NWN. It allowed static portions of the tile to be animated during the operation of dynamics parts of the scene. All animated parts needed to be parented to the A-node.

In custom content, the A-node was also used as a method to force transparent textures to render above dynamic content, such as player models and visual effects.

During early EE versions, the A-node stopped working. It did not return until preview version 8193.35 [2070a8b9].

The new A-node functionality is similar to the old version with all the same uses. It allows stuff like static object glass transparency, transparent foliage, and water that does not block legs.

To set up an A-node, simply make a dummy node with the same name as the aurorabase, suffixed with "a". Parent to the aurorabase dummy node.

Any mesh parented by the A-node will be rendered in the dynamic drawing phase after static meshes. This improves transparency ordering. It does require more processor time.

Tile Water Options

Water on tiles can be either walkable or not walkable, as determined by the walkmesh.

Walkable default water is set by surfacemat #6, whereas deep non-walkable water is set by surfacemat #17

Other water types exist based on surfacemat values, and you can make your own.

When splashing through walkable water types, a creature unit will leave a splash emitter particle on the surface water. The water surface is automatically determined by the engine. You do not need to do that manually.

Certain effects that leave wind behind, such as spawning in, can leave long-lasting wind-marks on water.

Water texture has a few special options. The first and more common option is fancywater, which is started by using a TXI file, but uses a special shader. The second older method is to use a TXI file to run an Arturo Noise function on the water texture.

SET File Parts

Path Nodes

Path nodes help units move through the tile from another tile to another tile. These are used instead of the walkmesh on the tile, allowing distance pathing to see the tile as a single simple node in a route.

Path nodes are set for each tile in the SET file.

The node type selected should align such that lines from edge to edge line up with the basic throughput of your tile.

It is better to know and understand path nodes before you start making tiles. Use pathnode icons as your starting point for the pathing types you can use in those tiles, that way you don't make a tile that cannot be properly pathed.

A list of path nodes can be found on the SET file description page.

Lines in path node icons connect sections of a tile edge to another edge on that same tile. Selected path nodes for adjacent tiles should align such that the lines from one pathnode would connect with lines on the adjacent tile.

When in doubt, choose the simplest pathnode that would allow a unit to move through the tile, even if it's not entirely correct. Pathing most of three sides of your tile is better than not pathing anything.

A failure of pathing will prevent units from correctly moving across one side of your tile. They will instead take paths through the tile and way out around other tiles just to move to the incorrectly pathed tile adjacent to your tile.

Through all the versions of EE, there has never been any added path nodes. Don't expect any in the future. Try to use only what is already available.

Pathing is required for proper function. Omitting it will prevent creature units from properly interacting with your players. It will also prevent players using click-to-move actions from using your tileset. However, players using driving keys will still be able to use the basic walkmesh to move across your tile.

Visibility Nodes

By default, the visibility node will be the same as the selected path node.

Visibility nodes tell the units if they can see across a given tile. If not, then LOS will be blocked.

In most cases, visibility nodes should be simpler than pathing nodes. Unless warranted, use the simplest visibility node, with straight lines from edge to edge, rather than split edges.

Door Visibility Nodes

Door visibility nodes are those which are used instead of the visibility node when a door is present and closed.

When a door is opened, the visibility node will take over.

Door visibility nodes control maximized darkness behind closed doors.

Groups and Features

Tile groups can be made in the SET file. These are just lists of tiles that will be placed at the same time.

Group tiles are listed from bottom left to upper right.

The first tile in a group must be unique in filename because the ITP file will detect the rest of the tiles in the group using the first tile's filename rather than its index.

Other tiles in the group can be repurposed in other groups.

Any tile in a group will not be available for randomized picking while drawing terrain and crossers.

Any non-group tile sharing the same filename as the first tile of a group will also not autopick while drawing terrain.

Tiles in groups will be rotated as a unit.

You cannot specify an orientation for a tile inside a tile group, so you cannot reuse the same tile but at different orientations in groups.

A group of only one tile is called a feature.

Groups with tiles having doors will place all doors at once. Removing the group is supposed to remove the associated doors, but can leave doors behind.

If you want to leave a randomized tile inside your group, you can set the tile index in that position to -1. However, the first tile in a group cannot use this feature and will crash the toolset.

Height Transitions

The tileset height transition is a value in meters representing the Z-axis (up) offset which the tiles will gain with each step of transition.

The toolset gives you the ability to use Raise/Lower when a tileset has the "HasHeightTransition" value = 1

You cannot lower a tile below elevation 0. There may also be issues with raising tiles too far.

Prior to some version of EE, height transitions needed to be integer values. In the current version, they can now be floating point decimals.

Terrain Types

Terrain types are your tile corners. They are the base terrain available in your tileset.

Terrain types are referenced in the SET and ITP file by name, not index.

Terrain types are required.

Crosser Types

Crosser types are your tile edge types. They are the secondary terrain available in your tileset.

Crosser types are referenced in the SET and ITP file by name, not index.

Crosser types are not required. The default crosser type is blank.

Tile Grass

Tile grass is late-drawn dynamic grass added to parts of the walkmesh at runtime.

Tile grass details like color and density are handled in the SET file.

You can specify an override grass texture name in the grass heading of the SET file.

Walkmeshes using surfacemat #3 will paint tile grass.

Tile grass will move like a danglymesh node, however its limits are different than all other danglymesh, allowing it to move and bounce back over longer time periods.

Tile grass can be affected by wind like danglymesh, however it receives different limitations based on options set by the client in the options menu.

Certain effects that leave wind behind, such as spawning in, can leave long-lasting wind-marks on grass.

See the SET file writeup for more details.

Doors

Door instances are stored with the tile they are attached onto.

In the SET file INI structure, they will directly follow the tile INI structure, and will be referenced as [TILEX_DOORY] where X is the tile index, and Y is the door index.

Sounds

Like doors, sounds can be added to tiles. This is not suggested.

Animloops

Animloops control a subset of the tile parts. Some parts can be bound to animloop 1, 2 and 3 separately, and then can be enabled/disabled separately. This allows one tile to have many uses.

Day and Night Cycles

During the daytime, the Day animation will play. Likewise the Night animation will play at night.

At the transition hours set in the module, Night2Day and Day2Night animations will play which are intended to cover the 1 hour interval of change going from Day to Night and back again.

During transition animations, you can slide parts out of view, including those with self-illumination values, like glowing glass pane windows. You can also switch on source lights.

Path Nodes

Groups and Features

Edge Tiles

Height Transitions

Terrain Types

Crosser Types

Tile Grass

Tile Water

Doors

Sounds