Type conversion

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!

Type conversion

Postby Ian » Thu Aug 17, 2017 2:12 am

One for Harry
I changed the normal conversion code (as well as the code for fixed shading) to this

Code: Select all
#define BYTE_TO_FLOAT(B)   ((2.0f * (B) + 1.0f) * (1.0F/255.0f))


Code: Select all
         // Per vertex normals
         if (ph.SmoothShading()) {
            p.v[j].normal[0] = BYTE_TO_FLOAT((INT8)(ix & 0xFF));
            p.v[j].normal[1] = BYTE_TO_FLOAT((INT8)(iy & 0xFF));
            p.v[j].normal[2] = BYTE_TO_FLOAT((INT8)(iz & 0xFF));
         }


from

Code: Select all
p.v[j].normal[0] = (INT8)(ix & 0xFF) / 128.f;


You can see for positive numbers this will effect the length of the normal.
Before for 127 / 128 = 0.99
Now
((127 * 2) + 1 ) / 255 = 1.0

It's only a 1% change, but didn't know if this would effect specular at all?
Maybe the bias you added might not be needed anymore?
Ian
 
Posts: 1220
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Aug 17, 2017 4:29 am

Interesting... I'm gonna try that now and let you know as soon as possible. ;)
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Aug 17, 2017 2:30 pm

Did that effect specular at all?
Ian
 
Posts: 1220
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Aug 17, 2017 2:46 pm

Sorry, I was testing when I noticed I've some problem in my private build with transparent polygons. So I'm currently struggling with some unknown bug. :x

Going from r626 to current at some point broke something and now light math doesn't give me the exact results as before, the bad thing is I don't know what's happened, and happens in some very corner case. :evil:

In particular (left: Model 3, right: Supermodel)
lem24_01.jpeg
lem24_01.jpeg (237.6 KiB) Viewed 653 times

See that highlight? Before it worked perfectly, now has disappeared! It's been like... 4 hours that I'm trying to fix that.
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Aug 17, 2017 3:22 pm

Shader debugging is hard!
Not like you can step through it with a debugger
Ian
 
Posts: 1220
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Aug 17, 2017 3:29 pm

Damn! :x

I hope to try tomorrow the type conversion thing, until i fix this madness I cannot trust any more shader math, let alone specular highlight, it seems to be something that blows up at a particular light/normal angle, but who knows?

I hope to not have hit another driver bug, my old Radeon HD4850 is considered legacy from 2014...
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Aug 17, 2017 3:51 pm

I'm using a gtx 960
a 2014 card shouldn't be too old at all .. I mean we are only using gl 2.1
Ian
 
Posts: 1220
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby Ian » Thu Aug 17, 2017 3:56 pm

One way of debugging shaders if you are really struggling is to dump the value out as the output colour
Ian
 
Posts: 1220
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Aug 17, 2017 3:58 pm

Ian wrote:One way of debugging shaders if you are really struggling is to dump the value out as the output colour


Yeah, infact is what I'm doing to see what's happening...
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby HarryTuttle » Thu Oct 19, 2017 6:44 am

Finally, problem solved! :)

It was again an issue with the polygon header hash computation and the caching mechanism. Like happened recently with a fog issue and VON 2, this time it was necessary to insert also the bits relating to shininess and specular coefficient into the mix.

Many of the weirdness present in LeMans24 are now fixed. The few remaining very little quirks (single polys) are, maybe, related to proper quad poly rendering. For example the following case is now solved and back to the same behavior as the original hw:

(Left = Model 3, Right = Supermodel old incorrect rendering)
Image

I'll post soon a patch.


P.S.
Hey Ian, since it's clear that polygon header attributes remain constant at (obviusly) polygon level but not at mesh level, either we expand the hash to be much more that 64 bits (to include as many attributes as possible) or we disable the caching mechanism altogether but, I think, with a huge performance hit. What do you think?
User avatar
HarryTuttle
 
Posts: 558
Joined: Thu Mar 09, 2017 8:57 am

Next

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 2 guests