This is the next thing I'm going to put into my engine, whether I need it yet or not isn't really important, I'm fascinated by it so as a hopefully enjoyable exercise, it's going in.

Firstly, I've been studying Black Ops 2 recently and it's fairly obvious they use some serious texture streaming. I was wondering if they will be streaming their textures from the DVD (slow??) or whether they might dump a load of textures (for the current level perhaps) to HDD temporarily (faster) and stream them from there. That would mean though that the end user would need a certain amount of free disk space and aren't there xboxes available with no HDD? I can't imagine they stream them from the DVD.

Secondly, when you see the level loading, you can see the MIPs loading in gradually (which is great eye candy in my opinion, I love trying to work out how things work), so to me this must mean they don't store their textures atomically (i.e. one texture file with all the MIP levels in it). So if they are separate, isn't it going to be pretty slow to load in an image, lock the texture on the card, update it with the incoming higher level MIPs and then unlock it again? I'm going to do some texts of this at some point but before I possibly waste my time, does anyone know roughly how it works? Am I on track?

I think that the lacking HDD support (think of Xbox I) on consoles was one of the major reasons to use streaming. The benefit of streaming is not only the reduced memory impact, but although the asynchroniously nature. Time isn't the most critical issue once you start streaming.

(i.e. one texture file with all the MIP levels in it)

Why not, when using DDS you can access the single mipmap levels easy enough. And you don't need to read every single mipmap-level, dividing your texture mipmaps into two sections (low/hi) is often enough.

So if they are separate, isn't it going to be pretty slow to load in an image, lock the texture on the card,

Loading and decompression can be done in an async. thread. Uploading the data to the videocard is most likely done by DMA, therefore the time impact could be quite small.

I was wondering if they will be streaming their textures from the DVD (slow??) or whether they might dump a load of textures (for the current level perhaps) to HDD temporarily (faster) and stream them from there.

I've seen some systems that stream from DVD to RAM and the HDD at the same time, so that next time it can just stream from the HDD (if one is present). This means that people with cheap (no HDD) Xboxes either have longer loading screens, or lower quality graphics for longer during streaming events.Streaming from DVD isn't really that bad (BluRay is worse) as long as you've taken care when creating your game's data archives in order to avoid seeking.All the console game engines that I've used have put a decent amount of effort into the data tools so that the order of data on disc matches the order in which the game's code will request it (or vice versa).Microsoft gives some tips here: http://msdn.microsof...5(v=vs.85).aspx

when using DDS you can access the single mipmap levels easy enough

The problem is that when reading from DVD, you want to read data in at least 32KiB blocks, and you want to read as many contiguous blocks as possible. The most optimal layout would have all the bottom-few mips of all the textures in your "level" packed tightly together, then all the next mips next to each other, then all the next-largest mips, etc... (assuming that you're streaming in a "level's worth" of textures at a time).DDS is also bad because it contains the header, then MIPs in order of highest-resolution to lowest resolution. This means that if you just want to read in the low-res mips first, you are forced to seek over the high-res ones. It might be more optimal to first stream in an entire contiguous array of DDS headers in one operation, and then determine your next move, rather than continually read individual headers off the disc.I've often seen texture data stored in "texture collection" files rather than as individual textures, to speed up loading operations.

isn't it going to be pretty slow to load in an image, lock the texture on the card, update it with the incoming higher level MIPs and then unlock it again?

The details for how you'd do this depend on the graphics API. On the consoles, you can manage video memory yourself, so if you know you're not going to create artefacts (because you know that you've set the min-mip-level render-state so that the incoming mips aren't going to be read by the GPU), then you can stream data into the texture's memory allocation without locking.Other APIs have flags to specify that you're not going to overwrite any in-use data with your update/map, so the driver doesn't need to lock. Alternatively, you can create two copies of the texture so that the one being updated isn't the same as the one being used (and then swap the pointers a few frames later), but that of course is paying a RAM penalty to save on locking.

I'm guessing it's better to just get streaming working in general and then concentrate on the efficiency of loading data.

Definately. If you're making a PC game, you don't need to put in half the optimisation effort that console devs do! Firstly you'll be loading your data from a HDD (or even SSD) instead of a DVD, and secondly, you don't have some platform gatekeeper that will block the release of your game unless you meet arbitrary quality requirements on loading screens