Just an FYI to the folks who are interested: Christoph's radiosity fixes
have been integrated and see to work very well. A hearty 'thanks' to him
for this! I intend to do a release in the next day or two that incorporates
the new code.

On my system (8 cores), cornell.pov at 1280x1024 AA 0.3 renders in 20
seconds with a speedup ratio of about 7x. I haven't looked into what might
be chewing up the rest of the CPU time, other than to note that the cores
aren't quite 100% pegged in the first five or so seconds of the render. (I
am guessing it may be related to the early sampling and octree code but
either way I'm happy enough with it just as it is:)

I haven't tried any animations yet or anything.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that incorporates
> the new code.
>
> On my system (8 cores), cornell.pov at 1280x1024 AA 0.3 renders in 20
> seconds with a speedup ratio of about 7x.

Whoa!  clipka is really Santa under disguise! :D

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote in message 
news:web.4965f14cbea0b42de44542980@news.povray.org...
> Whoa!  clipka is really Santa under disguise! :D

Hey .... and thanks Chris as well for getting to this quickly!

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that incorporates
> the new code.

You guys are magicians! I stand in awe of what both of you have accomplished.

Ken W.

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that incorporates
> the new code.

You're welcome! It's all just pure selfishness anyway :)

> On my system (8 cores), cornell.pov at 1280x1024 AA 0.3 renders in 20
> seconds with a speedup ratio of about 7x. I haven't looked into what might
> be chewing up the rest of the CPU time, other than to note that the cores
> aren't quite 100% pegged in the first five or so seconds of the render. (I
> am guessing it may be related to the early sampling and octree code but

Some things that may come into play here:

- The pre-render is done in multiple passes again, and after each pass the
system waits for all threads to finish (this will get some importance when
heading for that 100% reproducability thing) before starting the next pass;
this is *one* reason why the CPU utilization doesn't reach 100% during the
first seconds. This effect is strongest of course in images that render very
quickly, but will probably not be much of an issue for renders that take long
anyway. (A potential idea for optimization here would be to measure the (CPU)
time spent on a block during each pass, and do the most "expensive" ones first
during the next pass.)

- The first seconds of the pre-render sees a very high ratio of new samples
being taken per ray shot, with each new sample requiring the radiosity cache to
be locked for a brief moment, making it more likely for a thread having to wait
for another one to release its lock. In addition, and probably more
importantly, much of the cache's octree structure used to organize the samples
still has to be "grown" in this phase, again requiring a lock each time
additional nodes are added; these locks need to be maintained for a much longer
duration than for the mere adding of samples. These are additional reasons for
the incomplete utilization.

- The splotchy artifacts seen in 3.6 radiosity were due to a flawed design that
"cut short" some sample rays; with the flaws fixed, these rays are traced
further than before, increasing rendering time accordingly. (This shouldn't
play a role on cornell.pov though.) In addition, the fixes required passing
additional data through the render engine, thereby increasing general rendering
overhead a bit.

- With increasing radiosity recursion depth, POV-Ray reduces some quality
parameters. I modified the corresponding rules a bit in favor of quality, which
of course comes at a cost of time.

> either way I'm happy enough with it just as it is:)

Glad to hear that. I hope the beta testers will be as well. Me, however, I'm not
yet ;) I'm still trying to get some speedup for high-quality shots, using an
adaptive pretrace approach. Still encountering some obstacles though.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> Whoa!  clipka is really Santa under disguise! :D

You better stop this, or I might actually start believing it =B)

(So if you see me dressed all in red-and-white, you'll know what happened... ;))

Post a reply to this message

Chris Cason wrote:
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that incorporates
> the new code.

This is really good news. POV's radiosity is already the fastest I have 
encountered, and I get really good results as well. I have tested 
Kerkythea, YafRay and LightWave. POV-Ray's radiosity beats them all, but 
by what margin I cannot say.

Thank you to Chris Cason, clipka and the rest of the POV team!

Sam

Post a reply to this message

Oh you Great Heroes of Our (Render) Time!!

Chris, Clipka, without you the world would be a different place  :-)

Thanks!!

Thomas

Post a reply to this message

> This is really good news. POV's radiosity is already the fastest I have 
> encountered, and I get really good results as well. I have tested 
> Kerkythea, YafRay and LightWave. POV-Ray's radiosity beats them all, but
>  by what margin I cannot say.

   I find myself thinking the same when I try every other
raytracer/renderer... (we are talking about the free ones, of course).

> Thank you to Chris Cason, clipka and the rest of the POV team!

   Same here!

--
jaime

Post a reply to this message

I posted a test render in p.b-t.b. Did not experience the same speedup with 
all scenes. The new beta is slower once I started adjusting global radiosity 
settings.

Mike


"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4965cd6e$1@news.povray.org...
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that 
> incorporates
> the new code.
>
> On my system (8 cores), cornell.pov at 1280x1024 AA 0.3 renders in 20
> seconds with a speedup ratio of about 7x. I haven't looked into what might
> be chewing up the rest of the CPU time, other than to note that the cores
> aren't quite 100% pegged in the first five or so seconds of the render. (I
> am guessing it may be related to the early sampling and octree code but
> either way I'm happy enough with it just as it is:)
>
> I haven't tried any animations yet or anything.
>
> -- Chris

Post a reply to this message