[Patch] Sun Shading

[HarryTuttle]

Light model (clamped vs unclamped) in Step 1.5 (continued)

I'll recycle some screenshot posted time ago when discussing the light model for step 1.5...

Left = Model 3, Right = Supermodel

scud06.jpeg (244.3 KiB) Viewed 8652 times

The sky and road are luminous polygons while the walls are illuminated; both are fixed shaded.

To see how varying ambient light affects the luminous fixed shaded object look at these 2 frames from Abe's direct capture (ignore the half picture issue as the capture hw probably lost sync with source):

scud08.gif (211.62 KiB) Viewed 8652 times

From one frame to the other the scene becomes brighter; dumping to console the relevant viewport light values we see that the ambient term changes.

For clamp vs unclamp just look here paying attention to the car shininess and the stoned road underneath, especially in relation to the wall on the left (Right = Model 3, Others = Supermodel):

scud02.jpeg (242.53 KiB) Viewed 8652 times

[HarryTuttle]

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

This wouldn't be the only thing that Real3D does oddly in respect to modern hw . Unless we choose to apply a dedicated light model for each step version I think that using a "universal" formula and then applying the "clamp-to-one" where appropriate *could* be similar to the way original hw behaved. But I'm not putting my money on it...

We are still dealing with a black box whose logic sometimes is not immediately clear; even the specular light coefficients are a guess work: I don't know if they're a result of formula or just values fetched from a lookup table, I think it's just the result that counts in these cases.

But yes, on first approach I'd also think 1.5 multiplier for luminous polygons sounds very odd, considering that for fixed shading we must also add the ambient factor. What I'm looking for is at least consistency across all step 1.5 games, that's why I'm comparing with as much as direct capture footage I can...

[HarryTuttle]

Light model (clamped vs unclamped) in Step 1.5 (continued)

Virtua Striker 2 (step 1.5)

Left = Model 3, Right = Supermodel

vs215_02.jpeg (248.76 KiB) Viewed 8648 times

I've gamma adjust model 3 image since it was really too dark. Save for the time-of-day-dependent textures and model 3's orange toned colors they seem to be very similar in brightness and saturation.

This billboard object is luminous fixed shaded.

In magenta there's a detail not present in the clamped step 2.0 version: the switched off light bulbs, grouped in square, that draw the number are a bit lighter than the surrounding ones.

[HarryTuttle]

Light model (clamped vs unclamped) in Step 2.x

Again I had to color correct the video source at the expense of the white point temperature.

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


Self explanatory. (Some of the) luminous fixed shaded marked in magenta, see also the player car's yellow back light.

[HarryTuttle]

Light model (clamped vs unclamped) in Step 2.x (continued)

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


The dimmer version is correct.

Luminous regular shaded marked in magenta. The sky is affected too, but here's not visible.

As for the unclamping of illuminated polygons in step 2.x we've already talked before, taking Daytona 2 road brightness as an example. In the photo above the yellow dirt is illuminated regular shaded and unclamped.

Phew!... That's all for now!

[HarryTuttle]

Final recap. I think the basic light model formula is this:

Code: Select all

// Pseudo-code

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

if (!lightEnabled) {
  sunFactor = 1.0;
  if (!fixedShading) ambient = 0.0;
  ambient += 0.5;
  diffuse = 1.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 = !lightEnabled;
    break;
}

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


[Ian]

I'll have a dig into this soon. Thanks for the images Harry
Half way through adding geometry shaders to supermodel. Need to convert the 'triangle' data to line adjacency

[Ian]

Well this is lemans24 with current supermodel shaders (step 1.5)



What it should look like. The buildings should be full bright.


Checking the states

Lighting disabled


Fixed shading enabled


I am thinking the formula is even simpler than we imagine...
Maybe there is no colour or brightness modulation on step 1.5 when lighting is disabled + fixed shade enabled
Maybe
finalColour = textureColour;

All the signs/fire that you would expect to be full bright in scud also have these same bits set. Unless I am having a brain fail and forgot something :p

[HarryTuttle]

All the signs/fire that you would expect to be full bright in scud also have these same bits set. Unless I am having a brain fail and forgot something :p

Are you sure? Last time I checked the fires and signs inside the cave didn't have the fixed shaded bit, that's why I was confused at first and came to the theory of the x1.5 multiplier. Also in Scud, during the first attract sequence, you'll see the sky has also light disabled + fixed shaded but also changes intensity (albeit for a few frames) with the contribution of ambient light. Really weird...

Out of curiosity, are you using the legacy engine with the analysis tool, or did you port it to new engine? I'm interested because I tried to do that but did't quite work.

[Ian]

Are you sure?

Nope! Never sure lol. But testing this morning with the sky in scud no that formula doesn't work. Your 1.5 formula could be 100% correct, just trying to think of the absolute simplest formulas and start from there. Lighting model is hard to work out, because it's like an equation with potentially several unknowns. But the fact lemans24 looks broken with my build is both good and bad. Bad because it's broken, but good because it says 100% the formula is wrong.

Out of curiosity, are you using the legacy engine with the analysis tool, or did you port it to new engine? I'm interested because I tried to do that but did't quite work.

Using the legacy engine. I didn't bother porting the code.

Edit:

How about this?

Code: Select all

void Step15Lighting(inout vec4 colour)
{
   // on step 1.5 these polys seem to be effected by vpAmbient
   // logic is not completely understood
   if(hardwareStep==0x15) {
      if(!lightEnabled && fixedShading) {
         colour.rgb *= vec3(lighting[1].y + 1.5);
      }
   }
}

Did some more testing this morning. Vp ambient definitely plays a roll, I forgot about that It's also definitely modulated by the polygon colour, virtua striker needs that.