link to this article

A Major Feature has been extended (GNU+Linux only, at the moment)

This is a frontline report. Frontline because I am telling you of a feature that is currently not portable and runs on *nix Operating Systems only, at the moment. Anyway, I am happy that the technique works, even if it's so slow for very large datasets that Path Tracing is not an option, yet. But I have to say I haven't really tested it with smaller heightmaps so far (that is for me heightmaps that are smaller than 16,000^2 pixels).

What I am talking about is the "Explicit Paging" technique mentioned in the last news. It means that only parts of the heightmaps are kept in actual memory, while most of it is stored on your harddisk. This keeps picogen's memory footprint small, which is a Good Thing if your render goes on in the background.

Additionally the new tec makes it possible to have more (depends on how much harddisk space you can afford) heightmap than is addressible on a 32bit-CPU, which is important because 32bit are sucked up fast if you render terrain.

So, here's the updated todo list (porting the tec to Windows is an implementation detail;)):

• Lazy Building: Build nodes in the hierarchy only if they are actually needed. Tests have shown that the size of the Quadtree can be reduced to 1/6th of the original size, and even less.
• (solved) Explicit Paging: Enable storage of rarely used nodes on harddisk (or similar) devices so that RAM pressure is reduced.
• Sub Pixel LOD: It is common that nodes in the Quadtree are much smaller than a Pixel, so determine the maximum (sane) level of detail for nodes. This will also help out the Explicit Paging above.

And now, ppl, the renditions!

32769² = 2147614722 ~= 2148 MTriangles ~= 2.1 GTriangles (next one will be 8 Gtris!)

grrr, 32k^2!

heat

Orodruin