|
|
|
|
|
|
| |
| |
|
|
From: Vaclav Cermak
Subject: Re: POV 3.7 beta 31 slow with mesh objects
Date: 23 Mar 2009 04:39:00
Message: <49c74aa4@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |