Depth Cueing and Transparency

It looks more like "fog", than tranparency. Notice that the mountains on the left obscure the clouds behind them. Anyway, to have transparency, you add an "alpha channel" to the texture. The alpha channel value determines the transparency of the texel (0 = completely transparent, 1 = completely opaque). Look up "alpha blending" for more information on how to implement transparency.

I can write the function for evaluating the actual RGB parameters of a texel given its own RGBA parameters (hard-coded into the texture) and the RGB parameters of the pixel behind it, but how can I obtain the latter?

Additionally, while this tutorial is no end of help, it includes a variable n in its final equations for generating the apparent RGB values but never explains what n is.

Quote:

Original post by Quick Man I can write the function for evaluating the actual RGB parameters of a texel given its own RGBA parameters (hard-coded into the texture) and the RGB parameters of the pixel behind it, but how can I obtain the latter?

I thought you are doing a software renderer. If you are not, then you can leave all the computation and blending to the hardware. Just select the texture and set up the blending parameters.

Quote:

Original post by Quick Man Additionally, while this tutorial is no end of help, it includes a variable n in its final equations for generating the apparent RGB values but never explains what n is.

Unless he is doing something clever, "n" should be "alpha":

    new_r = ((r1*(alpha*256/255)) + (r2*(256-(alpha*256/255)))) / 256;    new_g = ((g1*(alpha*256/255)) + (g2*(256-(alpha*256/255)))) / 256;    new_b = ((b1*(alpha*256/255)) + (b2*(256-(alpha*256/255)))) / 256; 

But, I think I would use a simpler version which also is faster and has better precision:

    new_r = ( r1*alpha + r2*(255-alpha) ) / 255;    new_g = ( g1*alpha + g2*(255-alpha) ) / 255;    new_b = ( b1*alpha + b2*(255-alpha) ) / 255; 

Note that these computations require at least 16-bit unsigned values.

These are the equations I came up with today to get a value for a pixel (R1,G1,B1) with alpha value A in front of a second pixel (R2,G2,B2).

R = R2 + A(R1 - R2)
G = G2 + A(G1 - G2)
B = B2 + A(B1 - B2)

A is the alpha value, which when using depth-cueing as shown in that screenshot I can calculate as a function of Z for every point (X,Y,Z) relative to the camera, defined as (0,0,0). (This presupposes of course that I'm simulating movement of the camera by translating all polygons in the opposite direction. Z may well end up being something more interesting, like the average magnitude of the vectors from the camera to the vertices of the polygon.)

The picture you are referencing does not use transparency for depth-cueing.

Transparency for depth-cueing is not likely to work very well. Imagine that there is an object behind a mountain in the distance. You want to be able to see the object through the mountain?

Fog is used for depth-cueing in that picture, not transparency.

I wonder if that makes the job simpler, since one can simply assume the fog to be a certain colour and alpha blend the texture with the colour using the relationship between Z and A.

However, the image also shows the clouds and a bit of a curved shadow through the mountain, which implies either that it uses the right section of that background alpha-blended with the original texture of the polygon or that it does in fact use transparency - fog would be a nicer effect to use since it requires less work and produces a nicer look.

Using the fog would require using the rotated polygon as some sort of mask to grab the correct section of background and distort it for use as a texture after alpha-blending with the original texture. This is about as much work as is put into transparency if not more.

How can I save time, and have I gone about this the wrong way?