First I want to say...supers are listed in the "Advanced Features" category
in the documentation, so that's I'm posting here. There's no "intermediate"
user
folder, which is where I fit categorically. :)

I'm running an image that involves an indoor floorplane. Originally I had
thought it would just be a flat plane, but I decided to try some loops and
superellipsoids for a ceramic tile look. It was fairly simple to create,
but it all runs out to about 1000 superellipsoids to cover the floor.
Forunately I was able to clip it to save render time on some parts that
wouldn't be visible.

However, running the supers takes forever. Much, much longer than it takes
when running compared to a simple plane (over 11 min. versus about 20
seconds). 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?

Thanks,

-Mike
Knights Of Today

Post a reply to this message

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

Simple way to find out: replace them with boxes and see if it's still slow.

Are you using a difference or intersection involving them, by any chance?
Sometimes those can be slow because they don't make use of the bounding
heirarchy.

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

Post a reply to this message

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