Hi all,

I stumbled onto this improvement because of the Internet Movie Project
(IMP).  The bridge of their major set is composed of an intersection of
two ellipsoids and was rendering really, really slow.

So, I checked the 3.1g code and found that the intersection code was
using a mixture of bisection method and secant method to solve for the
intersection.  The problem I saw was that it was calculating the
solution using both methods and then throwing away one of the solutions
without looking to see if it was better!

After fixing that I got about a 66% increase in rendering speed on the
superellipsoid demo scene, and a similar increase on the IMP rendering.

I'm including the modified source file as an attachment.

I hope this helps,
Ben

Post a reply to this message

Attachments:
Download 'super.cpp.txt' (32 KB)

Ben Birdsey wrote:
> 
> Hi all,
<snip>
>                 Name: super.cpp
>    super.cpp    Type: application/x-unknown-content-type-cppfile
>             Encoding: base64

Hi Ben,

We appreciate you sharing with the POV-Ray community but would really prefer
that if you are going to post attachments such as this one you do it in the
appropriate binary group on this server. In this case the proper group would
have been povray.binaries.programming. The rest of your post was correct for
this group and was not a problem, content wise.

Thanks,

-- 
Ken Tyler - News Admin.

Post a reply to this message

Sounds good! I always avoided superellipsoids because they're so slow. If
this improvement works flawlessly I vote for it to be included in the next
MegaPOV that might arrive soon.

Regards,
Hugo

Post a reply to this message

Ben Birdsey wrote:
> 
> [...]
> 
> After fixing that I got about a 66% increase in rendering speed on the
> superellipsoid demo scene, and a similar increase on the IMP rendering.
> 

Before such a change makes into a future megapov version or official
POV-Ray it should be intensely checked if the new code works as good as
the old one.  The old intersection test does not work perfectly in all
situations and your method could possible be worse (or better of course).

BTW, for speed reasons an isosurface superellipsoid is usually faster than
a native one.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> BTW, for speed reasons an isosurface superellipsoid is usually faster than
> a native one.

You sure? When it's close to a square, the max_gradient is *huge*, if i
remember correctly. Close to a sphere it may be ok though.

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

Post a reply to this message

Slime wrote:
> 
> > BTW, for speed reasons an isosurface superellipsoid is usually faster than
> > a native one.
> 
> You sure? When it's close to a square, the max_gradient is *huge*, if i
> remember correctly. Close to a sphere it may be ok though.

The gradient of the superellipsoid function is quite large when far away
from the object.  Since you can work with a very tight container this
won't matter.

Just try it and compare the results.  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message