Supermodel Forum

I was working to an update to my code while I saw yours, and they're very similar. I too did change the polygon color directly (instead of multiply by 1.5 the lightIntensity) however it's a bit more elaborated than that.

After some testing with various step 1.5 games I found that these conditions need a dedicated math (and only for step 1.5):
1) fixed shaded luminous polygons without textures (check the gun calibration test menu of Lost World)
2) luminous polygons without textures (too many...)
3) textured luminous polygons (Fires in Scud's cave level)
4) textured fixed shaded luminous polygons (Virtua Striker 2 step 1.5 Billboard light bulbs, Scud skydome, walls, etc.)

So this is the updated light model:

Code: Select all

// Pseudo-code

if (fixedShading) {
  sunFactor = fsFixedShade;
}
else {
  sunFactor = dot(sunVector, fsViewNormal);
}

if (!lightEnabled) {
  if(hardwareStep==0x15 && texEnable) {
    if(fixedShading) {
      colour.rgb *= vec3(1.0 + fsFixedShade + lighting[1].y);
    }
    else {
      colour.rgb *= vec3(1.5);
    }
  }
  sunFactor = 1.0;
  diffuse = 1.0;
  ambient = 0.0;
}

lightIntensity = vec3(diffuse * sunFactor + ambient);   // diffuse + ambient

switch (m_stepping) {
  case (0x10):
    intensityClamp = true;
    break;
  case (0x15):
    intensityClamp = false;
    break;
  case (0x20):
  case (0x21):
    intensityClamp = false;
    break;
}

if(intensityClamp) {
  lightIntensity = min(lightIntensity,1.0);
}


I noticed too that fixed shading only seems to work for textured polys. Also wondering about the fixed shaded value fsfixedshade is it ever something other than 0.5? That we can see that effects rendering?

Ian wrote:Also wondering about the fixed shaded value fsfixedshade is it ever something other than 0.5? That we can see that effects rendering?

Yes, sometimes is different than that, I just noticed today while rewriting the math.

In Scud it seems to be around that (or just equal to that) so that the result is the same (skydome and walls).

In Virtua Striker 2 step 1.5 is different and that is visible at the beginning when the camera pans horizontally in front of the billboard; the light bulbs are now less bright (in respect of 0.5 value), much more similar to the arcade (see icuk7's video, albeit a little globally darker).

Okay seems we weren't that far away in the original formula The mistake was to take into account the sun diffuse component, which I guess would make no sense for luminous polys anyway.

Code: Select all

    else {
      colour.rgb *= vec3(1.5);
    }

Does that work consistently for luminous textured polys on step 1.5 ? Seems strange they would do this, but entirely possible.

To simplify even further the "core" math for luminous polygons we can rewrite the code like this:

Code: Select all

if (!lightEnabled) {
  if(hardwareStep==0x15 && texEnable) {
    float offset = fixedShading ? fsFixedShade + ambient : 0.5;
    colour.rgb *= vec3(1.0 + offset);
  }
  diffuse = 0.0;
  ambient = 1.0;
}

lightIntensity = vec3(diffuse * sunFactor + ambient);


This way we can handle luminous textured polygons (fixed shaded or regular ones) in step 1.5, while leaving all other cases of luminous polys (even other stepping hw) with the correct math, that is with the parameters set so that lightIntensity = 1 always.

It seems to work always. Unless someone has some corner case to show. Something which, paradoxically, I hope so we can even further understand how Real3D light model works

Ian, I'm testing an update to that formula that seems even more accurate:

Code: Select all

void Step15Luminous(inout vec4 colour)
{
   // luminous polys seem to behave very differently on step 1.5 hardware
   // when fixed shading is enabled the colour is modulated by the vp ambient + fixed shade value
   // when disabled it appears to be multiplied by 1.5, presumably to allow a higher range
   if(hardwareStep==0x15) {
      if(!lightEnabled && textureEnabled) {
         if(fixedShading) {
            colour.rgb *= 1.0 + fsFixedShade + lighting[1].y;
         }
         else {
            colour.rgb *= 1.0 + lighting[1].y;
         }
      }
   }
}


Note the else section. In Scud not all the torches have luminosity value "170"; considering that and also ambient light value that changes from a viewport to another, I'm doing some test and it works.

Also seems more logical that they're using ambient value as an offset for both fixed and regular shaded polygons.

I was wondering about that logic myself.
Do you have any test cases for it? Or comparisons to the real hw?

Ian wrote:Do you have any test cases for it? Or comparisons to the real hw?

Yes, I'll post some Scud, Lemans 24 and Lost World soon. Just the time to prepare them

Okay great
I think it's amazing how much progress we've made. It's like a giant jigsaw with the pieces slowly coming together.

Here they are:

(left = Supermodel, Right = Model3) LeMans 24: the trees


(left = Supermodel, Right = Model3) Scud Race: the fires


(left = Supermodel, Right = Model3) Lost World: the trees