I want to copy a small compressed texture into many sub regions of another (much larger) compressed texture.
The small compressed texture is a tiny 4x4 texels (to match s3tc compression algo) and I want to load this tiny texture once and then ‘paste’ it MANY times into a larger compressed texture (all done on 4 texel boundaries of course)
Is there an easy way of doing this? I want to avoid re-compressing the 4x4 block (which is semi-static) each time I copy it into the larger texture. I’m hoping for a fast path texture to sub-texture copy.
I know I could use pbuffers but then wouldn’t the pbuffer get compressed every time I called glcopytexsubimage2d ?
I assume by semistatic that you mean the 4x4 image does change. Or perhaps its the tiling that changes. Eitherway you are best not to use a compressed format in this case. Whatever you do don’t compress the texture using opengl. It works fine but SCT3 texture compression is extremely slow. Not something to do in real time. IT will take just as long to compress and image as it would to send the uncompressed version to the card. Plus if its an uncompressed and native format (RGB or RGBA) the video card should do the subimage copying which of course is significantly faster than the gl driver trying to the same with the cpu.
Using texture compression is really only a good thing with large static textures and decals. Anything that might potentially change is probably best left to an uncompresssed format.
This is largely my opinion but given my understanding of the way the texture compression is done its not worth it for dynamic textures.
I want to copy a small compressed texture into many sub regions of another (much larger) compressed texture.
The small compressed texture is a tiny 4x4 texels (to match s3tc compression algo) and I want to load this tiny texture once and then ‘paste’ it MANY times into a larger compressed texture (all done on 4 texel boundaries of course)
Rob J.[/b]
Have you tried GetCompressedTexImageARB and CompressedTexSubImage2DARB, based on your description they should do the work? I know that generally this kind of texture editing might not work with compressed textures, but I would not be too surprised if it would work for s3tc textures, as it should be trivial to implement in drivers.
As an alternative, if you are handling the raw texture data you could do the processing (just memcopy the data to correct place) before giving the data to Opengl and just upload the processed data using CompressedTexImage2DARB (s3tc data is organised in 4x4 pixel blocks, so copying that size aligned data is easy). This way should work in any case.
Eero
[This message has been edited by epajarre (edited 04-23-2002).]
You might try doing glCopyTexSubImage2D, but I don’t really know if it is optimized to bypass the decompress/compress operation if both source and target are compressed.
Also you should try the getCompressedxxx and CompressedTexSubImage way. It should not cause unnecessary uploads of the full large texture. SubImage modifications are usually well optimized in the drivers, because they are used by important performance critical applications (games).
I am actually not sure if there is a way for completely avoiding copying data out of the card, this is because OpenGL must keep a safe copy of the texture for example in case the operating system decides to thrash the onboard memory. But I am not sure what is the current state of the drivers in this area.
