Or is it the other way around and radiosity slows down ISO surface
rendering?  Either way, the combination of ISO and Radiosity makes for a
really slow render.  As a test, the following scene has seven ISO rocks,
and was rendered with the following parameters: 

  496 seconds: single light, no radiosity
43724 seconds: single light, radiosity using "Normal" setting from
               rad_def.inc (over 12 hours)!! 
  885 seconds: single light, fill light at camera, no radiosity
               (attached picture) 

  I then replaced all seven ISOs with spheres, leaving the textures, etc
and got: 

 21 seconds: single light, no radiosity
206 seconds: single light, radiosity using "Normal" setting from
             rad_def.inc 

  This is orders of magnitude faster than the ISOs with radiosity, but
the ISOs without radiosity aren't that much slower than the spheres. 
Any ideas?? 

-- 
Rich Allen
(Remove SPAM from my address to reply by e-mail)

Post a reply to this message

Attachments:
Download 'ROCK1.jpg' (83 KB)

Preview of image 'ROCK1.jpg'

>   This is orders of magnitude faster than the ISOs with radiosity, but
> the ISOs without radiosity aren't that much slower than the spheres.
> Any ideas??

Isosurfaces take a significantly longer time to calculate the intersection
with a single ray. So for a render without radiosity, there will be a time
increase, but with radiosity, which shoots *much* more than one ray per
pixel in order to calculate the realistic lighting, the render time
increases a *lot* more.

In addition, because of all the small holes in many isosurfaces, even more
of these slow rays have to be shot by the radiosity algorithm to get
realistic lighting.

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

Post a reply to this message

"Rich" <SrP### [at] ricoswebcom> asked:
> Why do ISO surfaces slow down radiosity so much?

[ ] You really want to know
[ ] You know, how intersections are calculated for the different
    primitives of POV-Ray
[ ] You have an image rendering for already 2 weeks (without AA) that
    contains only 1 Isosurface, 1 Mediacontainer and "some" lights
[X] You want a faster computer ...

SCNR ...

Post a reply to this message

I don't know, but I imagine that each call to the isosurface during
calculation of reflection, refraction, finish, radiosity, lightsources - all
causes the isosurface to be evaluated again and again.. Similar with
primitives, but even the fastest isosurface is much slower than a primitive,
hence the big slowdown.. This is my theory - not necessarily the fact.. IF
it works like that, then I have to say, a much better idea would be to
calculate the surface *first* once and for all, and *then* do all the rest
of calculations.

Regards,
Hugo

Post a reply to this message

On Thu, 11 Apr 2002 11:14:43 +0200, "Hugo" <hua### [at] post3teledk> wrote:
> I don't know, but I imagine that each call to the isosurface during
> calculation of reflection, refraction, finish, radiosity, lightsources - all
> causes the isosurface to be evaluated again and again.. 

Additionally when ray is posted from camera then it is always compared with
boundingbox first. Usually camera is outside isosurface container so not every
ray causes intersection calculation. When reflection/refraction/radiosity/shadow
is calculated ray always starts from isosurface surface and therefore every ray
causes intersection calculation with surface itself.

ABX

Post a reply to this message

Maybe tesselating the iso would be easier? I dunno...

--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

On Thu, 11 Apr 2002 12:11:52 +0200, "Apache" <apa### [at] yahoocom> wrote:
> Maybe tesselating the iso would be easier? I dunno...

not always easy possible by hand
and iirc not mixed with any tesselation patch, yet

ABX

Post a reply to this message

Hugo wrote:
> 
> I don't know, but I imagine that each call to the isosurface during
> calculation of reflection, refraction, finish, radiosity, lightsources - all
> causes the isosurface to be evaluated again and again.. Similar with
> primitives, but even the fastest isosurface is much slower than a primitive,
> hence the big slowdown.. This is my theory - not necessarily the fact.. IF
> it works like that, then I have to say, a much better idea would be to
> calculate the surface *first* once and for all, and *then* do all the rest
> of calculations.

You are right that isosurface intersection calculation are quite
computation intensive, but the relative slowdown because of reflection,
refraction, radiosity etc. should not be much larger.  Note that i'm not
talking about meshes, heightfields and optimized combinations of shapes,
just comparing basic shapes with isosurfaces.

And if you try an isosurface superellipsoid and a native one and compare
the results you will also see that the isosurface can be much faster.

I agree that there are quite a lot of possibilities to improve isosurface
intersection calculation like precalculations or caching of function
values, but don't forget that one enormous advantage of isosurfaces
compared to meshes for example is the low memory use.

Christoph

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

Post a reply to this message

> I agree that there are quite a lot of possibilities to improve isosurface
> intersection calculation like precalculations or caching of function
> values, but don't forget that one enormous advantage of isosurfaces
> compared to meshes for example is the low memory use.

Well I'm not into the source code, but what about to precalculate just the
bit of isosurface, that is currently rendering? I mean, POV-Ray renders
pixel by pixel, line by line. For each pixel, many things has to be done,
but it shouldn't be necessary to calculate the surface, for that pixel, more
than once.. I wonder if it's calculated many times, since some objects like
iso's takes much longer.

(I know this idea wouldn't provide a cache for transparant or reflected
objects. Those would have to be recalculated.)

Regards,
Hugo

Post a reply to this message

On Thu, 11 Apr 2002 14:01:35 +0200, "Hugo" <hua### [at] post3teledk> wrote:
> Well I'm not into the source code, but what about to precalculate just the
> bit of isosurface, that is currently rendering?

btw, there is precompute keyword in parametric object

> I mean, POV-Ray renders
> pixel by pixel, line by line.

another scanline renderer ;-)

> For each pixel, many things has to be done,
> but it shouldn't be necessary to calculate the surface, for that pixel, more
> than once.. I wonder if it's calculated many times, since some objects like
> iso's takes much longer.
> (I know this idea wouldn't provide a cache for transparant or reflected
> objects. Those would have to be recalculated.)

what about shadowing itself ?
what about shadow from many lights ?
what about radiosity lightning recived from itself ?
what about media somewhere inside or around ?

ABX

Post a reply to this message