hi,

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> ...
> >> This probably would not be possible, as 2 TB additional webspace is at
> >> the upper limit I can afford - and the original files come as *.zip from
> >> the NASA server...
> ...
> I tried xz... but my mesh2 inc files are still about 80 MB after
> compressing - so I will still need some 700 GB of webspace make them
> available for download. I recently did some research in webspace prices
> - and found out that 2 TB would be MUCH too expensive for me, as they
> usually are around 500 US$/year... the largest webspace offer I could
> afford is 500 GB for 36 euros/year, and that probably would be not
> enough for all 8000+ tiles processed into compressed mesh2 inc files.

on the source (zip) files -- you wrote a 3601x3601 tile needs ~1.5G.  that is
~115 bytes per pixel; likely, some/much of that information will not be
required.  suggest recoding those, to a custom file format.

on the mesh2 storage -- what if meshes were only created on-the-fly[*], when
needed for rendering that part of povearth?  sure, performance hits everywhere,
but within budget.

another "budgeting" option would be to focus on a single continent, initially,
and only produce those meshes.  (maybe, when you retire, your pension will allow
you to buy more cloud-storage.  :-))

[*] ini file 'Pre_{Frame,Scene}_Command'.


regards, jr.

Post a reply to this message

Hi(gh)!

On 13.04.20 11:26, jr wrote:

> just came across your .. brother-in-arms.  ;-)
> 
> <https://www.youtube.com/watch?v=8_bW3ab8YAk>

Yuck! That would be too chunky for me...

See you in Khyberspace!

Yadgar

Post a reply to this message

Hi(gh)!

On 13.04.20 12:23, jr wrote:

> on the source (zip) files -- you wrote a 3601x3601 tile needs ~1.5G.  that is
> ~115 bytes per pixel; likely, some/much of that information will not be
> required.  suggest recoding those, to a custom file format.

What do you mean with "custom file format"? Anything binary rather than 
text?

> on the mesh2 storage -- what if meshes were only created on-the-fly[*], when
> needed for rendering that part of povearth?  sure, performance hits everywhere,
> but within budget.

On the average raytracing geek's machine (if I regard my six-core AMD 
with 24 GB of RAM as average) this still would take 2 1/2 hours per 
elevation data tile... just downloading, decompressing and readily using 
them in a scene file would be faster!

> another "budgeting" option would be to focus on a single continent, initially,
> and only produce those meshes.

Yes, with POVghanistan only (160 tiles, liberally including also parts 
of neighbouring countries to have a neat rectangle - and, yes, doing the 
Shalimar Gardens at Lahore or the Golden Temple of Amritsar would be 
very nice, not to mention countless other examples of Mughal 
architecture throughout India and Pakistan), this would fit into my 
limited webspace resources...

>  (maybe, when you retire, your pension will allow
> you to buy more cloud-storage.  :-))

But cloud storage would not be publicly accessible, would it?
In fact, I am an early retiree... from a very patchy work life, so my 
pension is rather low, I can't help but having to win a lottery jackpot 
to be able to do full-fledged POVEarth... and also my other megalomaniac 
project, the Organ Palace - a museum showing all electronic organ models 
ever manufactured, at least in virtual space (X3D organs playable as VST 
instruments via MIDI keyboard(s) or even entire MIDI organ playtables) 
if not in the real world, then also containing a music school and 
concert venue... but there is no El Gordo in Germany!

See you in Khyberspace!

Yadgar

Post a reply to this message

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:

> What do you mean with "custom file format"? Anything binary rather than
> text?

No - I think what you need to do is what every computer graphics and movie set
designer does to get things like this to work - cheat like Hell.

You don't need 40 billion triangles where a few thousand, or a cleverly textured
primitive with normals will suffice.  I completely understand your goal - but at
the present, you will let the idea of the perfect sacrifice the reality of the
good.

If you have a very large tile - but there isn't much of note on it, then why
model every grain of sand?  Select the parts that NEED detail, and designate
those as meshes or some other detailed form.
What can you adequately get away with using heightfields, and planes and bezier
patches?

With bicubic patches - for the cost of only 16 control points you can get
2^u_steps x 2^v_steps triangles....

Fewer data points, less storage, less reading from disk - more interpolation and
procedural generation.

I'm not sure how all of the tiles are arranged on the globe - but I would start
with the framework, and decide how best to tile the surface.  Then when
rendering, the scene file only renders what is in view, and close enough to need
actual modeling.   Something like a view from space wouldn't need 8000 tiles -
you could do it like a soccer ball with 12 pentagons and 20 hexagons - or just
UV-map a sphere {}.  As you move in closer, the camera-globe distance determines
the model type and level of detail (LOD).


Then you can easily have 8000 tiles worth of renderable placeholders with
location markers, text for what you'd like to see there, comments in the code,
etc.  Missing tiles get a checkerboard or something to visually show that it's
missing.

I'd also institute a file naming system for easy version control, so that you
don't have to manually edit the parent pov file or parent inc file when changes
are made, but it's easy to see which one is newest.   "Tile 8000_2020_04_13.inc"
or something like that, and then you can include Tile 8000_*.inc" without
issues.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> ...
> You don't need 40 billion triangles where a few thousand, or a cleverly textured
> primitive with normals will suffice.  I completely understand your goal - but at
> the present, you will let the idea of the perfect sacrifice the reality of the
> good.

agree with this.  ~70% of the surface is ocean, so a lo-res representation of
that alone would lead to significant savings.

and the "Level Of Detail" point too is good.  how many people would want to zoom
in closely on deserts, or uninhabited areas in general?


regards, jr.

Post a reply to this message

Hi(gh)!

On 14.04.20 09:51, jr wrote:

> agree with this.  ~70% of the surface is ocean, so a lo-res representation of
> that alone would lead to significant savings.

But how to do this - as the reliefs are not "flat", but follow Earth's 
curvature?

See you in Khyberspace!

Yadgar

Post a reply to this message

hi,

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> On 14.04.20 09:51, jr wrote:
> > agree with this.  ~70% of the surface is ocean, so a lo-res representation of
> > that alone would lead to significant savings.
>
> But how to do this - as the reliefs are not "flat", but follow Earth's
> curvature?

o you could "mix" tiles.  using the 30m where detail matters, using 90m for
other areas.

o you could pre-process each ocean etc tile, averaging out N neighbouring
pixels.

o you could reduce the #vertices per mesh.  for instance, if the mesh data is
stored in GTS format, there's a tool ('gtstricutter' (have not used it (yet)))
which can remove triangles according to some constraints you supply on the
command-line.

there will any number of other ways too, I guess.


regards, jr.

Post a reply to this message

Hi(gh)!

On 14.04.20 11:57, jr wrote:

> o you could "mix" tiles.  using the 30m where detail matters, using 90m for
> other areas.
> 
> o you could pre-process each ocean etc tile, averaging out N neighbouring
> pixels.
> 
> o you could reduce the #vertices per mesh.  for instance, if the mesh data is
> stored in GTS format, there's a tool ('gtstricutter' (have not used it (yet)))
> which can remove triangles according to some constraints you supply on the
> command-line.
> 
> there will any number of other ways too, I guess.

Most likely, I will provide the data as heightfields rather than mesh2 
objects...

See you in Khyberspace!

Yadgar

Post a reply to this message

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!
>
> On 14.04.20 09:51, jr wrote:
>
> > agree with this.  ~70% of the surface is ocean, so a lo-res representation of
> > that alone would lead to significant savings.
>
> But how to do this - as the reliefs are not "flat", but follow Earth's
> curvature?
>
> See you in Khyberspace!
>
> Yadgar

http://www.econym.demon.co.uk/isotut/combine.htm
See:  "Addition and Subtraction"

You have latitude, longitude, and elevation.
Just modulate the elevation (radius)

A common way to approximate spheres is triangle subdivision, bumping the new
central vertex "out" to the radius.
http://news.povray.org/povray.binaries.images/thread/%3C57b60bd1$1@news.povray.org%3E/

So you'd just construct a base with a spherical curve (oblate spheroid geodesic)
and then add the height to the base.   "easy".  ;)

Post a reply to this message

> So you'd just construct a base with a spherical curve (oblate spheroid geodesic)
> and then add the height to the base.   "easy".  ;)
> 

And, than base can be a simple, boring, old sphere primitive with a 
water texture. To get the oblate shape, just use scale<1.003, 1, 1.003> 
with the Y axis coincident with the polar axis.

Post a reply to this message