The Harvest Moon Consortium

[Chandigar]

After many hours of debugging, I discovered something kind of interesting that I had no idea about before.

Heres the situation:

After tweaking and exporting a tileset, I went into the toolset and discovered that suddenly all of the individual primary and secondary tile lights no longer worked. Every single tile was brightly, evenly and fully lit. Even if I switched the area settings to torchlight only etc. I couldn't figure out what was causing this, because the individual lights and such for the tiles I tested appeared to be exactly the same, and none of the meshes were given self-illumination or anything.

Method:

I started by exporting individual tiles and series of tiles and replacing things, reverting back to the original old working hak whenever the bug manifested. Slowly narrowing it down to the series of tiles that were broken.

Observations:

- In the original hak, with an interior lighting scheme set, tiles showed appropriate random light 'blobs' when viewed in the toolset.
- In the original hak, one particular tile, a corner tile with stairs, was fully lit.
- Even though all other tiles on the test mod appeared to be lit correctly, 2 walls were generally slightly but visibly more brightly lit than the 2 other walls.
- Upon closer examination, these brighter walls were those that were facing the one fully lit tile, even though that tile was 6-7 rows/columns away and multiple enclosed rooms away.

Conculsions:

- Tiles with no tile lights set (primary and/or secondary) are automatically lit with a super bright light with infinite range.
- Even a single tile on a mod will affect the lighting of the rest of the tiles on the same map.

Solution:

- I discovered that my default "wall" tile had its light misnamed and therefore disabled, which meant that I had super bright lights illuminating every other tile from every angle, creating the effect mentioned above.

Hope this helps someone and/or saves them a few hours of hair pulling sleuthing!

[Bannor Bloodfist]

Absolute GREAT information. Especially for anyone attempting to merge some tile sets together... different tilesets often have different lighting parameters.

Thanks Chandigar.

[mobyksu]

i don't have my notes with me, but i know i've seen this problem crop up in one of the sets we've already tested... dungeon maybe? one particular tile that got listed with a lighting bug (by myself or others) has much brighter walls than its counterparts, but shows up correctly in other areas in the toolset. i bet this is the culprit. we'll have to make sure the rest of the fixing team gets a heads up on this. too bad finding the one wrong tile is going to be such a pain... even six or seven rows away! :_wall:

[Christopher]

Someone reported this about the set on the vault...

The main problem I had with this tileset originally (apart from some players reporting CTDs, which is now probably fixed) was that lack of individual tile lighting. This does now appear to be working in-game but for some reason it's still not displayed correctly in the toolset (refuses to display more than one tile colour).

I have found that some (not sure how big this gets) tiles do not have main lights? Not sure the reason of this? Are all tiles supposed to have main lights? Is their any reason why these would be excluded?

Balkur jumped in on this issue (vault comments);

Your lighting problem is that in every tile i've checked, all the node lights tcr_*_ml1 and tcr_*_ml2 contain the line isdynamic 1. This setting should be isdynamic 0. Having this set to 1 causes all sorts of strange effects besides lighting not showing up in the toolset. In-game the area feels like the game engine is haunted, where tile lighting may (or may not) turn on and off as you move around... almost at random.

Now this could be a dif. between early Aurora/Mdl Suite export scripts but I cannot find this "isdynamic 1". I use NWmax 8.53 and I can find nDynamic which maybe NWmax's version of this field. I intend to do more research but... anyone have some answers?

[Christopher]

This is from the Aurora Export scripts but much of the info applies to NWmax.

Lighting

Lighting is relatively simple in our engine; it uses a simple vertex lighting system where lights can have one of the following properties:

1. Static -- Some geometry is loaded in statically, and thus can be treated this way in the lighting system (for performance benefits). Static lights will only affect static geometry, which are really only the background tiles. Static lights are pretty much only used on the tiles themselves, for small amounts of shading. For this setting, leave both checks of "Is Dynamic" and "Affects Dynamic" un-clicked.
2. Dynamic -- Dynamic lights affect both types of geometry in the same way. We use these lights only for animating lights like torches and spell effects. As they are calculation intensive, dynamic lights should be used sparingly if possible. For this setting, click both checks of "Is Dynamic" and "Affects Dynamic".
3. Hybrid -- This flag counts a light as both static and dynamic. As long as the light does not move, it can light static geometry statically and dynamic geometry dynamically. We use the lights for the sun model, and all the predominant tile related lights we can. It's the best of both worlds, giving you control over both types without the performance hit that a pure dynamic light gives. To have this setting, just click "Affects Dynamic Objects".

Other functions in Aurora Light:

1. Lens Flares -- Most of these settings are self-explanatory, but the flare radius is in cm and the "Position" is a value from -1 to +1 of where the flare will occur (see description below spinner). We didn't use this function as much as I would have liked? the main reason for this is because lens flares will only get occluded by walkmesh geometry. Walkmesh will be described in another document, as it is fairly specific to creating tiles.
2. Fading Light -- When a light (connected to a model) is loaded or dropped from a scene, the light can effectively 'flick' on and off. If this check is on, the light will take a moment to fade on or off for a better overall feel. In some cases it's best to have this un-checked, for things like spells where you want the light to be at it's brightest as soon as it appears.
3. Multiplier -- It's tough to explain this one? first of all, a multiplier can make a negative light in our engine, which is quiet useful for darkening corners and general shading (some spells too!). We also use this to enlarge the inside radius of a light as the lighting system clamps at 1, and if a light has a multiplier that goes above this, then it will simply push the inside radius out further (but will keep the outside radius to the correct setting.
4. Priority -- Aurora has a light manager to prevent the engine from counting too many lights that affect dynamic objects. This relates to the light count setting in the game. In order for the manager to know which lights it can cull from the list first, we assign a priority number to it, from 1-5, 1 being the highest priority. This is the general scheme we used:
   1. The sun/moon
   2. Torches/ light spells
   3. Spells, general lights (which is why a new light will have this number as default)
   4. Un-needed tile lights
   5. Magic weapon lights. (for example)

[Christopher]

Of course the above was old documentation... but Joco pointed me to better material on the DLA Wikk. Which also sheds more light on Chandigar's issue pointed out earlier in the thread.

Aurora Dlight (helper object)

The Aurora DLight is representing a light node. NWN lights are very simple, so it only has a few parameters.

• The name of the light can be important if you're creating tiles, as you have to follow certain naming conventions then. If you're not following these naming conventions, the lights will be exported and work, but they won't be accessable in the toolset. To get the correct naming for tilelights, name them the same as the modelbase (eg ttr01_a01_01) and add the following...
  • ml1 - Mainlight 1 - (eg ttr01_a01_01ml1)
  • ml2 - Mainlight 2 - (eg ttr01_a01_01ml2)
  • sl1 - Sourcelight 1 - (eg ttr01_a01_01sl1) - this doesn't HAVE to be a light, but can be a simple helper instead
  • sl2 - Sourcelight 2 - (eg ttr01_a01_01sl2) - this doesn't HAVE to be a light, but can be a simple helper instead

Light Parameters

• The radius of the light is the effective radius (in cm) of the light.
• The multiplier can be used to enlarge the inner radius of the light, as well as create negative lighting.
• Priority The NWN engine has a light manager to prevent the engine from counting too many lights that affect dynamic objects. This relates to the light count setting in the game. The priority order is like this...
  • 1 - Highest - Sun/Moon
  • 2 - High... - Torches / Light spells
  • 3 - Medium. - Spells, general lights
  • 4 - Low.... - High-Priority Tile Lights
  • 5 - Lowest. - Magic Weapon Lights, Tile Lights
• Fading Light - Enable this to make lights turn on smoothly, instead of instantly turning to full brightness. As lights only get processed when they are on-screen, this helps with the general feel of tilesets for example - you don't want to have flickering ambient lights there.
• Color - you can set the color of the light here. Either use the color box and choose a color or enter RGB values in the fields. Note that the color is ignored on tile mainlights and sourcelights as this parameter gets controlled by the setting in the toolset.
• Negative Light - make this a negative light, make sure to up the multiplier value for best effect.
• Ambient - turn this on to create an ambient light, when off the light will affect diffuse colors.
• Is Dynamic Light , Affect Dynamic Objects - lights can have one of three dynamic states in NWN. Based on the setting the light will be more or less performance hungry. These two checkboxes control this.
  • Static - off/off - This setting will only affect static meshes, which basically is only TileGeometry. You can use this to shade certain areas on tiles for example.
  • Dynamic - on/on - This will affect all geom, dynamic and static, and should be turned on for animated lights. This is the most hungry setting - use sparingly.
  • Hybrid - off/on - The engine will determine if the light should be considered Static or Dynamic based on the situation. Sounds like the other two are useless, but the engine isn't always sure about your lighting motives
• Shadow - if the light should make objects cast a shadow based on this light.

• Tilelight Presets is a quick way to set the the standard settings for tile mainlights. When you select either Mainlight 1 or Mainlight 2 the light will be renamed, based on it's parent to fulfill the naming convention for tile mainlights (MODELNAMEml1 for example) and standard settings will be applied. The settings are based on Bioware suggestions in the Tile Creation Tutorial. The only difference between ml1 and ml2 is the name and the lightradius.

Lens Flares

Troubleshooting

Here are a few problems I've run into while bugtesting a tileset:

• Problem: If I set the tileset to torchlit only, I get individual tiles that are brightly lit. The light from these tiles spill over onto adjacent tiles or is contained within the tile but the transition from bright to dark is soft.
• Problem: If I set the tileset to torchlit only, some walls are dimly lit but others are dark.
  • Possible Solution: Check your light naming. I've found that if your naming is incorrect (ie you forget to add ml1, ml2) the toolset interprets the light as being on full brightness, all the time, and much larger than normal. These lights may have a wide enough range to affect lighting on every other tile in the same map.

• Problem: If I set the tileset to torchlit only, I get individual tiles that are brightly lit. The light from these tiles DO NOT spill over onto adjacent tiles and the transition from light to dark surfaces is very distinct.
• Problem: If I set the tileset to torchlit only, I get individual objects/meshes/faces that are brightly lit.
  • Possible Solution: This is most likely a texturing problem. If you extract the texture from that mesh in max, you may notice that although there is a map applied to the texture, the base ambient and diffuse colors are set to something other than grey. These colors aren't visible on the tile itself but they appear to control the self illumination level of the mesh. ex: a white background color will cause the mesh to be fully self-illuminated. The default should have an RGB value of 150/150/150. Try resetting the base back to grey and re-exporting the model.

• Problem: No matter what I put the tileset lighting settings at, all of the tiles are brightly lit.
  • Possible Solution: This is a more widespread version of the two problems above. Either there are many misnamed lights in the tileset that together serve to wash everything out or every texture was created with a white base color or both. In one case, I had broken lights in the default "wall" tile of an interiors tileset which washed everything out. In another case I had a tileset where all the base colors were white. If all the base colors are wrong, but wrong in the same way (ie all white) it may be easier to use a text file find & replace tool to just change the setting in all the models at once.

Back to NWmax_Documentation

[Chandigar]

Yea, actually that troubleshooting section was the section I added to the wiki heheh.. so... it could still be wrong!