I'm still trying to get some bump mapping code working on the GameCube, but unfortunately my work and other things leave me no free time at the moment.
Here is what I've got so far: http://bin.mypage.sk/FILES/bumpmap_demo.zip
The menu is operated from the digital pad:
mode 0: emboss bump mapping. That was easiest to get to work, and should work fine
mode 1+2: ST environment mapped bump mapping, normals are in tangent space. This is causing most problems.
mode 3: XYZ environment mapped bump mapping, normals are in object space. Should work, though I have to set up the indirect tex matrix to rotate normals into light space.
mode 1-3 should use a light probe calculated in a previous pass. For the moment I'm cheating and use a fixed light probe.
If you hold the left shoulder button you can move the camera with the analog sticks, if you hold the right shoulder button you can move the light. (Though the light only makes a difference for the emboss bump mapping at the moment.)
My problems:
- Some state doesn't seem to be correctly updated: After displaying mode 0 you have to go into mode 3 first to get the tangent space correctly set up. Is that something I'm doing wrong? From the documentation I have to disable textures on the tevs that I'm only using to transfer texcoords into the indirect tev unit, but I'm not sure if gx.c updates the registers in that case.
- For the ST bumpmapping to work you need to rotate the tangent space into light space. But the texture matrix doesn't seem to have any effect. Any ideas what I could be doing wrong?
- From the patent I assumed the inputs for the indirect tex unit should be colours R,G and B, though I find red is not available and you get values from "A" instead. Is that what others find as well? That means you're forced to store object-space bumpmap as RGBA, doesn't it?
P.S.: When the patents speak of a "light map", I'd use suggest to use "light probe": Under a light map I understand a map that stores incoming light over a surface, while a light probe would store incoming light at a point.
Bumpmapping problems
Re: Bumpmapping problems
Oh yeah, just a bit of explanation how it should work, so other people don't have to dig through the patents:
Emboss bump mapping
You need a displacement texture, that is a grayscale texture that describes how far a point is away from the polygon surface. That is set up as an input texture for two texture units, which are set up to subtract the second texture from the first. The vertex pipeline has a special mode to add an offset to the texture coordinates of the second texture, that depends on the position of a light source relative to a vertex. As a result, slopes that are angled towards the light source get a bit brighter, and slopes angled away get a bit darker. It's a nice and cheap effect, but it doesn't support different materials or specular effects, and it is limited to a single light source to work properly.
Environment mapped bump mapping
For this you need a normal map, that is a colour texture where each pixel encodes a normal vector relative to the polygon surface. And you need to render a light probe, that stores the outgoing light for each normal. You can probably just render a sphere and resolve that into a texture. The normal is set up as an indirect texture, the light probe is set up as a direct texture. The trick is now to project each normal into a position in the light probe, and use that colour for rendering. If your normals are in object space you should be able to just load the object-to-screen matrix into the indirect texture matrix, in which case you'll need only one direct tev. If your normals are in tangent space (for example if you're using a tiling texture) you need 3 tev, to pass each component of the tangent matrix multiplied by the object-to-screen matrix into the indirect tev, where it is multiplied by the normal. This is something I haven't got working myself, yet.
In my demo I'm mostly cheating by using a fixed light probe and by not rotating the object or camera, so the object-to-screen matrix is identity.
The disadvantage of this method is mostly that local lights don't work, because lights will always be calculated relative to a single light probe. I guess you could try to interpolate several light sources if it is really a problem, though I'd expect for most objects you get away with this.
Dot product bump mapping
The tev unfortunately don't have a dot product operator. But you should be able to set up a dot product manually using several tev units, though I haven't worked out the details, yet. The problem seems to be, that only the "d" component can receive a signed input value.
This would allow local lights, but would obviously be the most expensive.
Emboss bump mapping
You need a displacement texture, that is a grayscale texture that describes how far a point is away from the polygon surface. That is set up as an input texture for two texture units, which are set up to subtract the second texture from the first. The vertex pipeline has a special mode to add an offset to the texture coordinates of the second texture, that depends on the position of a light source relative to a vertex. As a result, slopes that are angled towards the light source get a bit brighter, and slopes angled away get a bit darker. It's a nice and cheap effect, but it doesn't support different materials or specular effects, and it is limited to a single light source to work properly.
Environment mapped bump mapping
For this you need a normal map, that is a colour texture where each pixel encodes a normal vector relative to the polygon surface. And you need to render a light probe, that stores the outgoing light for each normal. You can probably just render a sphere and resolve that into a texture. The normal is set up as an indirect texture, the light probe is set up as a direct texture. The trick is now to project each normal into a position in the light probe, and use that colour for rendering. If your normals are in object space you should be able to just load the object-to-screen matrix into the indirect texture matrix, in which case you'll need only one direct tev. If your normals are in tangent space (for example if you're using a tiling texture) you need 3 tev, to pass each component of the tangent matrix multiplied by the object-to-screen matrix into the indirect tev, where it is multiplied by the normal. This is something I haven't got working myself, yet.
In my demo I'm mostly cheating by using a fixed light probe and by not rotating the object or camera, so the object-to-screen matrix is identity.
The disadvantage of this method is mostly that local lights don't work, because lights will always be calculated relative to a single light probe. I guess you could try to interpolate several light sources if it is really a problem, though I'd expect for most objects you get away with this.
Dot product bump mapping
The tev unfortunately don't have a dot product operator. But you should be able to set up a dot product manually using several tev units, though I haven't worked out the details, yet. The problem seems to be, that only the "d" component can receive a signed input value.
This would allow local lights, but would obviously be the most expensive.
Re: Bumpmapping problems
BTW, it would be nice to know if people got this to build/run for themselves.
Who is online
Users browsing this forum: No registered users and 2 guests