[Patch] Spotlight and Fog

[HarryTuttle]

*Long Post ahead*.
This patch is for r566. I've reworked many things, some of which are still subject to revision as a result of guess-work and visual comparison.

Regarding the spotlight/lobelight properties:

- Spot position is expressed in screen pixel coordinates (as signed 13.3 fixed point, rounded float). This was hard to fix 'cause the only visual difference I noticed with the real thing was in this particular sequence (ECA):

eca01.png (77.9 KiB) Viewed 8969 times

- Spot ellipse dimensions (again in pixels) are a fraction of a fictional 2047x2047 mega screen, so are expressed as (part of) 16 bit values. This is hinted in the "Real3DPro1000ProductDescription", here:

The illumination pattern is an ellipse that can be scaled in the x and y directions. The maximum radius of the ellipse is 2047 pixels allowing the light lobe to cover adjacent displays.

The problem was that in the hidden debug menu of Scud and basically in 99% of the cases the dimensions nodes are filled with 0-255 values, making you think that at "255" spot is a point or have zero-dimension. By chance I've discovered that Magical Truck Adventure goes over that value reaching "2047" in a brief moment as soon you start a mission, where the yellow glowing sphere/portal appears and from which the 2 guys and the girl come out.

- I've truncated spotlight "start" parameter to the third decimal number. This avoids some crazy value especially in Star Wars. In some case could be < 0, meaning the light starts from "behind" the point of view. Before "start" value no object is spot-lighten.

- I've truncated spotlight "extent" parameter for the same reason as above. Again could be < 0 (skichamp) and if less than "start" it sets the new minimum "start" point.

- The decay begins from start+extent in seemingly inverse linear fashion, like hinted here (again "Real3DPro1000ProductDescription"):

The extent of the illumination (the distance from the illumination source to the point where the illumination declines) can be specified. The intensity of the illumination decreases as a function of the inverse distance from the eyepoint to each pixel when the extent of the light lobe has been reached.

The formula I've found working well is this:

Code: Select all

// Reference: https://imdoingitwrong.wordpress.com/2011/01/31/light-attenuation
decay = 1 / (d/r + 1)^2
where:
d = distance between the light’s surface and the point being shaded
r = the light’s radius


I've chosen arbitrarily to set "x" component of the spotlight ellipse as "r". This seems to scale globally the falloff distance as measure of the spot dimension.

- I've also added the spotlight-on-fog color parameter. That's used in light-on-fog (and scroll fog) calculations and sometimes can be different from the regular spotlight color. From the latter inherits the same elliptical shape and finally gets multiplied by the fog color(!).

(Continues on Part 2: Fog)

[HarryTuttle]

The fog is implemented in the same way as before, but is mixed with spotlight-on-fog like this:

- The fog itself is eventually dimmed by the "fogAmbient" parameter before mixing with the spotlight-on-fog.

- The spotlight-on-fog data is modulated by the "fogAttenuation" parameter and then added to fog. When this value is zero spotlight doesn't affect fog and vice-versa.

- Scroll fog is affected in the same way as regular fog by the spotlight-on-fog. However I could not make sense of the "Scroll Attenuation" parameter, thus is not emulated correctly. In theory it should behave like "fogAttenuation", but it throws out seemingly incoherent values. I've just interpreted it inverse to "fogAttenuation", so at least shows some light effect (especially in ECA intro), but it breaks somewhere else like here (so please don't complain, I already know and I'm working on it ):

eca02.png (150.66 KiB) Viewed 8967 times

Well, that's all for now, hope to not have left anything and since I feel lazy today I'll just post a screenshot of VF3TB (this is, btw, referenced in other subforums) and I can point you to this (https://youtu.be/wl6tCbnLl7M?t=100) excellent video of ECA to compare with. This particular sequence seems a sort of benchmark/reference for all spot & fog related.

vf3tb_01.png (206.43 KiB) Viewed 8967 times

[Ian]

This looks great, gonna give it a spin now. Still working through your other changes currently

[Ian]

Harry,
how come you needed to do this?

Code: Select all

      // Truncate to three decimal positions
      vp->spotRange[0] = std::trunc(1e3 * vp->spotRange[0]) * 1e-3;
      vp->spotRange[1] = std::trunc(1e3 * vp->spotRange[1]) * 1e-3;

[HarryTuttle]

I remember that, some time ago while dumping to console the "spotrange" values, i saw that those values sometime used to jump to infinite or some illogical values during open space battles in Star Wars.

Also in Scud debug menu, setting the start value to zero it doesn't snap internally to zero. Btw, in that menu a negative value of "start" is still internally "0", maybe a bug of the original code.

I may recheck later if truncation is still needed. I remember to put that for a reason but honestly now I can't remember anything beside the 2 reasons above , it currently doesn't have odd effects.

[Ian]

Well it looks like you've done really good work here.
I wouldn't have thought the h/w would truncate the values like that? No doubt it would just use them as is ..
Also you put a const float in the shader, which caused it to fail to compile (here).
But otherwise it looks great

I see you implemented the spot light code in the background fog. I had actually thought about that, but wasn't even sure if it was ever used
Gonna test a bit more, but will probably push your changes as is

[HarryTuttle]

Also you put a const float in the shader, which caused it to fail to compile (here).

Ah! You cannot be always sure of anything, even with so called standards.

In my PC compiles fine at runtime, who can imagine that a "cost float" could cause errors, go figure... (I've an old Radeon HD4850, btw)

[Ian]

Problem with glsl compilers .. Normally it's the other way around. Normally ati fails to compile (as it should), and nvidia runs all kinda of bad code :p

[Ian]

Harry, last question.
Should spot light be enabled, even if lighting is disabled? What about fixed shaded polys?

[HarryTuttle]

Spotlight-on-fog (and scroll fog) is always enabled, checked against ECO intro/demo. Normal spotlight don't know for sure, I just enabled them only when lightning is also enabled and, for now, all is well.

As for fixed shaded polys: some of them has also the lightEnable bit set so, at least in my private build, spotlight affects them too without using Sunlight parameters. I've to check again with real Model 3 however, a possible candidate could be Dirt Devils.

In this patch I didn't mess with LightEnable condition in <New3D.cpp> so, as consequence, fixed shaded polys are not affected by spotlight at all.