High Rez Textures and Texture Compression

[Humus]

Would it be possible to "automatically" mip-map textures as well, which would also be a dramatic saving on texture sizes?

Both OpenGL and D3D already support automatic mipmap generation. Of course, it still takes up the same space in video memory though, but on the other hand I don't see the "dramatic" save in texture size. The entire mipmap chain except the base level is only 1/3 the size of the base level. That means by not storing the mipmaps you save 25% of the storage space, which I don't consider that dramatic.

 

[Hellbinder]

What John means is its going to be a major feature of his next engine.

 

[Reverend]

What John means is its going to be a major feature of his next engine.

Really?

 

[Hellbinder]

Really?

You are mocking me.. arnt you...

If he's got a way around it,, then its highly likely a software work around.. which means it is highly likely its a major feature of his next engine.. which is why he cant talk about it.

Anyway... thats the way i see it.

 

[Gabrobot]

You are mocking me.. arnt you...

If he's got a way around it,, then its highly likely a software work around.. which means it is highly likely its a major feature of his next engine.. which is why he cant talk about it.

Anyway... thats the way i see it.

He's obviously talking about his MegaTexture technology, which is also being used in some Doom 3 powered games...Quake Wars for example uses a texture size of 32,000 by 32,000 for the terrain.

Now just what MegaTexture tech is, is another matter.

 

[Reverend]

Now just what MegaTexture tech is, is another matter.

 

[NeARAZ]

He's obviously talking about his MegaTexture technology, which is also being used in some Doom 3 powered games...Quake Wars for example uses a texture size of 32,000 by 32,000 for the terrain.

Me wonders whether that means true 32k size texture (i.e. the one that can be drawn completely by hand) of the resulting size from some combining algorithm (e.g. wang tiles). I suspect something of the latter (which of course is not that impressive ).

Something like wang tiles can also claim "infinite texture sizes". Something like Zioma's article in upcoming ShaderX4 ("Dot-Product for efficient detail texture mapping") can also claim huge texture sizes, controllable by artist (unlike wang tiles) and even working on ps1.1 - while in essence it is not much more than detail textures...

 

[[maven]]

Something like wang tiles can also claim "infinite texture sizes". Something like Zioma's article in upcoming ShaderX4 ("Dot-Product for efficient detail texture mapping") can also claim huge texture sizes, controllable by artist (unlike wang tiles) and even working on ps1.1 - while in essence it is not much more than detail textures...

That's one of the problems with 3D graphics becoming more scientific... I remember reading papers on environment mapped Phong faking, which at the time the demo-scene had been doing for years...

 

[NeARAZ]

That's one of the problems with 3D graphics becoming more scientific... I remember reading papers on environment mapped Phong faking, which at the time the demo-scene had been doing for years...

About Zioma's article: I'm not saying it's bad (in fact it's good), just pointing at example what might be similar to Carmack's mysterious MegaTexture. In essence it's not much more than detail textures, but has some scientific rationale behind it - human eye has different sensitivity for color vs. intensity; hence we can store them at different resolutions, etc.

 

[Richard]

Me wonders whether that means true 32k size texture (i.e. the one that can be drawn completely by hand) of the resulting size from some combining algorithm (e.g. wang tiles). I suspect something of the latter (which of course is not that impressive ).

I can tell you MT handles at least true 16364 x 16384 texture sizes "(i.e. the one that can be drawn completely by hand)". I would have tried 32k x 32k but my system was already buckling when creating a 16k x 16k megatexture. mental note: buy more ram

So now it's impressive? Support for higher than hardware limited texture sizes is not a new thing and IMO that's not what MT excels at.

 

[AlNom]

Is it selectively loading parts of the texture?

 

[Richard]

Hmm well, if you have textures with sizes higher than the hardware limit then you're already forced to implement some method of virtualising your texture resources to get them to fit into those hardware limits, right? I was actually thinking of being freed from texture repetition, what JC called "unique texturing" in that with arbitrary texture sizes and where you move the bar from "total texture memory in ram" to "total texture memory used in a scene at any given time" is that you can now have levels where every surface can be unique and you don't have to keep reusing your texture assets because of the limitations.

 

[Fox5]

You are mocking me.. arnt you...

If he's got a way around it,, then its highly likely a software work around.. which means it is highly likely its a major feature of his next engine.. which is why he cant talk about it.

Anyway... thats the way i see it.

With far more powerful multi core cpus of the new consoles, combined with their much higher system memory bandwidth, perhaps an engine targetted for xbox360 or ps3 could make use of a much more advanced texture compression method?

BTW, 3dfx tried to do a little bit over S3TC with FXT1, 8:1 ratio, but I believe it had some limitations that guaranteed its death. (was it mostly just a way to get around paying the S3TC license fees?)

 

[Simon F]

BTW, 3dfx tried to do a little bit over S3TC with FXT1, 8:1 ratio, but I believe it had some limitations that guaranteed its death. (was it mostly just a way to get around paying the S3TC license fees?)

IANAPatentLawyer but,IMHO, it infringed S3's patents and so would have been risky.

Also, it had the same compression rate as S3TC.

 

[Fox5]

IANAPatentLawyer but,IMHO, it infringed S3's patents and so would have been risky.

Also, it had the same compression rate as S3TC.

Did it? I remember it advertised as having an 8:1 ratio, and S3 only having a 6:1 ratio.

 

[Simon F]

Did it? I remember it advertised as having an 8:1 ratio, and S3 only having a 6:1 ratio.

They are/were both 4 bits per pixel.

 

[AlNom]

I was actually thinking of being freed from texture repetition, what JC called "unique texturing" in that with arbitrary texture sizes and where you move the bar from "total texture memory in ram" to "total texture memory used in a scene at any given time" is that you can now have levels where every surface can be unique and you don't have to keep reusing your texture assets because of the limitations.

Ah...

So this isn't done only on the technology side but also done in conjunction with level designers/artists? (edit: oh wait, you mean it's just the option of not having to reuse assets?)

Is hardware sufficiently fast enough to load unique textures on the fly according to the user's view or will there be some issues with stuttering or pauses during gameplay?

Not sure if I understand entirely here.

 

[Richard]

So this isn't done only on the technology side but also done in conjunction with level designers/artists? (edit: oh wait, you mean it's just the option of not having to reuse assets?)

Not sure what you mean here.

Is hardware sufficiently fast enough to load unique textures on the fly according to the user's view or will there be some issues with stuttering or pauses during gameplay?

That's the real question isn't it? Moving from "total texture budget" to a "total texture budget in a given scene" paradigm requires some changes and it will stress different parts of the system. We'll see how it works when ET: Quake Wars is released but JC isn't inept.

 

[AlNom]

Not sure what you mean here.

I guess I was reading too much into this part: "you can now have levels where every surface can be unique and you don't have to keep reusing your texture assets because of the limitations."

That's the real question isn't it? Moving from "total texture budget" to a "total texture budget in a given scene" paradigm requires some changes and it will stress different parts of the system. We'll see how it works when ET: Quake Wars is released but JC isn't inept.

ah... fair enough

hm... actually just thinking about that, several console games seem to have that sort of loading system in place. Halo 2 comes to mind: cut-scenes and even just turning around seems to show that textures (and even geometry) are loaded per-scene. I would really like to mod my xbox to put it on the hard drive and see if the texture "popping" is not noticeable if at all. Of course, another thing to consider is that on PC there would probably be much more texture data to load into memory due to a higher resolution.

It's also interesting that Halo 2 uses mip-maps like crazy so that it loads something to see while waiting for the final texture to be loaded (or at least something like that to explain why the resolution of someone's face automagically increases after 2 seconds in various situations). So if there is a loading speed problem on PC, I guess developers could go that route too...

Interesting choices to be made...

 

[Baraclese]

Is it a clipmap?
http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Texturing/Clipmap.pdf

Back when I browsed the doom 3 sdk I thought a megatexture was just a silly name for a texture atlas

Baraclese