Realtime texture streaming

posted in Brain spasm
Published August 30, 2007
Advertisement
Anyway, so there was that really cool thread in the graphics theory forum here on Gamedev.net, and it was all about Carmack's virtualised textures technology. As a spin off from implementing this technology I found this little gem whilst researching the possibilities for streaming textures in real time.

Nice eh? There's a huge great big chunk of research already in that paper, and it's written by one of the guys at ID Software. From this paper I think it's fairly safe to assume that you can speculate with more insight about how the new virtualised textures technology is working in the tech5 engine. For a start, they're using a custom image format which from the research in the article makes sense because one of the prerequisites of working with the virtualised textures system is that you must be able to load chunks of an image in as they are needed - not the whole image at once - which means that a wavelet based compression technique works best. JPEG2000 would look at first glance to be a good candidate for this except that compression rates aren't the best and decompression in open libraries is unoptimised for SIMD / multi-core. Also it looks as though ID may well perform on the fly DXT compression, though possibly only when video memory budgets are low as even SIMD optimised DXT compression routines require a large amount of processing power. It looks as though ID's technology is aimed squarely at the multi-core / multi-cpu trends of the future then.

So where this leaves me is basically I don't really have the time or resources to implement all this technology on my own so I'm most likely going to go with JPEG2000 which can be decompressed with GPU acceleration. This is because the DWT can be computed on the GPU, and the nice guys at the link given have integrated their solution with JasPer, and provide full source code. Nice guys!

Another question that was pretty much answered is that it looks like ID also generate mipmaps on the fly, using a simple box filter. This is to reduce the amount of data that needs to be streamed off disk and decoded.

I've been toying with the idea of doing actual hardware decoding on the fly with a fragment program that can decompress the image data. To be honest though this doesn't really make sense unless you store the mipmaps in the compressed format too. Also the only reason to have compressed textures in video memory would be to save texture memory - which DXT is better suited for. And the problem with that is doing it quick enough - even on crap hardware.
Previous Entry New article in the works
Next Entry Volumetric clouds
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement