Indirect texturing implementation question

[Danny7704]

Hi there,

I'm implementing a 2D normal mapping algorithm using per vertex bump offsets. To do so, I have to use indirect texturing to lookup the 2D normal map and then, per pixel, add the bump offset.

In concept this works in Dolphin. I'm using DevKitPro and extended one of the nehe tutorials. However, I'm experiencing some difficulties with the 3x2 matrix transform and and bias settings (when I fiddle around with it I do get some expected results, but I don't understand fully what it exactly does).

My question is, what exact calculation does the 3x2 matrix perform on STU components (or, what did you guys implement and is it conform actual Flipper specs). And does the bias setup (GX_ITB_ST) work correctly (i.e. does it subtract 128 from the S and T inputs)?

Thanks in advance,

Danny

[ector]

We (well, more like, Zerofrog and Donko) have implemented most of the known functionality of the indirect unit. But it still doesn't work correctly in all games so you can't rely on Dolphin's implementation being correct - if it works on the real Wii, and it doesn't work in Dolphin, it would be great if you could figure out why and fix it Look at the source code of the shader generators in Source/VideoCommon in the Dolphin source tree.

[Danny7704]

Thanks for the quick reply. I'll have a look at svn. I haven't looked into running it on my Wii yet. To be honest, this is my first time using hw 3D, implementing normal mapping and doing it for nintendo, so I still have to learn a lot But if your implementation supports EMBM correctly my normal mapping algorithm should work as well.

Any chance you know what I could do best to run it on an actual Wii? I would like to invest in a modded Wii that I can wire up directly to my computer, or, at least, a Wii that could execute directly from a sd card or so. I want to keep my current Wii 'stock'.

[Danny7704]

Hey Ector,

I ran into this in PixelShaderGen.cpp, line 571 from the current svn trunk:

Code:

// bias        
if (bpmem.tevind[n].bias != ITB_NONE )            
  WRITE(p, "indtevcrd%d.%s += %s;\n", n, tevIndBiasField[bpmem.tevind[n].bias], tevIndBiasAdd[bpmem.tevind[n].fmt]);

I'm not familiar with this stuff, nor do I have a clue of what magic you guys are performing, but I would have expected that last fmt parameter should be bias.

From what I can make up from your code, fmt seems to hold the texture format (i.e. 3-8 bit).

I don't have Visual C++ (I mostly do Java dev), so I can't compile it to try out what happens if I replace that latter fmt parameter with bias. So perhaps you could ask Zerofrog and Donko to have a look at it?

regards,

Danny

[ector]

If you look at the comment at line 346:

static const char *tevIndBiasAdd[] = {"-128.0f", "1.0f", "1.0f", "1.0f" }; // indexed by fmt

well .. it seems whoever wrote it knew what he was doing

[Danny7704]

Yeah you are right. I was too quick... The patent says depending on 8bit or other input formats, it uses respectively -128 or 1. I just thought that the shader would be set up for the various bias modes as well...

But I also found what I was looking for; the bump unit performs two dot products to generate s and t coordinates