Here's an enthusiasming result of summer of code:
Blender speedup quantified per feature (see stamps on the images) here:
http://wiki.blender.org/index.php/User:Jaguarandi/SummerOfCode2009/TestScenes

more ressources from here:
http://www.blendernation.com/google-summer-of-code-faster-ray-tracing/

Would such a boost be possible in Pov or is everything already as fast as it can
possibly be?

Post a reply to this message

Edit, I hope I didn't break too many rules with this topic

Post a reply to this message

Mr schrieb:
> Edit, I hope I didn't break too many rules with this topic

Why? This is about POV-Ray related tools, and blender can obviously be 
regarded as such.

Post a reply to this message

Mr schrieb:
> Would such a boost be possible in Pov or is everything already as fast as it can
> possibly be?

Note that...

- most of the scenes that mention a speedup are pathological cases

- it appears to me that when they say "173% faster", 100% would equal no 
speedup (though I may be mistaken; but it is remarkable that all these 
values are >100%), making some of the numbers a bit less impressive than 
they appear at first.

(Interestingly, they only mention the speedup, but not the absolute 
render time...?!)


As for POV-Ray, I guess there's still room for improvement here and 
there, but it'll be hard to find anything that could be sped up by 3943%.

Well, going for better handling of CSG differences (the pathological 
case with lots of tiny holes in a single big object) could be a case.

Subsurface scattering still provides a lot of room for speedup, too, but 
I guess that doesn't count, as it's still under development anyway.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > Would such a boost be possible in Pov or is everything already as fast as it can
> > possibly be?
>
> Note that...
>
> - most of the scenes that mention a speedup are pathological cases
>
> - it appears to me that when they say "173% faster", 100% would equal no
> speedup (though I may be mistaken; but it is remarkable that all these
> values are >100%), making some of the numbers a bit less impressive than
> they appear at first.
>
> (Interestingly, they only mention the speedup, but not the absolute
> render time...?!)
>
>
> As for POV-Ray, I guess there's still room for improvement here and
> there, but it'll be hard to find anything that could be sped up by 3943%.
>
> Well, going for better handling of CSG differences (the pathological
> case with lots of tiny holes in a single big object) could be a case.
>
> Subsurface scattering still provides a lot of room for speedup, too, but
> I guess that doesn't count, as it's still under development anyway.

The reason I ask is also because there seems to be a (not so) new trend of fast
renderers like Vray as proprietary and  Yafaray as open source Which get render
times so different from the ones I (think I) know better like mental ray.
I'm wondering where this time is going, what's the catch...?

Post a reply to this message

Mr schrieb:
> The reason I ask is also because there seems to be a (not so) new trend of fast
> renderers like Vray as proprietary and  Yafaray as open source Which get render
> times so different from the ones I (think I) know better like mental ray.
> I'm wondering where this time is going, what's the catch...?

Not sure. I like to believe that a whole lot of it is due to the focus 
on mesh-only geometry, and optimizations that can be applied in such cases.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > The reason I ask is also because there seems to be a (not so) new trend of fast
> > renderers like Vray as proprietary and  Yafaray as open source Which get render
> > times so different from the ones I (think I) know better like mental ray.
> > I'm wondering where this time is going, what's the catch...?
>
> Not sure. I like to believe that a whole lot of it is due to the focus
> on mesh-only geometry, and optimizations that can be applied in such cases.

Very interesting. Then is it planned (maybe for POV 4) or even possible to think
of a "dual" engine where the second "core" would turn on only for non mesh only
scenes?

Post a reply to this message

Mr schrieb:
> Very interesting. Then is it planned (maybe for POV 4) or even possible to think
> of a "dual" engine where the second "core" would turn on only for non mesh only
> scenes?

As there's so much that could be done in a totally different way (and 
not only geometry intersection finding, but also sophisiticated lighting 
models), a "dual engine" approach wouldn't seem to make much sense: They 
couldn't really share any significant amount of code.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Mr schrieb:
> > Very interesting. Then is it planned (maybe for POV 4) or even possible to think
> > of a "dual" engine where the second "core" would turn on only for non mesh only
> > scenes?
>
> As there's so much that could be done in a totally different way (and
> not only geometry intersection finding, but also sophisiticated lighting
> models), a "dual engine" approach wouldn't seem to make much sense: They
> couldn't really share any significant amount of code.

Yes, the best thing is to use the two types of engines then, to later make
better choices on when to use Pov. So little time and so much to learn.

Post a reply to this message