Light clamping

[HarryTuttle]

If you can upload a save state, must go out now Will look at it later

Save state here

[Ian]

Yeah that's odd, I assume that thing doesn't show up on the original h/w.
Will have a debug and see if I can work out why it's there

[Ian]

I think that issue is a timing problem
The culling nodes are referencing matrices which haven't yet been copied in memory. Similar to what ocean hunter is doing.
Not 100% sure that is what's is happening, but I think so.

[Ian]

What kind of errors do you see? Screenshots would help

dimmed specular in ECA:

I made a quick test build last night to colour models that used a scaling (larger/smaller) matrix. And I'd say 95% of the time the models never have any kind of scaling matrix. And if they do, they are usually unlit.

It is quite possible that the hardware is detecting .. the scaling in the matrix, and undoing it, to preserve the models normals, but honestly I would be quite surprised if this was the case. If it was the case, they probably wouldn't have ever bothered adding the model scale to the culling nodes.

If you are testing specular, the best game is really lemans24. The car selection screen, from what I recall is barely lit by regular lighting. It's mostly ambient + specular. I think the normals are unit length, and no scaling matrix, so probably quite a good test case. The only 'gotcha' is depending on the time of day?? The sun angle will flip. Videos of both exist.

[HarryTuttle]

Progress update:

My last theory, and hence the last patch proposal, proved to be wrong, you're right to do:

Code: Select all

(matrix * normal) / modelscale

My code had some problem with Ocean Hunter (which I didn't spot before) and Lost World (the terrain that's lifted when shooting on the ground).

We just have to normalize the sun vector when > 0, and in fragment shader we should clamp the diffuse factor "sunFactor" to be <= 1.0. That will fix the t-rex over brightened foot. There's some object with larger matrix scale that's supposed to be a bit overbright, while modelScale is still = 1.0 (unset), the important thing is to never clamp the ambient+diffuse 'cause will bring major light errors in most games.

I've also made a lot of progress with specular. Now is even more identical to the arcade counterpart: I've found that flat surfaces need a different math, and smooth surfaces need a simpler one.

I'll post soon the patch to better explain the current situation.

[Ian]

I've also made a lot of progress with specular. Now is even more identical to the arcade counterpart: I've found that flat surfaces need a different math, and smooth surfaces need a simpler one.

Sounds great Why would flat surfaces need different maths? You mean surfaces with flat shading, as apposed to per vertex normals?

[HarryTuttle]

You mean surfaces with flat shading, as apposed to per vertex normals?

Yeah, exactly. A good case is Harley, during the first running demo, all the buildings with reflective glass were rendered too dimmed, I always wondered why...

Obviously all that sounds too great to be true , infact I still have some problem with L.A. Machineguns, in that case flat shaded polys seem to need a third, different algo. At least compared with the only good quality video of that game that it's no longer on line (if you want it, just tell me).

Anyway, Machineguns is a strange beast on its own, the current solution seem to work in the 99% of the other cases. Time will tell... as always we need testing, especially from Supermodel vast user base.

[Ian]

Yeah I wouldn't worry about LA machine guns currently, because we know it uses it's own weird lighting model. If you can get lemans 24 to work, pretty sure we'll be 95% of the way there

[Ian]

Harry,
you might find that flat surfaces actually are a better test with regards to specular. On the hardware the specular is only being done per vertex, and with quadratic interpolation. None of those things effect us with flat polys

[HarryTuttle]

Yes, infact in this case is just a matter of multiplicating "NdotL" by a given factor which is not apparently a derivative of the exponent term or the specular value. In the end I still utilize a look-up table to fetch a valid value whose index is the exponent term.

BTW I'm almost to the end of the work, I'll post the patch divided in two parts. The first is a little modification to the sun light algorithm which serves as the base for the second that is the specular processing itself.

I must say that this update is shaping very well from the last time I posted about it. Thank you for directing me to Le Mans 24, the intro has almost everything I needed to test the specular correctness . Also thanks to icuk7's recent high quality direct capture of the ENTIRE intro uploaded on youtube, I was able to finally make some very useful comparison.