Hi,

  I tested scene with mesh objects with many triangles and POV 3.7 beta 
on two cores renders it slower than old single threaded MegaPOV.

  Test scene with statistics files from MegaPOV and POV 3.7 beta are on

  http://devel.disnel.com/pov3.7-test

  it is rad_test04. Mesh objects are with unnecessary high detail to 
demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7 
beta is mush faster than MegaPOV with them, as expected.

Vaclav

Post a reply to this message

Vaclav Cermak wrote:
>  I tested scene with mesh objects with many triangles and POV 3.7 beta 
> on two cores renders it slower than old single threaded MegaPOV.

>  it is rad_test04. Mesh objects are with unnecessary high detail to 
> demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7 
> beta is mush faster than MegaPOV with them, as expected.

How did you conclude from a scene using radiosity that meshes are slower?

	Thorsten

Post a reply to this message

Thorsten Froehlich napsal(a):
> Vaclav Cermak wrote:
>>  I tested scene with mesh objects with many triangles and POV 3.7 beta 
>> on two cores renders it slower than old single threaded MegaPOV.
> 
>>  it is rad_test04. Mesh objects are with unnecessary high detail to 
>> demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7 
>> beta is mush faster than MegaPOV with them, as expected.
> 
> How did you conclude from a scene using radiosity that meshes are slower?
> 
>     Thorsten

With scenes without meshes is POV 3.7 mush faster than MegaPov, with 
scenes with mesh objects is slower (much slower). From this I conclude, 
that there is some problem with mesh objects. I don't conclude anything 
about radiosity, I just use it nearly in all my renders and I used it in 
test renders as well. I may try it with radiosity switched off, if it helps.

Vaclav

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
> Thorsten Froehlich napsal(a):
> > Vaclav Cermak wrote:
> >>  I tested scene with mesh objects with many triangles and POV 3.7 beta
> >> on two cores renders it slower than old single threaded MegaPOV.
> >
> >>  it is rad_test04. Mesh objects are with unnecessary high detail to
> >> demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7
> >> beta is mush faster than MegaPOV with them, as expected.
> >

Hello.

I assume that this is:

  *recursion_limit 2*

Currently, a recursion_limit > 1 slows the rendering of the scene compared to
POV-Ray 3.6.
This, because the algorithm of radiosity is under investigation.

> test renders as well. I may try it with radiosity switched off, if it helps.

try!
;-)

--
Carlo

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
> With scenes without meshes is POV 3.7 mush faster than MegaPov, with
> scenes with mesh objects is slower (much slower). From this I conclude,
> that there is some problem with mesh objects. I don't conclude anything
> about radiosity, I just use it nearly in all my renders and I used it in
> test renders as well. I may try it with radiosity switched off, if it helps.

I assume we're talking about smooth meshes (i.e. mesh with smooth_triangle
elements, or mesh2 with normal vectors).

Can you do tests with "flat" meshes as well for reference?

Some of the changes I made to the radiosity code might have affected sample
density (and hence render time) on objects with pertubed normals (like smooth
meshes).

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
>   Test scene with statistics files from MegaPOV and POV 3.7 beta are on
>
>   http://devel.disnel.com/pov3.7-test
>
>   it is rad_test04. Mesh objects are with unnecessary high detail to
> demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7
> beta is mush faster than MegaPOV with them, as expected.

I took the liberty to add rad_test02 and rad_test04 to the portfolio of scenes I
use for benchmarking radiosity code changes. The 01 and 03 scenes asked for
additional include files which I did not find on the devel.disnel.com.

So far, tests with various variations to the radiosity code indicate that the
slowdown is in fact highly radiosity-related.

I expect future versions of POV-Ray to still require more CPU time for the
scenes than MegaPOV, but once again render faster in terms of "wall clock" time
even on a DualCore.

Post a reply to this message

Fell free to use these scenes in any way.

Rad_test01 is something different and uses my own set of macros (you can 
get them at http://povarch.sourceforge.net). This scene I used to 
determine, how POV 3.7 works with trasparent objects and radiosity, you 
don't need it for the problem with meshes. Rad_test03 uses fgrass.inc 
include file made by Rune S. Johansen and can be obtained on his pages 
(http://runevision.com). With this scene I tested, if the slowdown is 
not related to complex textures (fgrass has several layers of textures 
defined by function), I concluded, that not (you can look at .stat and 
.time files there, .stat is statistics output from POV, .time is output 
of UNIX time utility). Scene with fgrass texture was rendered faster 
with 3.7 (but not two times faster, the speedup was much smaller ...).

I'll try rad_test04 with recursion_limit 1, as proposed by Carlo. C, and 
with flat meshes, as proposed by you.

clipka wrote:
> Vaclav Cermak <dis### [at] disnelcom> wrote:
>>   Test scene with statistics files from MegaPOV and POV 3.7 beta are on
>>
>>   http://devel.disnel.com/pov3.7-test
>>
>>   it is rad_test04. Mesh objects are with unnecessary high detail to
>> demonstrate the problem. Rad_test 02 and 03 are without meshes and 3.7
>> beta is mush faster than MegaPOV with them, as expected.
> 
> I took the liberty to add rad_test02 and rad_test04 to the portfolio of scenes I
> use for benchmarking radiosity code changes. The 01 and 03 scenes asked for
> additional include files which I did not find on the devel.disnel.com.
> 
> So far, tests with various variations to the radiosity code indicate that the
> slowdown is in fact highly radiosity-related.
> 
> I expect future versions of POV-Ray to still require more CPU time for the
> scenes than MegaPOV, but once again render faster in terms of "wall clock" time
> even on a DualCore.
> 
> 
>

Post a reply to this message

rad_test04_flat (flat mesh) and rad_test04_rl1 (rad recursion level 1) 
are there with resulting files and statistics. Speed problem looks very 
similar with them.

Vaclav

Post a reply to this message

> (http://runevision.com). With this scene I tested, if the slowdown is
> not related to complex textures (fgrass has several layers of textures
> defined by function), I concluded, that not (you can look at .stat and
> .time files there, .stat is statistics output from POV, .time is output
> of UNIX time utility). Scene with fgrass texture was rendered faster
> with 3.7 (but not two times faster, the speedup was much smaller ...).

I'm not surprised about the conclusions you drew from those stats, and as a
matter of fact I do see the same results here. If I wasn't the guy currently
twiddling around with radiosity to get it back to speed, I would probably come
to the same conclusions as you did.


> I'll try rad_test04 with recursion_limit 1, as proposed by Carlo. C, and
> with flat meshes, as proposed by you.

The flat mesh idea is more sort of an experiment to get a clearer picture why
exactly radiosity is slowing down. If you're just after reasonably fast renders
of your shot, recursion_limit 1 is currently what you want.

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
> rad_test04_flat (flat mesh) and rad_test04_rl1 (rad recursion level 1)
> are there with resulting files and statistics. Speed problem looks very
> similar with them.

This is bad. I'm not too surprised about the flat mesh results, but the
recursion level 1 shots should render a good deal faster.

I'll run those scenes through my benchmarking process to see if I can get a
clearer picture on this.

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
> Rad_test01 is something different and uses my own set of macros (you can
> get them at http://povarch.sourceforge.net).

Um... I'm sorry to say, but no, I can't. All I get is a message saying:

"We're Sorry but this Project hasn't yet uploaded their personal webpage yet.
Please check back soon for updates or visit SourceForge"

Post a reply to this message

> don't need it for the problem with meshes. Rad_test03 uses fgrass.inc
> include file made by Rune S. Johansen and can be obtained on his pages
> (http://runevision.com). With this scene I tested, if the slowdown is

Are you sure it's Rune's grass? On runevision.com, all I could find was a
"grasstex.inc", with macro names "gt_*", not "fg_*".

Post a reply to this message

I'am sorry, sourceforge was changed several times from the time of start 
of POVarch project and I wrote URL without check.... Newest version can 
be obtained from SVN on sourceforget or I uploaded tarball into the same 
directory as test scenes

http://devel.disnel.com/pov3.7-test/POVarch.tar.gz

But as I already wrote, this scene (rad_test01) was only for my testing, 
and contains nothing related to mesh slowdown problem. It appeared on 
web only because I uploaded there whole directory ... And in fact, from 
my macro library it uses only macro for camera setup and sun setup.

clipka wrote:
> Vaclav Cermak <dis### [at] disnelcom> wrote:
>> Rad_test01 is something different and uses my own set of macros (you can
>> get them at http://povarch.sourceforge.net).
> 
> Um... I'm sorry to say, but no, I can't. All I get is a message saying:
> 
> "We're Sorry but this Project hasn't yet uploaded their personal webpage yet.
> Please check back soon for updates or visit SourceForge"
> 
> 
>

Post a reply to this message

Again sorry, it is older version of Rune's grass, I uploaded it into my 
directory with test scenes (file fgrass.inc). I'am not sure, if I am 
authorized to do this  (but other includes from him are under GPL), so 
I'll remove it as soon as possible.

clipka wrote:
>> don't need it for the problem with meshes. Rad_test03 uses fgrass.inc
>> include file made by Rune S. Johansen and can be obtained on his pages
>> (http://runevision.com). With this scene I tested, if the slowdown is
> 
> Are you sure it's Rune's grass? On runevision.com, all I could find was a
> "grasstex.inc", with macro names "gt_*", not "fg_*".
> 
> 
>

Post a reply to this message

Vaclav Cermak <dis### [at] disnelcom> wrote:
> Again sorry, it is older version of Rune's grass, I uploaded it into my
> directory with test scenes (file fgrass.inc). I'am not sure, if I am
> authorized to do this  (but other includes from him are under GPL), so
> I'll remove it as soon as possible.

Got the file, thanks. I hope Rune will forgvie us in this case ;)

Post a reply to this message

clipka wrote:
> 
> Got the file, thanks. I hope Rune will forgvie us in this case ;)
> 

Just removed the file, it was only a small offence, I think ;-)

Post a reply to this message