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.

Regards,

Remco

Post a reply to this message

I rendered the scene file, enough to see the folded shape in the middle anyway. I
see you're using very thin boxes, how about using polygons and/or triangles?

Post a reply to this message

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.

Post a reply to this message

"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

Wasn't it Remco de Korte who wrote:

>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.

Err, at the moment your object is actually the same colour on both
sides. I think you meant to write

  #declare origami=
  union{
    object{front}
    object{back}
  }

instead of 

  #declare origami=object{front}
  union{
    object{front}
    object{back}
  }

In this version "origami" is #declared to be the red box, and then a
copy of the bi-coloured box is rendered.


It's possible to have meshes (or anything else) with different textures
on each side in MegaPOV, by using the "interior_texture" keyword.


>
>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

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:
> 
> Wasn't it Remco de Korte who wrote:
> 
> >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.
> 
> Err, at the moment your object is actually the same colour on both
> sides. I think you meant to write
> 
>   #declare origami=
>   union{
>     object{front}
>     object{back}
>   }
> 
> instead of
> 
>   #declare origami=object{front}
>   union{
>     object{front}
>     object{back}
>   }
> 

Yes, you're right. That was a remainder of my experiments.

> In this version "origami" is #declared to be the red box, and then a
> copy of the bi-coloured box is rendered.
> 
> It's possible to have meshes (or anything else) with different textures
> on each side in MegaPOV, by using the "interior_texture" keyword.
> 

I haven't tried that, I wonder if it would make a big difference, with the total
amount of sections being the same. I'll see if I can figure out how to follow
your suggestion. Thanks.

> 
> --
> Mike Williams
> Gentleman of Leisure

Remco

Post a reply to this message