Space Saving Ideas (e.g. generating mip maps in memory?)

[Acert93]

There have been a number of threads discussing the media size constraints this generation, specifically quite a few on XBLA size limits or DVD9. Roboblitz seems to offer some unique solutions that may carry over to non XBLA games, but I was wondering if there were other ideas for space saving? I remember how the N64 had quite large and detailed (for the time) worlds in many cases even in the face of ROM limitations. CDs and DVDs lessen the need to be judicious and invest as much into tricks to maximize space but it seems we may, in some cases, be hitting such boundaries again.

Without getting into the HD Media vs. DVD9 vs. Wii Optical debate (please, enough threads on that to discuss that) I thought it would be nice to discuss some ways developers may be using the consoles to maximize the space they do have.

I got the idea for this question based on an idea that occured to me, namely games may have multiple resolutions (mip maps) of a single texture. Up close it will be the highest resolution texture, far away the smallest, and in the middle it will be a medium resolution texture and the GPU filters between these.

Games like Kameo and PGR3 seems to have a lot of resources dedicated to compression, so I was thinking: Could a developer place ONLY the largest mip layer on the optical disk, and during loading dynamically generate the medium and small mip layers? e.g. 1024x1024 texture on a DVD9, and when loaded the CPU could then generated a 512x512 and 256x256 resolution texture from the original?

While this may only be a little over 25% gain in memory space on the optical media and could pose problems with quality, it could improve load times and possibly free up hundreds of MBs of space for other assets. Is this already done or possible?

What other new tricks are being seriously looked into outside of procedural textures like Roboblitz is using? Are there any techniques that worked last gen but were not widespread that will become more common this time around?

 

["Nerve-Damage"]

I got the idea for this question based on an idea that occured to me, namely games may have multiple resolutions (mip maps) of a single texture. Up close it will be the highest resolution texture, far away the smallest, and in the middle it will be a medium resolution texture and the GPU filters between these.

Games like Kameo and PGR3 seems to have a lot of resources dedicated to compression, so I was thinking: Could a developer place ONLY the largest mip layer on the optical disk, and during loading dynamically generate the medium and small mip layers? e.g. 1024x1024 texture on a DVD9, and when loaded the CPU could then generated a 512x512 and 256x256 resolution texture from the original?

Although your technique may save some space (disc space), however the tradeoff would be adding more burden to CPU & GPU (especially in real-time) to calculate/recalculate every resize when needed.

 

[nAo]

You really don't want to generate mip maps for compressed DXTn textures at run time: mipmaps generation is easy and fast, quality compression is not.
Might be a viable idea for non compressed textures (let say high quality 2 channels normal maps) but I don't think it's worth the cost. What you really want to do with textures is to load them from disk in one single read already layed out and formatted as you need them in memory.

 

[Rodéric]

You really don't want to generate mip maps for compressed DXTn textures at run time: mipmaps generation is easy and fast, quality compression is not.
Might be a viable idea for non compressed textures (let say high quality 2 channels normal maps) but I don't think it's worth the cost. What you really want to do with textures is to load them from disk in one single read already layed out and formatted as you need them in memory.

That would be the DDS format on the PC.

 

[Cheezdoodles]

Here is a better idea - use procedural synthesis

 

[zed]

What other new tricks are being

hardly a new idea since its been widely used for years
api support for generating mipmaps based on the largest texture size is a very common feature

 

[ERP]

got the idea for this question based on an idea that occured to me, namely games may have multiple resolutions (mip maps) of a single texture. Up close it will be the highest resolution texture, far away the smallest, and in the middle it will be a medium resolution texture and the GPU filters between these.

We did this on a PS2 title, had the GS generate the MIP levels after the upload.
Purely to save memory, since it was a performance hit.

A lot of PC games let DX generate the MIPS.

 

[Fafalada]

We did this on a PS2 title, had the GS generate the MIP levels after the upload.
Purely to save memory, since it was a performance hit.

Some people actually gained performance that way (though they didn't remove mipmaps, they uploaded compressed maps and uncompressed after, the GS overhead is about the same, saved more memory then not storing mipmaps though), bus savings were enough to reduce their total rendering time.
But performance characteristics vary wildly depending on your setup - in our PS2 engine uploading mipmaps cut down GIF bus usage by a factor of 4-6 - so reverting to sending top levels only, would actually be a big performance hit even without the extra GS overhead for generating mips.