Fade Filter Fix

[Imadori]

Fade Filter Fix

Introduction

Method A

Method B

Explanation

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:

1.) Torch Light:​

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

​

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.

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.

​

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

1.) Find the Center:​

♦ Find out the Z/height nearby coordinates X = 0, Y = 0.

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.

3.) Height [ObjectEditor]:​

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

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

^{Map Initialization} trigger, create that dummy unit. It's IMPORTANT that it's placed at Coordinates/Point(0.00, 0.00).

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

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.

 

[KILLCIDE]

So what about the fadefilterfix.w3x fixes the fade-filter issue?

Also, what is the reasoning behind having the dummy unit on 0,0 with a fly height opposite of the Z for the center of the map?

 

[Imadori]

fadefilterfix.w3x is a testmap.

Ah. Forgot about that.
Done.

 

[KILLCIDE]

My mistake. I was referring to the mdx file as well.

 

[Dr Super Good]

*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.

 

[PurgeandFire]

Cool trick! I like the idea. As KILLCIDE said, it'd be good to add an explanation as to why the Z needs to be opposite. And why at (0, 0)? Can the light source be placed anywhere on the map?

 

[Dr Super Good]

And why at (0, 0)?

I explained why. When searching for which light sources to use to render a fragment patch it assumes the model is at position 0,0 in the environment even though it is the UI.

 

[A Void]

Nice! I've always wondered why fade filters were affected by lightning. Very useful.

 

[Imadori]

Updated!
It's almost 9 months! Please approve!

 

[IcemanBo]

It's a good tutorial. In metho A, could you add a tiny note, like I want to lower it to get at Z coordinate '0'? I didn't get it on first run, but it's actually a simple explanation. ;D Maybe we could link to DSG's post, too, in 'Explanation' tab.

Approved.