Supermodel Forum

So if I understood the hashing somewhat serves as replacement for an "if-then-else" condition in shader. Grouping identical polygons, based on their attributes (and hash), will make a single, group-level, compiled version of a shader. Is that right?

I've read that older GPUs had performance problems when branching, modern (OGL > 2.1) shader compilers are already optimized to compile only one version of the shader when the variable, in an "if" statement, is a uniform. Do you confirm this or has nothing to do with our situation?

One last thing: we need to expand the hash bits anyway, since there're attributes that aren't included, but when correctly emulated we could need them. I'll later check for polygon header bits not included. So for the time being we can just create the remaining fetching function in <PolyHeader.cpp> for future use.

The first thing is does is to split the model by texture number, which is required if we want to bind the correct textures to the model :p Every polygon with the same number, hopefully has the same hash ID, so gets added to the same entry in the map

sMap[hash]->polys

Ian, this is ideally what I'd hash:

Code: Select all

hash |= (header[0]);                      // bits    0-31
hash |= (header[1] & 8) << 32;            // bits   32-39
hash |= (header[2] & 8) << 40;            // bits   40-47
hash |= (header[3] & 8) << 48;            // bits   48-55
hash |= ((header[4] >> 6) && 26) << 56;   // bits   56-81
hash |= ((header[5] >> 8) && 24) << 82;   // bits  82-105
hash |= (header[6]) << 106;               // bits 106-137


I've left out the polygon normal XYZ terms and texture UV coordinates

If you made a hash out of
(header[0]);   
every poly that is numbered would receive a new hash value. So if you had 10k polys, you'd have 10k draw calls :p
Not sure that's what u want lol

Ian wrote:every poly that is numbered would receive a new hash value

I inserted polygon number because I was sure they aren't always used, I remember they are generally zeroed, but have to recheck. We can exclude them however, that would save us 15 bits. We'll still need 125 bits in total.

Some games definitely use them. Virtua fighter? not sure off the top of my head
But I see what you are trying to do, just simplify the code and yeah it's probably a smart idea

Harry, Ian.
There is something strange in using R675

Fighting viper 2 I found out when I was playing Grace Character.
There is a difference in the reflected light of the chest appearing in the victory pose.

Compared with the r674, the r675 reflected light differs.
It is too weak.

save here
https://drive.google.com/file/d/0Bw8OrQ ... sp=sharing

And the Harry
LA Machine Guns Intro
I have a symptom that the American flag does not display properly.

The comparison shots on the previous sun shading posts have a normal screen shot.
I wonder if it has been modified only in the internal version.

YoYo09 wrote:Compared with the r674, the r675 reflected light differs.
It is too weak.

Technically, with the last revision, specular highlight values should be passed from polygon headers to shaders in the right way. As expected, however, this changed something visually. This means that the old coefficients used in fragment shader need an update to better follow the arcade counterpart.

I'm currently working on this and the results, in my internal build, are encouraging since are even more faithful to the real thing. I'll post an update to the specular code by this weekend.

Regarding Fighting Vipers 2 we still need some good direct capture footage to compare with, the best I found on YouTube are captured from an old videotape (!). I'll exclude the console ports (like Dreamcast) since there's always something different from Model 3 versions.

YoYo09 wrote:LA Machine Guns Intro
I have a symptom that the American flag does not display properly.

The comparison shots on the previous sun shading posts have a normal screen shot.
I wonder if it has been modified only in the internal version.

You're right and it appears that's an issue someone (I think Bart) posted some time ago. I never noticed because I always play games at original resolution. Pushing to hires it shows up in both the official and my private builds.

I'll investigate on this as soon as possible but I think that's a detail texture issue: it's fetched when it shouldn't, this is the "offender":

By the way this game has also another bug related to a tiny missing texture during attract intro. I've posted about this in another thread.

The flag issue is an odd one. There is a microtexture applied to it and you can see it in supermodel. But on the real model hardware it seems microtextures only show up with mimap level 0. To properly emulate this you'd need to only run at the original 496x384 resolution (if you run at a higher resolution the minification filter won't kick in, at the same place), then we would have emulate exactly how the hardware picks the correct mip levels. I think Harry maybe has something close to this in his builds, but it's not something I've added. I may add it sometime later in the future, but it is highly resolution dependent.

I don't know about the specular differences. But my guess would be the offset coefficients that Harry added maybe won't be needed anymore?

By the way this game has also another bug related to a tiny missing texture during attract intro. I've posted about this in another thread.

You did? Probably something timing related. The textures seems to show up very late in that game.

Ian wrote:But on the real model hardware it seems microtextures only show up with mimap level 0. To properly emulate this you'd need to only run at the original 496x384 resolution (if you run at a higher resolution the minification filter won't kick in, at the same place), then we would have emulate exactly how the hardware picks the correct mip levels.

Very true! Ideally if we could be able to force the original hardware to run at higher resolution (Real3D could do it as far as i know) we'd confirm this strange behavior, unless there's a particular command to set the minimum/maximum lod texture for a particular polygon or texture. In this case it could be set for the micro texture to not show up for a particular lod level, but I doubt it works this way.

Ian wrote: I think Harry maybe has something close to this in his builds, but it's not something I've added. I may add it sometime later in the future, but it is highly resolution dependent.

I've implemented shader level tri-linear filter with lod manipulation/selection for both base and micro texture, just for experimenting and implementing the lod-0-only micro texture with its fading effect toward lod-1, as hardware does. But as you said it's still resolution dependent 'cause as soon I double game resolution the problem shows up in my build too. The only way to hide that oddity is to manually alter the micro texture lod offset.

Ian wrote:I don't know about the specular differences. But my guess would be the offset coefficients that Harry added maybe won't be needed anymore?

I've re-implemented your solution posted at the beginning of this thread, so I've substituted the normal math with yours to truly saturate the min/max values. Then I removed those ugly offsets from specular math in shader but I had to alter the remaining coefficients as they became really wrong. The current numbers I found don't make much sense anymore, but they work well (albeit only for smoothed polygons, flat ones are still wrong). I'll post later the updated patch.

Ian wrote:You did? Probably something timing related. The textures seems to show up very late in that game.

Here I posted something about missing textures in L.A. Machine and LeMans24. They don't simply show late, they don't show at all. But, yes, it could be timing-related like Fighting Vipers 2 with the old frame-sync logic. Maybe there are other cases as well which I'm not aware of.