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

"Kenneth" <kdw### [at] earthlinknet> wrote:
> 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.

Actually, if you are fine with generating mesh, then there is not much need to
go for mesh2: Both are compiled into the same internal data structures, with no
difference in memory or rendering speed efficiency whatsoever. Mesh2 is intended
for a more compact file format and easier generation by modeller software,
that's all.

Although it is not commonly known, POV-Ray does quite a good job at optimizing
mesh data, detecting identical vertices and normals and such.

Post a reply to this message

High!

Kenneth wrote:

> 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 maps to use here are so-called "simple cylindrical projections" - 
this means that on the map, longitudes and latitudes form a rectangular 
grid, each parallel crosses each meridian at a 90 degree angle, unlike 
in most other map projections which are designed to avoid as much 
distortion as possible. Also, with the simple cylindrical projection, 
all distances between latitudes are equal, unlike Mercator's projection 
which stretches to infinity at the poles. When "re-projected" to a 
sphere, the 2D distortion of the simple cylindrical projection disappears!

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

Yes, it is! With a mesh2 structure written by hand (without any loops), 
there also would be explicitly written vertex vectors, just like the 2D 
vectors you have to write when coding a prism!

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

Back in 2002, I tried to render a mesh (not mesh2!) of the Moon's 
surface generated with John Beale's "OrbCyl" tool - the whole thing took 
three days and was, as original map, only 1000 x 500 pixels large!

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

That would be pretty complicated to achieve with mathematic formulae... 
I think it would be much easier to do when modeling such surfaces 
intuitively with a graphical frontend, such as Wings3D, Hamapatch or 
Blender!

See you on www.khyberspace.de!

Yadgar

Now playing: Calling Your Name (Simple Minds)

Post a reply to this message

> The #if clause is necessary because the last vector statement must not be 
> followed by a comma.

In most cases in POV-Ray, an extra comma is permitted at the end of a list.

If that isn't the case for meshes, you can still go with the simpler

         <(a+1)*800+b, (a+1)*800+b+1, a*800+b+1>
         #if  ( b != 798 | a != 398 )
           ,
         #end

which doesn' t look like there's some crazy weird special case.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

=?UTF-8?B?SsO2cmcgJ1lhZGdhcicgQmxlaW1hbm4=?= <yazdegird@gmx.de> wrote:
> > 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 maps to use here are so-called "simple cylindrical projections" -
> this means that on the map, longitudes and latitudes form a rectangular
> grid, each parallel crosses each meridian at a 90 degree angle, unlike
> in most other map projections which are designed to avoid as much
> distortion as possible. Also, with the simple cylindrical projection,
> all distances between latitudes are equal, unlike Mercator's projection
> which stretches to infinity at the poles. When "re-projected" to a
> sphere, the 2D distortion of the simple cylindrical projection disappears!

The official cartographical term is "equidistant cylindrical projection" (aka
"plate carree projection").

Not to be confused with what POV-Ray calls a "cylindrical" projection - which
actually is an "equal-area cylindrical projection" (any subtype will do for
POV-Ray, e.g. Gall-Peters projection, Behrmann projection or Lambert
cylindrical equal-area projection, as they just differ in the way they are
"squeezed" to a certain aspect ratio, which is irrelevant for use in POV-Ray).

The "equidistant cylindrical projection" matches what POV-Ray calls "spherical
projection".

Post a reply to this message

"Slime" <fak### [at] emailaddress> wrote:
> > The #if clause is necessary because the last vector statement must not be
> > followed by a comma.
>
> In most cases in POV-Ray, an extra comma is permitted at the end of a list.
>
> If that isn't the case for meshes, you can still go with the simpler
>
>          <(a+1)*800+b, (a+1)*800+b+1, a*800+b+1>
>          #if  ( b != 798 | a != 398 )
>            ,
>          #end
>
> which doesn' t look like there's some crazy weird special case.

Another possibility would be to just add a "dead" vector to the end of the list
;)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Slime" <fak### [at] emailaddress> wrote:
> > > The #if clause is necessary because the last vector statement must not be
> > > followed by a comma.
> >
> > In most cases in POV-Ray, an extra comma is permitted at the end of a list.
> >
> > If that isn't the case for meshes, you can still go with the simpler
> >
> >          <(a+1)*800+b, (a+1)*800+b+1, a*800+b+1>
> >          #if  ( b != 798 | a != 398 )
> >            ,
> >          #end
> >
> > which doesn' t look like there's some crazy weird special case.
>
> Another possibility would be to just add a "dead" vector to the end of the list
> ;)

....or put the comma before the vector, so each vector supplies the comma for the
previous one, and the first one supplies the comma after the initial vector
total.

Post a reply to this message

High!

clipka wrote:

> The official cartographical term is "equidistant cylindrical projection" (aka
> "plate carree projection").

Yes, a "Rechteckige Plattkarte" in German!

> Not to be confused with what POV-Ray calls a "cylindrical" projection - which
> actually is an "equal-area cylindrical projection" (any subtype will do for
> POV-Ray, e.g. Gall-Peters projection, Behrmann projection or Lambert
> cylindrical equal-area projection, as they just differ in the way they are
> "squeezed" to a certain aspect ratio, which is irrelevant for use in POV-Ray).
> 
> The "equidistant cylindrical projection" matches what POV-Ray calls "spherical
> projection".

Interesting...are you a professional cartographer/student of geography?

See you in Khyberspace!

Yadgar

Now playing: New Gold Dream (Simple Minds) - my very first CD, back in 1987!

Post a reply to this message

=?ISO-8859-1?Q?J=F6rg_=27Yadgar=27_Bleimann?= <yaz### [at] gmxde> wrote:
> High!
>
> > The official cartographical term is "equidistant cylindrical projection" (aka
> > "plate carree projection").
>
> Yes, a "Rechteckige Plattkarte" in German!

Sounds like a typical German army term...

> Interesting...are you a professional cartographer/student of geography?

No, just an incredibly nosey person - all I *really* knew was how the
projections in POV are defined mathematically, and that there was obviously an
issue of technical terms when I saw you call POV's "spherical" projection a
"cylindrical" projection; everything beyond "caution, there's potential for a
mixup here" was the result of some WIYF'ing, to make that statement a bit more
precise... and make me appear smarter than I really am :P

(If you'd ask me about the same stuff tomorrow, I'd probably have to look it up
all over again... though I'd get there a bit quicker ;))

Post a reply to this message

Among other things, clipka saw fit to write:

> The official cartographical term is "equidistant cylindrical projection"
> (aka "plate carree projection").
> 
> Not to be confused with what POV-Ray calls a "cylindrical" projection -
> which actually is an "equal-area cylindrical projection" (any subtype will
> do for POV-Ray, e.g. Gall-Peters projection, Behrmann projection or
> Lambert cylindrical equal-area projection, as they just differ in the way
> they are "squeezed" to a certain aspect ratio, which is irrelevant for use
> in POV-Ray).

Just today I've been reading about those in Wikipedia, but I was creating
maps with GMT (Generic Map Tools), nothing related to POV-Ray :)

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