Among other things, clipka saw fit to write:

> Well, let's see...
> 
> We have ~ 30 MPixels.
> 
> [...]
> 
> So even with a plain vanilla mesh, this one comes at about ~7 GBytes.

Hmm... that means I'll be probably sticking with an isosurface for this
project (I'd lose more time trying to get everything right and optimize it
than rendering the isosurface version, and I have a deadline to meet :D).
The image-map-based isosurface would take, I guess, around 360 MB (3x32
bits per pixel, although the image itself is only a sixth of that (16-bit
grayscale)), and even the full resolution version is manageable.

Thanks for the report, by the way :)

> - 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).

Yes, I had already thought of this. I have a fortran subroutine somewhere to
subdivide a pentakis dodecahedron (60 triangles, 32 vertices) that I could
use but (see above) I don't think I'm going to deal with this now.

But I may write something some day.

> - 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).

That, unless there is some ready-to-use macro, I'm afraid is beyond my
abilities at the moment.

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message