<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000">
Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when
rendering a scene at 640x400 with antialiasing depth 2  the fastest
I can seem to get it to go is 18 pps.  (I'm using the WIN95 version) 
I have all other programs shut down. Render priority on highest, GUI priority
on lowest, and the render window closed....are there any more ways to speed
up render time?  Besides the obvious "turn down AA" or "buy a new
computer you cheapo".  Any suggestions?
<br>                   
Kyle
</body>
</html>

Post a reply to this message

Kyle wrote:

>  Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when rendering a
scene at
> 640x400 with antialiasing depth 2  the fastest I can seem to get it to go is 18 pps.
 (I'm
> using the WIN95 version)  I have all other programs shut down. Render priority on
highest,
> GUI priority on lowest, and the render window closed....are there any more ways to
speed up
> render time?  Besides the obvious "turn down AA" or "buy a new computer you cheapo".
 Any
> suggestions?
>                     Kyle

Don't use refection in your finish statement.
Don't use any objects that require csg operations.
Don't use any high order polynominal objects.
Don't use filter or transmit in your pigments.
Don't use media or fog.
Don't use while loops.
Don't have more than a couple of objects in your scene.
Don't use specular or phong highlights.
Don't use high diffuse values.
Don't use layered testures and pigments.
Don't use area lights.
Don't have radiosity turned on.

Basicaly render solid colored spheres sitting on a solid
colored plane with only one light source.

Or buy a faster computer you CHEAPO !!!

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000">
 
<p>Ken wrote:
<blockquote TYPE=CITE>Don't use refection in your finish statement.
<br>Don't use any objects that require csg operations.
<br>Don't use any high order polynominal objects.
<br>Don't use filter or transmit in your pigments.
<br>Don't use media or fog.
<br>Don't use while loops.
<br>Don't have more than a couple of objects in your scene.
<br>Don't use specular or phong highlights.
<br>Don't use high diffuse values.
<br>Don't use layered testures and pigments.
<br>Don't use area lights.
<br>Don't have radiosity turned on.
<p>Basicaly render solid colored spheres sitting on a solid
<br>colored plane with only one light source.
<p>Or buy a faster computer you CHEAPO !!!
<p>--
<br>Ken Tyler
<p>tyl### [at] pacbellnet</blockquote>
Unfortunately I'm guilty of just about all of that. :-(
</body>
</html>

Post a reply to this message

Ken wrote:

> Kyle wrote:
>
> >  Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when rendering a
scene at
> > 640x400 with antialiasing depth 2  the fastest I can seem to get it to go is 18
pps.  (I'm
> > using the WIN95 version)  I have all other programs shut down. Render priority on
highest,
> > GUI priority on lowest, and the render window closed....are there any more ways to
speed up
> > render time?  Besides the obvious "turn down AA" or "buy a new computer you
cheapo".  Any
> > suggestions?
> >                     Kyle
>
> >>>Don't use refection in your finish statement.
> Don't use any objects that require csg operations.
> Don't use any high order polynominal objects.
> Don't use filter or transmit in your pigments.
> Don't use media or fog.
> Don't use while loops.
> Don't have more than a couple of objects in your scene.
> Don't use specular or phong highlights.
> Don't use high diffuse values.
> >>>Don't use layered testures and pigments.
> Don't use area lights.
> Don't have radiosity turned on.
>
> Basicaly render solid colored spheres sitting on a solid
> colored plane with only one light source.
>
> Or buy a faster computer you CHEAPO !!!
>
> --
> Ken Tyler
>
> tyl### [at] pacbellnet

 Isn't that strange ? When I post to news groups I always somehow
let a typo or two creep in but my pov scripts, with only an occassional
exception, perform without error.

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

Comments to you Ken.
> 
> Don't use refection in your finish statement.
*point* *grin* 

> Don't use any objects that require csg operations.
The more so, use union instead of merge where possible, it's faster, can be done in
testing..
Difference is slowwwww...

> Don't use any high order polynominal objects.
If I don't understand them, I don't use them ???

> Don't use filter or transmit in your pigments.
Agree..

> Don't use media or fog.
Absolutely not...

> Don't use while loops.
Do this, but if you want to speed it up before final render, do an output to a file.
wether using the #debug or #fwrite is up to you, but it will reduce parsing a lot.
Same for #if and #switch

> Don't have more than a couple of objects in your scene.
When working, use a #if(fast=true) opbject { small_easy_thing_to_render } #else object
{
huge_memory_hog_that_looks_good_or_needs_work } #end

> Don't use layered testures and pigments.
See comment about #if for advanced objects

> Don't use area lights.
theese are huge...

> Don't have radiosity turned on.
Never...

> 
> Basicaly render solid colored spheres sitting on a solid
> colored plane with only one light source.
yeah... or without the light with ambient 1 .....

 
> Or buy a faster computer you CHEAPO !!!
hmm.... well.... Get a quad alpha system or something.... *grin*


More..
If you have a scene that needs to swap(paging-file), make sure you defragment  your
swap
file...

in win95/98 :
1	Defrag the hdd with the swap file on.
2	remove all startup programs from windows.
3	go to control panel->system->performance->virtual memory
	3.5	disable virtual memory.
4	reboot to DOS
	4.5	remove any .swp files in C:\windows or c:\
5	reboot to windows
6	defrag your hdd again
7	set the virtual memory to "own settings" - Min=40Mb(more if you think you'll need
it)-
-Max=300 (depends on free space)-
8	reboot
9	Restore all you startup programs
10	reboot.

This will make the swap file less defragmented, and will make it a bit faster if you
have
a scene that requires swapping... It's generally a good idea to defrag your hdd once a
week or something like that if you add/remove a lot o files.

//Spider

Post a reply to this message

This piece of advice may be of dubious value but...

Overclock your machine. Until very recently I also had 486/100. I OC-d it to
120 MHz; it was still a piss-ant, but somewhat faster. Also, try to optimize
all your BIOS settings...
Anyway, this will only get you so far (and it _might_ muck up your machine,
if you don't know what you're doing)

So basically, just get a new machine! I now have a cheapo PII Celeron
333=>419MHz; POV is more than 10 X faster. Am I happy?

Margus
    Kyle wrote in message <36A23F0B.8A9469FB@geocities.com>...
    Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when
rendering a scene at 640x400 with antialiasing depth 2  the fastest I can
seem to get it to go is 18 pps.  (I'm using the WIN95 version)  I have all
other programs shut down. Render priority on highest, GUI priority on
lowest, and the render window closed....are there any more ways to speed up
render time?  Besides the obvious "turn down AA" or "buy a new computer you
cheapo".  Any suggestions?
                        Kyle

Post a reply to this message

hrmmmmmmmmmmmm. I might be wrong, but why are you using the Win95
version on a 486?  It might be easier for basic development, but when it
comes time to render whip out that old boot disk and render it with the
dos compile.  It will should be faster, because you won't have Win95
hogging resources for itself.

--
KillFile http://www.keldin.com

"If you want to live forever, Love a child"

There are many things in this world that
get more attention than they should, this
is not one of them

http://www.missingkids.com

Post a reply to this message

Besides the obvious "turn down AA" or
> "buy a new computer you cheapo".  Any suggestions?
>                     Kyle

Get the DOS version of Povray; It runs _about_ 10% faster
than the Win95 one, even in a W95 dos box.  If you boot
straight dos, you will get more availiable memory, too...

Fabien.

Post a reply to this message

A DOS version of 3.0 POV-Ray (unofficial) called POV-Pro, so no 3.1
capablities.
It's a render-speed-increased-compile. Just lacks a lot of the
"official" look. From what I remember from using it some myself, it can
be much faster. Believe the author stated "up to 40 or 50%" faster. But
I recall 25% (or is it 125%, percentages always confuse me) being the
average.
My URL to it seems to be broken now though, browser errors if attempt is
made to use it.
You could email me and ask for POV-Pro, put that in the subject line,
I'll send it over, I seem to have misplaced the original archive of it
though. All I found here is the povpro.exe itself (714K), no readme,
nothing.
It's basically a plain old DOS POV-Ray though. Works in the same way, no
editor, help, nothing though. Use the official version for that.


Kyle wrote:
> 
> Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when
> rendering a scene at 640x400 with antialiasing depth 2  the fastest I
> can seem to get it to go is 18 pps.  (I'm using the WIN95 version)  I
> have all other programs shut down. Render priority on highest, GUI
> priority on lowest, and the render window closed....are there any more
> ways to speed up render time?  Besides the obvious "turn down AA" or
> "buy a new computer you cheapo".  Any suggestions?
>                     Kyle

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
=Bob

Post a reply to this message

> 7       set the virtual memory to "own settings" - Min=40Mb(more if you think you'll
need it)-
> -Max=300 (depends on free space)-
Actually, I've been told that setting your swap file to twice your
memory (unless you have 16 megs, then 3 times) with Min = 2 x Memory and
Max 2 x Memory.  This creates a permanent swap file which works faster,
and should be large enough.

Steve

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Don't use refection in your finish statement.
: Don't use any objects that require csg operations.
: Don't use any high order polynominal objects.
: Don't use filter or transmit in your pigments.
: Don't use media or fog.
: Don't use while loops.
: Don't have more than a couple of objects in your scene.
: Don't use specular or phong highlights.
: Don't use high diffuse values.
: Don't use layered testures and pigments.
: Don't use area lights.
: Don't have radiosity turned on.

  Don't use povray?

  Btw, I am still using a 486 66MHz. Some of you may know my images. They
are all made with that computer (except a few, when I render
the final image on a pentium at the school...)

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Spider <spi### [at] bahnhofse> wrote:
: The more so, use union instead of merge where possible, it's faster

  This isn't always true.
  If you have several semi-transparent objects, usually merging them is
faster than unioning them (probably because povray has to do fewer lighting
calculations because there are fewer surfaces). Of course the resulting
object from merging semi-transparent objects is completely different from
a union of them.

: Difference is slowwwww...

  This isn't always true either.
  I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
and the same spheres differenced took only 37 seconds.
  The size of the visible surface plays a very important role in the
rendering time, obviously because the shading calculations are rather slow.
The fewer the surfaces and the smaller (on screen), the faster.

:> Don't use media or fog.
: Absolutely not...

  Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
very nice results.

:> Don't have radiosity turned on.
: Never...

  I wouldn't say "never".

: 4	reboot to DOS
: 5	reboot to windows
: 8	reboot
: 10	reboot.

  "Windows has detected movement of the mouse. Please reboot the computer
for the changes to take effect."

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Yes, but this is up to everyone on his own...
I don't intend to have 128 Mb swap because I have 64 Mb ram and some programs tell me
I
must have a swap file.... (I've used them....)


//Spider

Stephen Lavedas wrote:
> 
> > 7       set the virtual memory to "own settings" - Min=40Mb(more if you think
you'll need it)-
> > -Max=300 (depends on free space)-
> Actually, I've been told that setting your swap file to twice your
> memory (unless you have 16 megs, then 3 times) with Min = 2 x Memory and
> Max 2 x Memory.  This creates a permanent swap file which works faster,
> and should be large enough.
> 
> Steve

Post a reply to this message

Nieminen Mika wrote:
> 
> Spider <spi### [at] bahnhofse> wrote:
> : The more so, use union instead of merge where possible, it's faster
> 
>   This isn't always true.
>   If you have several semi-transparent objects, usually merging them is
> faster than unioning them (probably because povray has to do fewer lighting
> calculations because there are fewer surfaces). Of course the resulting
> object from merging semi-transparent objects is completely different from
> a union of them.
Ok, you got me. Everything depends and nothing is true... ehh.. did I just Lie ??


> : Difference is slowwwww...
> 
>   This isn't always true either.
>   I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
> and the same spheres differenced took only 37 seconds.
>   The size of the visible surface plays a very important role in the
> rendering time, obviously because the shading calculations are rather slow.
> The fewer the surfaces and the smaller (on screen), the faster.
Hmm, most of my expereince with difference come from multiple objects, a difference of
a
text from a union... but then, text is generally pretty slow... IMHO


> 
> :> Don't use media or fog.
> : Absolutely not...
> 
>   Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
> very nice results.
Yes, but then.... it is slow...

> 
> :> Don't have radiosity turned on.
> : Never...
> 
>   I wouldn't say "never".
Hmm, Well, not until you have patience to wait...

> 
> : 4     reboot to DOS
> : 5     reboot to windows
> : 8     reboot
> : 10    reboot.
> 
>   "Windows has detected movement of the mouse. Please reboot the computer
> for the changes to take effect."
Keyboard not present, press any key to continue.
//Spider

Post a reply to this message

Hey I'll add one for the VFAQ perhaps.  Intersection can be really slow
if you are using two really large objects to make a smaller one. Manual
bounding is a good idea in this case to let POV know you just want to
check the smaller area where the visible object is.

-Mike

Nieminen Mika wrote:
> 
> Spider <spi### [at] bahnhofse> wrote:
> : The more so, use union instead of merge where possible, it's faster
> 
>   This isn't always true.
>   If you have several semi-transparent objects, usually merging them is
> faster than unioning them (probably because povray has to do fewer lighting
> calculations because there are fewer surfaces). Of course the resulting
> object from merging semi-transparent objects is completely different from
> a union of them.
> 
> : Difference is slowwwww...
> 
>   This isn't always true either.
>   I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
> and the same spheres differenced took only 37 seconds.
>   The size of the visible surface plays a very important role in the
> rendering time, obviously because the shading calculations are rather slow.
> The fewer the surfaces and the smaller (on screen), the faster.
> 
> :> Don't use media or fog.
> : Absolutely not...
> 
>   Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
> very nice results.
> 
> :> Don't have radiosity turned on.
> : Never...
> 
>   I wouldn't say "never".
> 
> : 4     reboot to DOS
> : 5     reboot to windows
> : 8     reboot
> : 10    reboot.
> 
>   "Windows has detected movement of the mouse. Please reboot the computer
> for the changes to take effect."
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

On 18 Jan 1999 03:58:23 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>Spider <spi### [at] bahnhofse> wrote:
>: Difference is slowwwww...
>
>  This isn't always true either.

And even when it is true, it's no slower than intersection or merge.
In fact, difference and merge may both be expressed in terms of 
intersections, and within the program differences are indeed expressed 
as intersections.

For the curious:

difference {object {A} object {B}} 
is equivalent to 
intersection {object {A} object {B inverse}}

and

merge {object {A} object {B}} 
is equivalent to
intersection {object {A inverse} object {B inverse} inverse}

(An aside: would making this substitution in the parser simplify the
CSG evaluation code sufficiently to gain any significant performance 
on rendering?  I doubt it.  Currently, in fact, the intersection 
version renders just a tiny bit slower than the merge version for the
same scene.  I don't know why that is.)

Post a reply to this message

Spider <spi### [at] bahnhofse> wrote:
:> :> Don't use media or fog.
:> : Absolutely not...
:> 
:>   Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
:> very nice results.
: Yes, but then.... it is slow...

  AFAIK, fog is about as slow as, for example, a phong finish calculation.
ie. rather fast.
  A fog made with media IS slow.

:> :> Don't have radiosity turned on.
:> : Never...
:> 
:>   I wouldn't say "never".
: Hmm, Well, not until you have patience to wait...

  Perhaps you have seen my radiosity test images on my page? They are all
calculated with my good old 486 66MHz.
  Of course it requires a bit of patience.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Mike <Ama### [at] aolcom> wrote:
: Hey I'll add one for the VFAQ perhaps.  Intersection can be really slow
: if you are using two really large objects to make a smaller one. Manual
: bounding is a good idea in this case to let POV know you just want to
: check the smaller area where the visible object is.

  Can you post a (very short) example code showing clearly this speedup
when bounding a difference by hand? I'll put it on the page if it's good.
Preferably with fast objects like spheres.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

It was hard to do because it's most useful with complex CSG, but I got a
difference to render about twice as fast using manual bounding.  It took
me 12 seconds to render this without the bounding and 7 seconds with it
uncommented.  I used the #while loop to slow things down enough to see
the difference better.  If fancy textures like ior, reflection, and
filter are used the results are far less dramatic, since they only slow
things down where the surface is actually visible.

#declare test =
difference {

union {
cylinder {<-2, -20, 0>, <-2, 20, 0>, 1}
cylinder {<2, -20, 0>, <2, 20, 0>, 1}
}

box {<-10, 1, -10>, <10, 30, 10>}
box {<-10, -1, -10>, <10, -30, 10>}
 

pigment {color rgb <1, .5, .5>}
//bounded_by { box {<-3.1, -1.1, -1.1>, <3.1, 1.1, 1.1>} } 
}

#declare copy = 0
#while (copy < 40)
object {test translate -20*x translate copy*x}
#declare copy = copy + 3
#end

Nieminen Mika wrote:
> 
> Mike <Ama### [at] aolcom> wrote:
> : Hey I'll add one for the VFAQ perhaps.  Intersection can be really slow
> : if you are using two really large objects to make a smaller one. Manual
> : bounding is a good idea in this case to let POV know you just want to
> : check the smaller area where the visible object is.
> 
>   Can you post a (very short) example code showing clearly this speedup
> when bounding a difference by hand? I'll put it on the page if it's good.
> Preferably with fast objects like spheres.
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Nieminen Mika wrote:
> 
> Spider <spi### [at] bahnhofse> wrote:
> :> :> Don't use media or fog.
> :> : Absolutely not...
> :>
> :>   Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
> :> very nice results.
> : Yes, but then.... it is slow...
> 
>   AFAIK, fog is about as slow as, for example, a phong finish calculation.
> ie. rather fast.
ok.

>   A fog made with media IS slow.
This is true.

> 
> :> :> Don't have radiosity turned on.
> :> : Never...
> :>
> :>   I wouldn't say "never".
> : Hmm, Well, not until you have patience to wait...
> 
>   Perhaps you have seen my radiosity test images on my page? They are all
> calculated with my good old 486 66MHz.
>   Of course it requires a bit of patience.
my point.


//Spider

Post a reply to this message

I've put a permanent 256 Megabyte swap file on drive D: and it does
pretty good.
Reason for choosing 256 MB in my case is because of large POV memory
needed by a couple of memory-hog scenes. 128MB would be potentially too
small, so I didn't want to risk that and 256MB is plenty of room to
spare so no worries in the future. If you have the MS System Monitor
handy, run it with all the memory options chosen and take a look at what
your maximums are. They will no doubt be more than you expect if you
haven't checked into it before. The Windows swapfile is not much of a
gauge of memory used, seems to me.
So, if you have a second physical drive, scandisk and defrag it good, go
into Windows Virtual Memory and manually configure it.
I've not seen disk thrashing as much as I used to before I did this.


Stephen Lavedas wrote:
> 
> > 7       set the virtual memory to "own settings" - Min=40Mb(more if you think
you'll need it)-
> > -Max=300 (depends on free space)-
> Actually, I've been told that setting your swap file to twice your
> memory (unless you have 16 megs, then 3 times) with Min = 2 x Memory and
> Max 2 x Memory.  This creates a permanent swap file which works faster,
> and should be large enough.
> 
> Steve

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
=Bob

Post a reply to this message

Ok, I added a question about this to the vfaq. It can be found at:
http://www.cs.tut.fi/~warp/povVFAQ.html#csgspeed

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Good work...
//Spider

Nieminen Mika wrote:
> 
>   Ok, I added a question about this to the vfaq. It can be found at:
> http://www.cs.tut.fi/~warp/povVFAQ.html#csgspeed
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

That's a pretty thorough explanation of CSG and rendering speed.

-Mike

Nieminen Mika wrote:
> 
>   Ok, I added a question about this to the vfaq. It can be found at:
> http://www.cs.tut.fi/~warp/povVFAQ.html#csgspeed
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Nieminen Mika wrote:
> 
>   Ok, I added a question about this to the vfaq. It can be found at:
> http://www.cs.tut.fi/~warp/povVFAQ.html#csgspeed


 Having answered this question on another newsgroup recently
it reminded me how often it is asked. I know that this pretty
much the same answer as given for the video card question but
also expands upon it to cover other areas. I didn't see it on
the VFAQ ( I might have missed it) so here is the response I
gave.

 How do I increase rendering speed:

 The truth is the computations needed for rendering images are both
 complex and time consuming. This is one of the few program types
 that will actualy put your processors FPU to maximum use.

   The things that will most improve speed, roughly in order of
   appearance, are:

 1. CPU speed

 2. FPU speed

 3. Buss speed and level one and two memory cache - More is better.
    The faster the buss sped the faster the processor can swap out
    computations into it's level 2 cache and then read them back in.
    Buss speed therefore can have a large impact on both FPU and
    CPU calculation times. The more cache memory you have available
    the faster the operation becomes because the CPU doesn't have
    to rely on the much slower system RAM to store information in.

 4. Memory amount, type, and speed. Faster and more is undoubtably
    better. Swapping out to the hard drive for increasing memory
    should be considered the last possible option for increasing
    system memory. The speed of the read/write to disk operation 
    is like walking compared to driving a car. Here again is were
    buss speed is a major player in the fast rendering game.

 5. Your OS and number of applications open. Closing open applications,
    including background items like system monitor, task scheduler,
    internet connections, windows volume control, and all other
    applications people have hiding in the background, can greatly
    reduce rendering time by stealing cpu cycles. Open task manager
    and see what you have open and then close everything but the
    absolute necessities. Other multi-tasking OS's have other methods
    of determining open application and should be used accordingly.

 6. And lastly your graphics card. This may seem unlikely to you
    but it's true. If you have a simple 16 bit graphics card your
    render times, compared to other systems with the same processor
    and memory but better CG cards, will be equal. No more no less.
    If you play a lot of games or watch a lot of mpeg movies on your
    system then by all means own a good CG card. If it's rendering
    and raytracing you want to do then invest in the best system
    speed and architecture your money can buy. The graphics cards
    with hardware acceleration are designed to support fast shading
    of simple polygons, prevalent in the gaming industry, and offer
    no support for the intense mathematical number crunching that
    goes on inside a rendering/raytracing program like Pov-Ray,
    Studio Max, and Lightwave. If your modeling program uses OpenGl
    shading methods then a CG card with support for OpenGL will help
    increase the speed of updating the shading window but when it
    comes time to render or raytrace the image it's support
    dissapears.

    Hope this help you to understand. Believe me this is a common
    question that has been answered many times. You want speed use
    a paint program :) 


  Any comments, additions, misconceptions, mistakes, or outright
  bogus statements  ?

-- 
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

Don't quote me on this... (I haven't used POV-Ray since I got MAX, so I
don't know if this still works...)

Can you use the bounded_by statement still?  This would be one way to speed
up the CSGs...  or does POV-Ray do this automatically now?

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch wrote:
> 
> Don't quote me on this... (I haven't used POV-Ray since I got MAX, so I
> don't know if this still works...)
> 
> Can you use the bounded_by statement still?  This would be one way to speed
> up the CSGs...  or does POV-Ray do this automatically now?
> 
> --
> Lance.
> 
> ---
> For the latest MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone

For the most part Pov uses automatic bounding boxes and in many
cases will issue a warning if and object or group of objects
is unnecessarily bounded. In some rare cases you can speed up the
parsing process by manualy bounding but pov does a pretty good
job by itself.

-- 
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

Lance Birch wrote:
> 
> Don't quote me on this... (I haven't used POV-Ray since I got MAX, so I
> don't know if this still works...)
> 
> Can you use the bounded_by statement still?  This would be one way to speed
> up the CSGs...  or does POV-Ray do this automatically now?
> 
> --
> Lance.
> 
> ---
> For the latest MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone

Please note:

My suggestions have concentrated on the hardware end of speeding
up the rendering process. I don't feel that tweeking the code
as anything but a crutch. Limiting the capabilities of any
software by not using it's features is limiting your abilities
to use the program to it's fullest extent. For me there is no
feature I will not use just because it takes a little longer.
Don't let your hardware become a bottle neck. Starve the children
and buy a faster machine. That's my motto.


-- 
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

I agree totally!!!  I recently upgraded to 160 Mb of RAM, which has
dramatically improved performance!!!  I was thinking of getting a dual
processor motherboard a while back, but I realised for the price it just
wasn't worth it.  What I really hate is when graphic artists lower their
polycount in a scene just because it renders faster.  I always go for
quality, I never care about the rendering time.  I guess that's the cool
thing about NURBS modelling, although it might take a little longer to make
the model, it certainly is easier to render at high-res, adaptive surface
degradation is a saviour!!!

So, in conclusion, I can't wait until holographic memory becomes cheap and
is sold to the general public!!!  (it's only about 5-10 years away!!!).  1
trillion bits per second, that's fast enough for me :-)

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Oh man!  Read the VFAQ http://www.cs.tut.fi/~warp/povVFAQ.html#csgspeed

-Mike

Lance Birch wrote:
> 
> Don't quote me on this... (I haven't used POV-Ray since I got MAX, so I
> don't know if this still works...)
> 
> Can you use the bounded_by statement still?  This would be one way to speed
> up the CSGs...  or does POV-Ray do this automatically now?
> 
> --
> Lance.
> 
> ---
> For the latest MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:  Having answered this question on another newsgroup recently
: it reminded me how often it is asked. I know that this pretty
: much the same answer as given for the video card question but
: also expands upon it to cover other areas. I didn't see it on
: the VFAQ ( I might have missed it) so here is the response I
: gave.

  I added your response to the VFAQ and wrote also another one. My response
is far from complete; any suggestions are very welcome.
http://www.cs.tut.fi/~warp/povVFAQ.html#renderingspeed

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Nieminen Mika wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> :  Having answered this question on another newsgroup recently
> : it reminded me how often it is asked. I know that this pretty
> : much the same answer as given for the video card question but
> : also expands upon it to cover other areas. I didn't see it on
> : the VFAQ ( I might have missed it) so here is the response I
> : gave.
> 
>   I added your response to the VFAQ and wrote also another one. My response
> is far from complete; any suggestions are very welcome.
> http://www.cs.tut.fi/~warp/povVFAQ.html#renderingspeed

Looks good to me.

-- 
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

Hehe..
I just use speeding things where results get better/unchanged. Why ??? I belive in
optimized code...  (and I have a slow processor)

//Spider

Ken wrote:
> 
> Lance Birch wrote:
> >
> > Don't quote me on this... (I haven't used POV-Ray since I got MAX, so I
> > don't know if this still works...)
> >
> > Can you use the bounded_by statement still?  This would be one way to speed
> > up the CSGs...  or does POV-Ray do this automatically now?
> >
> > --
> > Lance.
> >
> > ---
> > For the latest MAX plug-ins, images and much more, go to:
> > The Zone - http://come.to/the.zone
> 
> Please note:
> 
> My suggestions have concentrated on the hardware end of speeding
> up the rendering process. I don't feel that tweeking the code
> as anything but a crutch. Limiting the capabilities of any
> software by not using it's features is limiting your abilities
> to use the program to it's fullest extent. For me there is no
> feature I will not use just because it takes a little longer.
> Don't let your hardware become a bottle neck. Starve the children
> and buy a faster machine. That's my motto.
> 
> --
> Ken Tyler
> 
> tyl### [at] pacbellnet

Post a reply to this message

Kyle wrote:

> Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when
> rendering a scene at 640x400 with antialiasing depth 2  the fastest I
> can seem to get it to go is 18 pps.  (I'm using the WIN95 version)  I
> have all other programs shut down. Render priority on highest, GUI
> priority on lowest, and the render window closed....are there any more
> ways to speed up render time?  Besides the obvious "turn down AA" or
> "buy a new computer you cheapo".  Any suggestions?
>                     Kyle

Use the Linux version, it's 40% faster  8-)

Post a reply to this message

Miguel Alvarez Rodriguez <nor### [at] abonadoscpluses> wrote:

>Kyle wrote:
>
>> Hi everyone.  I'm using an old 486/100mhz to do raytracing, and when
>> rendering a scene at 640x400 with antialiasing depth 2  the fastest I
>> can seem to get it to go is 18 pps.  (I'm using the WIN95 version)  I
>> have all other programs shut down. Render priority on highest, GUI
>> priority on lowest, and the render window closed....are there any more
>> ways to speed up render time?  Besides the obvious "turn down AA" or
>> "buy a new computer you cheapo".  Any suggestions?
>>                     Kyle
>
>Use the Linux version, it's 40% faster  8-)

..or the DOS version!  Windows will slow down most any application!


-----------------------------
Orrin - Long Island, New York
orr### [at] orrinorg
http://www.orrin.org/carib/    (Caribbean Index)
http://www.orrin.org/syocc/    (Syosset Camera Club)
http://www.orrin.org/wphs/     (HS Reunion)
http://www.orrin.org/          (Site Index)

Post a reply to this message

Ken wrote:
> 
> Nieminen Mika wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > :  Having answered this question on another newsgroup recently
> > : it reminded me how often it is asked. I know that this pretty
> > : much the same answer as given for the video card question but
> > : also expands upon it to cover other areas. I didn't see it on
> > : the VFAQ ( I might have missed it) so here is the response I
> > : gave.
> >
> >   I added your response to the VFAQ and wrote also another one. My response
> > is far from complete; any suggestions are very welcome.
> > http://www.cs.tut.fi/~warp/povVFAQ.html#renderingspeed
> 
> Looks good to me.
> 
> --
> Ken Tyler
> 
> tyl### [at] pacbellnet

FYI here's the results of a little test I did the other day.
I made an array of spheres like this

union{ // switch this between merge and union
  #declare Z=-2;#while(Z<=2)
    #declare Y=-2;#while(Y<=2)
      #declare X=-2;#while(X<=2)
        sphere{<X,Y,Z>,0.9}
        #declare X=X+1;#end
      #declare Y=Y+1;#end
    #declare Z=Z+1;#end
    pigment{rgbt<1,1,1,.0.9>}
    bounded_by{box{-3,3}}  // toggle this line on and off
}

so I got an array of 5x5x5 spheres, set the camera so the spheres took
up about a quarter of the width of the image.  Now I rendered it using
union and with merge and also with/without bounding.

Results:
               pixels/second  
merge bound      4452
merge unbound    1528
union bound       933
union unbound    1839

So at least in this case the merge with manual bounding was by far the
fastest.

Cheers, PoD.

Post a reply to this message

On Sun, 17 Jan 1999 22:54:51 -0600, Bob Hughes <inv### [at] aolcom>
wrote:
[snip]
>My URL to it seems to be broken now though, browser errors if attempt is
>made to use it.
>You could email me and ask for POV-Pro, put that in the subject line,
>I'll send it over, I seem to have misplaced the original archive of it
>though. All I found here is the povpro.exe itself (714K), no readme,
>nothing.
>It's basically a plain old DOS POV-Ray though. Works in the same way, no
>editor, help, nothing though. Use the official version for that.
>
>
I've still got the original .zip file - even the samples .zip that
were on the site too. E-mail me for it/them (but expect a delay in my
reply) :)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

Ah ha! I found out why my URL to POVpro was not working.
I had mistakenly put "povray" as the final pathname.
Here it is, and it works:

ftp://terra.ru.com/pub/gamos/povpro/

POVpro is a DOS version of POV-Ray 3.0 optimized for speed.

Cliff Bowman wrote:
> 
> On Sun, 17 Jan 1999 22:54:51 -0600, Bob Hughes <inv### [at] aolcom>
> wrote:
> [snip]
> >My URL to it seems to be broken now though, browser errors if attempt is
> >made to use it.
> >You could email me and ask for POV-Pro, put that in the subject line,
> >I'll send it over, I seem to have misplaced the original archive of it
> >though. All I found here is the povpro.exe itself (714K), no readme,
> >nothing.
> >It's basically a plain old DOS POV-Ray though. Works in the same way, no
> >editor, help, nothing though. Use the official version for that.
> >
> >
> I've still got the original .zip file - even the samples .zip that
> were on the site too. E-mail me for it/them (but expect a delay in my
> reply) :)
> 
> Cheers,
> 
> Cliff Bowman
> Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
> PS change ".duffnet" to ".net" if replying via e-mail

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
=Bob

Post a reply to this message