I’m trying to implement a texture management system that uses bound texture maps as banks of smaller texture maps. Is there any way to tell OpenGL that I want to use a region within an existing texture as a new texture map with different attributes.
I’m not too sure why you would do that, but if you did want to, you would go about it by using glCopyTexSubImage2D …I think
There’s no way to do exactly what you described, so you’ll have to take HFAFiend’s advice and copy from your larger bank to a separate smaller texture.
This implies that you have to draw your large bank to the frame buffer before you can perform the copy, though. A workaround could be to use a pbuffer as the bank, rather than a texture.
- Tom
depending on what you mean by attributes, you can always access a different area of your textur, when you just change your texture cordinates accordingly
You can use just glTexSubImage if you don’t want to draw the texture bank to the framebuffer first.
j
Use the texture matrix to scale your tu/tv so that the range 0-1 falls where you want it within your bigger texture sheet.
Unfortunately, tiling will not work if you composite multiple small textures into one large texture.
Ok, it has become apparent that there is no decent way to implement texture management in this way under GL.
Are there any known ways of optimising texture loads so that hardware texture RAM is used to its maximum.
Is it just me, or are there other people who think that a function that looks like this
glBindTexSubImage2D(parenttex, newtex, x, y, width, height)
would be a valuable asset for OpenGL.
all comments welcome !
[This message has been edited by Leo (edited 04-25-2001).]
OpenGL is designed to abstract away certain features of the rendering system. Texture memory is one of them. While I wouldn’t be adverse to a vendor providing an extension that allows some independent texture memory management, forcing all implementations to provide one goes against the basic ideals of OpenGL.
I think that the function I’ve suggested doesn’t necessarily imply texture RAM management, although this is an advantage and why I’ve suggested it.
I think that allowing textures to be clustered in large images creates a high level management system which MAY be part of a hardware optimised implementation.
You know, if there was a way to specify an “active” or “tile” region within the currently bound texture, that would be somewhat useful. However, switching textures to a texture that’s already in VRAM is not a very expensive operation on current cards, so maybe it’s not needed.
I agree that as a switching optisation for cached textures there would be little point in the function.
Tiles, and other game textures, can be quite small and have odd dimensions. By specifying as regions in a larger image texture RAM can be used more efficiently.
New skinsets and terrain cels could also be released and updated with greater ease.
Originally posted by Leo:
[b]Is it just me, or are there other people who think that a function that looks like this
glBindTexSubImage2D(parenttex, newtex, x, y, width, height)
would be a valuable asset for OpenGL.[/b]
It could be useful in certain cases, but it does complicate memory management a lot. The drivers have to keep track of all the parent-child relationships between the textures, because they can’t swap out a parent if one of its children is being used.
Also, the drivers would have to track the relationships in both directions, because you might use glTexSubImage() on a child texture and thus require the parent texture to be updated.
It can be done, but it seems like the extra effort it requires would be better spent on something like this: http://www.opengl.org/developers/about/arb/notes/objmgt.html
- Tom
I’ve got a copy the OpenGL reference implementation. If I actually implement this function would anyone be interested in recomending it to the ARB?
You can’t just “bind” a subimage. The whole concept of doing that just doesn’t make sense for (probably) the vast majority of HW out there.
- Matt
Why not? If you can perform a pixel copy to a region in VRAM, then why is it unreasonable to assume that the same region can be used to define the extents of a texture?
As far as I know that vast majority of hw allows a clamped repeating texture map to specified with arbitory x/y coords and width / height dims within texture memory.
Maybe making a bound texture object isn’t the simplist way. Maybe the same result can be achieved with an extension to glTexParameter that clips off the unwanted area of the texture.
If you “bind” a subimage, the resulting texture would not be in a single continuous block of memory anymore - there would be a gap at the beginning and end of each row of pixels.
My guess would be that the hardware simply isn’t made for that. Can anyone provide more insights?
- Tom
Well, a couple problems I can see…
What about mip-mapping? GL_CLAMP texture wrap modes? How do ensure that the sub images are powers of 2 in both dimensions? Or do you just not enforce that? (Which make the extension impossible to use properly on most hardware.) Who is going to handle what textures go where?
In the end, it looks to me almost exactly like the current texture management system, except the textures are all stored in one big logical array. Which, as Tom pointed out, brings up memory access difficulties as opposed to simply having each image stored in order in memory, which is the way it is currently done.
j
I have a similar system to include real time videos of any size into 3d scenes.
I use sub images with appropriate texture coordinates, it works fine, but you’ll need some finetuning of texture coordinates to avoid some edges problems of the different textures.
It is simply a broken concept. I can’t provide all the details, but there are 5 or 10 big problems with it.
- Matt
Hi,
Tom:
I have now had the time to read the proposal at:
http://www.opengl.org/developers/about/arb/notes/objmgt.html
the texture mangement extensions include many useful details that many of us have been asking for, including
#define GL_MEMORY_ONBOARD_XXX 0x00000001
#define GL_MEMORY_AGP_XXX 0x00000002
#define GL_MEMORY_HOST_XXX 0x00000004
and
#define GL_POLICY_PINNED_XXX …
#define GL_POLICY_LOADED_XXX …
#define GL_POLICY_CACHED_XXX …
The ARB proposal also recognises that
http://www.opengl.org/developers/about/arb/notes/objmgt.html:
“Apps generally want to force textures to be resident (to avoid reloading them), lock textures in place (to minimize fragmentation), mark textures for unloading if space is needed, or even mark textures for automatic deletion (to avoid unloading them). It appears that there’s a disconnect between what the apps need and what the priority mechanism provides.”
Well, I’m glad that this had already been conceded!
wrt. contiguous memory. Well thats a good point, pity no one bothered to clarify it.
wrt. to mipmaps. Texture bleed would obviously occur with unaligned coordinates, but this would programmers responsiblity. OpenGL is also a 2D API and the requirement that a texture has power of 2 dimensions is restrictive, although there are work arounds.
Originally posted by mcraighead:
[b]It is simply a broken concept. I can’t provide all the details, but there are 5 or 10 big problems with it.
- Matt[/b]
Well, if you can’t say what they are, then I don’t see why I should believe you :P. OGL texture management is a broken concept and members of the ARB are currently working on a better model. Lets not forget that in version 1.0 you had to load the texture every time you wanted to use it!!! The point is not whether my concepts are broken, the point is that fine control over textures and texture RAM is desirable. How its done is irrelevent. Given your priviledged position maybe you could make some useful suggestions.
The are many demands on the OpenGL API, one competing demand is for realtime graphics for consumer PCs. Other APIs provide facilites that enable the programmer to use all of VRAM. It is a weakness in OpenGL that this option, if so desired, is not available.
Personally, I want to able to use all Texture RAM and to be reasonably sure that memory fragmentation is not much of an issue.
I also want to be able to use texture maps that don’t have power2 dimensions. If I lose mipmapping so be it. In 3 or 4 years time we might be using summed area maps instead of mipmaps.