• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Fade Filter Fix

Level 14
Joined
Oct 8, 2012
Messages
498
Fade Filter Fix

Introduction

Method A

Method B

Explanation

Introduction:

Have you ever used a fade-filter before?
Ever wondered why at night-time it turns blue or purple-ish?
And when you use the blank SetDayNightModels("","") trick, that fade-filter turns dark as well.
Well that's because, apparently, the model used by Blizzard is inside the map.
Worst, it is affected by terrain lighting! Day = White/Yellow-ish, Night = Blue/Purple-ish.
DSG explained why it does happen, but man I still think it's weird for an interface to do something like that.
Good thing a solution has been found!

Read Me:

Method A is the simple version. Take note that this method might produce unwanted light on your terrain. You might want to hide that lighting by blending it with another light that makes more sense. Like a campfire for example.
Method B does the same as Method A but in a cleaner way. It does not produce unnecessary lighting.

Finished Product:

preview-jpg.268063
Method A:

1.) Torch Light:

♦ Place a torch doodad, or any doodad that produces a white light, on your map at coordinates[0,0].
torch-jpg.268284

2.) Adjust the Height:

♦ Select it and press Ctrl + PageDown / PageUp to adjust it's height.
If you have a positive Z height on [0,0] like the example above (165.7), lower the torch. If it's negative (for example -165.7), elevate it instead.
torch2-jpg.268285

If positive (165.7), lower the light.
If negative (-165.7), elevate it.
The point is to position the light at 0.00 Z, or as near as possible. Read Explanation tab for more info.


♦ I say for a 165.7 Z, the torch must be buried completely.
torch3-jpg.268289

Done. Test the map and check if you made the right adjustments.​
Method B:

1.) Find the Center:

Find out the Z/height nearby coordinates X = 0, Y = 0.
coordinates-jpg.268059

Okay, this isn't exactly [0.0, 0.0] but [0.3, 2.0] is acceptable enough. Keep it close as much as possible.
So. The Z is 114.0. I'll remember that.

2.) Dummy [ObjectEditor]:

♦ Make a new unit and replace its model with filter_fix.mdx.
model-jpg.268062

3.) Height [ObjectEditor]:

♦ Change unit Height and Height Minimum to the exact opposite as the Z. Press Shift + Enter to edit as negative values.
height-jpg.268061

Map center Z is 114.0, so I'll put the negative instead which is -114.0.
Why? Because the unit's feet will naturally be placed always above the land (x=0, y=0, z=114.0). If I set it to -114.0, it will be moved down to 0.00 which is what we're aiming for. Read Explanation tab for more info.


4.) Create Dummy [Trigger Editor]:

♦ In
folder.gif
Map Initialization trigger, create that dummy unit. It's IMPORTANT that it's placed at Coordinates/Point(0.00, 0.00).
createunit-jpg.268060

Done. Test the map and check if you made the right adjustments.​
Explanation:

How does this work?:

♦ As I mentioned before, the Blizzard fade-filter model is somewhere within the map, and is affected by terrain lightings. That means if we brighten up that model by putting a white light near it, it will retain its original color and brightness (depends on how close it is to the light).

♦ That white light also blocks any lighting changes on its range, so no matter what terrain lighting your map change into, day, night, or custom, the fade filter model will never again be affected by it.

♦ And it turns out that the model is just right on the very center of every map, at exactly coordinates [X=0, Y=0, Z=0]. Found it by accident.

Thanks to @Dr Super Good for the detailed information:
Because like most games, and everything real time graphic related, the interface is rendered on 3D graphic accelerating hardware to take advantage of hardware acceleration.

The problem stems from the fixed function graphic APIs WC3 uses. It only supports 8 concurrent light sources per pixel render pass, and it only performs 1 pixel render pass per fragment. Since one can have objects emitting light, such as torches, the lights that are selected to render a specific patch of fragments are dynamically selected from physically nearby light sources. This is why if one places too many torches within close proximity some of the torches appear to not cast light on some of the fragments.

As emissive is not used, all fragments need some light to be a colour other than black. WC3 uses the day night models as the global light source used by everything (light index 0). This includes the lighting used to render overlays before blending.

The reason lights at 0,0 affect the overlays is because of the light source selector algorithm used to select which light sources to use for a bunch of fragments. If the fragment batch is produced from models in the environment then it selects by proximity. However when the fragment batch is produced from models not in the environment, eg the screen overlay to blend, then it assumes it is placed at position 0,0 and so selects nearby light sources.

There is another bug where by light sources that are visible but not specified in the environment appear at 0,0. If one selects Anubarak or other unit models that have portrait model lights then these lights appear at 0,0 of the world map while selected. Best seen when setting day night model to no model and then selecting the appropriate unit, the world will be illuminated from point 0,0 and pitch black when not selected. This even works when a day night model is present and it is night time, you will notice 0,0 get brighter. The effect is not normally visible during the day as brightness of a fragment is clamped at 1.0 and normal day night light is at least 1.4 bright (Blizzard compensating for incorrect colour management as a guess).

The light selector should have only been used for fragment patches from environmental models. Portraits should have had their own separate light pool which are not defined as environment lights so could not bleed over. Overlays should have used the same light source as the rest of the UI, which is constantly 100% bright.

Modern games do not suffer such problems with lighting as lights are implemented differently using the features of modern graphic APIs. StarCraft II supports a near unlimited number of light sources, and even emissive textures. HDR shaders mean that fixed brightness clamping no longer occurs allowing for more realistic lighting mechanics. Programmable pixel shaders mean that fragments do not require lights to be visible.
 

Attachments

  • fadefilterfix.w3x
    363.2 KB · Views: 113
  • filter_fix.mdx
    708 bytes · Views: 111
Last edited:

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,178
*Sigh* Why does terrain lighting affects fade-filter when it's supposed to be an interface anyway.
Because like most games, and everything real time graphic related, the interface is rendered on 3D graphic accelerating hardware to take advantage of hardware acceleration.

The problem stems from the fixed function graphic APIs WC3 uses. It only supports 8 concurrent light sources per pixel render pass, and it only performs 1 pixel render pass per fragment. Since one can have objects emitting light, such as torches, the lights that are selected to render a specific patch of fragments are dynamically selected from physically nearby light sources. This is why if one places too many torches within close proximity some of the torches appear to not cast light on some of the fragments.

As emissive is not used, all fragments need some light to be a colour other than black. WC3 uses the day night models as the global light source used by everything (light index 0). This includes the lighting used to render overlays before blending.

The reason lights at 0,0 affect the overlays is because of the light source selector algorithm used to select which light sources to use for a bunch of fragments. If the fragment batch is produced from models in the environment then it selects by proximity. However when the fragment batch is produced from models not in the environment, eg the screen overlay to blend, then it assumes it is placed at position 0,0 and so selects nearby light sources.

There is another bug where by light sources that are visible but not specified in the environment appear at 0,0. If one selects Anubarak or other unit models that have portrait model lights then these lights appear at 0,0 of the world map while selected. Best seen when setting day night model to no model and then selecting the appropriate unit, the world will be illuminated from point 0,0 and pitch black when not selected. This even works when a day night model is present and it is night time, you will notice 0,0 get brighter. The effect is not normally visible during the day as brightness of a fragment is clamped at 1.0 and normal day night light is at least 1.4 bright (Blizzard compensating for incorrect colour management as a guess).

The light selector should have only been used for fragment patches from environmental models. Portraits should have had their own separate light pool which are not defined as environment lights so could not bleed over. Overlays should have used the same light source as the rest of the UI, which is constantly 100% bright.

Modern games do not suffer such problems with lighting as lights are implemented differently using the features of modern graphic APIs. StarCraft II supports a near unlimited number of light sources, and even emissive textures. HDR shaders mean that fixed brightness clamping no longer occurs allowing for more realistic lighting mechanics. Programmable pixel shaders mean that fragments do not require lights to be visible.
 
Last edited:
Top