[Patch] Sun Shading

[Ian]

If I was to guess .. I'd say it was probably a bug in their implementation. I can't imagine the game designers thought, I know i'll make the lighting flash on and off randomly :p

That said I need to figure out what is happening to the normals that actually disables lighting with mat3(gl_ModelViewMatrix)

Maybe they are inverting the model axis with Scale(). Say swapping 2 of the axis and inverting the model normals or something.

[HarryTuttle]

Maybe they are inverting the model axis with Scale(). Say swapping 2 of the axis and inverting the model normals or something.

Or maybe some kind of overflow that causes the values to be multiplied by a high factor.

Anyway I'll post later the patch for review, since I've finally managed to implement a credible lightning logic, with results consistent with original Model3 videos.

[Ian]

Edit:
Okay I messed up the maths

Did some more debugging of lost world with the bullet brightness.
The scaling of the matrix is 5,5,5
So they have scaled up the object 5 times. It looks like they have changed the normals on only the front of the bullets to be around 0.148. If you multiply that by 5 you get 0.75.

This tells me the maths is probably simpler than what we think

[Ian]

Spent a few hours messing with this last night
Boiled it down to something simple like

In the shader

Code: Select all

fsViewNormal   = (mat3(gl_ModelViewMatrix) * gl_Normal) / modelScale;

Model scale comes straight from the culling nodes

Code: Select all

   if (!m_offset) {      // Step 1.5+
      
      float modelScale = *(float *)&node[1];
      if (modelScale) {
         m_nodeAttribs.currentModelScale = modelScale;
      }

If you assume the lighting is clamped with ambient+diffuse can't be more than 1, everything seems to look pretty much correct. I don't see any obvious shading problems?

[HarryTuttle]

This is my interpretation: Real3D uses "ModelView * Normal" assuming that every object is scaled uniformly.

When a scale dimension's magnitude is > 1 it divides the normal by the scale factor itself. When magnitude is < 1 it leaves as it is (Ocean Hunter) unless "modelScale" from nodes attributes is set (!= 0). ModelScale seems to act as an override, in this case the normal is divided by that number.

In my implementation I use ModelScale as a trigger, but the divisor fetched is still the scaling factor. That's because some value passed is not correct and coherent with what I observed in the original hardware. So as a safe measure I still divide by the scaling factor.

P.S.
Ian we thought about the same variable name

P.P.S.
Forgot to add: I modified the sun clamping logic in New3D.cpp, as it's value sometimes is > 1.0 (SWTrilogy) with seemingly correct lightning, while Magical Truck Adventure sometimes sets it way too off (255.f). So I assumed that every value that's >= 2.0 can be interpreted as an unsigned 8-bit.

Here's the patch

[Ian]

Your code is quite similar to what I came up with the only difference is, I just assumed when no modelScale value was set the value was 1.0f. I tried calculating the scale too from the matrix, and came up with different maths, but something that ends up roughly the same result. But in the end, not sure it is needed.

Interesting too about the light intensity greater than 1. Either the h/w just clamps the value or leaves it unclamped. I don't know which.

When I tried specular before, my code totally fell apart in these corner cases (like in lost world), which then made me think that my lighting formula was wrong. But now we have a better understanding of this, I think we should be able to get specular to work

Harry do you have a final version of the specular you worked on before? Because for the screenshots you posted for ECA and Scud, it looked almost perfect compared to the real hardware.

[HarryTuttle]

Interesting too about the light intensity greater than 1. Either the h/w just clamps the value or leaves it unclamped. I don't know which.

The light intensity > 1.0 (1.3 exactly) is used in SWTrilogy in open space scenes, and belongs to some viewports with only Tie Fighters or Bombers in it. Probably they wanted to exaggerate the metallic highlight effect.

But now we have a better understanding of this, I think we should be able to get specular to work

Harry do you have a final version of the specular you worked on before? Because for the screenshots you posted for ECA and Scud, it looked almost perfect compared to the real hardware.

Infact I too wanted to archive this phase, sun shading and specular, and pass to self-illuminated (Scud) and (again, AGAIN) return to fixed shading, especially for step 2.x. 'Cause I suspect that modelscale affecting normals can contribute to alter also fixed shading math.

As for specular: I'll check what i posted some time ago and eventually repost the updated patch as soon as I can. Time has passed and I don't remember if I've done some further work since then. What I can anticipate by now is that the math used for specular in transparent surfaces is still not 100% perfect (some little detail in Scud's car glasses and some building in Harley).

[HarryTuttle]

PATCH UPDATE:

- Fix for "isIsotropic" function in vertex shader. A really silly bug that escaped my attention.

[Ian]

What I can anticipate by now is that the math used for specular in transparent surfaces is still not 100% perfect (some little detail in Scud's car glasses and some building in Harley).

Does the specular term get added to the alpha value? If so it would drive the surfaces from transparent to opaque

I'll do some testing with light intensity greater than 1

[HarryTuttle]

Does the specular term get added to the alpha value? If so it would drive the surfaces from transparent to opaque

Yes, and I've already emulated it. The problem is about the brightness of the reflection texture applied, there are a couple of corner cases to fix. I'll experiment with them later.