Hi(gh)!

I succeeded in implementing Melody's macros to my POVEarth/POVghanistan 
script, so I can provide you with a first test rendering... but as 
generating smooth triangles and consecutively entire mesh2 objects 
entirely with POV-Ray SDL is abysmally sloooooooooow, I had to scale the 
altitude data resolution from originally 3600 by 3600 down to 100 by 100 
measuring points - and even this took 37 minutes. Generating the mesh2 
in the original resolution would take a whopping 33.3 days!

This has to be accelerated, of course - and I'll do this by converting 
both Melody's code for generating the normals and my code for generating 
the mesh2 object to C or C++. When this works, I'll start generating 
pre-calculated mesh2s from ASTER ASCII data tiles for the whole land 
surface of Earth and provide them for download on my webspace! So 
finally after 14 years (remember my posting from September 11, 2005?), 
the POVEarth project starts to gain momentum...

See you in Khyberspace!

Yadgar

Post a reply to this message

Attachments:
Download '2019-12-06 povghanistan test render, 100x100 matrix.jpg' (28 KB)

Preview of image '2019-12-06 povghanistan test render, 100x100 matrix.jpg'

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> Hi(gh)!
>
> I succeeded in implementing Melody's macros to my POVEarth/POVghanistan
> script, so I can provide you with a first test rendering... but as
> generating smooth triangles and consecutively entire mesh2 objects
> entirely with POV-Ray SDL is abysmally sloooooooooow, I had to scale the
> altitude data resolution from originally 3600 by 3600 down to 100 by 100
> measuring points - and even this took 37 minutes. Generating the mesh2
> in the original resolution would take a whopping 33.3 days!
>
> This has to be accelerated, of course - and I'll do this by converting
> both Melody's code for generating the normals and my code for generating
> the mesh2 object to C or C++. When this works, I'll start generating
> pre-calculated mesh2s from ASTER ASCII data tiles for the whole land
> surface of Earth and provide them for download on my webspace! So
> finally after 14 years (remember my posting from September 11, 2005?),
> the POVEarth project starts to gain momentum...
>
> See you in Khyberspace!
>
> Yadgar

ay cool. and learned something. I suspected like a billion points or something
... heh 33.days.

Hawaii was only 14 height_fields, setup internally took 10 secs.
14 1201x1201 tga images -
found DEMs of the world abysmally lacking, when supposedly we have 3.4 meters
data ... now that has to be ... ever calculate it? a lot of data!

I saw compiled .hgt files,  it seems the DEM project is outdated, but still
lives.

https://gis.stackexchange.com/questions/43743/extracting-elevation-from-hgt-file

yes,
loops in script too slow? compile with code::blocks.

Post a reply to this message

" ....
"big-endian" order with the most significant byte first, directly readable by
systems such as Sun SPARC, Silicon Graphics and Macintosh computers using
PowerPC processors. DEC Alpha, most PCs and Macintosh computers built after 2006
use Intel ("little-endian")

that was the deal it seemed ... when I made mozart.wav files from sheet music
integers. never understood it, used endian code prewritten, but did 4
variations.

byte-swapping, argh.

does anyone grok that stuff?

Post a reply to this message

"Melody" <nomail@nomail> wrote:
> " ....
> "big-endian"  / Intel ("little-endian")
>
I still have the wavform maker,
u can listen to computer generated Mozart while trying to grok byte swapping
code. another code::blocks project I did.

Post a reply to this message

Hi(gh)!

On 06.12.19 22:10, Melody wrote:

> ay cool. and learned something. I suspected like a billion points or something
> ... heh 33.days.

I think pre-calculating the mesh2 using C++ will speed things up at 
least three orders of magnitude!

> 
> Hawaii was only 14 height_fields, setup internally took 10 secs.
> 14 1201x1201 tga images -
> found DEMs of the world abysmally lacking, when supposedly we have 3.4 meters
> data ... now that has to be ... ever calculate it? a lot of data!
> 
> I saw compiled .hgt files,  it seems the DEM project is outdated, but still
> lives.
> 
> https://gis.stackexchange.com/questions/43743/extracting-elevation-from-hgt-file

I have the whole ASTER elevation data set (3601 by 3601 measuring points 
per square degree!) locally on my external hard disk... and if I get the 
C++ solution running, I'll start uploading pre-calculated mesh2s 
generated from the original ASCII tiles for each data tile onto my webspace!

> yes,
> loops in script too slow? compile with code::blocks.

Compiling? A POV-Ray script? Please explain...

See you in Khyberspace!

Yadgar

Post a reply to this message

hi,

"Melody" <nomail@nomail> wrote:
> " ....
> "big-endian" order with the most significant byte first, ...
> byte-swapping, argh.
>
> does anyone grok that stuff?

(hoping that's not a rhetorical question.  :-))

I like the library to "do stuff", so use 'htonl()' etc whenever possible.  see
man section 3.


regards, jr.

Post a reply to this message

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

> Compiling? A POV-Ray script? Please explain...
>
> See you in Khyberspace!
>
> Yadgar

I mean - for instance, compile the logic of conversion,
data to tga, a means povray can accept quickly as a height_field.

Another way to get .hgt data, (had to translate)
http://webglbasic.com/index.php/hgt-konverter

"It can then be converted to HTML, OBJ, or PLANE based on color and height."

then of course, if you have .obj file,
use poseray to make a POV model for you.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> (hoping that's not a rhetorical question.  :-))
>
> I like the library to "do stuff", so use 'htonl()' etc whenever possible.  see
> man section 3.
>
>
> regards, jr.

 htonl() and ntohl()

found it thanx

Post a reply to this message

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

> I have the whole ASTER elevation data set (3601 by 3601 measuring points
> per square degree!)

I'm thinking that there ought to be a way to compress a lot of that in order to
save space and possibly make render time faster as well.

I mean, just consider a case where an entire tile was dead flat.  You could
render that with
plane {}, 2 triangle {}s, or a box {}

Scroll down to "Data Compression" to see what I mean, more generally.
http://www.ams.org/publicoutreach/feature-column/fcarc-svd

Maybe just make sure that the elevation data is saved in a compressed image
format like jpg or something that simple...

I mean, especially if certain areas are shifting sand, or you can get away with
a more generic representation of certain mountains, etc.

(I wonder if a DEM tile could be Fourier transformed, and then the results used
to mathematically create an internal image on the fly, or make a grid of Bezier
patches using the Fourier data for the Bernstein polynomial coefficients....)

Post a reply to this message

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> > I have the whole ASTER elevation data set (3601 by 3601 measuring points
> > per square degree!)
>
according to DEMPOV Hawaii is 1201x1201 per degree,
spatialResolution 3 3 1 is still 90 meters res, it seems. and u have 30 meters.

so what file format is 3601? hgt?

see just need to write it,
your format to pov mesh2 with normals and to image.
and compile it.

send me a sample. heh

Post a reply to this message