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