>
> O.k., here it is - Yadgar's Little Asteroid Modeling Tutorial:

FASCINATING! I *very* much appreciate the time you took to explain this method
so clearly. Mesh 2 generation has been one of those 'mysterious' POV-Ray tools
that I've never understood before. And eval() is another tool I haven't yet
used, but am looking forward to experimenting with.

Since I'm familiar with Photoshop rather than the GIMP, I think I can extract a
grayscale image from the asteroid map (or I'll just make up my own!)

> Now to the programming in POV-Ray:
> [snip]
> According to the number of pixels in both dimensions (x and y), we read
> in the color data from a nested loop; to get reliable results, we pick
> the color from the center of each pixel...

That's a nice, subtle addition to your code.

> Points on the surface of spheroids are defined by geographical
> coordinates (latitude and longitude), which are derived here from the
> two-dimensional coordinates of pixels in the greyscale map: the 800
> points per row equal 360 degrees of longitude, the 400 rows equal -90 to
> 90 degrees of latitude.

Does this introduce any distortion into the way the asteroid map is applied to
the object? (I guess I need to read up on latitude and longitude!) I'm thinking
there might be, at the North and South 'poles.' Just guessing, out of ignorance.

> The advantage of mesh2 object compared with the older mesh objects is
> that with a mesh2 object, each surface point (vertex) need to be
> declared and read into the internal calculation matrix only once, while
> the old mesh object consists of triangles as three-point triples, thus
> each triangle needed nine floating point values, which, with most points
> repeating, led to exponentially growing rendering times.

I do see the intrinsic speedup. Though it appears to me that 'coding' a mesh 2
(vs. mesh) object is more complex--but that's only because I'm so new to the
idea. *Everything* seems strange and complicated when it's new!

> So, we get the following code:
>
> mesh2
[snip]

>        #declare rd = 8.1+GrayValue*(14-8.1);
>        #declare SurfacePoint =
> <sin(radians(long(b*(360/800)))*cos(radians(lat(a*(180/400))),
> sin(radians(lat(a*(360/800))),
> cos(radians(long(b*(360/800)))*cos(radians(lat(a*(180/400)))>;
>        rd*SurfacePoint // the vertex must be generated explicitly, not
> just defined!
[snip]

So  rd*SurfacePoint  doesn't need a #declare or anything, it's just used as
written?

>
> This code renders in about one minute - an old-school mesh would have
> taken many hours even on a Athlon 64!

Wow! Impressive. Yes, I'm used to *s-l-o-w* meshes.

Thanks again for your clear explanation! I need to take some time to digest it
all.

I have a question about eval(): If you were to actually evaluate a 3-D pigment
pattern (rather than a 2-D image), could those points in 3-D space be used with
your method to construct a mesh 2 object? I realize this is a non-detailed (and
rather naive) question; what I have in mind is producing something like your
asteroid, but with 'overhangs and undercuts' in the triangle mesh, similar to
what would be produced by an isosurface function, as opposed to a height_field.
In other words, the triangle vertices would not be 'restricted' to just height
values from a central radius point, but would be scattered in true 3-D space.
(For example, the various mesh-generation macros in shapes.inc can produce HFs
in the shape of a cylinder, sphere, etc.--but the resulting mesh doesn't have
overhangs or undercuts. Which is understandable, because that's what a
height_field is.)  But a method to produce an isosurface-like shape as a mesh 2
object would be VERY useful!  And much faster to render. (I can foresee problems
with this idea, though--triangles that might 'fold over' onto other ones,
possibly creating degenerate triangles or visible holes.  I *think*! But that
doesn't seem to me to be an insurmountable problem.)

Ken W.

Post a reply to this message