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