Directional contrast (models and optionally the world)

[Nash]

https://github.com/coelckers/gzdoom/pull/1133

Continue dpJudas' work on directional contrast. For best results, EvenLighting is advised.

- New MAPINFO option: DirectionalContrastMode. 0 = default (no added contrast), 1 = affect models only, 2 = affect models and world textures (walls and flats).

- New MAPINFO option: DirectionalContrast = <X>, <Y>, <Z>, <Strength>. Sets the directional contrast vector, and strength. All defaults to 0.

- New ZScript functions: Level.SetDirectionalContrast(double x, double y, double z, double w), Level.GetDirectionalContrastVec() and Level.GetDirectionalContrastStr().

- New MODELDEF option: NoDirectionalContrast for disabling contrast effect on specific models.

The purpose of this feature is to improve lighting contrast on models, and optionally the world. Without this, models have flat lighting, and normal/specular maps are only visible when they are touching dynamic lights, which often forces map authors to spam their level with dynamic lights. This addresses that problem.

Example file coming later, I need time to make it.

[Graf Zahl]

Like the other one - please provide a small demo so it can be reviewed.

[Nash]

Sorry I got a little busy with other work and didn't have time to prepare the demo file - will prepare it within the next few days (same goes for the other PR too).

[Nash]

Download demo file: https://www.dropbox.com/s/pn8r4b5qizdr0 ... o.pk3?dl=1

(too big to attach to forum)

You can select which map to start on to see the various directional contrast modes in action.

The fire button fires a fireball with a dynamic light (for material interaction purposes).

Disabled - as if the feature doesn't exist
Models only - the statues and your hand have directional contrast
Models + world - like above, but additionally the whole world gets affected too - including the wall and floor contrast direction (looks better than ZDoom's fake contrast IMO), and materials on all level textures also appear without needing a dynamic light source

[HAL9000]

Hi Nash. How can I test this,what GZDoom build is compatible with Directional contrast?

[Major Cooke]

You'll have to compile your own build if you want to test it.

[Deybar_TECH]

Oh God.


As I understand, this will solve the
need to use 8 small points of light
to simulate a sun lamp for my 3D
models.
which is greatly reducing performance.

I don't know anything about how to compile.
So I can only wait until all this is
included in the next version of
GZDoom to try it.

[drfrag]

What about merging this into QZDoom?

[Talon1024]

The models seem to be lit in one direction only, regardless of which direction they are facing. For example, if you walk around the "models+world" map in Nash's example PK3, and run "summon DemonStatue 0" in the console a few times, you'll notice that the model is always lit from the front, and never from the back.

[dpJudas]

Hmm, I can't spot any errors in the shader code in the PR itself. The directional contrast light vector is in world coordinates, pixelpos.xyz is in world coordinates, so the object normal vector should also be expected to be in world coordinates. Could there be a more general bug right now where the normal vector is not rotated for models?

[Nash]

The models seem to be lit in one direction only, regardless of which direction they are facing. For example, if you walk around the "models+world" map in Nash's example PK3, and run "summon DemonStatue 0" in the console a few times, you'll notice that the model is always lit from the front, and never from the back.

Could be bugged normals on the model. I'll try to re-export it later.

(it may be possible that it's a mistake on my part, it's happened before LOL)

In the mean time, you can debug normals in-game by typing gl_ssao_debug 4

[Talon1024]

BTW, it seems like scaling models up by a large factor in the MODELDEF file (for example, 10 on each axis) causes normals to break.

[Major Cooke]

I take back what I said. QZDoom will need a reset first I think. Since the last build is so old and there's been so many directory changes, merging it is going to be a complete clusterfuck, especially as it attempted to merge the squared PR.

[Nash]

BTW, it seems like scaling models up by a large factor in the MODELDEF file (for example, 10 on each axis) causes normals to break.

So is this an exporter problem? GZDoom problem? Something else? This warrants its own topic. :)

[dpJudas]

I did some testing with this model and I'm now 100% sure it has broken normals. If I programmatically forces it to recalculate the normals when loading the MD3 the light reflects correctly from the right direction.