Cubemap to Fisheye

Hi. I am writing a program that converts cubemap to fisheye. The problem that i face is that i cann’t (or more correct i don’t know how to) make the bordering pieces of the cubemap (that are mapped on the sphere) look attached completely and instead i use :


but then the bordering sides are like dark lines which is not nice as an effect. Can anyone help how can i make it look solid and not broken?

PS: Any help is good!!!

The dark lines come from filtering in the texture border color which defaults to black.
You need to do
to keep texture filtering from accessing the texture border color and you don’t need to setup the WRAP_R component because the cubemap’s final texture lookup is actually only 2D.

I tried it. The results are indeed better, but still the bordering sides of the 6 cubic sides are coloured . Is there any way to make it disappear?

Sorry, that should have completely solved the issue of accessing the texture border color.
If you still see problems they are something different and you need to provide more precise descriptions or better an image of what the remaining problem is. => Input and output images, rendering calls, etc. (OS, hardware, driver versions, in case it’s a bug.)

Summary of my system:

Computer Type: ACPI Uniprocessor PC
Operating System: Microsoft Windows XP
OS Service Pack: Service Pack 2
DirectX: (DirectX 9.0c)
CPU Type: AMD Athlon 64, 2000 MHz (10 x 200) 3200+
Motherboard Name: MSI K8T Neo2-F v2.0 (MS-7094)
Video Adapter: NVIDIA GeForce 6600 GT (128 MB)
3D Accelerator: nVIDIA GeForce 6600 GT AGP
System Memory: 1024 MB (PC3200 DDR SDRAM)

Could you send me your email? So that i can send you the images?

The way people present images here is to put them onto some web page (your own or a free image server) and post the link.
The full reply form has a button for “Enter an image” which opens a http address dialog.
If it is 80*80 pixels or smaller you could upload it as user icon. :wink:


PS: I magnified the fisheye, so that you can see the lines. Although a bit difficult, to see perhaps they still exit.

I meant, they still exist

The cubemap cross image has those lines as well!?
How did you render that one?
Or is that the input image? Then it’s broken from the start.
Check your upload routine.
Watch your PixelStore alignments.
Use another cubemap.

More debugging:
Do you use mipmaps?
How did you generate them?
Do you get more corruption the smaller you render your fisheye?

If you explicitly set your texture border color with glTexParameter to a fancy color like magenta or green for your image, does the resulting rendering show any of that?
It shouldn’t and the default border color is black, your lines are white so I really would blame the upload.

You could do a glGetTexImage and look at the data OpenGL has.

Use a tiny handmade cubemap texture, like six 1x1 images with the base colors red, green, blue for the positive and the inverse colors cyan, magenta, yellow for the negative faces.
There shouldn’t be any white or black artifacts between the faces.

Sorry for being late. Well the cubemap cross is the input image. I tried other cubemaps and yet the results are pretty much the same. What i can not understand is what the difference between glGetTexImage and glReadPixels is

With glGetTexImage you can read out the texture directly and look if what you think you uploaded matches exactly what OpenGL has in its texture to verify that there isn’t a problem in your loader.
If other cubemaps have the same problem that still doesn’t mean your loader is right.
If you actually grabbed the six cubemap faces from that cross image, it looks like you simply picked up white pixels from around the textures as well. That should be totally simple to verify and debug.

I asked the right questions. You just need to go through them one by one.

I know that cubemap from other demos and that exists as six individual faces and works.
BTW, for lots of other working cubemaps, just go to

What about downloading a simple cubemap reflection example which works to compare that with what you did?
You’re using a GeForce and this is the first hit when searching for “simple cubemap” on NVIDIA’s developer site:
(Boy, that’s from 1999! :smiley: Means your stuff simply needs to work and is not really an advanced topic.)
That should answer almost all about cubemaps you ever wanted to know. Sources at the bottom.

i use the theory that is in the site of nvidia that you gave me. Though it works perfectly when it comes to the use of 6 seperate pictures, there is still the problem when it comes to the use of a single image. Although i had (manually at least for each image) solved the problem of the unwanted white pixels, the bordering lines remain.

see this:

Try using different texture address modes, i`ve had a similar problem and it was solved with GL_CLAMP_TO_EDGE

i did try that. The bordering lines are (sort of) more homogenous in colour (compared at least with the colour of the rest), bust still the lines are a bit different.

Though it works perfectly when it comes to the use of 6 seperate pictures,

Means your rendering and texture parameter setup is ok.

there is still the problem when it comes to the use of a single image.

Still means, either the input image is wrong from the start and has those white lines already (=> Use a correct input image then!),
or your loader which separates the horizontal or vertical cross image to individual cubemap texture faces is defective (=> Fix it!)
You never explained or showed any code how you handled the input image.
It is trivial to take a horizontal or vertical cross image with a cubemap and separate the individial faces for the upload as the six level of detail 0 cubemap textures if the input data is correct

here is the code that i use in order to load the cubemap (in order to take the 6 faces):

void fisheye_projection_2(){
int i=0;

glPixelStorei (GL_UNPACK_ALIGNMENT,   1);
glPixelStorei (GL_UNPACK_SKIP_ROWS,   0);
	glPixelStorei (GL_UNPACK_SKIP_PIXELS, 0);
	glPixelStorei (GL_UNPACK_SWAP_BYTES,  0);
glPixelStorei (GL_PACK_ALIGNMENT,     1);
glPixelStorei (GL_PACK_ROW_LENGTH, image->width/4 );

data2[i]=(unsigned char*)malloc (image->componentsimage->width/4image->height/2*sizeof(unsigned char));








of course there is still the problem that every time i use a different input cubemap picture i may pick up pixels outside the 6 cube faces.

Just look at the cubemap you presented as input image.
If that is the original, the faces are neither correctly aligned nor power-of-two.
And your code above allocates 1/3 too much data per face, but that shouldn’t matter after you read in crap data.
Garbage in, garbage out. Fix your input image(s).

i checked the image and the dimensions are 800x600 (therefore not power of 2). In this case, what should be done?

Changing the parameters in glReadPixels or even something else?

Your input image is a horizontal cross cubemap, so a 800x600 input image means six 200x200 cubemap faces.
The non-power-of-two issue is just a problem on hardware which doesn’t support NPOT textures. Since your rendering works, and GeForce 6 supports NPOT that is not an issue on your system.

Again, I looked at your input image in a paint program and used a crop tool on the center image to see how big it is and noticed that for example the bottom image is too far to the right compared to the top image, and the left is also not matching the right in vertical placement. Means your input image is garbage. Period.
No wonder that you captured white borders if that is your original data.
I don’t know where you got that image from or why you use a horizontal cross layout at all. From demos I know that same cubemap comes as six 256x256 images. You said yourself that individual images worked perfectly so either use that or a correct input image to match your (correct) glReadPixels coordinates.

Which crop tool did you use to find all that information? It seems pretty useful.