Hi Y,
I couldn’t get glCopyTexSubImage2D to work.
Could you post your change?
[edit]Ah! wglsharelists … [/edit]
FPS now drops
1300 to 132fps 256^2
900 to 42fps 512^2
So for Nvidia, glCopyTexSubImage2D is substantially faster! The opposite of your ATI findings 
The above demo doesn’t generate mipmaps for the compressed texture… adding that slows thing down further:
1300 to 100fps
900 to 30fps.
Cheers.
Rob
Hi Ysaneya,
Could you try this with a FBO to see if that would help your performance out due to pbuffers are nasty compared to FBOs? Be interesting to find out… BTW do you have any screenshots of your terrain? Be interested in seeing them with so much texture RAM being used.
Pocketmoon: that’s a good news, because it means texture compression becomes usable for me. Yipee! So i’ll use glCopyTexSubImage2D on NVidia and glGetTexImage + glTexSubImage2D on ATI… thank you 
Mars_9999: i’m not on the machine with the code right now, but if you want you can try it yourself (pocketmoon posted the link to the exe+src a few posts before).
Screens of my procedural terrain (that’s a planet renderer):
http://fl-tw.com/Infinity/Media/Screenshots/planet_tex_new_4.jpg
http://www.fl-tw.com/Infinity/Media/Screenshots/planet_tex_new_13.jpg
http://fl-tw.com/Infinity/Media/Screenshots/planet_tex_new_17_med.jpg
http://fl-tw.com/Infinity/Media/Screenshots/planet_tex_new_18_med.jpg
The ground is lacking details - it’s not a limitation of the algorithm, i just haven’t got the time to implement detail textures yet.
Y.
Originally posted by Ysaneya:
Screens of my procedural terrain (that’s a planet renderer):
Y.
Doh! I’m kicking myself for not realising the link between this discussion and the one on http://www.fl-tw.com/Infinity about terrain texture usage
Glad to be of help!
Rob
use a fragment shader to do the compression yourself.
Originally posted by knackered:
use a fragment shader to do the compression yourself.
Is it possible to render a ‘self-compressed’ texture to a buffer (via a shader) and then have openGL bind to that buffer as DXT?
the rest is implementable…
find the min and max colour vectors in a 4x4 sample.
Derive the two interpolated values.
For each sample pick determine the closest of the 4.
Merge them into 4 x 16 bit values per compressed block (two 5:6:5 colour values and 32 bits of lookup)
I guess it could be done… but with a complex and long (so slow) fragment shader. I’m not ready to trade memory for an horrible performance.
Is it possible to render a ‘self-compressed’ texture to a buffer (via a shader) and then have openGL bind to that buffer as DXT?
I seriously doubt it.
Without bitwise operations, I have no idea how you’d produce the 2 16-bit colors, let alone the 2-bit codes that tell how much of a linear blend to use.
with a complex and long (so slow) fragment shader. I’m not ready to trade memory for an horrible performance.
No matter how long that shader is, it’d be faster than doing a memory transfer, running the compression on the CPU, and then re-uploading it again.
Originally posted by pocketmoon:
Is it possible to render a ‘self-compressed’ texture to a buffer (via a shader) and then have openGL bind to that buffer as DXT?
use a fragment shader to do the decompression yourself.
Ysaneya I would like to but my time is limited as of now… To much coding. 
I think it’s the same for everybody
Ysaneya :
after looking at your picture, I’m wondering how you did the sky background. I used the famous light scattering effect (published on www.ati.com/developer ) and got strange colors, still kind of realistic : http://dev.succubus.fr/ .
Did you use a texture, or did you use the same technique as me, tweaked to get better results? If so, what were your tweaks?
SeskaPeel.
I’m using a tweaked version of sky scattering that is supporting a viewpoint at any altitude (even in space). It’s using similar equations than in the ATI paper, but it also adds a variable atmosphere density function (which requires a ray/sphere intersection test on the vertex shader) and a non static sun color.
But i must say, i can’t really see your “strange colors”. What you show in these screens looks pretty good to me.
Yes, I’m using the same technique, from a swedish guy IIRC, that improved the Pretham’s version.
Anyway … my orange-ish colors look more like martian. Looking at yours, I have the feeling you get brighter colors, and that was precisely what I was missing (my blue was too dark, I had to tweak it manually).
Maybe I made a mistake in the implementation of the shaders … but the colors I get (even more for the sun itself) seem messed up.
Originally posted by Ysaneya:
I replaced your code to render to the color buffer, and do a glCopyTexSubImage2D.
Umm, sorry if I’m asking the obvious here: do you mean you copy part of an uncompressed texture into part of a compressed texture? I didn’t know you could do that!
And you say it’s fast on nVidia? Holy crab!
No, that’s actually copying a part of the color buffer into a texture that was created with a compressed format.
Originally posted by Ysaneya:
No, that’s actually copying a part of the color buffer into a texture that was created with a compressed format.
Well, yeah, that’s basically the same. You can bind any uncompressed texture to a FBO, and then use glCopyTexSubImage2D. Man, I’ll have to try this
I have one question though: Did you guys figure out if there’s any performance penalty for updating arbitrary sized subrectangles in a compressed texture? I would guess that, depending on the compression algorithm, it would be more efficient to update chunks that are aligned to 4x4 blocks, or something…
Originally posted by Mars_9999:
[b]Hi Ysaneya,
Could you try this with a FBO to see if that would help your performance out due to pbuffers are nasty compared to FBOs?[/b]
FBO won’t help in improving performance. They help in cleaning code
