|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In an effort to speed the render of the scene I'm working on, I reduced the
radiosity settings to default, but wound up with large patches of pure white
with jagged edges. I managed to fix some of it by increasing the number of
pretrace steps, but there are still large ambient areas in the render.
Can anybody tell me what causes this, and which settings I might adjust to fix
it? I can't find anything about this in the documents or tutorials.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
> In an effort to speed the render of the scene I'm working on, I reduced the
> radiosity settings to default, but wound up with large patches of pure white
> with jagged edges. I managed to fix some of it by increasing the number of
> pretrace steps, but there are still large ambient areas in the render.
>
> Can anybody tell me what causes this, and which settings I might adjust to fix
> it? I can't find anything about this in the documents or tutorials.
An image might help to better diagnose the issue. Are the "patches of
pure white light" isolated splotches, or do you have a general problem
with jagged edges in the radiosity gradients?
Generally, jagged edges are an indication that a lot of radiosity
samples are taken during the main render.
Whenever a sample is taken during the main render, some nearby pixels
have already been rendered with the presumption that the new sample
doesn't exist, using a different set of samples to interpolate between
than any pixel rendered later, so you get a discontinuity in the
gradient where the additional sample was taken. This isn't much of a
problem if the set of samples to interpolate between is large already,
as the discontinuity will be low in amplitude; but as the percentage of
samples taken during the main render grows, so does both the total
number /and/ amplitude of such discontinuities.
Among the report POV-Ray displays after finishing a render, there is a
table listing how many radiosity samples were taken during which pass at
which recursion depth, like this:
-----------------------------------------------------------
Pass Depth 0 Total
-----------------------------------------------------------
1 148 148
2 583 583
3 2067 2067
4 2028 2028
Final 2571 2571
-----------------------------------------------------------
Total 7397 7397
Weight 0.282
-----------------------------------------------------------
As a rule of thumb, the number of top-level samples ("Depth 0") taken
during the main render ("Final" pass) should be less than half the
number of top-level samples taken in total.
If the number of samples taken during the main render is too high, this
indicates that your pretrace coverage is too low, and you may need to do
the following:
- Set "always_sample" to "off" (this is the default if "#version 3.7" or
higher is specified); this will cause POV-Ray to only take samples
during the main render if it absolutely needs them. If you instead set
this to "on", artifacts are almost guaranteed.
- Set "nearest_count" to a reasonably large value; this will cause
POV-Ray to aim for a higher pretrace coverage. A value of 5 is ok, but
10 is better, and I personally always use 20 except for test renders.
- Decrease "low_error_factor"; this will also cause POV-Ray to aim for a
higher pretrace coverage, while at the same time making it less picky
when it comes to re-using samples during the main render. (Note that
this comes at the cost of "blurring" the radiosity effect; but when a
low pretrace coverage is your problem, then that's probably your least
concern.)
- Increase the number of pretrace steps by decreasing "pretrace_end"
("pretrace_start" usually has only a small impact on the pretrace
coverage, as long as it's reasonably large). If the number of pretrace
steps is too low, POV-Ray will be unable to achieve the pretrace
coverage as requested by the other parameters.
If "pretrace_end" is already at the lowest effective value (the inverse
of the image size) and the number of pretrace steps is still lower than
necessary to achieve the pretrace coverage prescribed by the other
parameters, the following settings may also help; they all affect the
pretrace coverage POV-Ray needs, but also the one it aims for:
- increase "error_bound" to reduce the required and aimed-for coverage
in general.
- Increase "minimum_reuse" to reduce the required and aimed-for coverage
near corners.
*BUT*
if your issue is isolated bright splotches, then the main problem is
most certainly entirely different, namely that you have some
comparatively small but very bright object in your scene. In that case,
you only have two viable options: Up your radiosity "count" parameter,
or try to replace that bright object with a conventional point or area
light source (maybe with a looks_like object).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Aug 2015 23:09:44 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
>> In an effort to speed the render of the scene I'm working on, I reduced
>> the
>> radiosity settings to default, but wound up with large patches of pure
>> white
>> with jagged edges. I managed to fix some of it by increasing the
>> number of
>> pretrace steps, but there are still large ambient areas in the render.
>>
>> Can anybody tell me what causes this, and which settings I might adjust
>> to fix
>> it? I can't find anything about this in the documents or tutorials.
>
> An image might help to better diagnose the issue. Are the "patches of
> pure white light" isolated splotches, or do you have a general problem
> with jagged edges in the radiosity gradients?
>
> Generally, jagged edges are an indication that a lot of radiosity
> samples are taken during the main render.
>
> Whenever a sample is taken during the main render, some nearby pixels
> have already been rendered with the presumption that the new sample
> doesn't exist, using a different set of samples to interpolate between
> than any pixel rendered later, so you get a discontinuity in the
> gradient where the additional sample was taken. This isn't much of a
> problem if the set of samples to interpolate between is large already,
> as the discontinuity will be low in amplitude; but as the percentage of
> samples taken during the main render grows, so does both the total
> number /and/ amplitude of such discontinuities.
>
> Among the report POV-Ray displays after finishing a render, there is a
> table listing how many radiosity samples were taken during which pass at
> which recursion depth, like this:
>
> -----------------------------------------------------------
> Pass Depth 0 Total
> -----------------------------------------------------------
> 1 148 148
> 2 583 583
> 3 2067 2067
> 4 2028 2028
> Final 2571 2571
> -----------------------------------------------------------
> Total 7397 7397
> Weight 0.282
> -----------------------------------------------------------
>
> As a rule of thumb, the number of top-level samples ("Depth 0") taken
> during the main render ("Final" pass) should be less than half the
> number of top-level samples taken in total.
>
>
> If the number of samples taken during the main render is too high, this
> indicates that your pretrace coverage is too low, and you may need to do
> the following:
>
> - Set "always_sample" to "off" (this is the default if "#version 3.7" or
> higher is specified); this will cause POV-Ray to only take samples
> during the main render if it absolutely needs them. If you instead set
> this to "on", artifacts are almost guaranteed.
>
> - Set "nearest_count" to a reasonably large value; this will cause
> POV-Ray to aim for a higher pretrace coverage. A value of 5 is ok, but
> 10 is better, and I personally always use 20 except for test renders.
>
> - Decrease "low_error_factor"; this will also cause POV-Ray to aim for a
> higher pretrace coverage, while at the same time making it less picky
> when it comes to re-using samples during the main render. (Note that
> this comes at the cost of "blurring" the radiosity effect; but when a
> low pretrace coverage is your problem, then that's probably your least
> concern.)
>
> - Increase the number of pretrace steps by decreasing "pretrace_end"
> ("pretrace_start" usually has only a small impact on the pretrace
> coverage, as long as it's reasonably large). If the number of pretrace
> steps is too low, POV-Ray will be unable to achieve the pretrace
> coverage as requested by the other parameters.
>
>
> If "pretrace_end" is already at the lowest effective value (the inverse
> of the image size) and the number of pretrace steps is still lower than
> necessary to achieve the pretrace coverage prescribed by the other
> parameters, the following settings may also help; they all affect the
> pretrace coverage POV-Ray needs, but also the one it aims for:
>
> - increase "error_bound" to reduce the required and aimed-for coverage
> in general.
>
> - Increase "minimum_reuse" to reduce the required and aimed-for coverage
> near corners.
>
>
> *BUT*
>
> if your issue is isolated bright splotches, then the main problem is
> most certainly entirely different, namely that you have some
> comparatively small but very bright object in your scene. In that case,
> you only have two viable options: Up your radiosity "count" parameter,
> or try to replace that bright object with a conventional point or area
> light source (maybe with a looks_like object).
>
This should be added to the docs.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Aug 2015 23:09:44 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
>> In an effort to speed the render of the scene I'm working on, I reduced
>> the
>> radiosity settings to default, but wound up with large patches of pure
>> white
>> with jagged edges. I managed to fix some of it by increasing the
>> number of
>> pretrace steps, but there are still large ambient areas in the render.
>>
>> Can anybody tell me what causes this, and which settings I might adjust
>> to fix
>> it? I can't find anything about this in the documents or tutorials.
>
> An image might help to better diagnose the issue. Are the "patches of
> pure white light" isolated splotches, or do you have a general problem
> with jagged edges in the radiosity gradients?
>
> Generally, jagged edges are an indication that a lot of radiosity
> samples are taken during the main render.
>
> Whenever a sample is taken during the main render, some nearby pixels
> have already been rendered with the presumption that the new sample
> doesn't exist, using a different set of samples to interpolate between
> than any pixel rendered later, so you get a discontinuity in the
> gradient where the additional sample was taken. This isn't much of a
> problem if the set of samples to interpolate between is large already,
> as the discontinuity will be low in amplitude; but as the percentage of
> samples taken during the main render grows, so does both the total
> number /and/ amplitude of such discontinuities.
>
> Among the report POV-Ray displays after finishing a render, there is a
> table listing how many radiosity samples were taken during which pass at
> which recursion depth, like this:
>
> -----------------------------------------------------------
> Pass Depth 0 Total
> -----------------------------------------------------------
> 1 148 148
> 2 583 583
> 3 2067 2067
> 4 2028 2028
> Final 2571 2571
> -----------------------------------------------------------
> Total 7397 7397
> Weight 0.282
> -----------------------------------------------------------
>
> As a rule of thumb, the number of top-level samples ("Depth 0") taken
> during the main render ("Final" pass) should be less than half the
> number of top-level samples taken in total.
>
>
> If the number of samples taken during the main render is too high, this
> indicates that your pretrace coverage is too low, and you may need to do
> the following:
>
> - Set "always_sample" to "off" (this is the default if "#version 3.7" or
> higher is specified); this will cause POV-Ray to only take samples
> during the main render if it absolutely needs them. If you instead set
> this to "on", artifacts are almost guaranteed.
>
> - Set "nearest_count" to a reasonably large value; this will cause
> POV-Ray to aim for a higher pretrace coverage. A value of 5 is ok, but
> 10 is better, and I personally always use 20 except for test renders.
>
> - Decrease "low_error_factor"; this will also cause POV-Ray to aim for a
> higher pretrace coverage, while at the same time making it less picky
> when it comes to re-using samples during the main render. (Note that
> this comes at the cost of "blurring" the radiosity effect; but when a
> low pretrace coverage is your problem, then that's probably your least
> concern.)
>
> - Increase the number of pretrace steps by decreasing "pretrace_end"
> ("pretrace_start" usually has only a small impact on the pretrace
> coverage, as long as it's reasonably large). If the number of pretrace
> steps is too low, POV-Ray will be unable to achieve the pretrace
> coverage as requested by the other parameters.
>
>
> If "pretrace_end" is already at the lowest effective value (the inverse
> of the image size) and the number of pretrace steps is still lower than
> necessary to achieve the pretrace coverage prescribed by the other
> parameters, the following settings may also help; they all affect the
> pretrace coverage POV-Ray needs, but also the one it aims for:
>
> - increase "error_bound" to reduce the required and aimed-for coverage
> in general.
>
> - Increase "minimum_reuse" to reduce the required and aimed-for coverage
> near corners.
>
>
> *BUT*
>
> if your issue is isolated bright splotches, then the main problem is
> most certainly entirely different, namely that you have some
> comparatively small but very bright object in your scene. In that case,
> you only have two viable options: Up your radiosity "count" parameter,
> or try to replace that bright object with a conventional point or area
> light source (maybe with a looks_like object).
>
This should be added to the docs.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 10 Aug 2015 23:09:44 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
>> In an effort to speed the render of the scene I'm working on, I reduced
>> the
>> radiosity settings to default, but wound up with large patches of pure
>> white
>> with jagged edges. I managed to fix some of it by increasing the
>> number of
>> pretrace steps, but there are still large ambient areas in the render.
>>
>> Can anybody tell me what causes this, and which settings I might adjust
>> to fix
>> it? I can't find anything about this in the documents or tutorials.
>
> An image might help to better diagnose the issue. Are the "patches of
> pure white light" isolated splotches, or do you have a general problem
> with jagged edges in the radiosity gradients?
>
> Generally, jagged edges are an indication that a lot of radiosity
> samples are taken during the main render.
>
> Whenever a sample is taken during the main render, some nearby pixels
> have already been rendered with the presumption that the new sample
> doesn't exist, using a different set of samples to interpolate between
> than any pixel rendered later, so you get a discontinuity in the
> gradient where the additional sample was taken. This isn't much of a
> problem if the set of samples to interpolate between is large already,
> as the discontinuity will be low in amplitude; but as the percentage of
> samples taken during the main render grows, so does both the total
> number /and/ amplitude of such discontinuities.
>
> Among the report POV-Ray displays after finishing a render, there is a
> table listing how many radiosity samples were taken during which pass at
> which recursion depth, like this:
>
> -----------------------------------------------------------
> Pass Depth 0 Total
> -----------------------------------------------------------
> 1 148 148
> 2 583 583
> 3 2067 2067
> 4 2028 2028
> Final 2571 2571
> -----------------------------------------------------------
> Total 7397 7397
> Weight 0.282
> -----------------------------------------------------------
>
> As a rule of thumb, the number of top-level samples ("Depth 0") taken
> during the main render ("Final" pass) should be less than half the
> number of top-level samples taken in total.
>
>
> If the number of samples taken during the main render is too high, this
> indicates that your pretrace coverage is too low, and you may need to do
> the following:
>
> - Set "always_sample" to "off" (this is the default if "#version 3.7" or
> higher is specified); this will cause POV-Ray to only take samples
> during the main render if it absolutely needs them. If you instead set
> this to "on", artifacts are almost guaranteed.
>
> - Set "nearest_count" to a reasonably large value; this will cause
> POV-Ray to aim for a higher pretrace coverage. A value of 5 is ok, but
> 10 is better, and I personally always use 20 except for test renders.
>
> - Decrease "low_error_factor"; this will also cause POV-Ray to aim for a
> higher pretrace coverage, while at the same time making it less picky
> when it comes to re-using samples during the main render. (Note that
> this comes at the cost of "blurring" the radiosity effect; but when a
> low pretrace coverage is your problem, then that's probably your least
> concern.)
>
> - Increase the number of pretrace steps by decreasing "pretrace_end"
> ("pretrace_start" usually has only a small impact on the pretrace
> coverage, as long as it's reasonably large). If the number of pretrace
> steps is too low, POV-Ray will be unable to achieve the pretrace
> coverage as requested by the other parameters.
>
>
> If "pretrace_end" is already at the lowest effective value (the inverse
> of the image size) and the number of pretrace steps is still lower than
> necessary to achieve the pretrace coverage prescribed by the other
> parameters, the following settings may also help; they all affect the
> pretrace coverage POV-Ray needs, but also the one it aims for:
>
> - increase "error_bound" to reduce the required and aimed-for coverage
> in general.
>
> - Increase "minimum_reuse" to reduce the required and aimed-for coverage
> near corners.
>
>
> *BUT*
>
> if your issue is isolated bright splotches, then the main problem is
> most certainly entirely different, namely that you have some
> comparatively small but very bright object in your scene. In that case,
> you only have two viable options: Up your radiosity "count" parameter,
> or try to replace that bright object with a conventional point or area
> light source (maybe with a looks_like object).
>
This should be added to the docs.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh no. Opera Mail is spamming my messages again.
:P
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
>> In an effort to speed the render of the scene I'm working on, I
>> reduced the
>> radiosity settings to default, but wound up with large patches of pure
>> white
>> with jagged edges. I managed to fix some of it by increasing the
>> number of
>> pretrace steps, but there are still large ambient areas in the render.
>>
>> Can anybody tell me what causes this, and which settings I might
>> adjust to fix
>> it? I can't find anything about this in the documents or tutorials.
>
> *BUT*
>
> if your issue is isolated bright splotches, then the main problem is
> most certainly entirely different, namely that you have some
> comparatively small but very bright object in your scene. In that case,
> you only have two viable options: Up your radiosity "count" parameter,
> or try to replace that bright object with a conventional point or area
> light source (maybe with a looks_like object).
>
In this case, using importance can help.
Add:
#default{radiosity{importance 0.001}}
or
#declare Average_Count = 75;
#declare High_Count = 160000;
#default{radiosity{importance Average_count/High_Count}}
In the radiosity block, set count to a large value:
count 160000
or
count High_Count // With declared indentifier
In your small and bright object(s), add this:
radiosity{importance 1}
That way, on average, you'll use about 160 samples for most of the
render, but up to 160000 for those problematic small and bright objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotronca> wrote:
> > Am 10.08.2015 um 09:21 schrieb Anthony D. Baye:
> >> In an effort to speed the render of the scene I'm working on, I
> >> reduced the
> >> radiosity settings to default, but wound up with large patches of pure
> >> white
> >> with jagged edges. I managed to fix some of it by increasing the
> >> number of
> >> pretrace steps, but there are still large ambient areas in the render.
> >>
> >> Can anybody tell me what causes this, and which settings I might
> >> adjust to fix
> >> it? I can't find anything about this in the documents or tutorials.
>
> >
> > *BUT*
> >
> > if your issue is isolated bright splotches, then the main problem is
> > most certainly entirely different, namely that you have some
> > comparatively small but very bright object in your scene. In that case,
> > you only have two viable options: Up your radiosity "count" parameter,
> > or try to replace that bright object with a conventional point or area
> > light source (maybe with a looks_like object).
> >
>
> In this case, using importance can help.
>
> Add:
> #default{radiosity{importance 0.001}}
>
> or
> #declare Average_Count = 75;
> #declare High_Count = 160000;
> #default{radiosity{importance Average_count/High_Count}}
>
> In the radiosity block, set count to a large value:
> count 160000
>
> or
> count High_Count // With declared indentifier
>
> In your small and bright object(s), add this:
> radiosity{importance 1}
>
> That way, on average, you'll use about 160 samples for most of the
> render, but up to 160000 for those problematic small and bright objects.
It sounds useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|