POV-Ray : Newsgroups : povray.binaries.images : #read: why is the second variable undeclared? Server Time
31 Jul 2024 02:21:08 EDT (-0400)
  #read: why is the second variable undeclared? (Message 1 to 6 of 6)  
From: Jörg 'Yadgar' Bleimann
Subject: #read: why is the second variable undeclared?
Date: 21 Apr 2010 11:05:48
Message: <4bcf144c$1@news.povray.org>
High!

As rendering Ghurghusht scenes using an isosurface for the planetary 
terrain, I decided to use meshes generated from it in the future. First, 
I have to find out most accurately the minimum and maximum elevations of 
the isosurface terrain by probing altitude with trace(). To get a really 
accurate representation, I divided the whole surface in 2592 (72 by 36) 
tiles, each covering 5 x 5 degrees by 1800 x 1800 pixels (o.k., each 
tile takes about 40 minutes, so the whole probing and afterwards, the 
creation of heightfields would be done after eight months, assuming that 
the computer runs 14 hours/day on average - but I hope this effort will 
pay off later when rendering surface animations!). While running through 
them using the clock variable, after each "frame" the current minimum 
and maximum values are stored in a tiny ASCII file just conisting of 
these two values separated by a tab.

Here is the code for the read routine:

       #fopen mm "minmax" read
       #while (defined(mm))
         #read (mm, min_file, max_file)
       #end
       #fclose mm
       #declare min_el=min_file;
       #declare max_el=max_file;

...but now I always get the error message "Cannot assign uninitialized 
identifier." Why? According to the manual, it's legal to read more than 
one variable from an ASCII file...

See you in Khyberspace!

Yadgar


Post a reply to this message

From: Vincent Le Chevalier
Subject: Re: #read: why is the second variable undeclared?
Date: 21 Apr 2010 11:52:57
Message: <4bcf1f59$2@news.povray.org>
Jörg 'Yadgar' Bleimann wrote:
> the current minimum 
> and maximum values are stored in a tiny ASCII file just conisting of 
> these two values separated by a tab.

The documentation says the values have to be separated by commas. 
Replace your tab by a comma and it should work fine...

-- 
Vincent


Post a reply to this message

From: Jörg 'Yadgar' Bleimann
Subject: Re: #read: why is the second variable undeclared?
Date: 21 Apr 2010 14:49:07
Message: <4bcf48a3$1@news.povray.org>
High!

Vincent Le Chevalier wrote:

> The documentation says the values have to be separated by commas. 
> Replace your tab by a comma and it should work fine...

No, it doesn't... either (when I initialize the two variables before 
opening the text file) both variables are set to zero with each new 
"frame", or (when I do not initialize) I still get the error message 
mentioned in my first post!

See you in Khyberspace!

Yadgar


Post a reply to this message

From: Christian Froeschlin
Subject: Re: #read: why is the second variable undeclared?
Date: 21 Apr 2010 15:21:13
Message: <4bcf5029$1@news.povray.org>


> accurate representation, I divided the whole surface in 2592 (72 by 36) 
> tiles, each covering 5 x 5 degrees by 1800 x 1800 pixels

Note that high resolution meshes require a lot of parse time,
so before you embark on this 8 month analysis you might wish
to verify that it will actually help your animation.

> Here is the code for the read routine

the code looks reasonable, can you post the data file
itself as you write it during the first frame?


Post a reply to this message

From: Jörg 'Yadgar' Bleimann
Subject: Re: #read: why is the second variable undeclared?
Date: 21 Apr 2010 19:18:41
Message: <4bcf87d1$1@news.povray.org>
High!

Christian Froeschlin wrote:

> the code looks reasonable, can you post the data file
> itself as you write it during the first frame?

Meanwhile, I found out my mistake: I just forgot to change the writing 
routine from tab to comma!

See you in Khyberspace!

Yadgar


Post a reply to this message

From: Jörg 'Yadgar' Bleimann
Subject: Re: #read: why is the second variable undeclared?
Date: 23 Apr 2010 12:14:34
Message: <4bd1c76a$1@news.povray.org>
High!

Christian Froeschlin wrote:

> Note that high resolution meshes require a lot of parse time,
> so before you embark on this 8 month analysis you might wish
> to verify that it will actually help your animation.

You're right... I found out that at least the first four month (the 
probing process) can be left out as at 24-bit resolution for the "height 
fields" (from which the actual mesh2s will be constructed) even with the 
rough 1800 x 900 probing across the whole planet, the smallest height 
interval will be a mere 2.5 mm - any higher resolution probing will 
increase this only by a few microns, and any elevations outside the 
range already determined could easily be handled by adjusting them to 
the "floor" and "ceiling" values.

The only problem with this mesh2/"heightfield" approach will be that 
unlike with the original isosurface, there will by no overhangs (but 
also no "hovering rocks") anymore...

Meanwhile, I did a test scene using the isosurface - it took 40 minutes 
and 25 seconds! I hope I get the mesh2 version working tonight...

See you in Khyberspace!

Yadgar

Now playing: I Take The Dice (Duran Duran) - as if time stood still 26 
years ago...


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.