Tilesets

From NWN1 Custom Content Guide

(Redirected from TileSets)
Jump to: navigation, search

Contents

[edit] Introduction

Tilesets are what makes up the terrain in Neverwinter Nights. The game is separated up into multiple areas, with each area using a unique tileset. Common tileset themes include Rural, Forest, or Caverns.

NWN uses a tile system because it allows module designers to quickly lay out an area without having to do any 3D modeling. Just place the tile(s) you want, and it handles the rest.

[edit] Usage

When you make a new area in the Aurora Toolset, you specify the size of the area. Since each tile is a 10 meter by 10 meter block, a 6x6 area is 60m x 60m in size. The rule of thumb is to not make areas larger than 16x16, as there are certain network performances to consider.

Note There seems to be a bug or resource limitation related to using tilesets. That is, while you can have as many core and custom tilesets available, having more than 24 different tilesets in use with placeables in them causes the game to crash.
Note Patch 1.64 raised this limit from 24 to 50. Here is Bioware's comment from the v1.64 patch notes: "Increased the limit on the number of tilesets that the game can use in a module from 24 to 50. "

[edit] Why Small Areas?

You have to understand how NWN's network system works between the client and server. While the client must also have the same HakPaks as the server, the client does NOT need to have a copy of the mod. What happens is when a client connects to the server and enters an area, the server sends to the client the information about the area, listing which tile in which coordinate, its orientation, and what objects are on it (placeables, triggers, or NPCs). When the client moves to another area, again, the server sends updated information.

This is why area size recommendations suggest 16x16 or less, as a 32x32 area requires 4 times the transfer time. This is also why a lot of the default Bioware tilesets have clutter, reducing the need to add placeables to them. As the objects have to have their location sent to the clients, the server has to keep track of the objects. The less there is in the area to track, the less there is to transfer, and less to factor in for pathfinding.

[edit] Modeling

[edit] The 'A-Dummy'

The 'A-Dummy' is a simple dummy that is linked to the modelbase. t's sometimes called 'animation dummy'. It's purpose is to 'mark' NON-static objects. All objects on a tile are considered static unless they are linked to this dummy.

All objects that are either animated or have some kind of interaction with another dynamic object (like a creature standing in the water) need to be linked to it.

To create an 'A-Dummy' for your tile, place a dummy in the exact postion of your tilemodel base. Name it the same as your model, and add an 'a' .

For Example:

  • ttr01_a01_01
    • STATIC GEOMETRY/OBJECTS
    • ttr01_a01_01a
      • DYNAMIC / ANIMATED OBJECTS
    • STATIC GEOMETRY/OBJECTS

[edit] Lights

With lights on a tile you have great control over the atmosphere in an area, you can make the Castle Interior Tileset appear as either the King's halls or some forsaken lich's tomb.

There are 4 types of lights that can be used in a tile:

  • Tile Mainlights
  • Tile Sourcelights
  • Dynamic Lights
  • Static Lights

[edit] Tile Mainlights

The color of Mainlights can be edited by the user of the toolset by rightclicking on a tile and setting the color using the presented colorpicker. Selecting a new visual scheme via Area Properties -> Visual changes the appearance of all tile mainlights in that area.

You can have up to two mainlight nodes in a single tilemodel.

To create a tilelight, place a light on your model, link it to the modelbase and name it the same as your modelbase + ml1 or ml2. So if your model is ttr01_a01_01 your two mainlights have to be named ttr01_a01_01ml1 and ttr01_a01_01ml2.

The color set on this light will be ignored by the toolset, but not the radius of your light.

[edit] Tile Sourcelights

Image:Tile lights l.jpg Sourcelights are very similar to mainlights in use; just as these they can be edited on a per-tile basis by rightclicking on the tile and are also affected by visual settings in the area properties. The main difference is, that they aren't 'light from somewhere' but are actually visible flames. They are used on many tiles in the interior tilesets. The appearance of these flames are hardcoded and cannot be changed, safe for the color of the flame.

You can have up to two sourcelight nodes in a single tilemodel.

To create a sourcelight, place a light or simple helper on your model, link it to the modelbase and name it the same as your modelbase + 'sl1' or 'sl2'. So if your model is 'ttr01_a01_01' your two sourcelight have to be named 'ttr01_a01_01sl1' and 'ttr01_a01_01sl2'. The color set on this light will be ignored by the game, as you set the color in the toolset.

[edit] Dynamic Lights

Dynamic lights aren't specific to tilemodels, I only note them here for a complete list.

Dynamic lights cannot be changed by the user but are triggered via the tile's animations. You can animate almost any parameter of a lightnode (not with MDL-Suite, though) to get various interesting effects. There is no naming scheme for this, as it can not be controlled by the toolset. But, like any animated object you got to make the lightnode a child of the 'a-dummy', else it's animation won't fire.

[edit] Static Lights

Static lights are simply unanimated lights, linked to any part of your model. They can be used to get a certain coloring on an object.

[edit] Sparklies

Image:Sparklie big.jpg Sparklies are best defined as gaps between meshes that allows the viewer to see through the ground and to the 'fog' that surrounds the area. This is most common along ground terrain as often you'd have the edges of a tile not QUITE matching up to the next one, so you'll have the gaps.

Click the image to see a zoomed up picture - you can see the line of blue dots between the gaps of the steps and the sidewalk.

[edit] Methods to remove sparklies

  1. Enable 'Snap to Vertex', so the verticies of the two meshes will line up with each other.
  2. In NWMax, there is a command in the Utilities side panel for "Desparkle" model, it snaps the verticies to the nearest centimeter, so it can often do the bulk of the desparkling for you.
  3. Have the lowest object on the ground overlap a bit from the other geometry
  4. Make sure tile edges have matching vertex counts.
  5. Another option is to use the Clean Models program, found here: CleanModels On Vault After you have finished whatever edits you have for a particular tile and/or the full tile-set.

See this image for a good / bad tile edge example...

Image:Tile sparklies sch.jpg As you can see, in the above image all vertices on both tiles meet

perfectly. Given all other tiles in that tileset (or at least all the ones that will be placed next to these), have the same edge layout, you won't experience sparklies.


In the lower image the tile on the right has been 'optimized' . While it is good to keep the polycount low, in this case it will cause sparklies on the edges. Definately where these two tiles meet ( see the red dots), and propably where other tiles (that are set up like the unmodified tile to the left) meet the 'optimized' tile .

  • Note: Sparkles can also be reduced by using Binary snap instead of decimal snap, to help alleviate the rounding errors in NWMax/Gmax/3dsMax.

[edit] Beware of Smoothing

"*When you import an item into <G>Max the import tools stick everything into the same smoothing group. If you look at many modified tiles released to the public in the toolset you'll see rounded looking corners that should be 90 degrees. This is because they were saved as a single smoothing group so the client tries to smoothly shade across every face.

This is caused by the binary-to-ascii conversion which has been back-engineered long time ago. As we only have that single tool, we might have to live with that.

To get smoothing you need to select faces and set smoothing groups. The engine does support smoothing and that's how you set it or unset it as the case may be depending on what your needs are."

  • Quotes taken from Danmar on Bioware forums.

[edit] Walkmeshes

Walkmeshes are a secondary mesh of the tile that defines where the creature can and cannot walk, what he can and cannot see vis line of sight, and what sort of sounds and effects to display as he moves (footsteps, dust clouds).

  • Always make the walkmesh fit into the 10m by 10m boundry, if it overlaps beyond it, it may crash the game.
  • While it's X and Y are limited, it's height can be as high as you want (see CODI's tower, or DLA's Solace tileset).
  • However, don't drop the level of the walkmesh more than -1 m, else it will crash.
  • Don't overlap any of the walkmesh. NWN acts as a '2D' game in that sense.
  • Try to keep the density of the walkmesh faces low, the game will handle pathfinding much easier.
  • Give some padding when blocking off multiple levels, else objects on the bottom will affect objects on the top, as NWN calculates X,Y distance, but not Z.

[edit] Animations

Name Start Time End Time
Day 7:00am 5:00pm
Day2Night 5:00pm 7:00pm
Night 7:00pm 5:00am
Night2Day 5:00am 7:00am
animloop1
animloop2
animloop3
default
tiledefault
--- ---
Each tile can have 8 types of animations associated with it. One sets the default settings for animated objects (tiledefault). Four 4 are related to day/night cycles, and the other three 3 are generic sequences which you can activate one of them at a time (so you can have the same tile look different three different ways). Remember that the animation default is also valid for a tile.

All animated objects on a tilemodel have to be linked to the 'a-dummy', else they are considered static objects.

Note: Day2Night and Night2Day always run for 2 hours when triggered, regardless of what length they are set in the model file. So if you made an item to help you change the time of day for testing, watch out for this.

[edit] Tile Groups

[edit] Tile Slicer

[edit] SET File

The .SET file is is the main file that controls the information for the tileset. It holds information and rules for how the tiles are laid out, where they can be laid out, groups, and even the length and colour of the grass.

Click here to see more information on the .SET file.

[edit] Tileset Combos

[edit] Addons

[edit] Palette Editing

The associated .ITP file for the tileset (should have the same name as the .SET file) holds the information that is displayed on the right panel of the Aurora Toolset. Which elements appear under which headings, the name and the tile or tilegroup associated with it.

Click Palette Editing to see more information on the .ITP file.

[edit] Other Files

File Used for
edge.2da Which tile displays and repeats outside the area
doortypes.2da Unique doors in the tileset
genericdoors.2da Generic doors in the tileset
loadscreens.2da The screens that appear when the area is loading
areag.ini file that tells the toolset how to draw a newly created area.

[edit] Random IRC Quotes

<ThriKreen> Soopaman, use edit mesh and edit the material ID of the faces
<ThriKreen> bring up the nwnwalkmesh material as a reference, so you'd like set the face to 1 for dirt, 4 for stone, 7 for no walk, 2 for obscuring
<ThriKreen> and I can't believe I just memorized the ID's
<GL> haha. You geek!


<Steel_Wind> you can't rush art
<Thallion> wait wait did he just say you cant rush art
<Thallion> SWEET i got tons of time for tilesets then


<Terrel-fen> no prob, Rome wasnt built in a day....
<ThriKreen> but I'm trying to get this Colosseum done in a week =)


<Dave> tilesets are never complete? Merely abandoned?


Main_Page | TileSets

Personal tools