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