Jump to content
  • Advertisement
Sign in to follow this  
bartman3000

OpenGL Implementing a Cube Map Lookup Function

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Suppose I did not want to use the cube mapping functionality that is built into a graphics API (i.e. samplercube in GLSL) and wanted to implement my own cube mapping, how would I go about doing this?

Note that I do not actually plan on doing this for any practical reason, I just want to understand whats happening behind the scenes. Here is my guess:

The lookup coordinate used with a cube mapping sampler is a direction vector from the center of the cube which goes in the direction you want to sample from. Using this vector, I would perform a ray - plane intersection test for each of the 6 faces on the cube to figure out which plane the ray intersects. I would then use the point of intersection on the plane as the 2D texture coordinate.

Is this how graphics APIs perform cube mapping or do they have a more clever way of doing it?

Interestingly the OpenGL wiki says the look up vector does not need to be normalized, does this mean the vector gets normalized by GLSL internally or do they use a completely different method from what I described?

Thanks

Share this post


Link to post
Share on other sites
Advertisement

Internally a sample of a cubemap is implemented this way (intrinsics will be used on consoles):

float2 sampleCube(
    const float3 v,
    out float faceIndex)
{
	float3 vAbs = abs(v);
	float ma;
	float2 uv;
	if(vAbs.z >= vAbs.x && vAbs.z >= vAbs.y)
	{
		faceIndex = v.z < 0.0 ? 5.0 : 4.0;
		ma = 0.5 / vAbs.z;
		uv = float2(v.z < 0.0 ? -v.x : v.x, -v.y);
	}
	else if(vAbs.y >= vAbs.x)
	{
		faceIndex = v.y < 0.0 ? 3.0 : 2.0;
		ma = 0.5 / vAbs.y;
		uv = float2(v.x, v.y < 0.0 ? -v.z : v.z);
	}
	else
	{
		faceIndex = v.x < 0.0 ? 1.0 : 0.0;
		ma = 0.5 / vAbs.x;
		uv = float2(v.x < 0.0 ? v.z : -v.z, -v.y);
	}
	return uv * ma + 0.5;
}

As you can see, normalization is implicit (see last line).

There are reasons why you would want to sample a cubemap manually in this manner, in particular for the use of shadow atlases (putting all your shadows on a single texture so that applying shadows to the scene can be done in a single pass).
This is what we did in Final Fantasy XV, and you can see an example of it in DOOM.


L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

Damn that is clever.

Seems like it just checks to see which direction the ray points in the most to figure out the face index.

But in order for the UV calculation to work, the ray has to be normalized though, right? Here is my attempt at trying to answer that question:

// Super simple cube map fragment shader written in GLSL
#version 400

uniform samplerCube cube;

layout(location = 0) out vec4 FragColor;

void main()
{
	FragColor = texture(cube, vec3(0, 1, 0) );
}

This shader generates the following assembly:

!!NVfp5.0
OPTION NV_gpu_program_fp64;
OPTION NV_bindless_texture;
 PARAM c[1] = { program.local[0] };
LONG TEMP D0;
OUTPUT result_color0 = result.color;
PK64.U D0.x, c[0];
TEX.F result_color0, {0, 1, 0, 0}.xyxw, handle(D0.x), CUBE;
END 

I was expecting to see that black magic math you linked in the shader in the assembly, but it seems like its contained within the TEX instruction.

Do you know how I can find out more about how the texture lookup instruction is implemented? I skimmed the documentation for NV_gpu_program5 but couldn't find anything. 

Thanks!

Share this post


Link to post
Share on other sites
You could check the assembly from an AMD GPU, AFAIK they don't have hardware cube map sampling, just a instruction that gives the face index.
Normalizing is not necessary, instead you divide the projected 2D plane coords by the distance from the plane. Look at L.Spiros code closely.

If this is disappointingly easy for you, you could look up how to calculate the projected area, which is more interesting and important for accurate lighting :)
http://www.rorydriscoll.com/2012/01/15/cubemap-texel-solid-angle/

Share this post


Link to post
Share on other sites

Unfortunately I don't have access to an AMD card.

That was a great article thanks for the link! On an unrelated note (I should probably make a new thread for this), any idea why the derivative map idea hasn't caught on? Seems like a gift from the gods based on that article.

Edited by bartman3000

Share this post


Link to post
Share on other sites

Unfortunately I don't have access to an AMD card.
That was a great article thanks for the link! On an unrelated note (I should probably make a new thread for this), any idea why the derivative map idea hasn't caught on? Seems like a gift from the gods based on that article.


I can only second that question :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!