|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been swamped with grad school work recently, and decided that I
needed to play with Povray again to stay sane. Thanks to Bill Pragnell's
Archimedean solids file in the Object Collection, this is the result.
I think I may have overdone it a bit with the focal blur, but too much
less and it seemed to lose the depth. Because of the reflectivity of the
'atoms' and large amounts of emissive and absorptive media, this was
about 8.25 hours for the render, which leads me to think that I could
turn down some settings in radiosity.
Post a reply to this message
Attachments:
Download 'buckyballs.jpg' (207 KB)
Preview of image 'buckyballs.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
CShake wrote:
> I've been swamped with grad school work recently, and decided that I
> needed to play with Povray again to stay sane. Thanks to Bill Pragnell's
> Archimedean solids file in the Object Collection, this is the result.
>
> I think I may have overdone it a bit with the focal blur, but too much
> less and it seemed to lose the depth. Because of the reflectivity of the
> 'atoms' and large amounts of emissive and absorptive media, this was
> about 8.25 hours for the render, which leads me to think that I could
> turn down some settings in radiosity.
8.25 hours for that WITH radiosity -and- focal blur? That isn't a bad
render time at all. (At least, not for me.)
Then again, it might just be time for me to upgrade to a new PC with a quad-
CPU.
Nice image.
--
Stefan Viljoen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen wrote:
> 8.25 hours for that WITH radiosity -and- focal blur? That isn't a bad
> render time at all. (At least, not for me.)
>
> Then again, it might just be time for me to upgrade to a new PC with a quad-
> CPU.
Yeah, this is on a quad core though. (AMD Phenom 9950)
my radiosity block:
pretrace_start 0.08
pretrace_end 0.01
error_bound 0.2
count 150
low_error_factor 0.5
minimum_reuse 0.01
recursion_limit 2
nearest_count 4
I'm thinking that I could up the error_bound and make it faster, but the
count is needed for the amount of media, and the recursion_limit is as
low as I want to go with all the reflection.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
CShake schrieb:
> my radiosity block:
> pretrace_start 0.08
> pretrace_end 0.01
> error_bound 0.2
> count 150
> low_error_factor 0.5
> minimum_reuse 0.01
> recursion_limit 2
> nearest_count 4
>
>
> I'm thinking that I could up the error_bound and make it faster, but the
> count is needed for the amount of media, and the recursion_limit is as
> low as I want to go with all the reflection.
Some things to note here:
- Radiosity probably does not contribute very much to your scene. You
have lots of reflective surfaces, and the others are quite dim. There is
not much diffuse interreflection going on here, so quality on that is
probably not an issue.
- error_bound 0.2 is insanely low.
- make it a habit to always set "always sample" to "off". It really
doesn't help at all (except if you want to provoke artifacts).
- recursion_limit does /not/ specify the "max_trace_level" to use for
radiosity sampling rays. Instead, it solely governs whether
radiosity-based illumination will be taken into account recursively, and
to what depth. Aside from that, radiosity sampling rays are treated
pretty much like normal rays, i.e. the number of classic reflections
they will follow is governed by the global "max_trace_level" (with some
caveats, but that's a different story). Given that radiosity probably
contributes very few to your scene anyway, the "radiosity effect on
radiosity" will be pretty close to zero, so you can set this value to 1.
As a matter of fact, radiosity contribution is probably so low that this
is one of the very few scenes where I'd personally try to go completely
without.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Some things to note here:
>
> - Radiosity probably does not contribute very much to your scene. You
> have lots of reflective surfaces, and the others are quite dim. There is
> not much diffuse interreflection going on here, so quality on that is
> probably not an issue.
>
> - error_bound 0.2 is insanely low.
>
> - make it a habit to always set "always sample" to "off". It really
> doesn't help at all (except if you want to provoke artifacts).
>
> - recursion_limit does /not/ specify the "max_trace_level" to use for
> radiosity sampling rays. Instead, it solely governs whether
> radiosity-based illumination will be taken into account recursively, and
> to what depth. Aside from that, radiosity sampling rays are treated
> pretty much like normal rays, i.e. the number of classic reflections
> they will follow is governed by the global "max_trace_level" (with some
> caveats, but that's a different story). Given that radiosity probably
> contributes very few to your scene anyway, the "radiosity effect on
> radiosity" will be pretty close to zero, so you can set this value to 1.
>
> As a matter of fact, radiosity contribution is probably so low that this
> is one of the very few scenes where I'd personally try to go completely
> without.
Fixed the error bound (I used 0.2 as a start because it was used in
Bill's test scene for the solids), which did speed up the render.
I am using radiosity because I'm lighting with a HDR probe, and the
black 'bonds' in the structures are very dark without it.
Here's another version - The render time dropped to just over 1 hour, it
would have been even faster but I bumped up the focal blur samples to 70
instead of 20, which made a visible improvement for me. Recursion_limit
was decreased to 1, and error_bound went up to 0.8. Even with
'always_sample off' I see in the message window that there is a line for
the 'Final' radiosity pass that has just over half of the total samples
taken, is this the actual final render pass or just the last radiosity
pass before the final trace?
Post a reply to this message
Attachments:
Download 'buckyballs_red.jpg' (203 KB)
Preview of image 'buckyballs_red.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
CShake schrieb:
> Even with
> 'always_sample off' I see in the message window that there is a line for
> the 'Final' radiosity pass that has just over half of the total samples
> taken, is this the actual final render pass or just the last radiosity
> pass before the final trace?
That is indeed the actual render pass. It is not uncommon for the actual
render to hit places where not a single sample is available despite all
effort; even the most exhaustive pretrace cannot guarantee a 100% coverage.
As a matter of fact, from my experience a 50:50 ratio between pretrace-
and final render samples is what I'd recommend to aim for, so your
pretrace settings are probably quite ok right now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|