UT S3TC OpenGL

[dawks]

Pre-compressing them into ram? as in they are only availible while the game is running?

 

[BenSkywalker]

Jukka-

"BTW, about S3TC and Quake III, I don't believe it uses S3TC'd lightmaps: updating them when dynamic lighting is enabled would be too computationally intensive. Worst S3TC issue in Q3 is the sky, and I believe that's because textures like the sky, ones w/ alpha channel data, are the hardest ones to compress accurately."

Are you sure? I ask because the artifacts that are painfuly evident in the sky are noticeable wherever a lightmap falls, just not nearly as bad. Perhaps this an issue with applying the lightmap over the compressed texture, compounding the flaws native to the compression?

"Support was gone in 2.24, which worked quite well, and was the last revision released."

In UT, it is listed as an option with my current Unreal.ini file and in the advanced options, though I am not sure if it does anything. 2.24? Did they not update the OpenGL code for 2.26? IMHO 2.24, and all prior versions, were extremely poor while 2.26 has been very impressive for D3D at least.

Would it be reasonable for id to release a patch that could pre-compresses all textures in a reasonable sized file? That would be sweet, though with the continued driver improvement it is coming less and less of an issue. With the 6.26s I lost 2-3FPS in Timedemo1 UHQ 10x7, and ~15FPS in Quaver when disabling texture compression.

 

[jpprod]

Are you sure? I ask because the artifacts that are painfuly evident in the sky are noticeable wherever a lightmap falls, just not nearly as bad. Perhaps this an issue with applying the lightmap over the compressed texture, compounding the flaws native to the compression?

I believe the latter is correct. Being a lossy compression scheme, S3TC artifacts - namely sacrifice of some color saturation, not terribly evident to human eye - would become visible when blended with a certain type of lightmap texture. Of course more accurate compression algorithm can greatly enhance quality here as well.

In UT, it is listed as an option with my current Unreal.ini file and in the advanced options, though I am not sure if it does anything.

Yep, I've tried that setting and it does nothing

Did they not update the OpenGL code for 2.26? IMHO 2.24, and all prior versions, were extremely poor while 2.26 has been very impressive for D3D at least.

AFAIK aside from bug fixes, 2.26 only added the new D3D renderer, which BTW finally properly supported all of the effects the Glide version did (detail textures and volumetric light). With the previous "big" release, 2.24, a completely new OpenGL renderer was added, and it remained in 2.26. I haven't compared driver file sizes/dates, but at least performance and visuals from 2.24->2.26 OpenGL were unchanged.

There are some issues from which the 2.24 OpenGL renderer can be recognized, at least on TNT series of cards. These are extremely slow performance when geometry changes (moving walls, wheel and such), peculiarities in volumetric lighting (sometimes characters are shown imporperly) and sometimes disappearing/performance-slowing grating (textures with 1 bit alpha channel, holes, in general).

Back then, when 2.24 was released, I actually felt the OpenGL was performing quite well on my TNT because the previous OpenGL/D3D-renderers had been completely useless.

Would it be reasonable for id to release a patch that could pre-compresses all textures in a reasonable sized file?

This is exatly what id should do. It would completely eliminate the quality issues and considerably speed up the level load times.

 

[dawks]

So like a Utility that will grab the textures, and compress them into a file. Then Quake can access them when needed.. That sounds pretty cool.