Type conversion

[Ian]

Some of those attribs such as shininess could be passed as vertex attributes, then you don't need to split the mesh based upon changes.
But it should be enough to just add them to the hash function. I actually meant to add them, I just never got that far :p

[HarryTuttle]

Some of those attribs such as shininess could be passed as vertex attributes, then you don't need to split the mesh based upon changes.

Interesting... in a process of shader modernization, in theory, it could be useful to pass every vertex/polygon-level attribute as shader vertex attribute, so we always get the correct values. However we've to pay attention to the number of attributes limit as defined by implementation...

Then a "mesh" could be just a model node, as called in the Real3D devguide.

[Ian]

If you look at how the meshes are split up in the superdebugger or something, you'll often see totally unrelated geometry grouped together by it's world position. One 'mesh' might references up to say 10 textures, because it's actually fragments from different parts of geometry grouped together. I'm pretty sure it's grouped like this is entirely due to culling.

[HarryTuttle]

I'm pretty sure it's grouped like this is entirely due to culling.

Yeah, this seems to be confirmed in the devguide, pag. 47. So basically a "mesh" is, for Real3D, a culling node. No matter what it contains.

[HarryTuttle]

Quick Fix to polygon header hashing function.

Changelog:

Code: Select all

* [COSMETIC] some indentation adjustment;
* [COSMETIC] change "(UINT64)((header[6] >> 11) & 0x1F)" to "(UINT64)LightModifier()" as the function is already defined;
+ [ADDED] some other used bits returned by these functions:
  FixedShading()
  TranslatorMap()
  Layered()
  SpecularValue()
  Shininess()
  MicroTextureID()
  MicroTextureMinLOD()
  ((header[3] >> 6) & 3) (= uv smooth bits)


[Ian]

That's a nice patch
is there anything we are really missing from it? Since I see you hit the 64 bits
We could make a new type with more bits if required, just have a struct with another byte or int or however much space is needed. Then write a bool comparison operator for it

[HarryTuttle]

We could make a new type with more bits if required, just have a struct with another byte or int or however much space is needed. Then write a bool comparison operator for it

That's, more or less, what I was thinking about. Currently I've not any other bit to add, but things may change soon as testing continues.

By just looking at well-known and decoded polygon header bits, we would run way over the 64 limit just now. So I think it's better to add a new type, in preparation for future inclusions.

[Ian]

Not totally sure we will need more? I mean the 7 word header will never get larger :p
Also I inlined some of the functions .. because they were returning floats. Casting to int will either truncate the values to 0 or 1 which isn't particularly handy

[HarryTuttle]

I meant the current situation is we saturated the 64 bit space by choosing only a subset of attributes. If we want to be sure we can just blindly compare all 7*32 bits of a polygon header.

But what about, for example, the normal coordinates (header 1,2,3 >> 8)? Should we have to compare even those?

I was thinking about comparing an array of 2-3 UINT64 elements (so excluding normals data), and make a bool comparison with the older/last array. I don't know if it's efficient, however. Maybe there are more elegant ways to make such a comparison.

[Ian]

Every time a new hash is generated it creates a new draw call, and the uniform memory as relevant is updated. Polygons with the same hash will get automatically sorted and drawn in the same draw call.
Don't need to split the meshes based upon the normals, as these are passed as vertex attributes. You could in theory pass everything as vertex attributes. (The legacy renderer more or less worked like that, it also didn't need to split meshes based upon texture type because it only had 1 giant mega texture.) I think on average you get 16x vec4s to work with. But the downside of that is its pretty expensive in the fragment shader.

If you do this in a fragment shader based upon a uniform
if(someVariable) {

}

The compiler when loading a shader can actually compile multiple different versions of a shader based upon different potential paths. Since a uniform in memory is the same for every polygon in a draw call, the GPU can pick the version of the shader with if(someVariable) removed completely and just execute that path without having to check it. If you are rendering at 1080p that is 2 million conditionals removed if you are touch every pixel :p