Tileset creation

Tileset Basics: Neverwinter Nights 2 shipped with seven tilesets, Mask of the Betrayer adds two more to that list, but many are looking for new and interesting environments to add to the game. The creation of a new tileset isnt terribly difficult but can be time consuming. There are a few Basic things to know before you get going...

My assumption here is that the reader is familiar with 3Dudio max and modelling in general, it isnt my intent to instruct on how the modelling itself is done or how to create useful textures.

Tools:

Everything that follows presumes you are using 3D Studio Max version 7 and Tazpn's MDB tools. Steps are a little different if you are using the Epotron utility (steps relating to flags which you dont have to enter in Exportron, since you can check a box for the proper properties)

2da files: Depending on the type of content you are including in your tileset you will use several 2da's from the game. Regardless you will have to add entries to Tiles.2da and Tilesets.2da, if you create metatiles for your new set you will also have to add entries to Metatiles.2da. Additionally, if you create tileset specific doors or placeables you will find yourself making entries in doortypes.2da and placeables.2da respectively.

Tiles.2da: This 2da file includes entries for every tile in every tileset in the game, it has six entries per tile as seen in the example below.

2DA V2.0

n LABEL STRING_REF TILESET TILE_TYPE VARIATIONS 0 Floor_4_Corners 111908 SI CCCC 1 1 Floor_3_Corners 111909 SI CCCX 1 2 Floor_2_Corners 111910 SI CCXX 1 3 Floor_1_Corner 111911 SI CRNR 1 4 Floor_2_Corners 111912 SI CXXC 1 5 Floor_1_Corner 111913 SI CXXX 1

The first is the line number of the 2da file and is simply a consecutive numbering from the beginning to the end of the file.

LABEL: The LABEL entry is a string entry that can be anything, or empty "****" (note: empty entries are always four asterisks) in the case of OEI tilesets the LABEL line corresponds to the text referenced by the String_ref entry. As of 1.06 the LABEL column has no effect on what you will see in the toolset.

STRING_REF: The String-ref column references a line in Dialog.tlk which is the main tlk file for the game. It is generally accepted that one does not edit dialog.tlk.

edit: You can enter a text string into the str_ref column and it will appear in the toolset, thus you can enter custom names for your tiles, you can also add in the correct name of your tileset or names of your metatiles. I have tested and Tiles.2da, tilesets.2da and metatiles.2da all exhibit this behaviour.

Note: this doesnt effect your ability to select, use, bake or otherwise work with new tiles.

TILESET:

This code is an abbreviation of the tileset name (SI = standard interior, CV = cave etc..) and appears in the name of each model in your tileset. More than two letters should work fine if you need it, though more than two letters hasnt been tested to my knowledge.

TILE_TYPE:

This is a 4 letter code used by Obsidian to identify the type of tile, it is also used to group similar tiles and it also identifies the icon used in the toolset that appears in the toolkit when selecting tiles. You can use any code of your own if you like.

However your models will also have this code as part of their name and if no Icon matches the code you use then none will appear in the toolset. You will want to add a new icon for each new code you create.

In many cases you should be able to reuse the OEI 4 letter codes, this has many advantages in that you can use the tile type code and the label and string-ref's that correspond with that code, this will make your tileset that much more familiar to users.

Take a look at OEI tile icons and tile layout to best learn the 4 letter code.

VARIATIONS: This is the number of tiles in the tileset that use the same code. If you have only one such tile then the entry should

be 1, 2 would be 2 and so on.

Tilesets.2da: This 2da identifies the tilesets available to the builder. The tilesets that shipped with the original release of Neverwinter Nights 2 incluede the; Standard Interior, Standard Castle, Crypt, Standard Mine, Caves, Illefarn and Shadow Fortress tilesets, Mask of the Betrayer add Sunken ruins and Estate. The 2da file also identifies a Tree Dungeon tileset but no models are included with the game and as such it doesnt really exist.

2DA V2.0

n LABEL STRING_REF TILESET 0 Standard_Interior 113585 SI 1 Standard_Castle 113586 SC 2 Crypt 113587 CR 3 Standard_Mine 113588 SM 4 Caves 113589 CV 5 Illefarn 113590 IL 6 Shadow_Fortress 113591 SF 7 Tree_Dungeon 113592 TD 8 padding **** ****

Column entries are similar to the Tiles.2da except in this case the LABEL column contains the name of the Tileset, the String-ref again points to that name in the Dialog.tlk file, the TILESET column is the same and must be identical to the tilset columnn Tiles.2da.

edit: you can enter the name of your tileset in the Str-Ref column and it will appear in the toolset - if your name incluses spaces make sure to place the underscore "_" character in place of the space in the text. If you desperately need the space and dont want to use the underscore - then try placing your text in quotation marks in the str_ref column (I havent tested this but its how it worked in nwn1 IIRC)

Padding: When entering your new tileset into Tilesets.2da or your tiles into Tiles.2da, be sure to provide ample padding between your entries and those of OBsidian, always provide a buffer so that when expansions and patchs are released, your entries remain unchanged.

It is also worthy to note that users of your tileset, who want to use other custom tilesets will have to combine their 2da files since only one can be read by the toolset or game at a time. It would be worthwhile to look at other tilesets available and see if you can find out their 2da line range and try to avoid them. There is also a wiki that is trying to organise a reservation system for tlk and 2da entries that can be found here.

File Naming Convention:

NWN2 naming conventions are important so your tile properly shows in the editor, and can easily be built with. Naming the objects in the tile is also important. Objects in a tile must have unique name, in the tile, and across all other tiles. If you have two identically named objects, one or the other will appear.. Actually you can pretty much name your files any way you desire - provided you are consistant through the listings in the 2da files. However the naming Convention used by Obsidian is logical and easy to follow, and if you use it you will automatically use the toolset icons they have already put together.

The standard approach to naming works quite well:

TL_AA_BBBB_##.MDB where: TL = prefix for tile models

AA = prefix for tileset (CV for caves for eg) - appears in Tiles.2da, Metatiles.2da and tilesets.2da

BBBB = tile type, coded values for the pattern of the tile - ie CCCC is for an open area tile, no walls on any

corners. (appears in tiles.2da and Metatiles.2da)


 * 1) = tile variation number, ie for the above 'CCCC' open area tile, lets assume you have 4 variations, these should

have identical names apart from the ## which should number from 01 to 04. So far I have made up to 12 variations and not

seen a cap. - Appears in Tiles.2da

The approach to variations is slightly easier to work with than NWN1 - as the tiles.2da has a single entry - with the

variation count in the last column. so if you were adding a tile that was a variation to an existing one - all you need

to do is add the variation count in the tiles.2da and name your new model appropriately. Understanding the 4 letter code: Once you understand how Obsidian used their code to identify the different configurations of tiles, it becomes easy to

not only know how to name your own tiles of the same configuration, but it also helps you to develop your own codes if

need be. The 4 code letters refer to the vertex's of the tile. They are read starting in the upper left corner and read left to right on upper line and left to right on lower line.

Code:

i.e. 1...2 3...4

Codes:

C - Corner...basicly if a wall doesnt end on this point its either 'c' or 'x'

X - nothing

W - point is an endpoint of a blank wall (no door)

D - point is the endpoint of a Wall with a door opening

pardon the ascii art Code:

Code: W-W .    | .     | .     | C.....W WWCW - (walls on N and E sides open on W & S with a corner in the SW

D-- --D .    | .     | .     | C.....W

So the codes represent endpoints..hallways however are slightly different.. a blank hallway wall uses the Code 'H' and

seems to default with open ends on E & W faces so a hallway with no doors would code as HHHH and look like.

Code: H-H .    . .     . .     . H-H

But a hallway with doors goes back to the Previous code - 1 door in a hallway is DDWW and a hallway w/ doors on north and

south walls is DDDD

Code:

D-- --D .    . .     . .     . W-W

D-- --D .    . .     . .     . D-- --D

There are a few tiles that have a unique code defining their layout.

STU (Stair UP) and STD (Stair down) both exit the tile on the north face.

RRRR seems to be a flat roof or blank flat tile - it has no walkmesh or collisions SPR1, 2 etc... are single tile Rooms with 1 or more doors. SPU1..2..3 etc.. are hallway terminators with varying door combinations SPU1.. door to N SPU2.. door to N & E SPU3.. door to N,E & W SPU4.. Door to N & W SPU5.. door to E & W SPU6.. no door

Meta tiles...or multiple tiles, are similar to the groups we saw in nwn1... their Code is M followed by a numeric code.

The code is the size of the metatile in the number of normal tiles wide x high. So a metatile that was the equivelant of

2 tiles wide and 2 high would be named TL_AA_M0202_##.mdb There is one floor tile code CRNR which is a open floor tile with one corner piece in the NW corner...why it isnt CXXX I

cant explain. Neither N or R appear in the code again..except in the case of R which appears only in the SPR code.

Basic Tile Modelling:

The size of an interior tile in nwn2 is 9 meters wide by 9 meters deep. Height isnt limited to my knowledge however high ceilings are difficult to see in game, and high walls make seeing down into the space during gameplay difficult. To make the tileset user friendly I would suggest matching the fade height of Obsidians tiles, what you do above the fade line is pretty much up to you.

edit: All geometry should have face ID's set to 1.... the only exception to this is the walkmesh whose id is set to determine the sound made while walking upon the surface.

Dimensions:

9m x 9m base OEI has geometry as far as -10.78 m below z=0 Walkmesh as low as -7.68m below z=0 Obsidians tiles fade at z= +4.2m typical door is centered on the sides of a tile and are 2.7m high x 1.8m wide height - no limit known

Polygon Count:

As a general rule, the fewer the number of polygons in your tile models, the better. Nwn2 can handle more polygons per tile than nwn1 could which is a good thing. My reccomendation would be to try to limit your tiles on average to 2000 polys or so.

Walkmesh:

The walkmesh is special geometry found in every tile. It's name must be the tiles (file) name appended with an �_W�

Example = TL_CV_CCCC_01_W

The walk mesh uses a texture also. I find it easiest to open a OEI tile and sample a walk mesh to get the texture. The vertex's on the edges of the walk mesh should match up with any walkmesh put next to it. So careful work on maintaining consistant vertex elevations of your walkmesh are important.

In the User defined properties. Type UIFlag = None

(Right click the object and select properties, then the User Defined tab)

While in properties, also make sure the "renderable" box is UNchecked

This flags the walk mesh as a walk plane. Face Ids are;

MTL DEC HEX Name 1 0 0x0000 no walk 2 9 0x0009 dirt 3 17 0x0011 grass 4 33 0x0021 stone 5 65 0x0041 wood 6 129 0x0081 carpet 7 257 0x0101 metal 8 513 0x0201 swamp 9 1025 0x0401 mud 10 2049 0x0801 leaves 11 4097 0x1001 water 12 8193 0x2001 puddles

notes about walkmesh:

For a walkmesh to bake from tile to tile - it is mandatory that the vertexes line up. what this really means is that each of the four edges of your tile must have walkmesh vertices in the exact same place as each other. Also if you want your tiles to mesh with tiles that originally came with the game then you must have vertices in the exact location that Obsidian placed theirs.

The easiest way to do this is to import an OEI tile and use its walkmesh as a basis for your own. Remember that you cannot add a new vertice at any edge of the tile without breaking its ability to seamlessly bake to any walkmesh that doesnt have that exact same vertice.

If you are working on a tile that is similar in type (i.e. CCCC) to an OEI tile then by all means import the walkmesh from one of OEI's tiles as a starting point for your own.

Also it takes a little bit of forethought when designing your tile to know where the walls or other elements are going to be so that they reasonably align with thes vertice points on your walkmesh.

Floors:

There are two types of floors that you can accomodate in your tiles; Static and Rotating.

Static Floor planes: Static floor planes do not actually rotate when you rotate the tile in the toolset. Instead the floor remains motionless and the walls, columns and roof rotate about the center of the tile. This works on any tile or tileset that has a single level.

Such tiles place a "_F" suffix to the floor plane and any other geometry that should remain motionless on the floor.

Example = TL_CV_CCCC_01_F

The advantage to this is that your texture doesnt need to be seamless regardless of rotation but can tile independantly in each direction. Also your floor geometry really aught to be the full 9m x 9m size of a typical tile.

In the User defined properties. Type UIFlag = No_Cast_Shadows

If it does not have this flag set, the object will not light correctly in game

Where this doesnt work at all is on any tile that changes elevations, such as stairs up or down, or pit tiles or any other multilevel tile. In this case you need a;

Rotating floor:

The rotating floor does exactly that, when you rotate the tile in the toolkit, the floor rotates with the wall and roof geometry. In this case your floor geometry can be anything, the suffix for this type of floor is "_RF"

Make sure to read "How to set up a tile for texture swapping"

To get the targeting cirlce to appear on the floor you need a different user flag...

In the User defined properties. Type UIFlag = No_Cast_Shadows | Projected_Textures

If it does not have this flag set, the object will not light correctly ingame and projected effects circles like your targeting circles for area of effect spells and even targeting circles around enemies and npcs wont appear.

Walls: One object in your scene needs the exact file name. You should always make it the wall. This is required for the collision mesh to be seen by the tile in game. It also applies to texture swapping. So the walls get named exactly as the tile will be named in game.

Example = TL_CV_CCCC_01

Make sure to read "How to set up a tile for texture swapping"

Object properties;

In the User defined properties. Type UIFlag = No_Cast_Shadows

If it does not have this flag set, the object will not light correctly in game

Roof fading: Adding the _R suffix to any object name will cause it to fade as the camera gets higher than the object. All of the tiles that ship with the game seem to fade at the same height (approx 4.2 m above the z=0 plane) when the players camera is below that plane the ceiling is visible. If you want your tiles to be able to work with the original tiles it is probably wise to set your fade height to match OEI's.

Example = TL_CV_CCCC_01_R

Make sure to read "How to set up a tile for texture swapping"

Object properties;

In the User defined properties. Type UIFlag = No_Cast_Shadows

If it does not have this flag set, the object will not light correctly in game

Collision mesh: The collision mesh is used to block line of sight and act as a barrier for the camera so you can�t fly the camera thru walls. The suffix of the collision mesh is _C3. The C3 mesh must be a single object and should be placed close to the wall to prevent the camera fromgoing behind the wall itself.

If the C3 mesh is to far away, it will not block LOS (but will block camera). The collision mesh, like the walkmesh, isnt visible in game.

The C3 mesh uses a texture also. Open a OEI tile and sample a C3 mesh to get the texture

Example = TL_CV_CCCC_01_C3

Object properties;

In the User defined properties. Type UIFlag = None Renderable is unchecked

Hook and anchor points: Hook and anchor points are used for automatic snap of certain objects to the tile, for example torches to walls or doors into door frames. I don�t make these. I simply import them from OEI tiles as I need them.

A door hook is a dummy object whose pivot point is the exact spot where the door�s pivot point will position itself. A door hook on a building should be oriented in the lower left hand corner of the doorway, and it�s local X axis should point across the face of the door

Hook-points have the prefix HP_ but may otherwise be named as desired.

Tiles with doors need atleaset two hook points.

One at the top center of the door frame, and the other at the bottom left inside of the doorframe (import a OEI tile to

see an example. ie TL_CV_DDCC_01.mdb)

Textures: In the material editor a good starting point would be to set your material to;

Standard Material (typical OEI settings) Specular = 100 Glossy = 10 Ambient Color = white Diffuse Color = white

You can vary these if you desire but be sure you are consistant throughout your tileset or you will be chasing material inconsistancies for a long time

Material Settings in 3ds Max: Textures and material properties must be correctly assigned and set in the max file. In some cases, a model�s material (shader) can be utilizing as many as four different textures. A Diffuse Texture, Self-Illumination Map, Tint Map, and Normal Map are all being utilized to achieve the final visual result of the object. Note that the tint map image is plugged into the �Filter Color� slot in the material editor. Only the Diffuse Color, Specular Color, Specular Level, and Glossiness have any bearing on the appearance of a model in-game.

Diffuse map - Diffuse map slot Normals map - Bump map slot - select Normal map Tint map - Filter color map slot Illumination map - Self-illumination map slot.

If you plan to allow tinting, be aware that lighter base textures seem to get better results when tinting than darker ones.

Example of my workflow after the tile is modeled and textured

1. Walkmesh

1. Apply texture 2. Set proper face flags for sound when walking (i.e. stone dirt etc..) 3. In the User defined properties. Type UIFlag = None 4. Make sure "renderable" is unchecked in properties 5. The walk mesh must be the tiles (file) name appended with an �_W� : Example = TL_CV_CCCC_01_W

2. C3 mesh

1. Apply texture 2. In the User defined properties. Type UIFlag = None 3. Make sure "renderable" is unchecked in properties 4. The C3 mesh must be the tiles (file) name appended with an �_C3� : Example = TL_CV_CCCC_01_C3

3. Naming

1. Hide all hook and anchor points (they need to keep their naming) 2. Hide Walkmesh and C3        3. Select all objects in the scene and open the re name in max ....Tool > Rename Objects 4. Check and fill in the base name like so TL_CV_CCCC_01_ 5. Check an fill out the Prefix name Obj_ 6. Check Numbered (set start number to 1) and Click rename :You objects will be named like this now Obj_TL_CV_CCCC_01_01 etc (do not close the rename tool) 7. Click drag and select all objects above the fade line (objects you want to fade) 8. Uncheck all options and then check only Suffix with a _R and hit rename. This will append the _R to the objects selected Obj_TL_CV_CCCC_01_01_R

4. Flagging

1. For all bits of geometry except floors, walkmeshes and C3 - In the User defined properties. Type UIFlag = No_Cast_Shadows 2. Make sure "renderable" is checked in properties 3. For floors enter In the User defined properties. Type UIFlag = No_Cast_Shadows | Projected_Textures 4. For textures with a alpha map make sure to enter In the User defined properties. Type UIFlag = Alpha test 5. note you can have more than one flag per item seperate them with "|"

5. Reset Transforms

1. Select all geometry and "Reset X-form" 2. this may cause some geometry to flip normals or move, you will have to fix this - also note there is no undoing this function in max

6. Location

1. Tiles should be centered at coordinates 0,0,0 2. standard floor elevation is z=0 3. so move the tile so that it is centered at 0,0 if your tiles floor level isabove or below z=0 make sure it is where you want it        4. once the tile is centered and the floor level is set at z=0 (or whatever your floor level is) select all geometry including walkmesh and C3 and reset all pivots to 0,0,0

7. Export to mdb