 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I don't know if there's really anything wrong here, but just in case anyone else
has experienced this situation I decided to show this example. Some darker
rectangular areas appear when this scene is rendered with radiosity. It's a
minor problem and probably something I'm doing wrong as usual, and I'm not
asking for any help. During the modeling phase I tried to make sure there were
no coincident surfaces, so I don't think that's the problem. (Version 3.7 Beta
37a)
By the way, the pin hasn't been properly positioned in the hole yet - it's still
a work in progress...
Regards,
Dave Blandston
Post a reply to this message
Attachments:
Download 'stairsteps.jpg' (121 KB)
Preview of image 'stairsteps.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.05.2010 14:06, schrieb Dave Blandston:
> I don't know if there's really anything wrong here, but just in case anyone else
> has experienced this situation I decided to show this example. Some darker
> rectangular areas appear when this scene is rendered with radiosity. It's a
> minor problem and probably something I'm doing wrong as usual, and I'm not
> asking for any help. During the modeling phase I tried to make sure there were
> no coincident surfaces, so I don't think that's the problem. (Version 3.7 Beta
> 37a)
I suppose it's typical artifacts from the radiosity code taking
additional samples during the final trace. Some pieces of advice to
prevent this effect:
- Use "always_sample off"
- Make sure your radiosity pretrace gathers a decent number of samples
already. From my experience, at least about half of all the samples
should be gathered during pretrace already. (If it doesn't, usually
decreasing pretrace_end will do the job.)
You can check this with the radiosity statistics. After render, POV-Ray
will output a table like this, listing the number of samples gathered
per pass and recursion depth:
--------------------------------------------------------
Pass Depth 0 Depth 1 Depth 2 Total
--------------------------------------------------------
1 1544 40899 7794 50237
2 6079 72001 2232 80312
3 22457 95237 1677 119371
4 66516 106702 1274 174492
5+ 246562 139354 2603 388519
Final 46489 161 - 46650
--------------------------------------------------------
Total 389647 454354 15580 859581
Weight 0.199 0.057 0.027
--------------------------------------------------------
In the "Depth 0" column, the "Final" value should be no more than about
half of the "Total" value.
(The example shows a render that took more than 88% of all samples
during a 6-pass pretrace, so that can pretty likely be cut down to 5
passes by doubling pretrace_end to increase speed.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> - Make sure your radiosity pretrace gathers a decent number of samples
> already. From my experience, at least about half of all the samples
> should be gathered during pretrace already. (If it doesn't, usually
> decreasing pretrace_end will do the job.)
>
> You can check this with the radiosity statistics. After render, POV-Ray
> will output a table like this, listing the number of samples gathered
> per pass and recursion depth:
>
> --------------------------------------------------------
> Pass Depth 0 Depth 1 Depth 2 Total
> --------------------------------------------------------
> 1 1544 40899 7794 50237
> 2 6079 72001 2232 80312
> 3 22457 95237 1677 119371
> 4 66516 106702 1274 174492
> 5+ 246562 139354 2603 388519
> Final 46489 161 - 46650
> --------------------------------------------------------
> Total 389647 454354 15580 859581
> Weight 0.199 0.057 0.027
> --------------------------------------------------------
>
> In the "Depth 0" column, the "Final" value should be no more than about
> half of the "Total" value.
Thanks! I'll tinker with the radiosity settings. It's so helpful to know what to
work on. I see that my settings must be way off, judging by the table below. The
"Final" number is almost the same as the "Total" number. I appreciate your help
very much.
radiosity {
count 300
error_bound .02
pretrace_start .08
pretrace_end .004
recursion_limit 2
normal on
} //radiosity
Pass Depth 0 Depth 1 Total
---------------------------------------------
2 1 330 331
3 6 1002 1008
4 48 7766 7814
5+ 277 27392 27669
Final 61083 1057679 1118762
---------------------------------------------
Total 61415 1094169 1155584
Weight 0.092 0.047
Regards,
Dave Blandston
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.06.2010 06:29, schrieb Dave Blandston:
> radiosity {
> count 300
> error_bound .02
> pretrace_start .08
> pretrace_end .004
> recursion_limit 2
> normal on
> } //radiosity
>
> Pass Depth 0 Depth 1 Total
> ---------------------------------------------
> 2 1 330 331
> 3 6 1002 1008
> 4 48 7766 7814
> 5+ 277 27392 27669
> Final 61083 1057679 1118762
> ---------------------------------------------
> Total 61415 1094169 1155584
> Weight 0.092 0.047
Yes, with these statistics numbers it's no surprise that you get those
blocky artifacts.
Your error_bound is unconventionally low, thus increasing the desired
sample density; typically, a value of 0.5 will do. "normal on" increases
desired density even more; unless you use radiosity as primary
illumination you can typically go without.
As already mentioned, do use "always_sample off"; I'd also recommend
"low_error_factor 0.5" to force the pretrace to go for a higher sample
coverage than the final trace would demand for.
The pretrace_start and pretrace_end look quite ok to me at a first
glance. If the other changes don't give you the desired final-vs-total
ratio though, you might want to decrease pretrace_end.
The statistics also show that only very few samples are gathered during
the first passes (and no samples at all in the very first one), so you
may want to reduce pretrace_start; I'd suggest to start at what is now
pass 3, i.e. "pretrace_start 0.02"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Yes, with these statistics numbers it's no surprise that you get those
> blocky artifacts.
>
> Your error_bound is unconventionally low, thus increasing the desired
> sample density; typically, a value of 0.5 will do. "normal on" increases
> desired density even more; unless you use radiosity as primary
> illumination you can typically go without.
>
> As already mentioned, do use "always_sample off"; I'd also recommend
> "low_error_factor 0.5" to force the pretrace to go for a higher sample
> coverage than the final trace would demand for.
>
> The pretrace_start and pretrace_end look quite ok to me at a first
> glance. If the other changes don't give you the desired final-vs-total
> ratio though, you might want to decrease pretrace_end.
>
> The statistics also show that only very few samples are gathered during
> the first passes (and no samples at all in the very first one), so you
> may want to reduce pretrace_start; I'd suggest to start at what is now
> pass 3, i.e. "pretrace_start 0.02"
Wow, after several hours of experimenting I think I finally have good radiosity
settings. I had to keep error_bound very low, otherwise the radiosity effect
disappeared in little crevices. One happy side-effect of my efforts was
discovering a better setting for adc_bailout - changing it from the default to
..1 sped things up considerably without a significant drop in quality. Thanks for
the great suggestions!
Regards,
Dave Blandston
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/1/2010 8:35 AM, clipka wrote:
> The statistics also show that only very few samples are gathered during
> the first passes (and no samples at all in the very first one), so you
> may want to reduce pretrace_start; I'd suggest to start at what is now
> pass 3, i.e. "pretrace_start 0.02"
Heh. I never thought to pay attention to the output statistics to tweak
radiosity settings.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
