[Patch] Textures

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!

[Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 8:06 am

This is a "placeholder" topic for everything related to my work on textures. I'll post here every update about the subject.

This is a very long term sub-project started some time ago in my private build which will mainly focus on:

1) [DONE] Correcting base + mipmap texture uploading to Texture RAM (i.e. all 10 LOD levels + decoding of tiles < 8x8). Patch posted.

2) Emulating, if technically possible with a Radeon HD4850 GPU..., quad textures, or at least a way to alter texture coordinates so that, for example, I can fix Fighting Vipers 2 texture issues in helicopters' search lights during attract demo. Also there's some game (like VON2) that, during the boot process, seems to continuously work with textures. This "thrashes" my video card which makes the whole OS crawl to the point that becomes unusable. Disabling any texture fetch operation in the fragment shader solves the problem. I don't know if it's a driver bug or something else. Work not started.

3) [DONE] Implementing texture filtering and coordinate wrapping modes (repeat, clamp-to-edge, mirrored, etc.) in fragment shader, simulating as much as possible the Real3D behavior. I'm using texelFetch and bypassing as much as possible the OpenGL sampler configuration. The performance impact is almost imperceptible. Patch pending.

4) [DONE] Implementing pixel dilate in alpha channel texels for format-0-and-contour textures, like the Real3D. It's implemented in fragment shader with very little to moderate performance impact. Patch pending.

5) [WIP] Decoding the NPScale polygon bits. This will be very hard, all my attempts so far failed. I've currently done some very basic complementary work, however the data itself needs to be understood. I suspect it's just an offset from a standard lod bias value that, in its turn, is computed from the dFdx and dFdx of the texture coordinates. Patch pending.

6) [WIP] Implementing the SetContourThreshold function. From a last check with Ian it seems that's used by the SDK function getPackedTexel5551() to pre-compute texture alpha channel before being stored. This means the texel RGBA fetched values are the definitive one. The only thing to be done at render time is to discard the fragment when texel alpha value is under a certain threshold which happens to be always 32 / 255. Patch pending.

7) Understanding the SetTranslatorMapEntry function, and where to fetch the values. Work not started.

8) [DONE] Confirming the correct scaling factor for detail textures. Patch posted.


That's all for now. :)


2017-12-12 EDIT: Added translator map to-do
2018-01-13 EDIT: Updates to points 2, 5 and 6
2018-01-15 EDIT: Added point 8
Last edited by HarryTuttle on Mon Jan 15, 2018 7:02 am, edited 7 times in total.
User avatar
HarryTuttle
 
Posts: 609
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Textures

Postby Ian » Mon Dec 11, 2017 9:48 am

i.e. all 10 LOD levels + decoding of tiles < 8x8


Do they exist in memory? That one has long puzzled me. There is space for these textures in the memory sheet, but we aren't uploading them, so they just appear black. I kinda assumed they didn't exist.

SetContourThreshold


I think this is just set in the library, so when it its processing an alpha texture it uses the supplied threshold, to convert it to 1 bit alpha. I don't think it's done on the hardware side, but I could be wrong.

Correcting texture uploading to host GPU (i.e. fix Fighting Vipers 2 tiling problem in helicopters' spotlights during attract demo + correct wrong Emi textures).

Is this not some timing related issue? About the thrashing, check if its the main textures or the mipmaps which are being uploaded

Decode the NPScale polygon bits.

I've no idea about this thing either. The bits never looked valid to me.

Implementing texture filtering and coordinate wrapping modes (repeat, clamp-to-edge, mirrored, etc.) in fragment shader, simulating as much as possible the Real3D behavior.

I had actually thought about this one. It's the only way to properly solve the weird non smooth repeat texturing. My current hack works, but the assumption breaks apart somewhat when used with mipmapping, since half a texel shift is no longer half a texel with mipmaps. But it's mostly okay.

Implementing pixel dilate in alpha channel texels for format-0-and-contour textures, like the Real3D.

What is this thing ? :)
Ian
 
Posts: 1323
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 10:17 am

Ian wrote:Do they exist in memory? That one has long puzzled me. There is space for these textures in the memory sheet, but we aren't uploading them, so they just appear black. I kinda assumed they didn't exist.


Yes, they exist. I've added sub-8x8 tile decoding offsets to deal with them. I'm currently working 1x1 mips, because some game (like Harley) properly uploads them, while others (like Daytona2) do not; i.e. the road texture on far distance become blue, while should be gray. There're little details that come out in some game with properly uploaded textures.

Anyway check this :)


EDIT: removed image embedding and posted as link 'cause it was too large to display in a post.
Last edited by HarryTuttle on Tue Dec 12, 2017 4:30 am, edited 1 time in total.
User avatar
HarryTuttle
 
Posts: 609
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Textures

Postby Ian » Mon Dec 11, 2017 10:26 am

I had to download the image, it was too wide and my browser clipped off the relevant part, but you are 100% right, it's definitely mipmapping down to 1x1 pixel. That's a really good discovery. But puzzling why some games wouldn't send these mipmaps? What's the lowest mipmaps daytona produces?
Ian
 
Posts: 1323
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 10:32 am

Ian wrote:I think this is just set in the library, so when it its processing an alpha texture it uses the supplied threshold, to convert it to 1 bit alpha. I don't think it's done on the hardware side, but I could be wrong.

You mean that the uploaded texture already has the correct 1-bit alpha values? In that case a fixed value of, let's say, 0.5 should be correct in any case; but I found that some textures need 0.5 while others (about 90% of them) need something like 32/255, i.e. the tree foliage, plants, etc. in many racing games.

Also the rounded texel "silhouette", which you can notice at very near distance depends on the 1-bit alpha interpolation which occur at rendering time in screen space and cannot be pre-computed when uploading textures. As always, in this and the other cases, screenshots are better than words. As I have some time I'll upload them to show better what I mean.
User avatar
HarryTuttle
 
Posts: 609
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Textures

Postby Ian » Mon Dec 11, 2017 10:42 am

Well if you look at the constructors for the texture image object, they all take 8 bit alpha. And there is a function that will automatically determine the best alpha format for the hardware. So I assume the contourthreshold is part of that pre-processing step before the textures get uploaded into memory
Ian
 
Posts: 1323
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 10:46 am

Ian wrote:But puzzling why some games wouldn't send these mipmaps? What's the lowest mipmaps daytona produces?


Well, the long explanation is this: I've noticed that not all textures have their mips defined to 1x1, like that memory region is filled with zeros. So uploading them, while theorically correct, will produce black low detailed textures, that's why I'm speculating the game is also sending an information to clamp the maximum LOD for some textures.

In Daytona 2, as reference, I'm checking a large sky texture (768x256) down to its 3x1 mip size. That last one is, I think, 1 pixel shifted to the left, and the gray road 1x1 pixel mip is wrongly placed on the upper row.

Here's the link (I'm not embedding it): https://imgur.com/ivMXcyD
User avatar
HarryTuttle
 
Posts: 609
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Textures

Postby Ian » Mon Dec 11, 2017 10:50 am

768 can't be a valid texture size because it's not a power of two?
It's probably 2 textures packed next to each other
Ian
 
Posts: 1323
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 10:52 am

Ian wrote:Well if you look at the constructors for the texture image object, they all take 8 bit alpha. And there is a function that will automatically determine the best alpha format for the hardware. So I assume the contourthreshold is part of that pre-processing step before the textures get uploaded into memory

That function I believe is for analyzing the dynamic range (min, max values) of the alpha map, and select the appropriate format. At least that's what I understood from the devguide. Yes, it also states that you need to specify the cut off threshold... anyway I'll post some screenshots of reference images I've chosen for my work on textures.
User avatar
HarryTuttle
 
Posts: 609
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Textures

Postby HarryTuttle » Mon Dec 11, 2017 10:55 am

Ian wrote:768 can't be a valid texture size because it's not a power of two?
It's probably 2 textures packed next to each other


Yes, it seems to split into 2 or even 3 of them, 256x256, and work at each one separately. I said that because looking at the map is assembled like a contiguous one.
User avatar
HarryTuttle
 
Posts: 609
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 3 guests