[Patch] Sun Shading

[HarryTuttle]

Ian, about your last commit: if you agree we can also pass a uniform like "stepping" to the shaders, because models Step 1.0 and 1.5 seem to always clamp the lower end of "sunFactor" to zero.

In addition Step 1.0 always clamps the max value of "lightIntensity" to 1.0.

(In <R3DShader.cpp> pseudo-code)

Code: Select all

if (stepping == 0x10)
  lightIntensity = min(1.0, lightIntensity);


[Ian]

Yeah sure, we could add the stepping to the shaders. But is the lighting in step 2.0 really uncapped ? (like specular).
Do you have examples of this?

Also do you have any idea how the clamping of the lighting works in LA machine guns and daytona? I've looked but can't find any obvious differences, unless I overlooked something.

[HarryTuttle]

But is the lighting in step 2.0 really uncapped ? (like specular).
Do you have examples of this?

I'm quite sure, and is not limited to step 2.x, also 1.5 is high-uncapped.

For step 1.5 just look at Scud. Pay attention to the pavement under the car, that's a regular shaded and not specular object.
(left = Supermodel capped, center = Supermodel uncapped, right = Original Model 3)

scud02.jpeg (242.53 KiB) Viewed 6985 times

For step 2.x we can look at Daytona BOTE. In the left picture the road and the white stripe on the right side of the road are too dimmed.
(left = Supermodel capped, center = Supermodel uncapped, right = Original Model 3)

d2bote01.jpeg (244.62 KiB) Viewed 6985 times

Also do you have any idea how the clamping of the lighting works in LA machine guns and daytona?

No idea... I looked also at poly and viewport data but found nothing. I examined the sun and vertex normal values, but nothing relevant. I'm currently looking at culling nodes, however.

[Ian]

Harry, that's excellent work!
I take it that has no obvious regressions?
I remember looking at the sdk and it force normalised the sun intensity + ambient so it could never be more than one. But most games the intensity + ambient usually add up to more than one.

[HarryTuttle]

I take it that has no obvious regressions?

Consider that I'm using that "uncapped' mode for steps 1.5 & 2.x since last year and I've done lots of comparisons with original Model 3 videos and never noted anything off, at least regarding regular illuminated polys.

Note also that Step 1.5 has another "feature": every self-illuminated poly has its shading value multiplied by 1.5, for fixed shaded AND self-illuminated the shading multiplier is 2.0. That's a conclusion made after observing several video of Scud, the beginner level in particular and the cave torches of the 3rd (medium) course.

However I'm still struggling with the many, very subtle, errors in polygons' brightness for illuminated objects. I'm watching the road stripes in advanced level of Daytona 2 BOTE and the sidewalks in Harley. There could be other cases obviously.

In vertex shader we're currently normalizing the dot product of normal's vector with its transformation matrix, but sometimes produces a bit over-brightened polys. Model scale doesn't count as in many cases it's not even set (= 0.0).

[Ian]

I had a quick look at scud last night, in the svn version the brightness matches almost perfectly. But I am not ramping up the brightness of the fixed shade polys so much. Honestly I thought it looked oversaturated when I tried it. Scud could be using something like a gamma ramp, that we haven't yet found. I know the SDK documents such functionality exists in the hardware.

I'll do some experiments with uncapped light brightness for step 1.5+, it should be quite easy to confirm.

[HarryTuttle]

In step 1.5 those values for fixed shading and/or self-illuminated object were an assumption of mine based on observation of their relative brightness with regular shaded polys and overall scene lightness compared with original hw footage.

I'm going to re-test everything in light of the recent changes. Also I'm going to post next days an update to sun shading 'cause I should have resolved the case of those dimmed polys in Ocean Hunter. Btw I need more testing but I believe I'm on the right path.

Scud could be using something like a gamma ramp

If I recall as stated in the devguide gamma correction is done per-device, so that the whole image is changed not only specific polys.

[Ian]

Also I'm going to post next days an update to sun shading 'cause I should have resolved the case of those dimmed polys in Ocean Hunter. Btw I need more testing but I believe I'm on the right path.

I'm quite interested to see that one. I've only briefly even looked at the issue but haven't really made any progress on it. I too looked at the 'model scale' value in the culling notes but haven't really been able to work out what it is for, if it is even related to lighting.

[Ian]

In vertex shader we're currently normalizing the dot product of normal's vector with its transformation matrix, but sometimes produces a bit over-brightened polys. Model scale doesn't count as in many cases it's not even set (= 0.0).

Harry, did you ever check the normals of those polys that end up too bright? Most games the normals are unit length. But I know in some games (like lost world) many of the models have normals less than 1. Either this was by design, or they had no idea what they were doing :p

You can check the length of the normals with something like

Code: Select all

if(V3::length(normal) < 0.9f) {
  printf("small normal");
}
else if(V3::length(normal) > 1.1f) {
  printf("large than unit length");
}

Normals could also in theory be larger than unit length.

Could also do something like this in the shader to check for normal length

Code: Select all

   float len = length(gl_Normal);
   if(len>1.1) {fsColor = vec4(1,0,0,1);}
   else if(len<0.9) {fsColor = vec4(0,1,0,1);}
   else  {fsColor = vec4(0,0,1,1);}

The way we are normalising the result of normal * matrix, won't preserve the original normal length. If i was to guess I would say the hardware calculates the scaling matrix, and then divides the result by it. Would be pretty cheap too, because would only need to recalculate the scaling after a matrix multiplication. Most of the matrix maths are just an x/y/z offset which wouldn't effect the maths.

[HarryTuttle]

Not only that, almost 99% the times that model scale has some value != 0 (in step 2.x, SWTrilogy), it almost coincides with the xyz scaling values in transformation matrix. However there are times where the scaling is < 1.0 and no model scale present (Ocean Hunter).

I've read also that when you have uniform scaling in the matrix you don't need to derive (expensively) the normal matrix (or use the built-in gl_NormalMatrix), i.e. the transpose of the inverse of the model-view matrix. But you can just get the first 3 columns (3x3 mat) and directly multiplicate with the normal vector. That's why Ocean Hunters has dimmed objects.

In that case it seems logical that the Real3D would just skip useless calculations. I'm still testing however, since it will directly affect specular. Still I don't know what can trigger that zero or negative clamping in sun lightning.