 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwerty gov> 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
|
|
| |
| |
|
|
|
|
| |
|
|
