Big optimization idea in bumpmapping pixel shader

This topic is 4766 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

OK, this just came to me(the recent gamasutra article about texture compression sparked this idea). Proposal: Instead of storing a texture + normal map in RGB + XY with calculated Z form, I believe it would be more efficient to store it in RG + XYZ with calculated B form. Explaination: The process of deriving Z from X and Y on a normal map is a fairly complex one. If Z was stored with the normal map, it would mean that the normal map's length component could be adjusted to increase or decrease the brightness of that texel. If the color component is "normalized" so that R+G+B=1 and the XYZ normal was shortened/elongated to compensate, it is possible to remove the B component from the color and calculate it through the equation: B=1-R-G. The math behind it: Traditional method pixel shader code(no preprocessing): XY = XY Z = sqrt(1 - X*X - Y*Y) RGB = RGB * dot(XYZ, lightXYZ) My method: Preprocessing: XYZ = XYZ * (R+G+B) / 3 RG = RG / (R+G+B) Pixel shader code: XYZ = XYZ * 3 RG = RG * dot(XYZ, lightXYZ) B = (1-R-G) * dot(XYZ, lightXYZ) As you can see, this eliminates a sqrt cycle and untangles a mul in the pixel shader. Has anyone thought of this before? Has anyone ever seen an implementation of it? Edit: My math was funky, I fixed it [Edited by - dreddlox on January 2, 2006 5:10:11 AM]

Share on other sites
What about the other 99.9% of cases in which the diffuse/colour texture isn't pseudo-normalized, such that R+G+B=1?

Share on other sites
Quote:
 Original post by Cypher19What about the other 99.9% of cases in which the diffuse/colour texture isn't pseudo-normalized, such that R+G+B=1?

The color texture is pseudo-normalized in preprocessing(ie. non-runtime). When the length of the normal is adjusted, the texel effectively becomes brighter or dimmer to compensate for the pseudo-normalization.
This is basically an adaptation of the YUV color of video codecs(Y=lumi, UV = chroma).

Have an example:
Start with the color RGB={0.5, 1.0, 0.5} and the normal XYZ{sqrt(0.5},sqrt(0.5},0}, the transformed light vector of {1,0,0}
Do my preprocess math to get the new values: RG = {0.25,0.5}, XYZ = {sqrt(0.5}*2/3,sqrt(0.5}*2/3,0}
Calculate that RGB' = {0.25,0.5,0.25}.
Multiply through lighting equation to get pixel value: RGB = (sqrt(0.5}/2,sqrt(0.5},sqrt(0.5}/2}

Preprocess to get RGB={0.5,1.0,0.5}, XY = {sqrt(0.5),sqrt(0.5)}
Calculate XYZ = {sqrt(0.5},sqrt(0.5},0}
Multiply through lighting equation to get pixel value: RGB = (sqrt(0.5}/2,sqrt(0.5},sqrt(0.5}/2}

[size=-1]Edit: I'm tired and not completing my sentences. Lay off >.<

Share on other sites
Why do you have to calculate either? Can't you just store the Z in the normal map along with X and Y (as well as having an RGB texture), or am I missing something here?

Share on other sites
Quote:
 Original post by MonderWhy do you have to calculate either? Can't you just store the Z in the normal map along with X and Y (as well as having an RGB texture), or am I missing something here?

Mainly to conserve memory bandwidth. Almost all texture formats store require that a texel is either 1, 2 or 4 bytes big, this means that an XYZ texture would be stored as an XYZ_ texture(ie. a unused byte on the end), whereas an XY texture would be stored as is, and would take up half the space of the XYZ_. Another possibility is having an RGBX texture and a YZ texture, but that just feels silly.
Admittedly, this would mean my algorithm is most useful in a situation with an alpha channel, eg. RG + XYZA. But combinations of the DXTs can make RG + XYZ worthwhile.

Share on other sites
Quote:
 Another possibility is having an RGBX texture and a YZ texture, but that just feels silly.

Well I'd say it's a matter of whether it'll run at a speed equal to or greater than your method, than whether it feels silly or not.

Plus you can have other info you may want as well stored in textures. E.g. Gloss maps, height maps (for parallax mapping), alpha channels etc.

Sure there will be situations where your method may be worthwhile but remember to consider the other options as well.

• What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 28
• 16
• 10
• 10
• 11
• Forum Statistics

• Total Topics
634102
• Total Posts
3015536
×