Texture Mapping with Glaux

Started by
0 comments, last by Solitethos 20 years, 7 months ago
I just started with openGL, I''ve noticed many people say Glaux is horribly outdated, yet it is essential to Lesson 6. If Glaux is outdated, what is the current method for loading texture data? I thought about writing my own load functions for bmp/tga but I need to know what format openGl requires the data to be in to bind it. Perhaps there''s a newer library out there that takes care of all this? Any help? Thanks.
Advertisement
quote:Original post by Solitethos
I just started with openGL, I''ve noticed many people say Glaux is horribly outdated, yet it is essential to Lesson 6. If Glaux is outdated, what is the current method for loading texture data?


There is no "current method". GLaux is a utility which is meant primarily for beginners. Once you become more experienced you''ll probably want to write your own image loading code. Besides, loading a bitmap is relatively easy and has been discussed many times on these boards (run a search and you''ll find plenty of topics on it).

quote:
I thought about writing my own load functions for bmp/tga but I need to know what format openGl requires the data to be in to bind it. Perhaps there''s a newer library out there that takes care of all this? Any help? Thanks.


This is all in Nehe''s tutorials, but I''ll give you a rundown on what "OpenGL format" is all about. I''ll use some exotic terms as well to make things more ineteresting.

First off, memory can be viewed in any form or shape and the fact is that there really is no true form or shape for it. Although memory can be accessed sequentially, that isn''t the only way to do it.

An image is always two-dimesional. For images, this "form" is called the spatial domain (for 1D signals it''s called the time domain). A 2D field that is composed of a regular grid of points (or any items for that matter), is called a matrix. Therefore, a digital image is a matix. This is probably what you already know.

A matrix looks generally like this (I used absolute values instead of fancy addresses such as ni and ni+1):

1|1  2|1  3|1  4|11|2  2|2  3|2  4|21|3  2|3  3|3  4|31|4  2|4  3|4  4|4


You can access it as M[x][y]. This is how you can access memory as well. However, memory is split into virtual slots, each of which has a numeric address. Since someone long long ago decided to assign these addresses sequentially and not in pairs (as you would find them in a matrix), that''s how it''s turned out. In order to conform the above matrix to this rule, there are some adjustments that need to be made. You can access the elements of the above matrix as M[Y * n + X], or you could rearrange the entire matrix to look like this:

1  2  3  45  6  7  89  10 11 1213 14 15 16


This is also what you probably already know.

And that, my friend, is the "OpenGL format".

So let''s recap and bring the actual bitmap into all of this. As you can see, OpenGL expects a regular contiguous chunk of memory from you that contains the image data. The image data is generalised from the matrix form to a simple row:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Each of these numbers identifies a value - for images this mostly means a single pixel. An image can theoretically contain any number of bits to describe a pixel. Generally, however, you''ll find that this number has byte boundary (eg 8, 16, 24). For pcx, and severals forms of compression you''ll find that this won''t always be the case, though.

So, in conclusion, if you tell GLAux to load a bitmap for you and you retrieve the Data component for that bitmap, the above array is what you will get. Bitmaps have the nasty property of storing lines in upside down order, but GLaux takes care of rearranging them for you. If you look at the bitmap''s properties, more precisely at the BitsPerSample property, you''ll be eble to tell how many bits/bytes each of the numbers in the last table contain: for 24 that is 3 bytes (r, g, b), for 8 that is generally an index in a palette table usually stored at the beginning of the bitmap (you''ll need to do the matching yourself - if you use GLAux, it does that for you). A bitmap can also be RLE-compressed, but these are applicable only for bitmaps that have 256 or fewer colors (8 bits and less). I don''t know if GLAux handles RLE compression properly - it probably does. Mostly you won''t be needing to load compressed bitmaps, however, since you''ll most likely want to maximize their quality as opposed to reducing their size.

In conclusionv. 2 - run a search on this forum. I believe it might have been Anonymous Poster who just recently posted his bitmap loader and I''m sure he won''t mind if you take a peek at it. I wrote a hole lot of baby talk here, but I hope this''ll put the end to the endless succession of "what is OpenGL format like" type of questions. The truth is: it''s all just memory and the simplest (not to mention the most efficient) way of handling memory is the row type - that''s how most applications do it. It''s that simple!
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared

This topic is closed to new replies.

Advertisement