Superellipsoids are indeed one of the slowest primitives in POV-Ray.

  Try replacing then with the round boxes found in shapes.inc (see
documentation) to see if it helps.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Superellipsoids are indeed one of the slowest primitives in POV-Ray.
>
>   Try replacing then with the round boxes found in shapes.inc (see
> documentation) to see if it helps.

Thanks, I'll try that.

Slime - nothing directly, but I am cutting a hole in the middle of the whole
group of them. I'm going to have to try something different - it's just too
slow to be practical.



-Mike
Knights Of Today

Post a reply to this message

Mike Thorn <web### [at] roboticsresourcescom> wrote:
> Slime - nothing directly, but I am cutting a hole in the middle of the whole
> group of them. I'm going to have to try something different - it's just too
> slow to be practical.

  Don't cut a hole on the entire union of tiles.
  Instead, make a union of only the tiles being affected by the cut and
cut the hole to this union only.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> Slime - nothing directly, but I am cutting a hole in the middle of the
whole
> group of them.

That might be the cause of the slowdown. I mean, superellipsoids are slow,
but not *unbearably* slow in my experience.

Try this: rather than doing this:

difference {
union {
// superellipsoids
// other stuff
}
union {
// big hole cutout
}
}

do this:

#declare bighole = union {
// big hole cutout
}
union {
difference {
union {
// other stuff
}
object {bighole}
}
difference {
union {
// superellipsoid 1
}
object {bighole}
}
difference {
union {
// superellipsoid 2
}
object {bighole}
}
...
}

I wouldn't be surprised if that speeds things up.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Wasn't it Mike Thorn who wrote:
>There's not really a lot I can do about it because I'm not really
>a mathematical kind of person so using an isosurface is out of the
>question, but I'm just curious: is the superellipsoid really that
>inefficient of an object or is it just the fact that I have 1024 of them?

I nearly replied saying that the f_superellipsoid isosurface is much
slower than the superellipsoid object, but then I noticed that using a
single isosurface to generate 1024 small superellipsoids isn't much
slower than generating one large isosurface superellipsoid. That almost
put it into contention with 1024 small real superellipsoid objects. 

In the following code, "Roundness" is the same as the value that you
would use for superellipsoid{<Roundness,Roundness>}, and "Size"
specifies how many there are in each direction, so 32 gives 32*32=1024.
The top surface of the tiles is at y=0.

#declare Roundness = 0.05;
#declare Size = 32;

#include "functions.inc"

camera { location  <-1, 1, -4> look_at <0, 0.3, 0> angle 30}
background {rgb 01}
light_source {<-100,200,-100> colour rgb 1}

#declare F=function{- f_superellipsoid(x,y,z,Roundness,Roundness)}

isosurface {
  function {F(mod(abs(x*Size),2)-1,y+1,mod(abs(z*Size),2)-1)}
    max_gradient 21
    contained_by{box {<-1,-1/Size,-1><1,0,1>}}
    pigment {checker rgb 0.9, rgb 0.5 scale 2/Size}
    finish {phong 0.5 phong_size 10}
}

sphere {y*0.5, 0.5 pigment {rgb 0.2} finish{phong 1 reflection 0.8}}

Post a reply to this message

Wasn't it Mike Thorn who wrote:
>
>I am cutting a hole in the middle of the whole group of them.
>

That'll be what's making it slow. It's the same sort of situation that's
covered in my holes tutorial <http://www.econym.demon.co.uk/holetut> but
inside out. One large hole in a union of many small objects, rather than
many small holes in one large object.

What happens is that the CSG causes POV to be unable to calculate
efficient bounding, and ends up putting the whole thing into one huge
bounding slab. This then means that POV has to test every ray that
crosses this large bounding slab against every one of the 1024
superellipsoids. With efficient bounding, there are 1024 small bounding
slabs and each ray only hits a few of them, so there are only a small
number of superellipsoid intersection tests for each ray.

There are two good solutions. That described by Slime (difference the
hole from every superellipsoid) and the use of a single isosurface (as
described in my previous response).

Slime's method works by allowing POV to create a bounding for each
superellipsoid-minus-big-hole object.

The isosurface method works by the fact that it is a single object, so
each ray only needs one intersection test even when the isosurface looks
like it consists of 1024 smaller pieces.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams wrote:
> Wasn't it Mike Thorn who wrote:
> 
>>I am cutting a hole in the middle of the whole group of them.
>>
> 
> 
> That'll be what's making it slow. It's the same sort of situation that's
> covered in my holes tutorial <http://www.econym.demon.co.uk/holetut> but
> inside out. One large hole in a union of many small objects, rather than
> many small holes in one large object.
> 
> What happens is that the CSG causes POV to be unable to calculate
> efficient bounding, and ends up putting the whole thing into one huge
> bounding slab. This then means that POV has to test every ray that
> crosses this large bounding slab against every one of the 1024
> superellipsoids. With efficient bounding, there are 1024 small bounding
> slabs and each ray only hits a few of them, so there are only a small
> number of superellipsoid intersection tests for each ray.
> 
> There are two good solutions. That described by Slime (difference the
> hole from every superellipsoid) and the use of a single isosurface (as
> described in my previous response).
> 
> Slime's method works by allowing POV to create a bounding for each
> superellipsoid-minus-big-hole object.
> 
> The isosurface method works by the fact that it is a single object, so
> each ray only needs one intersection test even when the isosurface looks
> like it consists of 1024 smaller pieces.

You're a genius. Or I'm an idiot. Either way, you just slashed my render 
time on that floor from ~4:32 to ~35sec. Wow.

Thanks a million...you don't realize what saving that much time means to 
me, and after seeing a few of the things on your website that one can do 
with an iso, I'm now a big fan of them. Too bad math is my personal 
archenemy.

Speaking of bounding, I've heard that POV's bounding isn't always as 
efficient as it could be. Would it be worth my while to manually bound 
every object in my scene, or would it be too much trouble for minimal gain?

Every time I sign on to this board I realize just exactly how much more 
I belong in .newusers than anywhere else. :) You guys are great. Thanks 
again.

~Mike

Post a reply to this message

Mike Thorn <mik### [at] realitycheckmultimediacom> wrote:
> Speaking of bounding, I've heard that POV's bounding isn't always as 
> efficient as it could be. Would it be worth my while to manually bound 
> every object in my scene, or would it be too much trouble for minimal gain?

  It depends on the object.
  Certain objects are difficult to bound automatically, although most of
them can be done so.

  If I'm not completely mistaken, min_extent() and max_extent() return
the coordinates of the bounding box of the object. You can use them
to visualize where the bounding box really is.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Wasn't it Mike Thorn who wrote:
>
>Speaking of bounding, I've heard that POV's bounding isn't always as 
>efficient as it could be. Would it be worth my while to manually bound 
>every object in my scene, or would it be too much trouble for minimal gain?

Most of the time POV's bounding is extremely good. For single objects,
unions and merges it's far more likely that you'll make things go slower
if you try to apply manual bounds. There are a handful of specific
situations where POV can't calculate reasonable bounds. The most
significant of these are things like those covered in my holes tutorial,
but note that you can't fix these situations by just manually bounding
the objects.

POV isn't able to sensibly bound shapes created by intersecting planes,
like the Tetrahedron in shapes2.inc, so the included declaration of
Tetrahedron contains a manual bound. POV doesn't apply bounds to
infinite planes, and doesn't manage to spot situations where an
intersection of infinite planes creates a finite object.

POV automatic bounding is limited to slabs (i.e. box shapes which are
limited to being aligned with the axes) so there may be some situations
where a long thin rotated bounding box might fit an awful lot better
than such a fat orthogonal slab. 

If you suspect that POV is applying poor bounds to something in your
scene you can always display the vista buffers by putting +UD in the
command line. Vista buffers are 2d squares in the image plane that are
drawn round the bounding slabs. (Hint: if there are less than three
objects in the scene you are testing, also add +MB0 to the command
line.)

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

>>Speaking of bounding, I've heard that POV's bounding isn't always as 
>>efficient as it could be. Would it be worth my while to manually bound 
>>every object in my scene, or would it be too much trouble for minimal gain?
> 
> 
>   It depends on the object.
>   Certain objects are difficult to bound automatically, although most of
> them can be done so.
> 
>   If I'm not completely mistaken, min_extent() and max_extent() return
> the coordinates of the bounding box of the object. You can use them
> to visualize where the bounding box really is.

Not forgetting the [easier to turn on but somewhat less useful] "show 
bounds" option...

Typically, POV seems to make a pretty good job of things. I have a habit 
of making polyhedrons out of infinite planes - this is a somewhat 
pathelogical case. If you were to (say) take the intersection of two 
huge spheres that only just touch (creating a "lense" shape), that might 
be slightly sub-optimal. (But not as bad as you might think...)

Andrew.

Post a reply to this message