How Much Memory Does This Planet Need?

These are the numbers I'm using for the planet in the video and below are estimates of how much uncompressed memory would be needed for a planet with these properties:

Patch Size (# vertices on a single patch edge): 33
Max Depth of Quad Tree: 5
Texture Size Per Patch: 128 x 128

Assuming I could use a single height map, normal map and tangent map and sample them by using geomipmapping:
16 bit height map memory = 6 faces x ((33 verts per patch x 2^(max depth + 1)) - (2^(max depth + 1) - 1))^2 x 2 (because 16 bit)
= 6 x ((33 x 64) - (64 - 1))^2 x 2
= 6 x (2049 x 2049) x 2
= 6 x 8,396,802
= 58,777,614 bytes

8 bit normal map memory = 6 faces x ((33 verts per patch x 2^(max depth + 1)) - (2^(max depth + 1) - 1))^2 x 3 (for x,y,z)
= 6 x (2049 x 2049) x 3
= 75,571,218 bytes

tangent map is the same size as normal map

128x128 textures memory: this is a summation for each level or you can just calculate the amount needed for the deepest level and multiply by 1/3rd for a ceiling estimate (same estimate used when doing mip mapping) because each level is one mip map level lower than the level below it.
= 6 faces x texture size x num patches at lowest level x num bytes per pixel
= 6 faces x (128 x 128) x (2^(max depth + 1))^2 x 3
= 6 x (128 x 128) x 4096 x 3
= 1,207,959,552 bytes
ceiling = 1,207,959,552 + (1,207,959,552 / 3) = 1,610,612,736 bytes

So the total is:
58,777,614 + 75,571,218 + 75,571,218 + 1,610,612,736
= 1,820,532,786 bytes

So just under 2 GB for a single planet and nothing else. While 2GB is not an unreasonable amount of RAM to ask a gaming rig to set aside these days it is still too much if you want to have a lot of other models, animations and textures loaded. That's why I've been working on resource management more than anything else.

I would like to allow the entire planet to be custom made and loaded from disk rather than just generated on the fly and I'd like to be able to support a combination of both. The idea is that a planet starts out randomly generated and then get's customized by the artist - this should work well in cases where you have a couple continents and the rest is ocean floor, or where you have a moon that is not customized at all. No reason for your artists to spend time on the ocean floor usually, and hopefully they can tweak the generation parameters to get close the the type of land formations they want.

Really, I could load the height map into memory and always generate the normals and tangents based on the height map. The textures would be too large to keep all in memory at once so I would still have to load/unload those as needed.

Alternately, I could scrap the whole texture per patch thing and go back to some blended texture pixel shader based on a blend map that is the same resolution as the height maps ( 6 x (2049 x 2049) x 8 layers = 201,523,248 bytes)

MyFirstPlanet Video

Here's the first video showing the planet with textures and atmosphere shader. I used fraps (windows only) and recorded it while running in OpenGL mode. DirectX would probably be smoother but I haven't ported the shaders to HLSL yet.

My First Planet - Work In Progress - Ogre3d Engine from petrocket on Vimeo.

Now I'm still working on a simple way to pull terrain patch textures and normal maps from the disk when they're available instead of creating them on the fly - this way I hope to be able to modify the diffuse textures and customize the planet (so easy to say, so hard for me to do).

My first idea is to create a resource pool for the terrain patch diffuse images and normal map images and then load files from disk into those resource pools as need from the build thread. Not sure if this will work well enough because it may just not be loading enough images in advance to keep ahead of demand.

I should probably create a second thread that is a low priority thread with an entirely different quad tree based on the camera position in the future (assuming the user keeps moving in the same direction). I could update this quad tree and load images for this future position when the real camera position based quad tree isn't updating/building (and when would that be???)