 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmx de> 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
|
|
| |
| |
|
|
|
|
| |
