 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] aol com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
