Jellby <me### [at] privacynet> wrote:
> Well, I managed to create a 7500x3750 mesh of the data in a 16GB-RAM machine
> (how much more memory does a mesh take compared to an image map?),

Well, let's see...

We have ~ 30 MPixels.

Let us assume for now that you're not using any bells and whistles, just plain
flat triangles.

For each pixel, one vertex and two triangles are created: 30 MVertices and 60
MTriangles.

Each vertex has a 3D co-ordinate associated, using low-precision (32-bit)
floats: 12 bytes per vertex, 360 Mbytes in total.

Each triangle has the following information associated:
- two 1-bit flags
- three 32-bit integer vertex indices
- three 32-bit integer texture indices (may be unused)
- three 32-bit integer normal indices (may be unused)
- three 32-bit integer UV co-ordinate indices (may be unused)
In addition, the following additional information is precomputed for
performance:
- two 2-bit "flag-alikes"
- a 32-bit integer reference to the triangle's unsmoothed normal vector
- a 32-bit float storing the offset of the triangle to <0,0,0> along the normal
- some 3D low-precision helper vector for smoothed triangles (may be unused)
=> 17 32-bit values and a few bits (which will probaby padded to 32 bit): 68
bytes per triangle, ~4Gbytes in total.

But here's more to come: We mentioned an integer reference to the triange's
surface normal; that normal is stored somewhere else - in worst case, one
normal per triangle (note however that here's a hint for saving space:
Triangles on parallel planes can share normal data! Similarly, a mesh2 may be
reduced in size by using a kind of "normal palette"), each normal being a 3D
low-precision vector: 12 bytes per normal, 720 Mbytes in total in worst (and
not much less in typical) case.

Then, we have the mesh's internal bounding mechanism: Each triangle will add at
least a "leaf" to the bounding hierarchy, and possibly a "node" as well; each
node and leaf stores the following information:
- a flag
- a 16-bit integer holding the number of children
- six 32-bit floats describing the extents of the bounding box
- a pointer to the list of children (as you mention a 16 GB system, this will be
64 bit in your case)
=> 36 bytes per triangle (minimum), ~2 GBytes in total

Note that this is still without UV co-ordinates or smooth normals.

So even with a plain vanilla mesh, this one comes at about ~7 GBytes.

It should be possible to reduce the overhead for vanilla meshes a bit; however,
I don't think it will be possible to save much more than 0.5 GByte.


A few things to note:

- Using a rectangular grid isn't the most efficient way to build a roughly
spherical mesh: You get an unnecessarily high number of vertices at the poles
(which will actually be distributed highly anisotropically and therefore prone
to causing artifacts). You may want to go for a geosphere approach instead
(i.e. a subdivided polyhedron - typically based on an icosahedron, but a
cube-based one may be easier to start with).

- At that resolution, I guess you definitely want to go for adaptive resolution
in the mesh, reducing the vertex density with distance from the camera (and
even more so outside the camera's view; even if those areas should show up in
reflections, you'll probably not need them to be full resolution - if you need
them at al).

Post a reply to this message