Le 2020-08-08 à 18:23, Jörg "Yadgar" Bleimann a écrit :
> Hi(gh)!
> 
> Meanwhile I got the rendering of ASTER tile terrain reliefs running once 
> more - albeit only with Earth as a simple sphere, if I add realistic 
> flattening, the scene remains empty except for the ocean and basic Earth 
> sphere - strange!
>> 
> Yadgar

When you add the flattening or oblatenes, how do you do it ?

Normally, just adding a scale after the modelling should do the trick.

scale<Oblatenes, 1, Oblatenes>

Post a reply to this message

Hi(gh)!

On 09.08.20 23:39, Alain Martel wrote:

> When you add the flattening or oblatenes, how do you do it ?

With the calculation of the mesh2 vertices:

#declare V_vec_Arr[c] = 
(rd+hval)*<sin(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize)),

(1-flattening)*sin(radians(latstart+(a/ydim)*latsize)), 
cos(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize))>;

> 
> Normally, just adding a scale after the modelling should do the trick.
> 
> scale<Oblatenes, 1, Oblatenes>

Worth a try...

See you in Khyberspace!

Yadgar

Post a reply to this message

On 10.08.20 00:14, Jörg "Yadgar" Bleimann wrote:

>> Normally, just adding a scale after the modelling should do the trick.
>>
>> scale<Oblatenes, 1, Oblatenes>
> 
> Worth a try...
> 
> See you in Khyberspace!
> 
> Yadgar

Did not work either - no terrain relief visible in the scene!

Post a reply to this message

hi,

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> On 10.08.20 00:14, Jörg "Yadgar" Bleimann wrote:
> ...
> Did not work either - no terrain relief visible in the scene!

have never seen an "Operation timed out" error, and searching the (installed)
documentation gave no clue.  it would be useful to hear from people who know the
code, in which circumstances/situations that error can happen.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> it would be useful to hear from people who know the
> code, in which circumstances/situations that error can happen.

Is there a way to grep the source code to find out where that gets spit out, as
a starting point for backtracking?
(I'd recommend 3.6 source, as IIRC 3.7 has all the complicated, hard-to-follow
multithreading.  If it's in 3.6, and it's still a mystery, then what is learned
from studying the code can be used as a roadmap to 3.7)

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > it would be useful to hear from people who know the
> > code, in which circumstances/situations that error can happen.
>
> Is there a way to grep the source code to find out where that gets spit out, as
> a starting point for backtracking?

sure.  something like
  $ find /path/to/povray/src -type f -exec grep -Hn 'search term' {} \;

('-H' to make 'grep' report the file name, '-n' for line number; add '-i' to
make the search case insensitive)

> ...

meanwhile I found two relevant threads in the newsgroups:

<http://news.povray.org/povray.general/thread/%3C52dcd2b3$1@news.povray.org%3E/>
<http://news.povray.org/povray.general/thread/%3C56a2bec2%241%40news.povray.org%3E/>


regards, jr.

Post a reply to this message

On 8/10/20 6:47 AM, jr wrote:
...
> 
> have never seen an "Operation timed out" error, and searching the (installed)
> documentation gave no clue.  it would be useful to hear from people who know the
> code, in which circumstances/situations that error can happen.
> 
...

Something is running too slow is the non helpful, short answer, I didn't 
post yesterday - because it sound to me ears a little snarky despite 
being accurate... :-)

Reasons could be many. Paging (using too much memory). Systems is 
otherwise overloaded etc - or just slow.

If the message hasn't somewhere been assembled from parts and pieces, 
it's probably a 'kTimeoutErr' using a 10 (second?) default set 
indirectly by 'kDefaultTimeout'.

The only use of kTimeoutErr sits in a chunk of remaining 'c' code inside 
the message passing system (source/povms/povms.c). If it is this error, 
it can happen when sending a stream of data - somewhere.

If you can compile yourself, there looks to be a _DEBUG macro in the 
message code which when set extends the timeout to 100 (seconds?) if 
running that bit of code under a debugger. Other debugging / workarounds 
would require much more twiddling.

Aside: I've been digging around again in the frontend code and looking 
some at this message passing system. Error wise, all over in the 3.7 
code, there is a fair bit of error handling that looks to have been left 
hanging - incomplete / not fully flushed out. It would certainly be 
helpful in this case to know more about the 'message' being sent on the 
timeout.

Possible Workarounds:

Try it again.

Be sure your machine isn't 'at all' busy with anything else when you 
kick off the animation.

If your machine supports >1 work thread use fewer or one (+wt1) and see 
if you get the error.

If you're running large render block sizes, shrink them.

Use -cc so the state file work does not get done.

Use a ramdisk (or if not that a faster disk) for all input and output 
files if possible.

Aside 2:
I don't much understand the message passing system code, but it looks 
like most information internally is getting passed around using it. I 
think the idea was to eventually be able to support rendering remotely 
on a large cluster of machines with a single controlling gui/entity.

The remote capability doesn't especially interest me with povr, and I'm 
carrying the question: Should I try replace it / change it / simplify 
the vfe/povms stuff... Don't know. Some conceptual parts are OK - ini / 
command line parsing mostly in the vfe, but then the truth is the 
reality for unix/linux is this common *x parsing is quite weak and has 
open bugs. One of which I recently ran down - only to find another right 
behind it... Many flag / file command line parsing errors end up as ini 
file not found errors... (1)

(1) - On unix/linux, if you are not running 'povr,' you are mostly not 
seeing any actual command line / ini parsing errors except a catch all 
thing which, IIRC, I think Jerome added at some point during v3.7 
development which returns the command line with a generic message 
something went wrong. Anyway, guess my mind is drifting from the 
original subject - but another tangled in error reporting not being that 
helpful.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/10/20 6:47 AM, jr wrote:
> ...
> > have never seen an "Operation timed out" error, and searching the (installed)
> > documentation gave no clue.  it would be useful to hear from people who know the
> > code, in which circumstances/situations that error can happen.
> >
> Something is running too slow is the non helpful, short answer, I didn't
> post yesterday - because it sound to me ears a little snarky despite
> being accurate... :-)
>
> Reasons could be many. Paging (using too much memory). Systems is
> otherwise overloaded etc - or just slow.

after having read through the threads referenced in earlier post, I'm
almostready to add a rant of my own.  about how people who migrate to GNU/Linux
are often unaware that now they must, on occasion, don the system administrator
hat.  but I won't.  ;-)

> ...

snipped the explanatory part, for which thanks.

> Aside 2:
> I don't much understand the message passing system code, but it looks
> like most information internally is getting passed around using it. I
> think the idea was to eventually be able to support rendering remotely
> on a large cluster of machines with a single controlling gui/entity.

that is interesting.  if instead of "large cluster" one had this capability for
the LAN.  I'm sure that many users, like me, have more than one computer on the
LAN, and it would be way cool if POV-Ray could exploit that.

> ...

regards, jr.

Post a reply to this message

Am 09.08.2020 um 00:23 schrieb Jörg "Yadgar" Bleimann:
> Hi(gh)!
> 
> Meanwhile I got the rendering of ASTER tile terrain reliefs running once 
> more - albeit only with Earth as a simple sphere, if I add realistic 
> flattening, the scene remains empty except for the ocean and basic Earth 
> sphere - strange!
> 
> But when I try to render a sequence of consecutive images, such as
> 
> +ipovearth.pov +ogeorgia_panorama-.png +w1024 +h768 +a0.3 +ki0 +kf719 
> +kfi0 +kff719 (a simple camera rotation pull)
> 
> after completing the first frame, I get:
> 
> Operation timed out
> Operation timed out
> Render failed
> 
> Why?
> 
> See you in Khyberspace!
> 
> Yadgar
I have no real idea why this happenes time and again. I expierenced it 
time and again myself. In most cases restarting the rendering with +c at 
the command line helps. And in this cases saving and loading radiosity 
data can save some hours.

Best regards
Michael

Post a reply to this message

On 10.08.2020 14:05, William F Pokorny wrote:
> Something is running too slow is the non helpful, short answer, I didn't 
> post yesterday - because it sound to me ears a little snarky despite 
> being accurate... :-)

No, that is pretty much the only answer available.

> Reasons could be many. Paging (using too much memory). Systems is 
> otherwise overloaded etc - or just slow.

Well, really slow. Remember that this means messages take 10 seconds to 
be passed from one thread to the next. Normally threads should be called 
every few milliseconds. If the operating system needs ten seconds to 
switch threads, something is wrong, or the receiving end is "gone", 
meaning it crashed. The later is way more likely for a simple scene.

> If the message hasn't somewhere been assembled from parts and pieces, 
> it's probably a 'kTimeoutErr' using a 10 (second?) default set 
> indirectly by 'kDefaultTimeout'.

Indeed.

> The only use of kTimeoutErr sits in a chunk of remaining 'c' code inside 
> the message passing system (source/povms/povms.c). If it is this error, 
> it can happen when sending a stream of data - somewhere.

The code isn't remaining, it is intentionally C code, so it can be 
ported really everywhere and run on a very low level, with some of the 
message passing APIs around and interact with the thread management 
directly. It will also work even if basically all memory is exhausted by 
using some private pool. For those who want a C++ API, there is one, of 
course. It sits on top of the C code.

> If you can compile yourself, there looks to be a _DEBUG macro in the 
> message code which when set extends the timeout to 100 (seconds?) if 
> running that bit of code under a debugger. Other debugging / workarounds 
> would require much more twiddling.

The question is not where the message is sent, but where it should be 
received. The whole POVMS code has extensive debugging support that can 
be enabled by macros.

> Aside: I've been digging around again in the frontend code and looking 
> some at this message passing system. Error wise, all over in the 3.7 
> code, there is a fair bit of error handling that looks to have been left 
> hanging - incomplete / not fully flushed out. It would certainly be 
> helpful in this case to know more about the 'message' being sent on the 
> timeout.

No, this isn't really the case. By the time you get into trouble with 
the message passing, you are already in such a mess that you likely 
cannot recover in a meaningful way. The most likely cause of the message 
passing to stall for a simple scene is actually that the receiving side 
crashed in some way, i.e. by an exception that left the message handler 
in an unexpected way.

> Aside 2:
> I don't much understand the message passing system code, but it looks 
> like most information internally is getting passed around using it. I 
> think the idea was to eventually be able to support rendering remotely 
> on a large cluster of machines with a single controlling gui/entity.

No, it is also a core of the threading functions. What it really does it 
provide a separation between the frontend and the backend such that you 
can actually render multiple scenes or images of a scene at the same 
time. It also allows you to do this while the frontend GUI and the 
backend(s) run in separate processes. It also is the code used for 
render continuation (that actually works even if you switch systems in 
between) and a bunch of other stuff.

> The remote capability doesn't especially interest me with povr, and I'm 
> carrying the question: Should I try replace it / change it / simplify 
> the vfe/povms stuff... Don't know.

Suggestion: If you don't understand some code, it is a clear indication 
you should stay away from it until you do ;-)

VFE is basically a quick solution Chris Cason implemented early in the 
3.7 development because something was needed for the Windows frontend. 
It is by no means required. It is just a collection of stuff that is 
really mostly meant for the Windows frontend, and does not work all that 
well for a command line frontend. Actually, in 3.7 the command line 
frontend used to be in there and would compile by enabling the main 
function - I know because this feature was a major part of the 
development process of 3.7.

> (1) - On unix/linux, if you are not running 'povr,' you are mostly not 
> seeing any actual command line / ini parsing errors except a catch all 
> thing which,

Well, the code could be added. But you are right that the error handling 
of INI files was not finished in time.

Thorsten

Post a reply to this message