Hi all,

This must have been done hundreds of times, but well... there's no harm done
in discussing it once again.

I'm interested in modelling a "realistic" shape of our planet. With this I
mean basically a sphere (or spheroid) with a surface displacement matching
elevation/relief data. So far so good, I have the sphere and I have the
elevation data (<http://www.ngdc.noaa.gov/mgg/global/global.html>), I don't
need more resolution, but I don't want much less either.

Now the question is how to put them together in POV-Ray. The most obvious
solution is an isosurface. I created a 16-bit PGM file, 21600x10801 pixels,
a spherical image map of this file (in a pigment, in a function), and then
an isosurface of an sphere plus this function's .hf component. This works
fine, everything's OK, but it's sloooow (especially if I want radiosity,
refractions, etc).

The other solution is creating a mesh out of this data. I tried using the
HF_Sphere macro, but I'm afraid I need much better resolution than
possible. The maximum resolution vector I could use was about <500,1000>
(larger dimensions gave parsing errors in shapes.inc), and I'd need
<10801,21600>. For a total vertex number larger than a few million, this
number is written in exponential notation, and I don't think the mesh2
parser likes that. Besides, I'm afraid the file created (if I want
HF_Sphere to write a file) would be really huge.

Any thoughts? Other solutions? Fixes for HF_Sphere?

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

Jellby <me### [at] privacynet> wrote:
> I'm interested in modelling a "realistic" shape of our planet. With this I
> mean basically a sphere (or spheroid) with a surface displacement matching
> elevation/relief data. [...]
>
> Any thoughts? Other solutions? Fixes for HF_Sphere?

For a truly *realistic* shape, just use a plain sphere and bump mapping - you'll
not notice the difference anyway. We're talking about roughly 1.4/1000th of the
radius.

If you need to zoom in to such a scale that size does matter, you may want to go
for a classic height field based on a subsection of the image.

Post a reply to this message

Amongs other things, clipka saw fit to write:

> For a truly *realistic* shape, just use a plain sphere and bump mapping -
> you'll not notice the difference anyway. We're talking about roughly
> 1.4/1000th of the radius.

Erm... yes, sorry, you are perfectly right and I knew that. I really didn't
mean realistic to that extent, in other words, I want to (greatly)
exaggerate the relief :)

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

"Jellby" <me### [at] privacynet> wrote in message 
news:i4a### [at] badulaqueunexes...
> Amongs other things, clipka saw fit to write:
>
>> For a truly *realistic* shape, just use a plain sphere and bump mapping -
>> you'll not notice the difference anyway. We're talking about roughly
>> 1.4/1000th of the radius.
>
> Erm... yes, sorry, you are perfectly right and I knew that. I really 
> didn't
> mean realistic to that extent, in other words, I want to (greatly)
> exaggerate the relief :)
>

It's a bit convoluted, so there may be a better way but:

You could use a tiff as an image_map in a pigment. So with map_type 1 you 
get a spherical pigment and can use it in a function.
Combining that function and a sphere function in an Isosurface you should be 
able to get what you want. You could parameterise it and make it pulse or 
add other functions to make it wiggle etc.

I did a quick Google and found an example by Ron Parker at 
http://www.geocities.com/Athens/Academy/8764/spovraydjgpp.html (bottom 
right).   Although it says it's for 3.1g with a patch, I believe that 
something similar should work with an unpatched 3.6.1 or 3.7 Beta (I didn't 
try it though).

Regards,
Chris B.

Post a reply to this message

Among other things, Chris B saw fit to write:

> It's a bit convoluted, so there may be a better way but:
> 
> You could use a tiff as an image_map in a pigment. So with map_type 1 you
> get a spherical pigment and can use it in a function.
> Combining that function and a sphere function in an Isosurface you should
> be able to get what you want. You could parameterise it and make it pulse
> or add other functions to make it wiggle etc.

I did that already, but with a 16-bit PGM instead of tiff, as I said in my
first message. The drawback is that since it is an isosurface it is very
slow. Building a mesh from the data would be better, but at the resolution
I need/want the macros/parsing don't seem to work fine (but I guess I have
enough memory, I can use the image_map after all, and there are 2GB in the
machine).

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

----- Original Message ----- 
From: "Jellby" <me### [at] privacynet>
> The other solution is creating a mesh out of this data. I tried using the
> HF_Sphere macro, but I'm afraid I need much better resolution than
> possible. The maximum resolution vector I could use was about <500,1000>
> (larger dimensions gave parsing errors in shapes.inc), and I'd need
> <10801,21600>. For a total vertex number larger than a few million, this
> number is written in exponential notation, and I don't think the mesh2
> parser likes that. Besides, I'm afraid the file created (if I want
> HF_Sphere to write a file) would be really huge.
>

I took a look at HF_Sphere and I think you can let it produce pieces of for
instance 15 degrees in stead of 180 degrees (just like the pieces inside an
orange).
You have to produce 24 of them for the whole earth and use the pieces that
are visible. You don't need the back side of earth.
Experiment with the line:

#local Dir = vrotate( vrotate(x,(-89.9999+179.9998*UV.z)*z), -360*UV.x*y );

If I understand the macro correctly it rotate from -90 until +90 degrees.

Just a thought.

Success

Jaap Frank

Post a reply to this message

"Jellby" <me### [at] privacynet> wrote in message 
news:trj### [at] badulaqueunexes...
> Among other things, Chris B saw fit to write:
>
>> It's a bit convoluted, so there may be a better way but:
>>
>> You could use a tiff as an image_map in a pigment. So with map_type 1 you
>> get a spherical pigment and can use it in a function.
>> Combining that function and a sphere function in an Isosurface you should
>> be able to get what you want. You could parameterise it and make it pulse
>> or add other functions to make it wiggle etc.
>
> I did that already, but with a 16-bit PGM instead of tiff, as I said in my
> first message. The drawback is that since it is an isosurface it is very
> slow. Building a mesh from the data would be better, but at the resolution
> I need/want the macros/parsing don't seem to work fine (but I guess I have
> enough memory, I can use the image_map after all, and there are 2GB in the
> machine).

I think the problem with your isosurface is that you are using too high a 
resolution for the image map... Assuming you arent going to render this at a 
stupidly large resolution like 32000x24000, the details on your image map 
will be smaller than the pixels in the resulting image.

I just rendered up an image at 1024x768 AA 0.3 using the isosurface 
technique and a 4000x2000 image map and it rendered in just over a minute on 
my Q6600.

Rarius

Post a reply to this message

http://earth.imagico.de/

I think he discusses technique somewhere there.

Post a reply to this message

Jellby wrote:

> Any thoughts? Other solutions? Fixes for HF_Sphere?

You really need separate levels of detail (LoD) for what you're trying 
to model.  When the whole planet is in view, even the largest mountains 
occupy only a handful of pixels, and therefore a low resolution map will 
do fine.  For closer views, you need greater detail, but only of the 
areas that are actually in view.

So you need the capability to tell what's actually in the camera's view, 
and to parse the maps for that area for the level of detail appropriate 
to that view.

Regards,
John

Post a reply to this message

I was a bit to fast. The 180 degrees is for top down. The 360 degrees is 
around the earth.

Jaap

"Jaap Frank" <jjf### [at] casemanl> schreef in bericht 
news:49da3f5d$1@news.povray.org...
> ----- Original Message ----- 
> From: "Jellby" <me### [at] privacynet>
>> The other solution is creating a mesh out of this data. I tried using the
>> HF_Sphere macro, but I'm afraid I need much better resolution than
>> possible. The maximum resolution vector I could use was about <500,1000>
>> (larger dimensions gave parsing errors in shapes.inc), and I'd need
>> <10801,21600>. For a total vertex number larger than a few million, this
>> number is written in exponential notation, and I don't think the mesh2
>> parser likes that. Besides, I'm afraid the file created (if I want
>> HF_Sphere to write a file) would be really huge.
>>
>
> I took a look at HF_Sphere and I think you can let it produce pieces of 
> for
> instance 15 degrees in stead of 180 degrees (just like the pieces inside 
> an
> orange).
> You have to produce 24 of them for the whole earth and use the pieces that
> are visible. You don't need the back side of earth.
> Experiment with the line:
>
> #local Dir = vrotate( 
> vrotate(x,(-89.9999+179.9998*UV.z)*z), -360*UV.x*y );
>
> If I understand the macro correctly it rotate from -90 until +90 degrees.
>
> Just a thought.
>
> Success
>
> Jaap Frank
>
>
>

Post a reply to this message