On 6/29/23 09:31, Chris R wrote:
> I may end up shifting the camera location slightly and see if that eliminates
> the problem spots, but I'd be interest in trying to figure out whether I'm just
> hitting some threshold edge condition where an algorithm is just never
> terminating.  Could I be hitting a loop where the threshold condition cannot be
> met due to floating point precision problems?

(64 cores... What a dream! :-) )

Yes, always possible there is some unknown problem causing the run 
extreme render times.

Given you have the problem isolated to two blocks, why not try what Bald 
Eagle suggested. There are the (start row / end row) and (start column / 
end column) controls. These I used often while running down various 
solver issues (image artefacts) in 2017 / 2018 (a).

So. You could start by making a pretty good guess at the image rows 
covering those to hung blocks. Then try row by row renders using:

povray ... +sr600 +er600 ...

povray ... +sr601 +er601 ...

When you find a row which hangs you can then start to use the column 
options:

povray ... +sr602 +er602 +sc500 +ec1500 ...

povray ... +sr602 +er602 +sc700 +ec900 ...

You might need to 'kill' the hung processes (or cntl-c cancel if that 
works) while you isolate to pixels. You can use the 'kill' command for 
this or 'kill' via linux process monitoring commands like top/htop.

Should be you can leave all other options the same and slowly isolate 
the problem pixels. If like my old hanging transparent blobs, it might 
end up being just a pixel position or two (b).

If you can get to a scene of reasonable size and complexity also cut 
down to a small number of problem pixels, I'll take a look at it on my 
little two core i3 while doing some extra performance/debugging stuff.

Note though. Real life has me tied up until late July or more likely 
early August so I won't be able to look at anything immediately.


Aside: I think all linux distribution offerings come with 'top' or 
'htop' commands. It might be interesting to kick off one of these 
commands in a terminal while povray is struggling to look at whether cpu 
bound (povray processes at near 100%) or perhaps consuming large amounts 
of memory - and so perhaps the 'hung' threads are paging even on your 
huge machine (b). Large memory use would hint at runaway recursion 
internal to the code (runaway transparency being one way this might 
happen).

Bill P.


(a) Somewhere, I have a script framework which isolates to particular 
pixels automatically based on various triggers - but that framework had 
nothing which isolated on 'long render times...'

(b) Or there is a very remote chance the block is hung on exit. We have 
seen 'render block' hangs with the Simple Direct media Layer (SDL1.2) 
preview code - which the official v3.8 code still uses - though there 
has long been a newer and less buggy 2.0 package. Using something like 
top or htop, you might see the povray process(es) using very little cpu 
or memory resource in this sort of case.

Post a reply to this message