Sign in to follow this  
  • entries
    15
  • comments
    13
  • views
    11876

Realtime texture streaming

Sign in to follow this  
TheGilb

628 views

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.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now