InsideQC Forums

Does anyone already tried this ? Is this even feasible at least in modern hardware ? more importantly, would it be worth the effort (in terms of performance gain) to justify all the required changes to the texture uploading and switching ? I was thinking about something similar to the lightmap atlas texture, only containing regular textures (plus respective mipmaps). I imagine that modern hardware, being able to handle 1024x1024 (and higher) textures would easily accommodate a good bunch of them in a few atlas, reducing the OpenGL state switch greatly. Opinions ?

i think it would be hard to properly align all of the textures at least for me in worldcraft/hammer it would take a ton of extra time. but i think it would be a cool experiment.

maybe easier done with that .map exporter i found for max. thats if it exports textures+alignment as well.

Well, I did it for lightmaps in QF's glsl renderer. I tossed all of the lightmaps into a 2kx2k texture (I have suitable sub-texture allocation code). Turns out e1m3 takes ~8% of the texture, so actual textures should fit for standard quake maps. As to the gains: the less you change state, the better.

However, there is one serious problem to doing an atlas texture: repeating textures. You would need to do fancy trickery in your shaders to work around the lack of hardware repeat.

ceriux wrote:i think it would be hard to properly align all of the textures at least for me in worldcraft/hammer it would take a ton of extra time. but i think it would be a cool experiment.
maybe easier done with that .map exporter i found for max. thats if it exports textures+alignment as well.

No, I mean building the texture atlas engine-side, during the map texture upload. By default, GLQuake uploads every texture separately (the exception being 2D graphics which are uploaded to the so called "scrap textures" exactly for performance reasons). This made sense back in the Voodoo 1 days when there was a hardware limitation to texture sizes (256 x 256 IIRC). Nowadays even modest hardware from like 5 years ago is able to handle at least 1024x1024 textures, so theorically uploading several map textures into a single OpenGL texture would result in far less texture switch during rendering, which would translate in some performance gain (specially in slow hardware like embedded Intel GPU's).

taniwha wrote:Well, I did it for lightmaps in QF's glsl renderer. I tossed all of the lightmaps into a 2kx2k texture (I have suitable sub-texture allocation code). Turns out e1m3 takes ~8% of the texture, so actual textures should fit for standard quake maps. As to the gains: the less you change state, the better.

However, there is one serious problem to doing an atlas texture: repeating textures. You would need to do fancy trickery in your shaders to work around the lack of hardware repeat.

Very interesting information. I agree the effort to handle texture repeat by software wouldn't be trivial.

you would gain from being able to throw all surfaces onto the screen with the bsp tree ordering, meaning early-z optimisations would drastically reduce overdraw (assuming you do the same with lightmaps too). you'd also gain from a few less texture changes.
you can use texture arrays or perhaps 3d textures as a way around the wrapping issue, but that requires that each texture has the exact same dimensions.
you could chop up surfaces easily enough to cope with texture repeats. its not really that different from clipped decals, it is more geometry though, but you'll barely notice that. You would need a few pixels around the edge of the texture to handle mipmapped repeats however.

This is basically what software Quake does (and - when you think about it - it's not a million miles away from megatexture). Probably not a huge performance gain though, there's more to be had from more intelligent drawing of MDLs (and using such a method would give you big problems with external textures).

A player atlas would be cool. Having all the 16 clients managed onto one texture page, with partial texture updates for color/skin changes much like the treatment of dynamic lights.

surely its better to not need a separate texture for every player?

mh wrote:This is basically what software Quake does (and - when you think about it - it's not a million miles away from megatexture). Probably not a huge performance gain though, there's more to be had from more intelligent drawing of MDLs (and using such a method would give you big problems with external textures).

Yup, agreed about the megatexture resemblance (if you imagine mt as a huge non-repeatable atlas). But I don't see why external textures would be hard to deal with (except maybe because they are usually bigger than regular textures and probably a smaller number of them would fit into a OpenGL texture); once uploaded they would be handled like any other.

frag.machine wrote:except maybe because they are usually bigger than regular textures and probably a smaller number of them would fit into a OpenGL texture

That's exactly it.

Spike wrote:surely its better to not need a separate texture for every player?

Precisely. Any GPU from the past 10 or so years doesn't need separate textures for each player and can use shader-based color mapping to avoid having to use them. Even older ones could hack it with some semi-creative use of blend funcs.

how would modders work with something like this?

Ideally, they wouldn't, as it would all happen behind the scenes and thus not even know it's happening.

oh cool! id like to see if something like this were worth while.