Hi,
I've the following situation: a scene contains six objects with media (in the
center of the image). They are small, approx 10% of the final image.
When I render the scene (pov 3.7.0) the image is rendered to 97% in few minutes,
but the last 3% needs more than one hour! This final time seems to depend on the
amount of other objects in the scene, when I reduce them, the final part render
faster (but reducing objects is not an option).

What is povray doing at the end of the image?
How can I speed this up ?

Post a reply to this message

Le 2022-05-03 à 18:12, Juergen a écrit :
> Hi,
> I've the following situation: a scene contains six objects with media (in the
> center of the image). They are small, approx 10% of the final image.
> When I render the scene (pov 3.7.0) the image is rendered to 97% in few minutes,
> but the last 3% needs more than one hour! This final time seems to depend on the
> amount of other objects in the scene, when I reduce them, the final part render
> faster (but reducing objects is not an option).
> 
> What is povray doing at the end of the image?
> How can I speed this up ?
> 
> Jürgen
> 

It may be related to your media settings.
What is the sampling method ?
If using method 3, the default, did you increase the intervals value 
above 1 ? Using method 3, intervals MUST remain at 1. Increasing it 
greatly increase the rendering time for no effective improvement.
How many samples ? Try using less samples. Go as low as you can without 
degrading the quality of your render. A solid, uniform, media may need 
only 3 samples, while one using a busy pattern like granite or agate, or 
a highly turbulent one, could demand over 100.

Any overlapping media containers ? (having common volumes)
If your media containers overlap, it can cause some performance issues 
and cause artifacts. That's particularly true if one have a simple 
pattern demanding few samples and the other have a pattern demanding a 
high samples count.

Do those objects have an ior ?
A medium to high ior will cause total internal reflections.
Do you use dispersion ? Dispersion greatly increase the total number of 
rays needed.

Any reflective surfaces ?

Post a reply to this message

I have noticed some kind of similar media-rendering behavior, especially with
scattering media (but also with emission + absorption.)

I'm running V3.8.0 beta 1  (Windows), on a core I7 8-core/16-thread machine.

I currently use the default 'render block size' of 32X32 pixels and no 'mosaic
preview'. The last few 'render blocks' that get processed in my images (which
are in areas where there is media) seem to cause my machine to work *extremely*
hard. I have noticed this in two different ways: My machine's cooling-fan speed
greatly increases; and the Windows 'Task Manager' app shows that those last few
blocks cause the processor to suddenly jump to nearly 100% use.

On my machine, there does not seem to be an actual slowdown in the render-- just
some very hard processor work behind-the-scenes.

This is my *guess* as to what is going on (simply from a user's standpoint, and
not a programmer's):
Due to symmetric multi-processing, it would seem that each 'render block' in the
image is being processed by a particular core/thread(?)-- or, the blocks for
most of the render are being shared among those. But for the very last block--
or last few blocks-- the SMP process is reducing the number of threads(?) to
process those... in other words, maybe the last block is using only one core,
and trying to make it do *all* of the processing... resulting in a slowdown (or
overheating of the processor, in my case.)

Again, this is purely guesswork. I don't know the inner workings of processors
or POV-ray's SMP stuff ;-)

Post a reply to this message

On 04.05.2022 00:12, Juergen wrote:
> Hi,
> I've the following situation: a scene contains six objects with media (in the
> center of the image). They are small, approx 10% of the final image.
> When I render the scene (pov 3.7.0) the image is rendered to 97% in few minutes,
> but the last 3% needs more than one hour! This final time seems to depend on the
> amount of other objects in the scene, when I reduce them, the final part render
> faster (but reducing objects is not an option).
> 
> What is povray doing at the end of the image?
> How can I speed this up ?

If you have a very simple scene with a single complex object in a very 
small part of it, it my end up in one or a very few blocks, which take 
very long to render.

If you want a better distribution of the computational load, you should 
decrease the render block size such that your object gets distributed 
between multiple render blocks.

Thorsten

Post a reply to this message

Le 2022-05-04 à 14:40, Kenneth a écrit :
> I have noticed some kind of similar media-rendering behavior, especially with
> scattering media (but also with emission + absorption.)
> 
> I'm running V3.8.0 beta 1  (Windows), on a core I7 8-core/16-thread machine.
> 
> I currently use the default 'render block size' of 32X32 pixels and no 'mosaic
> preview'. The last few 'render blocks' that get processed in my images (which
> are in areas where there is media) seem to cause my machine to work *extremely*
> hard. I have noticed this in two different ways: My machine's cooling-fan speed
> greatly increases; and the Windows 'Task Manager' app shows that those last few
> blocks cause the processor to suddenly jump to nearly 100% use.
> 
> On my machine, there does not seem to be an actual slowdown in the render-- just
> some very hard processor work behind-the-scenes.
> 
> This is my *guess* as to what is going on (simply from a user's standpoint, and
> not a programmer's):
> Due to symmetric multi-processing, it would seem that each 'render block' in the
> image is being processed by a particular core/thread(?)-- or, the blocks for
> most of the render are being shared among those. But for the very last block--
> or last few blocks-- the SMP process is reducing the number of threads(?) to
> process those... in other words, maybe the last block is using only one core,
> and trying to make it do *all* of the processing... resulting in a slowdown (or
> overheating of the processor, in my case.)
> 
> Again, this is purely guesswork. I don't know the inner workings of processors
> or POV-ray's SMP stuff ;-)
> 
> 
> 
Each render block is rendered by a single core. So, your supposition is 
correct.
In cases similar to this one, reducing the render blocks MAY improve the 
performance by forcing those problematic blocks to get rendered by more 
than a single core.

So, try using +rb16 or +rb12 and see if there is any improvement.
Also, changing the rendering pattern so that the rendering start near 
the centre could help to at least hide some of the slowdown by having 
the problem blocks starting to get rendered sooner.

Post a reply to this message

Thorsten <tho### [at] trfde> wrote:
>
> If you want a better distribution of the computational load, you should
> decrease the render block size such that your object gets distributed
> between multiple render blocks.
>
> Thorsten

That works very well, thanks! From my own 'naive' analysis, I had been wondering
if a smaller block size would help, but I never tried it. (For my tests, I
forgot to mention that my media object occupies about 50% of the screen space--
unlike the OP's small object that is probably 'enclosed' by a single render
block.) Your suggestion works in both cases, of course.

A smaller render-block size has another great advantage: The scene renders
faster.
Here is my example (using scattering media):

block size of 64 pixels: 2 mins 16 sec
block size of 8 pixels:  1 min 10 sec

That's a definite improvement! And my machine's processor seems to run less hot,
based on the cooling-fan speed.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
>
> So, try using +rb16 or +rb12 and see if there is any improvement.
> Also, changing the rendering pattern so that the rendering start near
> the centre could help to at least hide some of the slowdown by having
> the problem blocks starting to get rendered sooner.

Thanks Alain.

The 'extra' benefit that never occurred to me was the faster rendering time when
using a smaller block size. I thought the result might be the
opposite...probably based on my old and fuzzy memories of running media on
single-core machines, before POV-ray's SMP implementation.

Post a reply to this message

Op 05/05/2022 om 23:05 schreef Kenneth:
> Thorsten <tho### [at] trfde> wrote:
>>
>> If you want a better distribution of the computational load, you should
>> decrease the render block size such that your object gets distributed
>> between multiple render blocks.
>>
>> Thorsten
> 
> That works very well, thanks! From my own 'naive' analysis, I had been wondering
> if a smaller block size would help, but I never tried it. (For my tests, I
> forgot to mention that my media object occupies about 50% of the screen space--
> unlike the OP's small object that is probably 'enclosed' by a single render
> block.) Your suggestion works in both cases, of course.
> 
> A smaller render-block size has another great advantage: The scene renders
> faster.
> Here is my example (using scattering media):
> 
> block size of 64 pixels: 2 mins 16 sec
> block size of 8 pixels:  1 min 10 sec
> 
> That's a definite improvement! And my machine's processor seems to run less hot,
> based on the cooling-fan speed.
> 
> 
Ha! Never thought about that 'trick'!

-- 
Thomas

Post a reply to this message

Op 05/05/2022 om 19:45 schreef Alain Martel:
> So, try using +rb16 or +rb12 and see if there is any improvement.
> Also, changing the rendering pattern so that the rendering start near 
> the centre could help to at least hide some of the slowdown by having 
> the problem blocks starting to get rendered sooner.

Just nitpicking: +rb should be +bs

;-)

-- 
Thomas

Post a reply to this message

Op 5-5-2022 om 09:35 schreef Thorsten:

> If you want a better distribution of the computational load, you should 
> decrease the render block size such that your object gets distributed 
> between multiple render blocks.
> 

Is this also true when doing a stochastic render? Generally, I use:

+am3 +a0.03 +ac0.90 +r3

Is adding +bs12 (for instance) relevant in that case?

Thanks

-- 
Thomas

Post a reply to this message