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!

Re: Type conversion

Postby Ian » Thu Oct 19, 2017 7:54 am

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
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Oct 19, 2017 9:50 am

Ian wrote: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.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Oct 19, 2017 10:13 am

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.
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Oct 19, 2017 10:29 am

Ian wrote: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.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby HarryTuttle » Thu Oct 19, 2017 10:39 am

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)
Attachments
diff.zip
(3.31 KiB) Downloaded 78 times
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Oct 19, 2017 10:54 am

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
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

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

Ian wrote: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.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Oct 19, 2017 1:51 pm

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
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: Type conversion

Postby HarryTuttle » Thu Oct 19, 2017 2:49 pm

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.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: Type conversion

Postby Ian » Thu Oct 19, 2017 3:28 pm

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
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 2 guests