![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
This was just meant to be a test render. Then time passed and I began to
realize that radiosity (even with not-so-extreme settings) doesn't get on
with glass. How is it possible? Is there something in the code that says
"hey, a transparent object! Make a 100000-steps-for()-loop for every pixel
to make it slower. Only the patient ones will deserve it!"? Is there a way
to speed up radiosity indoor scenes (possibly with glass)?
I'm not a patient one, so I killed the render after 41 hours of agony.
--
Jonathan.
Post a reply to this message
Attachments:
Download 'pity.jpg' (80 KB)
Preview of image 'pity.jpg'
![pity.jpg](/povray.binaries.images/attachment/%3C3be39102%40news.povray.org%3E/pity.jpg?ttop=443840&toff=10150&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>
> This was just meant to be a test render. Then time passed and I began to
> realize that radiosity (even with not-so-extreme settings) doesn't get on
> with glass. How is it possible? Is there something in the code that says
> "hey, a transparent object! Make a 100000-steps-for()-loop for every pixel
> to make it slower. Only the patient ones will deserve it!"? Is there a way
> to speed up radiosity indoor scenes (possibly with glass)?
Remember: radiosity+glass+area_light+antialias>=infinite :)
Gilles said that a workaround is lowering ior, but that could affect
realism of the glass if it is too close. In this case, as it seems not
very transparent, you could make it opaque (it will look cool anyhow!).
> I'm not a patient one, so I killed the render after 41 hours of agony.
A pain you killed it: but if it was just finishing the glass! The slow
part was almost finished! Oh...
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
JRG wrote:
>
> This was just meant to be a test render. Then time passed and I began to
> realize that radiosity (even with not-so-extreme settings) doesn't get on
> with glass. How is it possible? Is there something in the code that says
> "hey, a transparent object! Make a 100000-steps-for()-loop for every pixel
> to make it slower. Only the patient ones will deserve it!"? Is there a way
> to speed up radiosity indoor scenes (possibly with glass)?
> I'm not a patient one, so I killed the render after 41 hours of agony.
>
Hmm, are those wood planks isosurfaces?
Glass with radiosity can be quite slow, but 1d17h is not very extreme for
such a scene. I had a similar situation in my picture for the 10best
cover image contest and it came near a halt (~30min per line) on my old K6
when reaching the glass objects. There were photons and a lot of
isosurfaces too of course.
Something that would really help in such a situation would be a
no_radiosity modifier for objects. You could create a second bowl for
radiosity with no_image, no_shadow and no_reflection and a simple material
and use no_radiosity for the real bowl.
The fruits look great, apart from the leftmost apple floating in the air
of course. Is there subsurface scattering on the orange?
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jaime Vives Piqueres wrote:
> Remember: radiosity+glass+area_light+antialias>=infinite :)
Then radiosity+glass+area_light+antialias+isosurfaces...
> A pain you killed it: but if it was just finishing the glass! The slow
> part was almost finished! Oh...
No. Every line was getting slower and slower, no matter how much glass the
line was passing through. I think that in radiosity scenes glass can
considerably slow down things even if it is behind the camera...
--
Jonathan.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christoph Hormann wrote:
> Hmm, are those wood planks isosurfaces?
Yes, they are.
> Glass with radiosity can be quite slow, but 1d17h is not very extreme for
> such a scene. I had a similar situation in my picture for the 10best
> cover image contest and it came near a halt (~30min per line) on my old K6
> when reaching the glass objects. There were photons and a lot of
> isosurfaces too of course.
But it was a final render, not a simple test! :)
I have to say that with recursion_limit 1 things were a bit less slow, but
the unlit parts were completely black, so I had to raise it to 3.
Not to mention the fact that without the glass object the scene looked much
brighter (who knows why)...
> Something that would really help in such a situation would be a
> no_radiosity modifier for objects. You could create a second bowl for
> radiosity with no_image, no_shadow and no_reflection and a simple material
> and use no_radiosity for the real bowl.
What about rendering the scene without the glass, saving radiosity data, and
reloading them later with always_sample off and with the glass objects
included? Would it look good? I have to try.
> The fruits look great, apart from the leftmost apple floating in the air
> of course.
<Cough>... :)
> Is there subsurface scattering on the orange?
Nope. The scattering with that iso was really slow and didn't look that
good. But with radiosity it looks good anyway.
--
Jonathan.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Set glass or transparent objects like this when saving rad data:
no interior
no normal
no reflection
diffuse 0 ambient 0
filter/transmit only
Then set them back to normal and:
load_file "rad.dat" always_sample off pretrace_start 1 pretrace_end 1
diffuse 0 ambient 0 appeared to speed it most.
This was just from 10 minutes of testing so more quality may
be possible without increasing render time dramatically.
_____________
Kari Kivisalo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I did some more testing and this is good for glass when
saving rad data:
max_trace_level recursion_limit+1
diffuse 0 ambient 0
no normal
no reflection
Low res without aa is enough for the rad data.
Close beta 7 before rendering with the saved data. It was
very slow when rendering right after saving the rad data.
_____________
Kari Kivisalo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Kari Kivisalo wrote:
> I did some more testing and this is good for glass when
> saving rad data:
>
> max_trace_level recursion_limit+1
> diffuse 0 ambient 0
> no normal
> no reflection
I will try it for sure.
> Low res without aa is enough for the rad data.
Even with high quality settings?
> Close beta 7 before rendering with the saved data. It was
> very slow when rendering right after saving the rad data.
Hmm, is this a known bug of some sort?
Thanks for the hint,
--
Jonathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
JRG wrote:
>
> > Low res without aa is enough for the rad data.
>
> Even with high quality settings?
If you want to force rad sample for every pixel then
you must use final resolution but 1/2 - 1/3 resolution
should be enough for most scenes.
> > Close beta 7 before rendering with the saved data. It was
> > very slow when rendering right after saving the rad data.
>
> Hmm, is this a known bug of some sort?
I haven't reported this yet due to lack of minimal scene
but I think there is a "using load_file after save_file
causes slowdown" bug which may be related to "restarting
while in pretrace causes slowdown" bug.
The combined rendertime for the rad and final scenes
was 1/8th of the one pass render for my test scene.
_____________
Kari Kivisalo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I've rendered a 320x240 version for saving data, which took about 20
minutes. I followed your suggestions and I also turned off the area_light
and the displacement of the iso- wood planks.
Now I'm rendering the 640*480 version which seems quite fast. I will post
the result when finished.
I'm wandering how save_file and load_file work. I mean, if turn
always_sample off it shouldn't matter whether you use some radiosity
settings or some others, should it?
--
Jonathan.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |