clipka <ano### [at] anonymousorg> wrote:
> Am 06.05.2010 01:11, schrieb Dre:
> Hey, the radiosity feature /is/ fully operational in the current 3.7
> betas for quite some months already (except if Dave needs to use the
> abort/continue feature)...

Uh-oh, that means I've done something wrong again... There are two objects that
I have to comment out to render the whole scene with radiosity activated, or
else the radiosity pre-trace steps seem to go on forever. Version 3.62 will
render the scene without problems, so I assumed the radiosity feature wasn't
quite implemented yet in version 3.7. Thanks for the tip!

Regards,
Dave Blandston

Post a reply to this message

Am 09.05.2010 18:22, schrieb Dave Blandston:

> Uh-oh, that means I've done something wrong again... There are two objects that
> I have to comment out to render the whole scene with radiosity activated, or
> else the radiosity pre-trace steps seem to go on forever. Version 3.62 will
> render the scene without problems, so I assumed the radiosity feature wasn't
> quite implemented yet in version 3.7. Thanks for the tip!

I'd be interested in details, because that shouldn't happen, so maybe 
there's still some problem in certain situations.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I'd be interested in details, because that shouldn't happen, so maybe
> there's still some problem in certain situations.

Here's a complete but simple scene demonstrating the situation. Version 3.7 will
eventually render the scene, but when the object is used in a more complex scene
the radiosity step goes on seemingly forever. There is one more object I've come
across that causes the same phenomenon, which I can post as well if you wish.

Regards,
Dave Blandston

------------------

//Version 3.7 Beta 37a takes 24 minutes 55 seconds to render at 512 x 384 +am2
+r3.
//Version 3.62 takes 6 minutes 31 seconds to render with the same settings.

//Measured on a computer with four processors.

global_settings {
   radiosity {
      count 300
      error_bound .02
      pretrace_start .08
      pretrace_end .004
      recursion_limit 2
      normal on
   } //radiosity
} //global_settings

#include "colors.inc"

camera {
   location <0, 0, -3>
   direction <0, 0, 4/3>
   look_at <0, 0, 0>
} //camera

#local Dome = object {
   difference {
      sphere {0, 20001}
      sphere {0, 20000}
   } //difference
   texture {
      pigment {
         gradient z
         color_map {
            [0, 1 color White * 1.8 color White * .6]
         } //color_map
      } //pigment
      finish {ambient 1 diffuse 0}
      scale <1, 1, 20000>
   } //texture
   no_reflection
} //object

object {Dome}

plane {z, 4 inverse texture {pigment {color rgb <213, 250, 81> / 255 * .6}}}

#local RingDiameter = 1 + 5/32;
#local RingWireRadius = 3/64;

#local Ring = object {
   #local NDegrees = 360 + 180;
   #local DeltaTheta = 15;
   #local NPoints = NDegrees / DeltaTheta + 3;
   #local DeltaZ = RingWireRadius / (360 / DeltaTheta) * 2;
   sphere_sweep {
      b_spline
      NPoints
      #local Theta = -DeltaTheta;
      #local CurZ = -DeltaZ;
      #local I = 0;
      #while (I < NPoints)
         <RingDiameter / 2 * cos (radians (Theta)), RingDiameter / 2 * sin
(radians (Theta)), CurZ>, RingWireRadius
         #local Theta = Theta + DeltaTheta;
         #local CurZ = CurZ + DeltaZ;
         #local I = I + 1;
      #end //#while
   } //sphere_sweep
   texture {pigment {color Yellow}}
} //object

object {Ring}

Post a reply to this message

Am 10.05.2010 12:31, schrieb Dave Blandston:

> Here's a complete but simple scene demonstrating the situation. Version 3.7 will
> eventually render the scene, but when the object is used in a more complex scene
> the radiosity step goes on seemingly forever. There is one more object I've come
> across that causes the same phenomenon, which I can post as well if you wish.

Hm... is the other a sphere_sweep object as well?

At present I'm pretty much inclined to think that this is not an issue 
of radiosity /per se/, but rather a general performance issue with 3.7's 
implementation of sphere sweeps, which is only emphasized by the numer 
of rays shot for radiosity.

As far as this particular object goes, I suggest you try using a set of 
half-tori instead of the sphere_sweep.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Hm... is the other a sphere_sweep object as well?
>
> At present I'm pretty much inclined to think that this is not an issue
> of radiosity /per se/, but rather a general performance issue with 3.7's
> implementation of sphere sweeps, which is only emphasized by the numer
> of rays shot for radiosity.
>
> As far as this particular object goes, I suggest you try using a set of
> half-tori instead of the sphere_sweep.

The other object is a little harder to pin down - it's a union of several boxes
and a couple intersections (with bounded_by containers) comprising the Metallica
logo. It's very low-tech CSG originally made with POV-Ray version 1, but it has
bevelled edges and reflection. Depending on what other objects I include in the
scene, render times vary quite a bit when using radiosity. I'm trying to narrow
the problem down more...

Thanks for the advice regarding the sphere_sweep!

Regards,
Dave Blandston

Post a reply to this message