POV-Ray : Newsgroups : povray.general : Optimizing CSG : Re: Optimizing CSG Server Time
9 Aug 2024 09:00:48 EDT (-0400)
  Re: Optimizing CSG  
From: Remco de Korte
Date: 18 Aug 2000 15:28:36
Message: <399D8DC3.DF3088BB@xs4all.nl>
"J. Grimbert" wrote:
> 
> Remco de Korte wrote:
> >
> > I have an origami-object that is made with CSG. Every fold is a new sit of
> > clipping and rotating. I have made some aeroplanes this way and it works out
> > fine. The trouble is, they're terribly slow to render. I understand that since
> > each new manipulation cuts the object up in more parts the problem is here
> > somewhere. I have tried optimizing it but nothing seems to make a significant
> > difference. I think I'm overlooking something obvious, perhaps it would help if
> > I did something with bounding boxes but all the things I have tried didn't work
> > or at least not very well.
> > I have posted a scene file to binaries.scene-files hoping someone will check it
> > out and be able to make it work faster. I've commented out some light_sources
> > and that helps but not really very much.
> 
> Well, from a quick render and some reading of your code,
> it seems you are multiplying the basic object, a union of two boxes,
> inside more and more complex construct.
> 
> I noticed a lot of clipped_by and I'm pretty sure that you
> may instead use an intersection , thus reducing the bounding boxes.
> 
> On the same way, given the pyramidal explosion of your construct,
> I wonder if disabling the bounding box would not give some speed-up.
> (with 8 stages using two objects, you have about 2^8 (=256) basic objects,
> i.e. 512 real box and the whole hierarchy of bounding box:
> 512+256+128+64+32+16+8+4+2+1 = 1023 !!
> 
> Given the compactness of the object, when a ray it one box, it may
> as well hit the others... so you probably end up doing 1023+512 box intersection
> per ray. (may be not, but I do not remember that clipped_by was also
> taken into account for the bounding box [source is too far away for me at this
> time])
> 
> You could also accelerate the rendering of the background by
> doing an intersection with a box in which you know your origami is in
> (side effect on the top bounding box: it is smaller; The box should
> of course never show itself, as the origami is smaller and inside.)
> 
> I let you do the experiments.

Thanks for your reply, also to Libellule.

I considered using triangles or a mesh, which would have been much faster were
it not that I want the front and back of the sheet to have a different pigment.
In fact, in the original object I use image_maps. That doesn't affect the speed
much.
I also thought about using triangles and alternating the pigment depending on
which side is face towards the camera but I couldn't figure out how to do that
in POV. 
Two thin boxes seemed like the easiest way.

As J. Grimbert noted this means there are going to be a lot of parts (and this
isn't even the most complicated model) with their bounding boxes. I thought I
had tried everything, also experimented with bounding boxes with no effect. 
However, after sending the message, I thought I'd try it once again and put the
whole object in one single bounding box. This way the largest part of the
background is rendered much faster. I had tried this before but didn't know how
large a box I should take so to be safe I used a large bounding box. Far too
large, so the effect was nil. Now it occured to me that the site of the sheet
you start with can be used to get a tight(er) fitting bounding box. It renders 3
times faster now, which still is rather slow. So if there's anything else I've
missed I'd like to know.

I didn't understand the suggestion about the intersection for the background.

Regards,

Remco


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.