[Patch] Sun Shading

[Ian]

It's possible they did something dumb like ..

1.0 * 128 = 128.0
Which of course would overflow a signed it. Not really sure what happens with signed overflow, probably undefined.

Negative would be okay since signed int 8 is -128 -> 127

[HarryTuttle]

Ian, some new ideas for self-illuminated (= luminous) polys or: "another chapter of my never-ending arm wrestling with the Real3D odd light model".

Given that fixed shading value is a drop-in replacement for the NdotL result, as we already found out this summer, the general formula for a basic illuminated polygon can be expressed with:

Code: Select all

// Pseudo-code

if (fixedShaded)
  shade = fixedShadingValue;
else
  shade = NdotL;

// Basic lightning formula
fragment.rgb *= (diffuse * shade) + ambient;


Now, extending the concept to luminous polygons (the ones which aren't affected by lightning, as stated in the devguide), we can rewrite the above like this:

Code: Select all

// Pseudo-code

if (lightEnabled) {
  if (fixedShaded)
    shade = fixedShadingValue;
  else
    shade = NdotL;
}
else
  shade = 1.0;

// Basic lightning formula
fragment.rgb *= (diffuse * shade) + ambient;


This seems to give the correct results especially in Scud. But there's a catch: sometimes the brightness of luminous polys can be excessive (compared with real Model3 footage) so here comes into play the intensityClamp uniform. By settings that like this:
for step 1.0 games: always true;
for step 1.5 games: always false;
for step 2.x games: always true only for luminous polygons;

We obtain the correct brightness in seemingly every cases. As always I didn't played every game 'till the end, but it's worth a try.

[Ian]

Harry, slightly unrelated question.
I assumed (maybe incorrectly) that fixed shading wouldn't work with specular .. I never explicitly tested it. Do you think it could?

[HarryTuttle]

In my personal build I apply specular in fragment shader regardless of shading type and I've never encountered problems. Also in <New3D.cpp> I pass fixed shading attribute as is.

Code: Select all

currentMesh->fixedShading = ph.FixedShading();


Same logic when calculating the fixed shading value. The condition is simply:

Code: Select all

[...]
if (ph.FixedShading()) {
[...]


In SWT, when reaching the Death Star reactor, it seems to render correctly.

[Ian]

Guess I'll need to do some testing

[HarryTuttle]

I apply specular in fragment shader regardless of shading type

Just to make the above statement more clear: in my fragment shader I have a global variable ("shade") which contains the shading value as the result of this:

Code: Select all

// Pseudo-code

if (fixedShaded)
  shade = fixedShadingValue;
else
  shade = NdotL;


So when I later compute specular (but also lightning), instead of redoing the NdotL math, I just throw in the "shade" value from above condition. That's why, in either a sun shaded or fixed shaded polygon, I always obtain some "sane" number to use in specular math.

[Ian]

The current code basically works the same way

Code: Select all

      // Compute diffuse factor for sunlight
      if(fixedShading) {
         sunFactor = fsFixedShade;
      }
      else {
         sunFactor = dot(sunVector, fsViewNormal);
      }

I checked all the bits for the specular value or specular coefficient in this scene. The ceiling and floor both uses fixed shading, and both have specular enabled.



And they are all zero. So they are totally unaffected by specular. So I think it should be safe to remove the specular + fixed shaded check.

[HarryTuttle]

Light model (clamped vs unclamped) in Step 1.0 (not fixed shading capable)

Left = Model 3, Right = Supermodel (clamped vs unclamped)


The brighter one is, obviously, unclamped and wrongly shaded. The yellow marker evidentiates luminous polygons; all the others are illuminated and magenta markers evidentiate some of them.

[HarryTuttle]

Light model (clamped vs unclamped) in Step 1.5

Here's an example of luminous, regular & fixed shaded, polygons:

scud09a.png (43.81 KiB) Viewed 5940 times

Those marked in magenta are regular shaded luminous polygons (the torch flames), their gray level is 170. They must be multiplied by 1.5 so the new value will be 255, as we should expect for a full saturated texture (the flame). Instead here are grayish. The pillars and street signs, marked in green, are fixed shaded luminous polygons. See next image.

Left = Model 3, Right = Supermodel

On the right, the dimmer version is the wrong one. This particular example served as proof for the 1.5 multiplier for regular shaded luminous polygons, not much the clamped vs unclamped issue.

See the next post for another example of luminous polygons in model step 1.5 and why we've to keep illuminated & luminous polys max value unclamped...

[Ian]

I had wondered about the torches in that scene for a while. And 1.5 does appear to give the correct brightness. But that kind of makes me think we have the basic formula wrong. Why would they just randomly multiply the brightness by 1.5? It doesn't make much sense