[Patch] Sun Shading

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: [Patch] Sun Shading

Postby Ian » Sun Aug 20, 2017 11:21 am

It's possible they did something dumb like ..

1.0 * 128 = 128.0
Which of course would overflow a signed it. Not really sure what happens with signed overflow, probably undefined.

Negative would be okay since signed int 8 is -128 -> 127
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Oct 06, 2017 3:00 pm

Ian, some new ideas for self-illuminated (= luminous) polys or: "another chapter of my never-ending arm wrestling with the Real3D odd light model".

Given that fixed shading value is a drop-in replacement for the NdotL result, as we already found out this summer, the general formula for a basic illuminated polygon can be expressed with:
Code: Select all
// Pseudo-code

if (fixedShaded)
  shade = fixedShadingValue;
else
  shade = NdotL;

// Basic lightning formula
fragment.rgb *= (diffuse * shade) + ambient;


Now, extending the concept to luminous polygons (the ones which aren't affected by lightning, as stated in the devguide), we can rewrite the above like this:
Code: Select all
// Pseudo-code

if (lightEnabled) {
  if (fixedShaded)
    shade = fixedShadingValue;
  else
    shade = NdotL;
}
else
  shade = 1.0;

// Basic lightning formula
fragment.rgb *= (diffuse * shade) + ambient;


This seems to give the correct results especially in Scud. But there's a catch: sometimes the brightness of luminous polys can be excessive (compared with real Model3 footage) so here comes into play the intensityClamp uniform. By settings that like this:
for step 1.0 games: always true;
for step 1.5 games: always false;
for step 2.x games: always true only for luminous polygons;

We obtain the correct brightness in seemingly every cases. As always I didn't played every game 'till the end, but it's worth a try.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Oct 06, 2017 3:34 pm

Harry, slightly unrelated question.
I assumed (maybe incorrectly) that fixed shading wouldn't work with specular .. I never explicitly tested it. Do you think it could?
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Oct 06, 2017 4:01 pm

In my personal build I apply specular in fragment shader regardless of shading type and I've never encountered problems. Also in <New3D.cpp> I pass fixed shading attribute as is.
Code: Select all
currentMesh->fixedShading = ph.FixedShading();


Same logic when calculating the fixed shading value. The condition is simply:
Code: Select all
[...]
if (ph.FixedShading()) {
[...]

In SWT, when reaching the Death Star reactor, it seems to render correctly.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Oct 06, 2017 4:03 pm

Guess I'll need to do some testing :)
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Oct 06, 2017 6:07 pm

HarryTuttle wrote:I apply specular in fragment shader regardless of shading type

Just to make the above statement more clear: in my fragment shader I have a global variable ("shade") which contains the shading value as the result of this:

Code: Select all
// Pseudo-code

if (fixedShaded)
  shade = fixedShadingValue;
else
  shade = NdotL;

So when I later compute specular (but also lightning), instead of redoing the NdotL math, I just throw in the "shade" value from above condition. That's why, in either a sun shaded or fixed shaded polygon, I always obtain some "sane" number to use in specular math.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Sat Oct 07, 2017 5:21 am

The current code basically works the same way

Code: Select all
      // Compute diffuse factor for sunlight
      if(fixedShading) {
         sunFactor = fsFixedShade;
      }
      else {
         sunFactor = dot(sunVector, fsViewNormal);
      }


I checked all the bits for the specular value or specular coefficient in this scene. The ceiling and floor both uses fixed shading, and both have specular enabled.

Image

And they are all zero. So they are totally unaffected by specular. So I think it should be safe to remove the specular + fixed shaded check.
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Sat Oct 14, 2017 3:00 pm

Light model (clamped vs unclamped) in Step 1.0 (not fixed shading capable)

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

The brighter one is, obviously, unclamped and wrongly shaded. The yellow marker evidentiates luminous polygons; all the others are illuminated and magenta markers evidentiate some of them.
Last edited by HarryTuttle on Sat Oct 14, 2017 4:37 pm, edited 1 time in total.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Sat Oct 14, 2017 4:36 pm

Light model (clamped vs unclamped) in Step 1.5

Here's an example of luminous, regular & fixed shaded, polygons:
scud09a.png
scud09a.png (43.81 KiB) Viewed 278 times

Those marked in magenta are regular shaded luminous polygons (the torch flames), their gray level is 170. They must be multiplied by 1.5 so the new value will be 255, as we should expect for a full saturated texture (the flame). Instead here are grayish. The pillars and street signs, marked in green, are fixed shaded luminous polygons. See next image.

Left = Model 3, Right = Supermodel
Image
On the right, the dimmer version is the wrong one. This particular example served as proof for the 1.5 multiplier for regular shaded luminous polygons, not much the clamped vs unclamped issue.

See the next post for another example of luminous polygons in model step 1.5 and why we've to keep illuminated & luminous polys max value unclamped...
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Sat Oct 14, 2017 5:23 pm

I had wondered about the torches in that scene for a while. And 1.5 does appear to give the correct brightness. 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
Ian
 
Posts: 1216
Joined: Tue Feb 23, 2016 9:23 am

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 4 guests