 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've put together a guide on how to improve rendering speed with
POV-Ray. It is meant to be an introduction to the topic, a collection of
links to already existing articles and a place to publish new tips and
tricks:
http://torfbold.com/index.php?main=Graphics&sub=POV+Speed+Guide
I'm of course very interested in feedback from the community. So if
you've got critcism, suggestions, spotted typos, etc. I'd like to know
about it.
If you want to contribute a tip or trick to the guide, this is of course
appreciated even more ;) Two-pass radiosity renders should be mentioned
somewhere, for example... (I can't give tips on things I don't know
nothing about ;)
Thanks for any tips, and a special "Thank you!" to the whole community
for always being my main source of POV-Ray knowledge (I hope I can give
something back to the community with my article).
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <419a5b55$1@news.povray.org> , Florian Brucker
<tor### [at] torfbold com> wrote:
> I'm of course very interested in feedback from the community. So if
> you've got critcism, suggestions, spotted typos, etc. I'd like to know
> about it.
For now, four things:
* Great idea and good work!
* In the hardware section, don't make "graphic cards" bold, but "You don't
even need a graphic card to raytrace" because later on you mark bold what is
needed, and a reader only scanning the text could misunderstand that
paragraph.
* Question: On which platform did you measure the streams? I am wondering
because they are much faster than I would have expected.
* The thread about functions you link to contains some wrong information.
The author sin/cos evaluated constant expressions assuming that would make
the function faster. This is not necessary, the function compiler is able
to evaluate constant (sub-)expressions automatically. Currently (as of
3.6.1) the only exception to this are when the constant expression is a
user-defined function (thus what the user declared as "function { ... }") or
a functions that take more than one argument (except "pow", which is
optimised). As such, the functions min, max, select and atan2 are not
optimised if they represent a constant expression. However, it is likely
that in the future (with only a dot-dot version change, i.e. in 3.6.4 or so)
even these functions will be evaluated if they are a constant expression.
The only reason it is not currently done is lack of time to implement what
is needed to do it.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
> I've put together a guide on how to improve rendering speed with
> POV-Ray. It is meant to be an introduction to the topic, a collection of
> links to already existing articles and a place to publish new tips and
> tricks:
>
> http://torfbold.com/index.php?main=Graphics&sub=POV+Speed+Guide
>
> I'm of course very interested in feedback from the community. So if
> you've got critcism, suggestions, spotted typos, etc. I'd like to know
> about it.
Fairly elaborate but you stay somewhat vague in a lot of places - in the
hardware section you say FPU, L1 cache, L2 cache, memory and bus speed
are important but not to what extend and what this means for the reader
- in fact the influence of memory/cache performance depends quite a lot
on the scene. These parts of your guide are probably of quite limited
help for someone who tries to speed up his renders.
What you write about performance of scanline rendering vs. raytracing is
wrong in fact - like any statement that one of them is faster than the
other. They just scale differently. Also it is not that much more
research is going into scanline rendering algorithm improvements than
into raytracing techniques but of course there is a real lot of money
put into specialized hardware.
Still it gives a nice outline what aspects are actually influencing the
render speed.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The better standard unix tool for examining running processes is 'top',
not 'ps'. By default 'ps' will only show the processes run by the user
himself, not other users nor system processes, and 'ps' will not show
any other info about these processes, while 'top' by default shows all
the top processes running in the system sorted by default by the CPU
time they are taking, which is usually what the user is interested in
(this makes 'top' much more equivalent to the task manager of windows).
Graphical interfaces usually do not take almost any CPU time at all
if you are not doing anything with them (unless you are using older
versions of MacOS X) so it's usually not necessary or useful to shut
them down for rendering. In order to better establish whether a
graphical interface slows down rendering in any considerable way
(when you are not doing anything but running POV-Ray with it) you
should *test* it, not just assume it.
Wasn't the image called "First Strike at Pearl Harbour" (unless I have
completely missed a perl joke in that image...)?
The link http://www.geocities.com/SoHo/Workshop/9193/ doesn't seem
to work...
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker nous apporta ses lumieres ainsi en ce 2004-11-16 15:00... :
> I've put together a guide on how to improve rendering speed with
> POV-Ray. It is meant to be an introduction to the topic, a collection
> of links to already existing articles and a place to publish new tips
> and tricks:
>
> http://torfbold.com/index.php?main=Graphics&sub=POV+Speed+Guide
>
> I'm of course very interested in feedback from the community. So if
> you've got critcism, suggestions, spotted typos, etc. I'd like to know
> about it.
>
> If you want to contribute a tip or trick to the guide, this is of
> course appreciated even more ;) Two-pass radiosity renders should be
> mentioned somewhere, for example... (I can't give tips on things I
> don't know nothing about ;)
>
> Thanks for any tips, and a special "Thank you!" to the whole community
> for always being my main source of POV-Ray knowledge (I hope I can
> give something back to the community with my article).
>
>
> Florian
Nice looking page in Firefox, not so nice in msie.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Alain" <aze### [at] qwertygov> wrote in message
news:419a7c6d$1@news.povray.org...
> Florian Brucker nous apporta ses lumieres ainsi en ce 2004-11-16 15:00...
:
>
> > I've put together a guide on how to improve rendering speed with
> > POV-Ray. It is meant to be an introduction to the topic, a collection
> > of links to already existing articles and a place to publish new tips
> > and tricks:
> >
> > http://torfbold.com/index.php?main=Graphics&sub=POV+Speed+Guide
> >
> > I'm of course very interested in feedback from the community. So if
> > you've got critcism, suggestions, spotted typos, etc. I'd like to know
> > about it.
> >
> > If you want to contribute a tip or trick to the guide, this is of
> > course appreciated even more ;) Two-pass radiosity renders should be
> > mentioned somewhere, for example... (I can't give tips on things I
> > don't know nothing about ;)
> >
> > Thanks for any tips, and a special "Thank you!" to the whole community
> > for always being my main source of POV-Ray knowledge (I hope I can
> > give something back to the community with my article).
> >
> >
> > Florian
>
> Nice looking page in Firefox, not so nice in msie.
hehe. that was my first impression too. well, i had half of it anyway. "Nice
looking page, and even in Firefox!"
havn't looked in IE yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
> I've put together a guide on how to improve rendering speed with
> POV-Ray. It is meant to be an introduction to the topic, a collection of
> links to already existing articles and a place to publish new tips and
> tricks:
Thanks Florian! I found it very informative - I don't know as much as the
other guys here about Pov and its internals, but I anyway found a few
interesting tips I didn't know about for speeding up my scenes.
--
Stefan Viljoen
Software Support Technician
Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
>> for always being my main source of POV-Ray knowledge (I hope I can
>> give something back to the community with my article).
>>
>>
>> Florian
>
> Nice looking page in Firefox, not so nice in msie.
Looks pretty darn good in Mozilla too...
--
Stefan Viljoen
Software Support Technician
Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <419af7de@news.povray.org> , Stefan Viljoen <ryl### [at] polardcom>
wrote:
>> Nice looking page in Firefox, not so nice in msie.
>
> Looks pretty darn good in Mozilla too...
That's the same thing...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:419b158c$1@news.povray.org...
> In article <419af7de@news.povray.org> , Stefan Viljoen <ryl### [at] polardcom>
> wrote:
>
> >> Nice looking page in Firefox, not so nice in msie.
> >
> > Looks pretty darn good in Mozilla too...
>
> That's the same thing...
Actually, Mozilla Firefox isn't the same as the browser in the Mozilla
Suite.
But it uses the same layout engine so I guess for all intents and purposes
so far as rendering it is :)
</nitpick>
Lance.
thezone - thezone.firewave.com.au
thehandle - www.thehandle.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwertygov> wrote:
> Nice looking page in Firefox, not so nice in msie.
It's nice to see that some people finally have the courage to drop
msie from the list of fully supported browsers.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> * Great idea and good work!
Thanks!
> * In the hardware section, don't make "graphic cards" bold, but "You don't
> even need a graphic card to raytrace" because later on you mark bold what is
> needed, and a reader only scanning the text could misunderstand that
> paragraph.
Good idea.
> * Question: On which platform did you measure the streams? I am wondering
> because they are much faster than I would have expected.
Text terminal in Linux (Gentoo 2.4.25). I tried to get timings using
-GA, but that did not work at all (I got the debug messages
nevertheless), see my thread in p.b.g.
> * The thread about functions you link to contains some wrong information.
> [constant expressions evaluated at parse time]
But it still true that using internal functions for non-constant
expressions is faster than using user defined functions, isn't it? As
mentioned in that paragraph the subject is above my level of knowledge,
so I just quoted Tor's post. I hope I can do some benchmarks myself
about it.
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Fairly elaborate but you stay somewhat vague in a lot of places - in the
> hardware section you say FPU, L1 cache, L2 cache, memory and bus speed
> are important but not to what extend and what this means for the reader
> - in fact the influence of memory/cache performance depends quite a lot
> on the scene. These parts of your guide are probably of quite limited
> help for someone who tries to speed up his renders.
100% ACK. As you say yourself, the specific scene makes a huge
difference with those values. I could have left it out, but IMHO the
influence of hardware on render times should be mentioned somewhere. So
I tried to give a basic overview of how it works (this paragraph is
pretty much the same as the one found in the docs). Additionally, I
wanted to make sure that the reader gets to know that the pure CPU speed
in GHz is not the only thing that matters (as opposed to the image some
CPU manufacturers try to create).
> What you write about performance of scanline rendering vs. raytracing is
> wrong in fact - like any statement that one of them is faster than the
> other. They just scale differently. Also it is not that much more
> research is going into scanline rendering algorithm improvements than
> into raytracing techniques but of course there is a real lot of money
> put into specialized hardware.
I'm not involved into CG research myself, so I might be wrong about how
much is researched in which field. It's just my impression that of the
many papers about CG you find on the net, a majority discusses
scanline-rendering issues.
The performance comparison might be wrong in general, too, but this is
again what applies for most people: The basic user, who renders average
scenes, will often find that scanline rendering is faster. That's why I
tried to make clear, that scanline may be faster, but that raytracing
will give you more accurate results.
> Still it gives a nice outline what aspects are actually influencing the
> render speed.
Thanks!
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The better standard unix tool for examining running processes is 'top',
> not 'ps'.
You're right. Don't know what I was thinking oO
> Graphical interfaces usually do not take almost any CPU time at all
> if you are not doing anything with them (unless you are using older
> versions of MacOS X) so it's usually not necessary or useful to shut
> them down for rendering. In order to better establish whether a
> graphical interface slows down rendering in any considerable way
> (when you are not doing anything but running POV-Ray with it) you
> should *test* it, not just assume it.
Does displaying the image which is rendered at the same time take much
CPU time? I don't know, but I believed in what the docs say about it.
It's true that I did not test the CPU usage of a graphical interface.
Perhaps I should leave that sentence out.
> Wasn't the image called "First Strike at Pearl Harbour" (unless I have
> completely missed a perl joke in that image...)?
> The link http://www.geocities.com/SoHo/Workshop/9193/ doesn't seem
> to work...
It's really called "First Strike at Pearl", according to
http://irtc.org/stills/1998-12-31.html Perhaps there's a camel hidden
somewhere ;)
That link is strange: It did work when I wrote the article. It doesn't
work now, you're right, and all links which google spits out about the
topic aren't working, either. Perhaps Glenn McCarter or N.B. took their
website offline.
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
> The performance comparison might be wrong in general, too, but this is
> again what applies for most people: The basic user, who renders average
> scenes, will often find that scanline rendering is faster. That's why I
> tried to make clear, that scanline may be faster, but that raytracing
> will give you more accurate results.
Either make it right or don't write anything about it. Just writing
something because it conforms with the unqualified impression of the
majority is quite a bad idea. I know quite a lot of people (including
professional journalists) do this but this does not make it any better.
The idea to summarize the whole issue with 'scanline rendering is faster
but raytracing is more accurate' is surely tempting since it is simple
and everyone could understand it but it is wrong and sooner or later
everyone who believed this will draw the wrong conclusions.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker wrote:
...
>> * The thread about functions you link to contains some wrong information.
>
> > [constant expressions evaluated at parse time]
>
> But it still true that using internal functions for non-constant
> expressions is faster than using user defined functions, isn't it? As
> mentioned in that paragraph the subject is above my level of knowledge,
> so I just quoted Tor's post. I hope I can do some benchmarks myself
> about it.
Florian,
most of the speedup of Alex Kluchikov's isosurface code was
due to my use of "temporary" functions to receive pre-
calculated values passed as arguments from other functions.
I found this to be a good way to overcome POV-Ray's lack of
local variables for functions. (This seems to be a common
technique around here now ;)
Back in 2002 I wanted to find a way to make my "Almost Sphere
Spirals" (at POV-Ray HOF) image render faster. First I thought
that if I could rearrange the functions so that they were
easier to read and understand, then maybe afterwards I could
manage to simplify and speed things up. I was quite frustrated
that I couldn't use local variables. Suddenly I got the idea
mentioned above. And fortunately this rearranging also
resulted in code that renders much faster than my original
code. (Now this solution seems obvious to me, but back then it
was a lot of work before I arrived at it.)
Different versions of my SphereSpiralsFunction(), that defines
that shape, can be found here (if anyone is interested):
http://news.povray.org/3C549C14.A9009E4@online.no
http://news.povray.org/povray.text.scene-files/20990/
http://home.no/t-o-k/POV-Ray/Riemann_Sphere-Isosurface.txt
Regarding Thorsten's comment:
My impression from the beta testing of POV-Ray v3.5 was that
internal functions evaluated faster than similar user defined
functions, so I might have assumed that this was still the
case when I wrote that code. I need to test this some day...
(But even if it is now not faster to use internal functions
and "precalculated" constants, I think it is a good
programming practice that results in more readable and less
error prone code.)
--
Tor Olav
http://subcube.net
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> In article <419af7de@news.povray.org> , Stefan Viljoen <ryl### [at] polardcom>
> wrote:
>
>>> Nice looking page in Firefox, not so nice in msie.
>>
>> Looks pretty darn good in Mozilla too...
>
> That's the same thing...
Strange you mention that - I must have a beta version of Firefox. 'cause I
dl'ed it a few days ago and almost all pages look absolutely awful -
missing html, broken frames, links that don't show up, etc. etc.
--
Stefan Viljoen
Software Support Technician
Polar Design Solutions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker <tor### [at] torfboldcom> wrote:
> > Graphical interfaces usually do not take almost any CPU time at all
> > if you are not doing anything with them (unless you are using older
> > versions of MacOS X) so it's usually not necessary or useful to shut
> > them down for rendering. In order to better establish whether a
> > graphical interface slows down rendering in any considerable way
> > (when you are not doing anything but running POV-Ray with it) you
> > should *test* it, not just assume it.
>
> Does displaying the image which is rendered at the same time take much
> CPU time? I don't know, but I believed in what the docs say about it.
> It's true that I did not test the CPU usage of a graphical interface.
> Perhaps I should leave that sentence out.
The GUI may not take up much in CPU time, but it can certainly be a memory
hog, and many of my scenes are hampered by memory usage more than CPU
usage. I think it's still worth mentioning.
- dan B hentschel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stefan Viljoen nous apporta ses lumieres ainsi en ce 2004-11-18 01:29... :
>
>Strange you mention that - I must have a beta version of Firefox. 'cause I
>dl'ed it a few days ago and almost all pages look absolutely awful -
>missing html, broken frames, links that don't show up, etc. etc.
>
Do a new DL and reinstall.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dan B hentschel <dan### [at] alumritedu> wrote:
> The GUI may not take up much in CPU time, but it can certainly be a memory
> hog, and many of my scenes are hampered by memory usage more than CPU
> usage. I think it's still worth mentioning.
If the GUI is inactive, the OS will swap its memory to disk when POV-Ray
needs more memory.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> The better standard unix tool for examining running processes is 'top',
> not 'ps'.
I see you have not corrected this. Any reason?
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just wanted to inform you that I moved the Speed Guide from my
personal homepage to the POV Wiki (http://www.wikipov.org) for different
reasons. It can now be found at
http://povray.tirnalong.com/ow.asp?SpeedGuide
(The version on my homepage will be taken offline soon).
While porting the guide into the wiki, I also updated it along the
suggestions made in this thread. I would have done so earlier, but Real
Life (tm) thought different about that :)
Thank you all for your tips & criticism, and feel free to comment on the
ported version.
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
