18 replies to this topic

[sebh]

Description
I first thought about the technique I'm going to present you here the first time I have heard about the Mega-Texture technology of John carmack from Id Software. I wondered what effect real-full texture virtualization would allow us to achieve ? That is : each surface has it's own texel and you can modify it. That's why I have started to develop this little demo. The goal was to have every surface in the virtual environment having it's own texture and texels.

Here are the features :
- high dynamic surfaces : that is the curvature and color can be changes. (bullet holes, acid blood, etc)
- you can virtualy apply an infinite number of decals on the geometry without any lose of framerate.
- attenuation and occlusion of projections on surface thanks to a shadow-mapping-like algorithm.


For further details, read the dedicated page on my website http://sebastien.hillaire.free.fr or ask me questions :-)

[tobeythorn]

Sebastien,
This technique looks really good. I also found some of your other work on your website interesting.

[sebh]

Thank you for the compliment. :-)

When i will have time, I plan to implement this effect in the Quake3 game engine...

[rouncer]

the more ram you dispose of the more pretty your world looks.

[sebh]

Yes in my case, because I have just tested the effects with a quick but not optimized implementation.
A better usable solution would be to use real texture virtualization. In this case, when a page fault occurs, the texture page must be loaded but the resident texture page (if there is one) must be saved if it has been previously modified by any decals.

[starstutter]

Another optimization could take advantage of the fact that people's eyes are more sensitive to changes in brightness than in color. This implies that you could have a lower resolution color texture, and a high resultion monocrome texture that could be twice the resolution at the same memory cost.

[Reedbeta]

starstutter said:

lower resolution color texture, and a high resultion monocrome texture

That's exactly how JPEG compression works (well, part of it)...but you probably already knew that.

[starstutter]

Reedbeta said:

That's exactly how JPEG compression works (well, part of it)...but you probably already knew that. ;)

err, actually I didn't but that's cool to know :) Unfortunatley though you can't compress the textures in real-time... well, you can but it would be pointless. But you probably already knew that.

[sebh]

That's funny, because I know well the Human Visual System (HSV) and attention (thanks to my PhD thesis).

I agree, but this type of compression would not be faster enough for real time. Besides, I do not want to see jpeg compression artefacts due to fast compression on any surfaces. And sometimes you want to see a lot of details so having a lower resolution color texture may not be the best solution. But that's very interesting...

I would like to see more applications that heavily take advantage of the HSV features. A lot of research have proven that the HSV could be exploited for exemple to accelerate the rendering process but I'm afraid that this is not very used in practice...

[sebh]

I forgot to say that there is a demo on my website... (for those who did not visit it)

[starstutter]

sebh said:

I agree, but this type of compression would not be faster enough for real time.

Oh no that's not what I meant lol. What I meant was to have a fairly low-res color texture, but then have a full-res monocrome texture (you could use it in object-space bump mapping). Either that or you could have a full-res normal map texture. I know that that would take more memory, but normal-mapped decals are kind of necessary for current gen graphics imo.

[sebh]

Ok I understand. Currently, I have the surface color and heightmap textures having the same size and It would be easy to get the heightmap having half the resolution of the color map since I treat them as separate textures. This should work.

-> The decals in this demo are "normal-mapped" since they modify surfaces heightmap used by the reliefmapping algorithm and to compute normals on the fly.

[Reedbeta]

sebh said:

I do not want to see jpeg compression artefacts due to fast compression on any surfaces.

I think most of the classic JPEG artifacts are actually due to the quantization of high frequencies, in the second stage of JPEG compression (the DCT stage). What's being proposed here is, instead of storing an RGB image, storing a YUV image with the UV at half linear resolution. That would give 50% memory savings over plain RGB, at the expense of requiring more texture lookups in the shader (since in practice, the Y and UV would have to be in separate textures) and requiring a matrix multiply to decode into RGB.

It's an interesting idea but ultimately, DXT is probably more effective...better compression ratio, and decompression is implemented in hardware.

[sebh]

OK.

And I agree that DXT would be a better solution :-)

[rouncer]

i think having the whole world completely unique texels makes for a superior world, that wastes memory.
it takes too long to load.
i wouldnt just be usin it for decals tho, id be making the whole world look normal mapped even if it was just textured.
its something any dumbass like me understands.
i wouldnt know what dxt is.
just use block compression i cant notice the difference :) but i dont have a phd.

but how are you gonna get your editor in on compressed textures?

[sebh]

Hi Rouncer,

The technique proposed by Id(and other) is not only to have the whole world normal mapped. Doom3 and HL2 were entirely normal mapped to ;-)

To my knowledge, the next title of Id, Rage, has unique texture over all surfaces (albedo, gloss and normal map). And they justify this by telling that they can virtually apply an infinite number of decals. (Take a look at the video of their editor on Game Tutorial). That is to say, you can completly avoid texture repetition and add unique details on each surfaces. That is a powerfull tool for artists. And this technique has many other advantages : constant video memory usage, etc...

My demo is long to load because I do not have virtual texturing with loading via streaming from the HardDrive and real time DXT decompression : have a look at this web page http://silverspaceship.com/src/svt/ : real time and fast DXT compression on the CPU is possible ;-)
The goal of my demo was to show what effects could be possible with real texture virtualization. (not only static unique texturing on surfaces)

One other extension could be to have liquid (blood, water...) flowing on surfaces based on the heightmap and the gravity. (There is one demo of nVidia about this)

I hope I gave answers to all your questions and that I have helped you to understand this technique.

[starstutter]

sebh said:

To my knowledge, the next title of Id, Rage, has unique texture over all surfaces (albedo, gloss and normal map). And they justify this by telling that they can virtually apply an infinite number of decals. (Take a look at the video of their editor on Game Tutorial). That is to say, you can completly avoid texture repetition and add unique details on each surfaces. That is a powerfull tool for artists. And this technique has many other advantages : constant video memory usage, etc...

I think perhaps the way they're doing this is by basicly having one enourmous texture (hence mention of mega-textures in Doom) and sections of them are loaded into the game at run-time. I heard John Carmak talking about a problem he feared where "a player would turn a corner and see nothing but a blurry mess for a few seconds". So my guess is they load them by dividing the world up into zones, pre-empting where the player is going to be, and loading the information in over the course of several seconds as not to stall the pipeline.

I noticed something similar to this in the Unreal engine. Every once in a while (like in bioshock) when you go into a new room you'll see the texutres of new surfaces start out very blurry and then they clear up.

[sebh]

I agree with you to some extend.

In Doom, the mega texture was not used.
In Ennemy territory, the mega texture was only used for the terrain (some kind of clip map algorithm).
I think, in Rage, they are going to use something like virtual texture as presented on the web page I gave because Carmack has given a tip to this guy. (I you read his presentation, he mention it). So, for me, the technology used in Rage will be virtual texture. Moreover, there is a presentation of Crytek at Siggraph 2008 which expose virtual texture and other thing. Very interesting stuff :-)

My plan is to implement such thing when I will have time... (to busy right now because of my PhD thesis)

Anyway, I agree with you for the blurry textures; and grouping ressources by zone could have advantages.

[sebh]

Hey,

Just to say that if you experiment a crash, you must delete the OpenGL32.dll.

The zip on my website has been updated : sebastien.hillaire.free.fr