Help with omnilight in dungeon tileset

[DaveDave91]

I`m making a map in DUNGEON and I noticed that my lights does not apply to ground tiles. Is not a light problem but a tileset one because I changed it to every other tileset and the lights work except in Dungeon and Underground... I know, it`s supposed to be under the ground and light doesnt reach? lol

Is there a way to change this so my light works without changing tileset?

 

[Retera]

I am not aware of an in-game setting that prevents light from reaching the ground in Dungeon tileset.

The game light system chunks terrain into grid squares of 4x4 terrain cells where each cell is size 128x128 (so basically a giant area that is 512x512 units in World Editor -- these are the ones outlined in yellow when grid is on) and then each grid square can have at most 8 lights showing, and beyond that it does not display additional lights.

So, if you have lights that reach a lot of the stuff on the map and use the 8 slots, this can cause the lights to disappear. The way that was calculated has always seemed a bit buggy to me, and I would not be surprised if it might have some bugs where a light uses up a slot on terrain squares nearby or perhaps globally that it did not need to use up, so in a map with a large number of lights you might eventually stop seeing them even when there were not 8 in one place, for some reason -- not sure. I posted a Hive thread about the problem 16 years ago but nobody seemed to solve it over the last 16 years.

What you probably want to do is to make your Dungeon or Underground map use a different light environment. So, basically, if we assume that your problem isn't a matter of hitting the 8 lights limit, but actually an issue of "fully saturating the ground with light" at all hours of the in-game clock (even at night), then your problem is actually quite simple. You want a different light environment for your Warcraft III map. There are two ways to achieve this:
- Way 1: Import different light environment files in place of the original ones for Dungeon/Underground
- For example, if you look up Environment\DNC\DNCAshenvale\DNCAshenvaleUnit\DNCAshenvaleUnit.mdx and Environment\DNC\DNCAshenvale\DNCAshenvaleTerrain\DNCAshenvaleTerrain.mdx and import them back into your map as custom model imports over top of the Environment\DNC\DNCDungeon\DNCDungeonUnit\DNCDungeonUnit.mdx and Environment\DNC\DNCDungeon\DNCDungeonTerrain\DNCDungeonTerrain.mdx files, then when you pick Dungeon tileset it will have Ashenvale light environment. You can do the same for Underground
- Way 2: the World Editor will generate your map script to contain the line call SetDayNightModels("Environment\\DNC\\DNCDungeon\\DNCDungeonTerrain\\DNCDungeonTerrain.mdl","Environment\\DNC\\DNCDungeon\\DNCDungeonUnit\\DNCDungeonUnit.mdl") so if your map script is getting generated or modified by some external program you can change that function call, but if it's not and you're just doing a standard World Editor map then you can literally go into the trigger editor and call the same function with some other inputs. So for example, maybe you could put in some trigger that runs on standard initialization, a simple call to call SetDayNightModels("war3mapImported\\myTerrainFile.mdl", "war3mapImported\\myUnitFile.mdl") which will load the light environment you want when the map starts.

Note that in either of the above two ways, you're not likely to see the preview in World Editor. If you want to see the preview in World Editor, the easiest way to do this is to mod your game client itself and add the modified file in place of the default one(s).

If you want a custom light environment rather than simply replacing one of the existing ones with a different existing one, the format of these light environment files is to have literally just a standard Warcraft 3 MDX Model that opens in whatever 3D model editor you like, except for the fact that the model contains one single Light Emitter that is the "sun light" with an animation that has a set timeline that needs to stay what it is to match the Day/Night cycle. Notably, if you look at the file for Ashenvale or Lordaeron, this model has a "Light Emitter" that changes color over time and goes to blue at night, but full white color during the day. Hence why you can see your "light emitters" of World Editor during the night only -- during the day, the ground is fully saturated with light and so additional light doesn't change its color.

In a similar way, the Dungeon and Underground tilesets have a light that does not change to blue at night. So, as a result, they will "fully saturate" most of the ground with light regardless of the time of day.

By understanding this, and customizing the light emitter files, you could have a reversed light environment where the world turns red during the day but shows full color at night, so that light emitters reveal themselves and work only during the day, or all manner of other crazy and custom creations.

 

[DaveDave91]

I am not aware of an in-game setting that prevents light from reaching the ground in Dungeon tileset.

The game light system chunks terrain into grid squares of 4x4 terrain cells where each cell is size 128x128 (so basically a giant area that is 512x512 units in World Editor -- these are the ones outlined in yellow when grid is on) and then each grid square can have at most 8 lights showing, and beyond that it does not display additional lights.

So, if you have lights that reach a lot of the stuff on the map and use the 8 slots, this can cause the lights to disappear. The way that was calculated has always seemed a bit buggy to me, and I would not be surprised if it might have some bugs where a light uses up a slot on terrain squares nearby or perhaps globally that it did not need to use up, so in a map with a large number of lights you might eventually stop seeing them even when there were not 8 in one place, for some reason -- not sure. I posted a Hive thread about the problem 16 years ago but nobody seemed to solve it over the last 16 years.

What you probably want to do is to make your Dungeon or Underground map use a different light environment. So, basically, if we assume that your problem isn't a matter of hitting the 8 lights limit, but actually an issue of "fully saturating the ground with light" at all hours of the in-game clock (even at night), then your problem is actually quite simple. You want a different light environment for your Warcraft III map. There are two ways to achieve this:
- Way 1: Import different light environment files in place of the original ones for Dungeon/Underground
- For example, if you look up Environment\DNC\DNCAshenvale\DNCAshenvaleUnit\DNCAshenvaleUnit.mdx and Environment\DNC\DNCAshenvale\DNCAshenvaleTerrain\DNCAshenvaleTerrain.mdx and import them back into your map as custom model imports over top of the Environment\DNC\DNCDungeon\DNCDungeonUnit\DNCDungeonUnit.mdx and Environment\DNC\DNCDungeon\DNCDungeonTerrain\DNCDungeonTerrain.mdx files, then when you pick Dungeon tileset it will have Ashenvale light environment. You can do the same for Underground
- Way 2: the World Editor will generate your map script to contain the line call SetDayNightModels("Environment\\DNC\\DNCDungeon\\DNCDungeonTerrain\\DNCDungeonTerrain.mdl","Environment\\DNC\\DNCDungeon\\DNCDungeonUnit\\DNCDungeonUnit.mdl") so if your map script is getting generated or modified by some external program you can change that function call, but if it's not and you're just doing a standard World Editor map then you can literally go into the trigger editor and call the same function with some other inputs. So for example, maybe you could put in some trigger that runs on standard initialization, a simple call to call SetDayNightModels("war3mapImported\\myTerrainFile.mdl", "war3mapImported\\myUnitFile.mdl") which will load the light environment you want when the map starts.

Note that in either of the above two ways, you're not likely to see the preview in World Editor. If you want to see the preview in World Editor, the easiest way to do this is to mod your game client itself and add the modified file in place of the default one(s).

If you want a custom light environment rather than simply replacing one of the existing ones with a different existing one, the format of these light environment files is to have literally just a standard Warcraft 3 MDX Model that opens in whatever 3D model editor you like, except for the fact that the model contains one single Light Emitter that is the "sun light" with an animation that has a set timeline that needs to stay what it is to match the Day/Night cycle. Notably, if you look at the file for Ashenvale or Lordaeron, this model has a "Light Emitter" that changes color over time and goes to blue at night, but full white color during the day. Hence why you can see your "light emitters" of World Editor during the night only -- during the day, the ground is fully saturated with light and so additional light doesn't change its color.

In a similar way, the Dungeon and Underground tilesets have a light that does not change to blue at night. So, as a result, they will "fully saturate" most of the ground with light regardless of the time of day.

By understanding this, and customizing the light emitter files, you could have a reversed light environment where the world turns red during the day but shows full color at night, so that light emitters reveal themselves and work only during the day, or all manner of other crazy and custom creations.

I followed some of your steps and only the VILLAGE light environment works, at this point I can`t make sense of it. So, now my lights works on the ground tiles BUT is too weak compared with the lights on doodads and units, I tried increasing the intensity of some lights in magos but it does not make a difference in ground tiles, it is still too weak. I will add that my lights are nothing weird, just standard omnidirectional with standard values.

This is an example, the light is strong in the rocks and bridge (doodad) but weak af in the ground

 

[Retera]

Is that a bunch of custom tiles or is that Reforged graphics?

If you're doing Reforged, be sure to extract the environment lights from war3.w3mod:_hd.w3mod:environment/dnc/dncvillage/dncvillageunit/dncvillageunit.mdx (and equivalent folder for terrain) for example instead of from the base war3.w3mod directory. I'm also not entirely certain that Reforged works in the same way, although I would assume that it probably does. I recall someone researching that the only light in the game system that is permitted to cast shadows is the light from the unit environment light on Reforged, so it might have special handling.

Edit: I guess Magos wouldn't easily work with files from Reforged, though, so without more pictures I'm unclear about the nature of your work environment.

 

[DaveDave91]

Is that a bunch of custom tiles or is that Reforged graphics?

If you're doing Reforged, be sure to extract the environment lights from war3.w3mod:_hd.w3mod:environment/dnc/dncvillage/dncvillageunit/dncvillageunit.mdx (and equivalent folder for terrain) for example instead of from the base war3.w3mod directory. I'm also not entirely certain that Reforged works in the same way, although I would assume that it probably does. I recall someone researching that the only light in the game system that is permitted to cast shadows is the light from the unit environment light on Reforged, so it might have special handling.

Edit: I guess Magos wouldn't easily work with files from Reforged, though, so without more pictures I'm unclear about the nature of your work environment.

Is classic 1.27, the tileset is reforged textures. I`m working on this:

Made in Classic - WIP - Need feedback pls!

This was made for classic with some reforged assets. It started as a cinematic (wich is exactly what i have right now) but I think this need to be a playable map. I need some ideas with the story and some feedback on the intro cinematic, pls help me make it better!

www.hiveworkshop.com

 

[Retera]

Okay cool. Yeah, then I would definitely think that the custom light imports should work then. If you're having trouble importing a different value for the unit light, double check the file path to ensure that it does not have a typo -- or if you're using JASS script, ensure that the correct file path was provided to the function call.

 

[Dr Super Good]

Lighting is often broken in World Editor for Reforged graphics.

Classic graphics does not use a HDR pipeline. This means that a lightness value of 1.0 maxes out the brightness. So a light with 400 brightness will at most result in 1.0 brightness no matter how near or far the objects are. To make matters worse it does not use colour space correction so incorrectly applies the linear based lighting model math in the non-linear sRGB colour space which is why Warcraft III classic graphics had a certain art style to it.

I recall Warcraft III using 2 separate lighting sources, one for terrain and another for units/destructables. Maybe the issue is that these two lights are not consistent?

If mixing classic objects with Reforged terrain, be aware that the classic objects lack texture information that the Reforged graphics engine uses. A Reforged texture has up to 4 different texture layers representing different types of information such as emission, normal/height, the kind of material and the diffuse. A classic texture is diffuse only with classic models providing per-vertex normals, using default information for the other layers. As such lighting might look discontinuous between a Reforged and Classic model or texture, even if they are meant to be similar diffuse colours.

 

[DaveDave91]

I recall Warcraft III using 2 separate lighting sources, one for terrain and another for units/destructables. Maybe the issue is that these two lights are not consistent?

That`s right, no matter how I modify the lights, terrain and doodads/units look different. Terrain light is weak and poor color while doodads are bright and colorfull, I guess is just a limitation of the game engine and I will not be able to fix it modifying the lights and I will have to do it the hard and tedious way wich is scanning my terrain, convert it to mdx and place it as a doodad.

By the way, I don`t have Reforged, just assets and textures converted for classic 1.27.

Thank you guys for the replays!

 

[Retera]

I guess is just a limitation of the game engine

I am quite skeptical of this. In the past, I have created a custom game mode where:

• Terrain and Unit lights were set to solid black, no light, so that all lighting in the game came from light emitters
• Terrain and Unit lights were set to solid 100% ambient light, so that no lighting in the game came from light emitters

Accordingly, depending on the Terrain and Unit lights that you use in your configuration, the two might be lighted differently or they might be lighted the same. But which one of those is the case is dependent on your configuration, and if it is wrong then that is wrong in your configuration (map/game mode), not in the game engine itself.

 

[DaveDave91]

I finally FOUND THE PROBLEM!

The issue was doodads colored inside world editor, I`m doing a volcanic landscape and I colored all of my doodads 50/50/50 RGB, almost black and as result they "absorb"(?) more light than the terrain, they look brighter and more colored by the light source. I converted all the textures and I colored them inside Photoshop and that fixed the problem, the textures look exactly like before and now the light is consistent with terrain and doodad.

Now my map lacks that light intensity that I was trying to achieve with the terrain

Classic graphics does not use a HDR pipeline. This means that a lightness value of 1.0 maxes out the brightness. So a light with 400 brightness will at most result in 1.0 brightness no matter how near or far the objects are. To make matters worse it does not use colour space correction so incorrectly applies the linear based lighting model math in the non-linear sRGB colour space which is why Warcraft III classic graphics had a certain art style to it.

If this is correct there is no way to make lights stronger, I tried with 999999 intensity and it`s the same, however I`m happy with this, I`ll keep trying.

• Terrain and Unit lights were set to solid black, no light, so that all lighting in the game came from light emitters

I tried that to increase the light brightness with Custom script: call SetDayNightModels("","") and saddly it made no difference.

 

[Dr Super Good]

just assets and textures converted for classic 1.27.

Are you saying that you are using reforged assets ported to classic graphics? If so then the baking of those assets is likely a contributing issue here.

If this is correct there is no way to make lights stronger, I tried with 999999 intensity and it`s the same, however I`m happy with this, I`ll keep trying.

Yes this is a limitation with older games. The fixed function pipelines of late 1990s to early 2000 only supported lighting multipliers in the range of 0 to 1.0. It was not until around mid 2000s that HDR graphic pipelines became a standard and lights of any intensity were supported. For example, StarCraft II does not have this issue as it uses a HDR render pipeline, a very bright light in StarCraft II can saturate the screen pure white.

Warcraft III also has a limit of 8 lights per mesh rendered, again from limitations with the fixed function hardware of the period. This includes the environment light and is why lights break if you put too many high sources nearby. The work around for the time would be multiple render passes, each with different light sources selected, and then blending the results, but this was likely considered too resource intensive for the Warcraft III developers back in the early 2000s and so instead they hand-built their maps with the 8 light source limit in mind.

Selecting a unit with a character portrait with a built in light, such as Anubarak/Crypt Lord portrait model, contributes that light to the 0,0 origin of the map. As such in practice you might only have 6 lights per mesh to reliably deal with, and the light culling algorithm might cull significant contributors in preference over minor ones as it was not the most precise. Modern game engines like StarCraft II ("modern" lol) do not suffer from this limitation since they use a different way to simulate and render lighting, with StarCraft II even supporting lights casting dynamic shadows such as from gun nuzzle flashes.

 

[DaveDave91]

Are you saying that you are using reforged assets ported to classic graphics? If so then the baking of those assets is likely a contributing issue here.

I already considered that, but the WC3 classic models react the same to the lights. Anyway, I inspected the models and recalculated normals in 3dsmax and exported back to mdx just in case and nothing changed, just more detailed normals.

Yes this is a limitation with older games.

I'll keep trying to find a way to do it.