[Patch] Fixed Shading

[HarryTuttle]

So what do you think the correct formula is?

I really think it's this:

Code: Select all

shade = 1.f + (float)((UINT8)(ix & 0xFF)) / 128.f;

I can also confirm all the values for Step 1.5, I've just finished to re-check all the Scud race videos and made many other comparisons.
I'm also quite sure about Step 2.x self-illuminated, I'm checking right now illuminated polys. Also TranslatorMap seems to not affect the choice of the formulae.

So basically it's the ambient light that "decides", once the threshold of 0.5 is reached.

[Jiterdomer]

This is a really nice fixes you got there, Harry! Anyway, how can I apply your patches into the source code because I'm going to add this to my own source code for my build downloads? Anyway, does it improve the lighting for the MGM Statue in the Las Vegas Stage from LA Machineguns even though it lacks specular lighting?

[HarryTuttle]

Ian, late night update.

After extensive testing with Step 2.x fixed shading in games like Dirt Devils, L.A. Machineguns, Star Wars Trilogy, Sega Rally 2 and Magical Truck Adventure i can summarize the final, correct behavior below:

Code: Select all

if (ph.LightEnabled()) {
  float offset = ((vp_ambient >= 0.5f) || ph.TranslatorMap()) ? 0.75f : vp_ambient;
  shade = ((vp_ambient >= 0.5f) || ph.TranslatorMap()) ? (float)((INT8)(ix & 0xFF)) : (float)((UINT8)(ix & 0xFF));
  shade /= 255.0f;
  shade += offset;
}
else {
  shade = 1.0f;
}


As you can see it changed a lot, but finally this is it. Let me know what do you think about. As for the Step 1.5 version I can confirm what I've already posted before.

how can I apply your patches into the source code

I just posted (again) another update of my patch, as you can see the situation is still a bit "fluid", I would suggest you to wait for Ian's & Bart's approval and the official commit.

In general my patches are not meant to be applied directly 'cause they are proof-of-concept waiting for discussion, review and approval; also they aren't cumulative, that is: if you apply one patch, say "microtexture", and then apply "Fixed shading", the latter may revert some or every change made by the first. That's because each of them is applied against current svn version r528, not against the previous one.

Anyway, does it improve the lighting for the MGM Statue in the Las Vegas Stage from LA Machineguns even though it lacks specular lighting?

I'm afraid not, because it currently lacks specular lightning... Seriously, that object has nothing to do with fixed-shading, only specular. So until we merge the new algorithm for specular simulation it stays as a monochromatic yellow block. However, if all goes well with fixed-shading I'll post my patch for specular lightning soon.

[Ian]

So what do you think the correct formula is?

I really think it's this:

Code: Select all

shade = 1.f + (float)((UINT8)(ix & 0xFF)) / 128.f;

I can also confirm all the values for Step 1.5, I've just finished to re-check all the Scud race videos and made many other comparisons.
I'm also quite sure about Step 2.x self-illuminated, I'm checking right now illuminated polys. Also TranslatorMap seems to not affect the choice of the formulae.

So basically it's the ambient light that "decides", once the threshold of 0.5 is reached.

I tried this one with scud .. and it was definitely too bright.
Fixed shading is supposed to be easy. You set a fixed brightness value for the vertex and done. But it gets a bit more complex since the poly colour is always multiplied by the vertex brightness. And the colour itself can modulate the brightness for the final poly, ie if you set a black value.

So, so far we get the simple forumula
FinalColour.r = FixedShade * polyColour.r
FinalColour.g = FixedShade * polyColour.g
FinalColour.b = FixedShade * polyColour.b

As far as I can tell this looks correct for most things that used fixed shading. Except for scud, large parts of the game look way too dark. The sky, signs, everything. Examining these polygons the colour values are always less than 1. But not only that the fixed shade values are also less than one. Multiplying these two together the brightness is even darker.



If you look at the building, it's over bright. That's impossible with our current formula. Even if fixed shade was 100% and the colour was white, it still wouldn't come out that bright. All these polys are marked with a different flag, lighting enabled or disabled, i forget which.

With these polys if you assume the formula is instead
FinalColour.r = FixedShade + polyColour.r
FinalColour.g = FixedShade + polyColour.g
FinalColour.b = FixedShade + polyColour.b

This is basically how the current code works. This seems to look more or less perfect for scud. Actually I thought the castle section might be darker in the original arcade or with more contrast. But it's more or less correct.

This also looks correct for LA machine guns which makes heavy use of fixed shading, basically everywhere.
What threw me most was dirt devils, it looks mostly correct, except the part under the bridge. It needs a value of 0.5 added to it. Which lead me to speculate the fixed shade value could have been ofset by something else. But I've totally failed to work out what exactly. What looks correct for dirt devils, then breaks all other games.

[HarryTuttle]

I'm re-checking the Step 1.5 case, in light of your screenshot (my bad... I've checked everything else and this one slipped off! )

This also looks correct for LA machine guns which makes heavy use of fixed shading, basically everywhere.
What threw me most was dirt devils, it looks mostly correct, except the part under the bridge. It needs a value of 0.5 added to it. Which lead me to speculate the fixed shade value could have been ofset by something else. But I've totally failed to work out what exactly. What looks correct for dirt devils, then breaks all other games.

Maybe a coincidence but for Step 2.x, the threshold of 0.5 in ambient light is the value that "switches" algorithm. Until you "throw it" in the equation what will work on Dirt will breaks others (like for example SWTrilogy reactor level) and vice-versa, like you said. Maybe that threshold is fetched from another register, who knows? I just found that's connected with fixed-shading formula.

As for LA Machineguns: if you don't add a constant you'll have a correct shading but much darker than is supposed to be, for the very same reason you'll get dark tunnel in Dirt's beginner course and darker savanna in Magical Truck. Adding 0.5 is still dark, 1.0 is too much bright, so I just used the middle value 0.75. Checking with videos (I must admit not the best quality) for relative brightness it should be right, at least with the last piece of code posted before. Also, unlike my first findings, this constant is valid only for > 0.5 ambient light value, in the opposite case we should use the ambient itself (this one checked with, again, the reactor scene in SWT).

Luckily all this headache is needed only for illuminated polys, every instance of self-illuminated encountered will be fine with the value "1.0" (we're still talking about Step 2.x).

If you colourize the polys to show every combination you'll see better what i mean. I've done this in my first ugly code otherwise it'd have been too difficult to understand the mechanism. Anyway let me know if i should post some screenshot to show that concept better.

[HarryTuttle]

Little update: what i forgot to say before is that fixed-shading seems to be used to modulate the polycolor, that means you can have darker or brighter final result as valid values.

So using that normal "x" value as an INT8 in some cases (like L.A. Machineguns) will correctly shade the buildings.

BTW, thanks for spotting that error in Scud. I like corner cases...

[HarryTuttle]

Ian, I fixed it.

You were absolutely right about step 1.5 self-illuminated fixed-shaded polys. However I always felt they were "out-of-place" with other elements. In fact I took as reference the luminosity of regular polys (not fixed-shaded) to get the right formula. *BUT* (and this really took me off-guard) the overall scene luminosity is higher due to the fact that Model 3 step 1.5 apparently doesn't clamp sun lightning to 1.0, as it does in step 1.0 (confirmed with VF3) and maybe step 2.x (at this point I need to check again).

So after a little change in fragment shader the whole scene became a lot brighter and consequently your formula now fits perfectly. I changed also the illuminated fixed-shaded case accordingly and now I think it's almost done.

There're still some "crazy" regular poly which darkens the texture rgb colour, like the water in your screenshot or the torches inside the cave in medium level.

Anyway, to recap, this is the situation with step 1.5:

Code: Select all

if (ph.LightEnabled()) {
  shade = 0.5 + (float)((UINT8)(ix & 0xFF)) / 128.0f;
  if (vp_ambient < 0.5f) {
    shade = vp_ambient + (float)((INT8)(ix & 0xFF)) / 128.0f;
  }
}
else {
  shade = 1.0f + (float)(128 + (INT8)(ix & 0xFF)) / 255.0f;
}


[Ian]

I'll try it out in a bit
I can see why the viewport ambient value would be a factor in fixed lighting .. I mean that would make sense.
But not sure why it would be conditional on a certain value? ie 0.5 ?

[HarryTuttle]

Ian, I just fixed also the remaining low light polys. For self-illuminated not fixed-shaded you've have to multiply the shade by 2.0. This brings back vivid torch lightning inside the cave in medium level. Also gives an overall more saturated color to the scene, especially in the terminal stage.

That's why, incidentally, when creating the post-fx mock-up in my comparisons i had to always push the saturation level...

Anyway I'm still testing, just to be sure.

[HarryTuttle]

But not sure why it would be conditional on a certain value? ie 0.5 ?

I got it by "instinct" (I'm a bit heretic here), seeing that the ambient light value stays often in the rounds of 127 or just much more or much less, as it was divided in two groups. So I thought that a threshold of 0.5 could be fine as a on/off switch.

Anyway I'm watching also the value for translatorMapOffset, it jumps often from "4" to "127", I want to check if there's a connection.