Hi there,
I was wondering if there’s a way I can somehow parameterise my values to glTexCoord while it is part of a display list. I’ve got a quad constructed with glTexCoord and glVertex and then I put it in a DL. Can I somehow modify my glTexCoord params while it is in the DL, or should I just generate another DL with the other params I have?
Sorry if this is a dumb question; its late here. 
Cheers,
-C
There’s the solution to use the texture matrix. I don’t know any other means to do that with keeping display lists.
Thanks so much for your reply.
My thought is to have one bitmap textured if I’m at a scale of 1, and another, higher resolution (say x2) bitmap for when I’m at a scale of 2 (zoomed in). The higher resolution bitmap will just reflect a quadrant of the lower resolution bitmap in terms of area. The idea is that I can display more detail as I zoom in yet not consume more memory than the lower resolution bitmap.
I’m concious of memory consumption given that my higher resolution bitmap, if it was to represent the same area as the lower resolution one, would consume GBs of memory.
I think that I can now use glMatrixMode with GL_TRANSFORM and then glScale/glTranslate to scale the area that I want to texture on to.
Am I on track?
Cheers,
-C
Well, I’m not sure anymore if texture matrices will help you. I think you’ll need to take a different way to achieve what you want. But what you want to do is a bit not well formed.
You say you’d like to avoid consuming memory just by displaying only the portions that are seen when zooming, but you display your whole object (threw display lists). If you can change that, I think using mipmaps will help you: that will allow you to define several textures, once per level, so that you’ll have different level of details.
Wanting to split the textures depending on the zoom factor (and thus the visible geometry) is a good idea, but you’ll need as much textures as you’ll have visible portions of your model, and as much level you’d like your zoom to have. And you’ll have, as you said, to change the texture coordinates. This also means if you move a bit your camera, on some zoom factors, you’ll need to combine several high-level textures and computes the appropriate texture coordinates, which is hard.
So, my best advice, as I said above, is to use mipmaps: create your most high-level texture, then build the mipmaps with gluBuild2DMipmaps. And that’s all, gl does the work for you: it chooses the matched texture regarding what portion of the screen your model covers.
If you’d like to keep your way, then I might think of how to do that: use multitextures and define the coordinates for each texture unit regarding the level of detail and the portion you take into consideration. I’ve never done that thought. But if you activate the good texture unit before calling to glCallLists then that might work. But it’s really more harder than what I said above.
Hope that helps.
regards
Thanks again for your reply.
I did consider the mipmap approach before but not in any great detail. I certainly like the idea of GL choosing which texture to use.
However, I was under the impression that GL would have to be given the entire high resolution bitmap for those close-up situations i.e. that it is not possible to give it portions of high resolution bitmaps representing the dimensions of the clipping area. It would not be plausible to assign a 2-3GB bitmap to a mipmap structure; or am I missing something here.
Cheers,
-C
If your image is as big as several giga bytes, then you might cut it into several parts, right. However, you’ll forcelly encounter some hangs in your application because not all the textures will be able to stand in the graphic memory (they won’t all be resident).
And I think the best thing is to cut your model too, which is not an easy task at all.
You’ll also have to forget display lists, or cut your model into several display lists. Then you’ll have to test the visibility of each portion of the model and only render the ones that are visible (obviously) and make resident the matching textures.
Otherwise, and as I said before, there’s the solution to use multitexturing: you can easily use 3 or 4 textures units, each one would be dedicated to a texture level of detail. You’ll activate just one texture unit at once but the texture coordinates would have already been affected (at startup) for all the units.
I’m sorry I cannot say more, your problem is not a ‘normal’ one
Hope that helps.
Thanks again for your advice. I’ll let the forum know how I go.
Cheers,
-C