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

Among other things, myself wrote:

> Any thoughts? Other solutions? Fixes for HF_Sphere?

Thank you all for your comments.

First, the though thing. I should be ashamed of myself, it turn out I had
commented this same issue 4 years ago:

http://news.povray.org/povray.general/thread/%3C41d6bd46@news.povray.org%3E/
http://news.povray.org/povray.bugreports/thread/%3Cgk91u0h8lh17tscq6hplsijdfpcsmdt5j5%404ax.com%3E/

so now, if I apply my own patch, I shold be able to do more testing.

I am rendering an image at 4000x3000 resolution, and most of the screen is
filled by the modelled Earth and it's reflection (this makes it not too
useful to try to restrict the modelling to the visible parts, since between
the reflection and the shadows, most of the surface plays some role).

As for whether I need so high a resolution for the elevation data
(20000x10000), probably not, and I'm not aiming at close-ups or landscapes
(like in Chris Hormann's page, wonderful pictures!). But tried with
something like 4000x2000 and it wasn't really enough for final the
resolution I'm aiming at.

Anyway, I don't think the problem with the isosurface is the resolution, it
is equally (more or less) slow with a lower resolution image map, it is the
isosurface itself, plus radiosity, antialiasing, photons, reflections,
refractions... :D But I guess a mesh should improve speed over the
isosurface.

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

Rarius wrote:
> "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 
> 
> 

IIRC someone wrote an isosurface to mesh converter, but I had problems 
getting it to work.

-Mike

Post a reply to this message

Among other things, Jellby saw fit to write:

> so now, if I apply my own patch, I shold be able to do more testing.
>
> I am rendering an image at 4000x3000 resolution, and most of the screen is
> filled by the modelled Earth and it's reflection (this makes it not too
> useful to try to restrict the modelling to the visible parts, since
> between the reflection and the shadows, most of the surface plays some
> role).

Well, I managed to create a 7500x3750 mesh of the data in a 16GB-RAM machine
(how much more memory does a mesh take compared to an image map?), and it
doesn't look so well, though maybe it could be fixed with some normals and
double-illuminate. The good news is the mesh renders about twice faster.

-- 
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:
> Well, I managed to create a 7500x3750 mesh of the data in a 16GB-RAM machine
> (how much more memory does a mesh take compared to an image map?),

Well, let's see...

We have ~ 30 MPixels.

Let us assume for now that you're not using any bells and whistles, just plain
flat triangles.

For each pixel, one vertex and two triangles are created: 30 MVertices and 60
MTriangles.

Each vertex has a 3D co-ordinate associated, using low-precision (32-bit)
floats: 12 bytes per vertex, 360 Mbytes in total.

Each triangle has the following information associated:
- two 1-bit flags
- three 32-bit integer vertex indices
- three 32-bit integer texture indices (may be unused)
- three 32-bit integer normal indices (may be unused)
- three 32-bit integer UV co-ordinate indices (may be unused)
In addition, the following additional information is precomputed for
performance:
- two 2-bit "flag-alikes"
- a 32-bit integer reference to the triangle's unsmoothed normal vector
- a 32-bit float storing the offset of the triangle to <0,0,0> along the normal
- some 3D low-precision helper vector for smoothed triangles (may be unused)
=> 17 32-bit values and a few bits (which will probaby padded to 32 bit): 68
bytes per triangle, ~4Gbytes in total.

But here's more to come: We mentioned an integer reference to the triange's
surface normal; that normal is stored somewhere else - in worst case, one
normal per triangle (note however that here's a hint for saving space:
Triangles on parallel planes can share normal data! Similarly, a mesh2 may be
reduced in size by using a kind of "normal palette"), each normal being a 3D
low-precision vector: 12 bytes per normal, 720 Mbytes in total in worst (and
not much less in typical) case.

Then, we have the mesh's internal bounding mechanism: Each triangle will add at
least a "leaf" to the bounding hierarchy, and possibly a "node" as well; each
node and leaf stores the following information:
- a flag
- a 16-bit integer holding the number of children
- six 32-bit floats describing the extents of the bounding box
- a pointer to the list of children (as you mention a 16 GB system, this will be
64 bit in your case)
=> 36 bytes per triangle (minimum), ~2 GBytes in total

Note that this is still without UV co-ordinates or smooth normals.

So even with a plain vanilla mesh, this one comes at about ~7 GBytes.

It should be possible to reduce the overhead for vanilla meshes a bit; however,
I don't think it will be possible to save much more than 0.5 GByte.


A few things to note:

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

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

Post a reply to this message

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