| | |
Applying texture to sphere turns it blue
Thread Solved |
Your palette is flipped!
Red is Blue and Blue is Red. Green is fine!
You're using a 24-bit BMP and those are oriented Blue, Green, Red, however the frame buffer is Red, Green, Blue!
I usually use TGA's so I'm not sure if you need to swap the texture or if Glut is suppose to do it!
Red is Blue and Blue is Red. Green is fine!
You're using a 24-bit BMP and those are oriented Blue, Green, Red, however the frame buffer is Red, Green, Blue!
I usually use TGA's so I'm not sure if you need to swap the texture or if Glut is suppose to do it!
Last edited by wildgoose; Jul 8th, 2009 at 4:59 am.
Okay looked at your BMP loader and noticed a big problem. I went into one of my full blown BMP loaders and twiddled yours specific to 24-bit RGB bitmaps.
Problem #1 - you were treating header data as pixel data!
Problem #2 - BGR vs RGB
Problem #3 - You had to hardcode your bitmap resolution instead of using the values set int the bitmap.
This is more like a hack but it'll fix your bitmap issue!
Note that I left your width, height, and depth to be passed in to the function but I actually ignore them as they are read from the file itself!
Problem #1 - you were treating header data as pixel data!
Problem #2 - BGR vs RGB
Problem #3 - You had to hardcode your bitmap resolution instead of using the values set int the bitmap.
This is more like a hack but it'll fix your bitmap issue!
Note that I left your width, height, and depth to be passed in to the function but I actually ignore them as they are read from the file itself!
C Syntax (Toggle Plain Text)
// // BMP version 3.x header // #pragma pack(1) typedef struct Bmp3XHead_Type { unsigned short ImageFileType; // File Identifier (always 0) unsigned int FileSize; // Size of files in bytes unsigned short Reserved[2]; unsigned int ImageDataOffset; // Start of image data offset } Bmp3XHead; #pragma pack() // // BMP version 3.x informational header // #pragma pack(1) typedef struct Bmp3XInfo_Type { unsigned int HeaderSize; // Size of this header unsigned int Width; // Width of image unsigned int Height; // Height of bitmap in scanlines unsigned short Planes; // # of color planes unsigned short Depth; // # of bits per pixel unsigned int Compression; // Type of compression unsigned int ImageSize; // Size of bitmap in bytes unsigned int HRes; // Horizontal Resolution in pixels/meter unsigned int VRes; // Vertical Resolution in pixels/meter unsigned int nColor; // # of colors in image unsigned int nColorCnt; // Number of important colors in palette } Bmp3XInfo; #pragma pack() void load_texture ( char *filename, int width, int height, int depth, GLenum colour_type, GLenum filter_type ) { GLubyte *texture ; FILE *file; file = fopen( filename, "rb" ); if ( file == NULL ) printf("File not found: \n", filename); Bmp3XHead head; fread( &head, sizeof(head), 1, file ); if ( 0x4d42 != head.ImageFileType ) { fclose(file); return; } Bmp3XInfo info; fread( &info, sizeof(info), 1, file ); width = info.Width; height = info.Height; depth = info.Depth; if (depth != 24) { fclose( file ); return; } depth >>= 3; fseek( file, head.ImageDataOffset, SEEK_SET ); // Start of pixels! texture = (GLubyte *) malloc ( width * height * depth * ( sizeof(GLubyte)) ); if (texture == NULL) { printf ( "Cannot allocate memory for texture\n" ); fclose ( file); exit ( 1 ); } fread ( texture , width * height * depth, 1 , file ); fclose ( file); // Swap blue & red GLubyte *pix, *pixEnd, col; pix = texture; pixEnd = texture + width * height * depth; while( pix < pixEnd ) { col = *pix; *pix = *(pix+2); *(pix+2) = col; pix += 3; } // Set Filtering type glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, filter_type ); glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, filter_type ); // Set Texture Evironment glTexEnvf ( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE ); // Build Mipmaps gluBuild2DMipmaps ( GL_TEXTURE_2D, colour_type, width, height, colour_type, GL_UNSIGNED_BYTE, texture ); // Free up the array free ( texture ); }
Last edited by wildgoose; Jul 8th, 2009 at 5:50 am. Reason: tab adjustments
•
•
Join Date: Jan 2008
Posts: 79
Reputation:
Solved Threads: 0
Mad respect wildgoose. I talked to my professor last night about my issue and we were on to what you managed to figure out. The problem definately lied with the images, more specifically the color indexes. When it stopped being an issue for me was when i decided not to use images in bmp format but rather use raw images. I mentioned I initially had an issue with images in said format and that was because the program i was using to convert my images was not doing it properly. I decided to use photoshop, and i should have done that in the first place, and i had working textures.
I'll definately try out the great fix, genius material btw, you posted for me when i get back from work and see how that turns out. Thanks a lot for analyzing my issue and helping me fix it!
+1!
I'll definately try out the great fix, genius material btw, you posted for me when i get back from work and see how that turns out. Thanks a lot for analyzing my issue and helping me fix it!
+1!
no problem, just send the check to............
When I looked at it late last night I noticed again that the image seemed inverted blue vs brown. I scaled mars large, and when I applied the earth texture onto mars, water was brown, ground was blue. Then applied the moon texture onto mars, it appeared correct. That was clue #1 & 2.
I created a solid red texture and it showed up blue. I knew what was wrong but then tested the blue texture and it showed up red confirming my suspicion. And of course green was green. Thus the first posting of red and blue were swapped. I don't use BMP's I use TGA's but I remembered the BMP's are in BGR order, not RGB.
I then wrote the red-Blue color swapper and it didn't work. That's when I looked at your BMP loader more closely and then noticed the other problem. NO HEADERS. You were trying to treat the BMP like a raw file. I cut in the headers, overrode your inputs {w, h, d} with those from the file, and it came up like it was suppose to!
By the way. Move the image types within the planet functions themselves, don't keep them outside. And unless you're planning on trying to show earth textures on Jupiter, etc. Don't pass in the texture enum to get the texture name. Hard code them within the individual planet function's texture name lookup.
There are other cleanup issues, but just think, "How can I make this look more clean!" Once functionality is working. Save a copy of the project, then continue making changes. Archiving the project has to do with having a backup if cleaning goes terrible wrong. You'll have a fall back point to the last know good working version.
When I looked at it late last night I noticed again that the image seemed inverted blue vs brown. I scaled mars large, and when I applied the earth texture onto mars, water was brown, ground was blue. Then applied the moon texture onto mars, it appeared correct. That was clue #1 & 2.
I created a solid red texture and it showed up blue. I knew what was wrong but then tested the blue texture and it showed up red confirming my suspicion. And of course green was green. Thus the first posting of red and blue were swapped. I don't use BMP's I use TGA's but I remembered the BMP's are in BGR order, not RGB.
I then wrote the red-Blue color swapper and it didn't work. That's when I looked at your BMP loader more closely and then noticed the other problem. NO HEADERS. You were trying to treat the BMP like a raw file. I cut in the headers, overrode your inputs {w, h, d} with those from the file, and it came up like it was suppose to!
By the way. Move the image types within the planet functions themselves, don't keep them outside. And unless you're planning on trying to show earth textures on Jupiter, etc. Don't pass in the texture enum to get the texture name. Hard code them within the individual planet function's texture name lookup.
There are other cleanup issues, but just think, "How can I make this look more clean!" Once functionality is working. Save a copy of the project, then continue making changes. Archiving the project has to do with having a backup if cleaning goes terrible wrong. You'll have a fall back point to the last know good working version.
![]() |
Similar Threads
- Texture mapping for sphere! (Game Development)
- Blue screen of death when windows lis trying to load... (Troubleshooting Dead Machines)
- Convert mouse position to Texture position on ball (Game Development)
- New layout comments (DaniWeb Community Feedback)
- i think my computer is infected (Viruses, Spyware and other Nasties)
- Converting Images Please Help (C#)
- Crazy hyperlinks not behaving as expected!!! (Web Browsers)
- Cpu Performance low (Motherboards, CPUs and RAM)
- Cannot boot Windows XP (Windows NT / 2000 / XP)
Other Threads in the Game Development Forum
- Previous Thread: C++ Help Needed Please!
- Next Thread: Episode 3 - Development of FPX Game engine
| Thread Tools | Search this Thread |
3d advertising ai algorithm ban c++ cambridge camera censorship china competition console development engine fov fpx game gamer games gaming gauntanamo government idaho in-gameadvertisement intellectualproperty l-systems laracroft lindenmayer live manhunt math mathematics matrix mercenaries microsoft mmorpg modded msn naked news nintendo obama opengl palin physics pirate playstation politics projection ps3 rpg search selection software sony stephenhawking stocks studio technology terrorism tombraider uk videogame web wii world-of-warcraft xbox xbox-live xbox360





