Hi(gh)!

Still aiming at POVEarth/POVghanistan (and also high-quality renderings 
of other Solar System bodies) - but currently, there is a bottleneck 
when it comes to generating "spherical" (i. e. following Earth's 
curvature) mesh2s from 16-bit (or whatever format) heightfields!

The Japanese ASTER mission elevation tiles have a resolution of 3601 by 
3601 measuring points (i. e. pixels in a heightfield generated from 
these data) - but even with 16 GiB of RAM, I had to decrease the 
resolution to 2600 by 2600, otherwise POV-Ray would crash.

Of course this is because POV-Ray generates full ASCII code rather than 
(like with heightfields) binary data to internally represent the mesh2 
object.

Have there ever been any attempts to write a patch to make binary meshes 
feasible with POV-Ray?

See you in Khyberspace!

Yadgar

Post a reply to this message

Le 15-06-15 09:09, Jörg 'Yadgar' Bleimann a écrit :
>
> Hi(gh)!
>
> Still aiming at POVEarth/POVghanistan (and also high-quality renderings
> of other Solar System bodies) - but currently, there is a bottleneck
> when it comes to generating "spherical" (i. e. following Earth's
> curvature) mesh2s from 16-bit (or whatever format) heightfields!
>
> The Japanese ASTER mission elevation tiles have a resolution of 3601 by
> 3601 measuring points (i. e. pixels in a heightfield generated from
> these data) - but even with 16 GiB of RAM, I had to decrease the
> resolution to 2600 by 2600, otherwise POV-Ray would crash.
>
> Of course this is because POV-Ray generates full ASCII code rather than
> (like with heightfields) binary data to internally represent the mesh2
> object.
>
> Have there ever been any attempts to write a patch to make binary meshes
> feasible with POV-Ray?
>
> See you in Khyberspace!
>
> Yadgar

I'd start with an hight_field, then, start to play with functions and 
isosurface.
Take your TIFF image, convert it into an image pattern, then into a 
function.
The image's coordinates would become the longitudes and latitudes, to be 
adjusted by the base coordinates of the location to be rendered, and the 
values of each points would be added to a base radius to give the actual 
elevation.

Just don't convert into a mesh.



Alain

Post a reply to this message

Hi(gh)!

On 17.06.2015 23:54, Alain wrote:

> I'd start with an hight_field, then, start to play with functions and
> isosurface.
> Take your TIFF image, convert it into an image pattern, then into a
> function.
> The image's coordinates would become the longitudes and latitudes, to be
> adjusted by the base coordinates of the location to be rendered, and the
> values of each points would be added to a base radius to give the actual
> elevation.
>
> Just don't convert into a mesh.

O.k., this would avoid the memory-consuming generation of ASCII script 
code - of course at the expense of rendering time. But I never found out 
how to constrain such a function to a certain surface area defined by 
geographic coordinates rather than just producing a whole "sphere"...

The more sophisticated approach would be hacking the very source code of 
POV-Ray, adding an object type "Geo_Mesh", which internally would be 
treated just like a heightfield - you would specify an image map (or 
even ASCII matrix file) containing the elevation data, then geographic 
coordinates for opposite corners, finally the "base radius" of the 
sphere to which the elevation values would be added.

Does such a patch for POV-Ray already exist - or would I be the first to 
write it?

See you in Khyberspace!

Yadgar

Post a reply to this message

Le 15-06-18 21:26, Jörg 'Yadgar' Bleimann a écrit :
> Hi(gh)!

>
> O.k., this would avoid the memory-consuming generation of ASCII script
> code - of course at the expense of rendering time. But I never found out
> how to constrain such a function to a certain surface area defined by
> geographic coordinates rather than just producing a whole "sphere"...
>
> The more sophisticated approach would be hacking the very source code of
> POV-Ray, adding an object type "Geo_Mesh", which internally would be
> treated just like a heightfield - you would specify an image map (or
> even ASCII matrix file) containing the elevation data, then geographic
> coordinates for opposite corners, finally the "base radius" of the
> sphere to which the elevation values would be added.
>
> Does such a patch for POV-Ray already exist - or would I be the first to
> write it?
>
> See you in Khyberspace!
>
> Yadgar

I'd use a box to contain only the part to be used, dimentiones as small 
as possible. If the container is a sphere, then, it should be default to 
just a sphere outside the area of interest.
The max_gradient should be relatively low, in the 2.2 range, with a 
simple function. This should render reasonably fast. Using evaluate 
could make things go slightly faster.

As for the patch, I don't think it exist.




Alain

Post a reply to this message

Hi(gh)!

On 19.06.2015 16:30, Alain wrote:

> I'd use a box to contain only the part to be used, dimentiones as small
> as possible. If the container is a sphere, then, it should be default to
> just a sphere outside the area of interest.
> The max_gradient should be relatively low, in the 2.2 range, with a
> simple function. This should render reasonably fast. Using evaluate
> could make things go slightly faster.

You probably misunderstood me - I'm aware of a function which allows 
heightfields to be "wrapped" around a sphere as an isosurface (it's even 
included in the ready-made script texts with the Windows version of 
POV-Ray 3.7!). But this would apply to global heightfields - I instead 
thought of heightfields only covering a small tile of the surface, for 
example 1 by 1 degree, and they should not globally "wrap", but be 
constrained to their geographic coordinates!

> As for the patch, I don't think it exist.

Then I probably know what I have to do - perhaps around 2020, there 
might be an inofficial 3.7 (or 3.8) patch named "GeoPOV" which 
facilitates binary meshes ("Geo_mesh2")... but it would be a long and 
arduous task, especially for me who never modified professional C++ code!

See you in Khyberspace!

Yadgar

Post a reply to this message

Are you looking for omething like this?

http://www.imagico.de/

http://earth.imagico.de/gallery-menu.php?lang=en

-- 
-Nekar Xenos-

Post a reply to this message

Hi(gh)!

On 20.06.2015 06:53, Nekar Xenos wrote:
> Are you looking for omething like this?
>
> http://www.imagico.de/
>
> http://earth.imagico.de/gallery-menu.php?lang=en
>
Yes, but Christoph uses isosurfaces rather than meshes - much too slow 
for animations!

See you in Khyberspace!

Yadgar

Post a reply to this message

=?UTF-8?B?SsO2cmcgJ1lhZGdhcicgQmxlaW1hbm4=?= <yazdegird@gmx.de> wrote:
> Hi(gh)!
>
> Still aiming at POVEarth/POVghanistan (and also high-quality renderings
> of other Solar System bodies) - but currently, there is a bottleneck
> when it comes to generating "spherical" (i. e. following Earth's
> curvature) mesh2s from 16-bit (or whatever format) heightfields!
>
> The Japanese ASTER mission elevation tiles have a resolution of 3601 by
> 3601 measuring points (i. e. pixels in a heightfield generated from
> these data) - but even with 16 GiB of RAM, I had to decrease the
> resolution to 2600 by 2600, otherwise POV-Ray would crash.
>
> Of course this is because POV-Ray generates full ASCII code rather than
> (like with heightfields) binary data to internally represent the mesh2
> object.
>
> Have there ever been any attempts to write a patch to make binary meshes
> feasible with POV-Ray?
>
> See you in Khyberspace!
>
> Yadgar


Maybe adding  support for an existing library like Alembic format would solve
this request and some others?
https://en.wikipedia.org/wiki/Alembic_%28Computer_Graphics%29

or micro poly tesselation and displacement at rendertime, renderman style? Does
Aqsis have it? as an open source example?


I don't know much about all these solutions but I would love to be able to do
exactly the same thing you request.

Post a reply to this message

Am 22.06.2015 um 15:16 schrieb Mr:

> Maybe adding  support for an existing library like Alembic format would solve
> this request and some others?
> https://en.wikipedia.org/wiki/Alembic_%28Computer_Graphics%29

Nope. We need to transform it into a POV-Ray specific internal 
representation anyway.

> or micro poly tesselation and displacement at rendertime, renderman style?

I don't think this will fly; there are rendering algorithms where micro 
tesselation fits in easily, but raytracing isn't one of them.

Post a reply to this message

On 15/06/15 15:09, Jörg 'Yadgar' Bleimann wrote:
[...]
> The Japanese ASTER mission elevation tiles have a resolution of 3601 by
> 3601 measuring points (i. e. pixels in a heightfield generated from
> these data) - but even with 16 GiB of RAM, I had to decrease the
> resolution to 2600 by 2600, otherwise POV-Ray would crash.

Very very belated, but I've been doing something similar with my Flooded
Moon project (http://cowlark.com/flooded-moon). I have a bespoke tool
which takes a set of NASA PDS files and generates a mesh centred on the
camera, with the polygon size dropping off in the distance. You may find
it useful.

[...]
> Have there ever been any attempts to write a patch to make binary meshes
> feasible with POV-Ray?

I'd love such a thing --- particularly if it could be a format which
Povray could use directly without conversion. And then have it loaded
with mmap. Writing out 2GB of ASCII mesh out to disk just so I can load
it straight back in to memory is so *slow*, and all wasted work.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Post a reply to this message