Gliden64: Pachinko Nichi & other Seta games: "lighting" (HLE)

Created on 11 May 2020  路  12Comments  路  Source: gonetz/GLideN64

I studied the "lighting system" of some Seta games which have a rewritten fast3d ucode (completely rewritten but full compatible gbi wise with fast3d)

I was thinking that I got wrong by saying that the lighting was working correct in HLE but actually....

i have some doubts

See the screen in Pachinko 365 Nichi:

LLE

LLE

HLE:

HLE

I see a color difference.

Do you?

Most helpful comment

I would say step one is calculating some norm of the matrix and, thus, step two is normalizing it.

Compatible norms satisfy for some vector norm. I'm guessing that the idea is to have the results of modelview matrix times vertex normal almost normalized and thus skip normalizing normal vectors (at world coordinates). You get this by using a normalized modelview matrix and normalized vertex normals (at model coordinates).

The result would be faster lighting (normalizing one matrix is faster than normalizing many vectors) but less realistic lighting, as normal vectors won't be exactly normalized.

Ideally one should use a compatible norm, but it seems to me the algorithm is prioritizing ease of calculations. I would say those computations result in the L12 norm. Notice I said L12 and not the more standard L21. There's also the nuance of the hardcoded multiplication.

The rest of the steps seem standard to lighting computation.

Hope this helps.

All 12 comments

Stunning is the hair, color is really different. HLE is too bright, LLE is darker overhaul.

Same in Eiko St Andrews

HLE

LLE

The difference so small is impossible to notice unless you're comparing HLE/LLE side by side. Is it worth looking into it?

I spent already a lot of time on it :)

thinking about it the "lighting system " only appears when the players arrives in Eikou. Would it be a way to manage the framebuffer/colors buffer? Wild idea for the time being.

@olivieryuyu it does look darker in LLE. Out of curiosity, how did you notice the slight difference? I find it impressive that you discovered this, because I wouldn't have noticed unless i looked at both at the same time.

some Seta games have a rewritten fast3d ucode (completely rewritten but full compatible gbi wise with fast3d)

I noticed that a long time ago, notably because the Y was reversed.

I am trying to get in the ucode i am trying to develop an optimized way to do lighting

I was curious the Seta microcode which does something completely different and for which neither Sergey or me have a clue about.

I was curious the Seta microcode which does something completely different and for which neither Sergey or me have a clue about.

Could you explain it in details here? The Seta microcode does really weird computations instead of traditional lighting. I don't understand what is it, but someone else may find it out.

We discussed somewhat about it in the Discord64 server, you may want to check #n64_dev there

Here how lights seems to work

  1. calculate n

top of modelview matrix:

            1    2     3    

            4    5     6    

            7    8     9                           

n = sqrt((1 + 4 + 7)虏 + (2 + 5 + 8)虏 + (3 + 6 + 9)虏) * 0x1BB (???)
  1. We change the elements of the top of the modelview matrix

            1/n    2/n    3/n        
            4/n    5/n    6/n        
            7/n    8/n    9/n
    
  2. multiply this new matrix with the normals

  3. multiply 3. by the the light directions

  4. add each elements of 4. together

  5. multiply 5. by the colors of the light

I can notice that the ambient light shares the same value for R, G and B

I can notice that the unique light shares the same value for R, G and B

Completely senseless to me.

  1. looks like a different way I usually see to compute the dot product.
    It looks like doing a horizontal add like you can easily do in SSE plus a hardcoded val for multiply.

Its very much a speed optimization. Smart. I guess its done to save on multiply ops.

http://ok-cleek.com/blogs/?p=20540

I would say step one is calculating some norm of the matrix and, thus, step two is normalizing it.

Compatible norms satisfy for some vector norm. I'm guessing that the idea is to have the results of modelview matrix times vertex normal almost normalized and thus skip normalizing normal vectors (at world coordinates). You get this by using a normalized modelview matrix and normalized vertex normals (at model coordinates).

The result would be faster lighting (normalizing one matrix is faster than normalizing many vectors) but less realistic lighting, as normal vectors won't be exactly normalized.

Ideally one should use a compatible norm, but it seems to me the algorithm is prioritizing ease of calculations. I would say those computations result in the L12 norm. Notice I said L12 and not the more standard L21. There's also the nuance of the hardcoded multiplication.

The rest of the steps seem standard to lighting computation.

Hope this helps.

i believe you could be right :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gonetz picture gonetz  路  14Comments

andrea-petrucci-1975 picture andrea-petrucci-1975  路  8Comments

Roggieh123 picture Roggieh123  路  7Comments

Dorzalty picture Dorzalty  路  20Comments

AriaHiro64 picture AriaHiro64  路  13Comments