Virtual Texturing part 2

A picture, or well in this case a movie, is worth more than a thousand words:

On top of the screen you can see (pages A/B) how many pages are used (A), and how many there are in memory (B).
The FPS / Ms should really be ignored..

Internally the OpenGL library for C# i'm working with (OpenTK, and i don't have the source-code) or a broken driver is forcing my app to sync to my monitor's refresh rate (60hz), and my recording software is seriously interfering with the timing of that syncing.

Update: putting a timer around the rendering code (and not relying on OpenTK's timer which is always synchronized to the monitors' refresh rate) showed that i was actually rendering around 4000-5000fps (0.2-0.3ms) instead of just 60fps ;)

Other than that there hasn't been any real performance optimalisations yet and i'm doing some things the quick & dirty way (readbacks are not async, page uploads are not async either, and should probably be spread out over multiple frames etc. etc.).
I'm basically just doing whatever i can to get things working like i want instead of trying to use the most optimal OpenGL api mechanisms at the moment.

Next to that there are still some artifacts there, i mean next to the usual video compression artifacts, which i'm trying to track down at the moment.
Just look at 0:30 to 0:32 in the bottom-left corner of the video.
It's weird that the page loading artifacts are there, because at the moment i'm uploading all the required pages before i use them.

The virtual texture is a mere 8192x8192 at the moment and completely in memory (no reading from disk at the moment).
Any larger texture would have to be loaded from disk, my system would probably not like loading a 16384x16384 texture in memory ;)

Filtering is trilinear, Bilinear would obviously be faster and would stress the system less as there are fewer pages to be required to be used per frame.
Seams between pages are more visible with bilinear filtering, but surprisingly hard to spot using trilinear filtering.. in fact, i haven't been able to spot a single one so far!

Next steps would be to fix all the artifacts, start reading back from disk, and optimizing everything.

Virtual Texturing part 1.

Yay! I finally managed to liberate a little time for me to work on virtual texturing!

Thinking it would help me avoid worrying about additional borders i used a texture-array instead of a large texture for my physical page-cache texture.

(Edit: My test textures just happen to be a 'best case' and with alternating border colors between pages an aliased edge is actually visible, so additional page-borders are still necessary)

Each layer in the texture-array (255 max) is a single page, each page is 128x128, which would give me a cache of 255 x 128 x 128 pixels.

Right now the 'virtual texture' is small enough that it fits completely in video memory, so it's not exactly 'virtual', there's no readback yet either.

There's already a page lookup table however.

The next step would be to readback which pages are visible, upload them and update the page lookup table.

Here's a short video showing the blending between the pages

Yes Yes no fancy graphics or even interesting geometry, I'm on a tight time schedule here people! ;)

While working on this i did realize that the rage screenshot in my last post has something odd in it..

Before i only noticed that all the pages where just nice and square and that they had a nice locality to them.

What i failed to notice, and what i notice now, that it's just plain weird that there's just no blending or any transitions between what i assumed where mip-maps!?

Maybe they're showing pages at the highest resolution? And the ones in the back are bigger because some pages just happen to have a larger geometric area assigned to them? And it just, by chance, looks like some sort of weird rough mipmapping?

Rage

I was just reading a new pdf about Rage, which i'm sure you know is the new game from id software, and i noticed something interesting in one of the screenshots:


Notice how the texturing is nicely aligned?

Seems to me that it would be possible to build a rough bounding volume tree with which you could determine which pages are potentially visible.
(Something I'm thinking about with my Deferred Virtual Texture Shading stuff)

Interestingly they're still reading back from the gpu which pages are visible at which LOD.
I wonder if that could be done more efficiently on the cpu avoiding the readback completely.