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

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

>
> ... from the original ASCII tiles ...

so if not hgt, thats even easier, no byte swapping

scanning files is well demonstrated in C
main.c that is, its in utilities

sample would be cool

Post a reply to this message

Hi(gh)!

On 09.12.19 08:36, Melody wrote:
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> 
>>
>> ... from the original ASCII tiles ...
> 
> so if not hgt, thats even easier, no byte swapping
> 
> scanning files is well demonstrated in C
> main.c that is, its in utilities
> 
> sample would be cool

Sorry that I have to disappoint you - but doing this in C++ turned out 
to be even slower than in POV-Ray SDL! Roughly estimated, a complete 
3601 by 3601 mesh2 will now take 115 days to be processed...

On the other hand, with anti-aliasing I probably get rid of the artifact 
pixels (at least a test render with only 100 by 100 measuring points 
looks that way)... currently, I generate a full-resolution mesh2 for the 
Kabul area, which will be done in about 90 minutes.

See you in Khyberspace!

Yadgar

Post a reply to this message