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

Hugo wrote:
> 
> 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 don't really understand, without reflection/refraction you have usually
only two intersection tests per pixel, where do you want to avoid
calculations?

There is already a cache for the last ray that speeds up renders of
isosurfaces with large 'empty' areas, for example a torus with small minor
radius.

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 don't really understand, without reflection/refraction you have usually
> only two intersection tests per pixel, where do you want to avoid
> calculations?

Alright, I wasn't sure what happened. Your explanation sounds logical. I
suppose, with radiosity, samples are taken all over the scene, going into a
cache, and then applied to objects as appropiate?

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

Don't know.  ;o)

Regards,
Hugo

Post a reply to this message

Having done a lot of simulation and coding with long math functions, I find
that after three or four steps, floating point roundoff creeps into a lot of
functions.  This might be one source of that "surface speckle" or rough effect
that some isosurfaces demonstrate.  That can cause a lot of trouble for ray
tracing.
    I am not in any way familiar with the deep coding in POVray, but it seems to
me that averaging a number of solutions might be one approach to getting rid of
the speckles.  If that is what is being done, then it would easily explain the
slowdown in speed.
    In particular, using complex functions such as trig or log values to create
a form can lead to an inherent "graininess" due to those functions being very
sensitive to initial input value.  They would sometimes tend to magnify the
floating point resolution of the math.  Take the log function, for example.
    If you input a value and perform a log calculation on it, the answer is
usually much smaller than the input.  In that case, a variation of an order of
magnitude leads to perhaps a single digit change in the output.  In that case,
the function is very insensitive to the floating point resolution of the system.
    On the other hand, if you are using arctangent or exponent functions, a tiny
change in input value can lead to significant changes in the output value.  A
one-bit change in the input can lead to a many-bit change in the output.  So
supplying an argument at the input that is one bit different from a previous
value can lead to a large difference in the result.  This means that "noise" can
actually swamp out the real answer or move the value around quite a bit.
    This can be very significant if that function is at the tail end of four or
twenty calculations, where the machine has reached system roundoff in a few of
those steps.  There you will find your source of random surface noise; the
inherent "quantum" graininess of any digital computing system.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

light_source{0#macro k(_)sphere{13*z+i*_.5pigment{agate}finish{phong.3}}#end
1}#macro _(s,i,g)#if(s)k(1)k(-1)_(s-1i+g,g)#end#end _(3x+3*y<2,-2>)_(2x,y)_(
2x-y,x)_(4x*3,-y)_(4<3,1>x)_(2x*6,-y)

Post a reply to this message

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

Sure, you can go ahead and store the information that "a ray from this point
hit the isosurface at this point", but the chances of another ray ever
hitting that same point from the same direction are extremely tiny. Even if
you did encounter another ray that passed through that point, you'd still
have to test if it hits the isosurface before it reaches that point.

Remember, we're not dealing with pixels, we're dealing with an infinite
number of points in three dimensional space.

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

Post a reply to this message

"Sir Charles W. Shults III" wrote:
> 
>     Having done a lot of simulation and coding with long math functions, I find
> that after three or four steps, floating point roundoff creeps into a lot of
> functions.  This might be one source of that "surface speckle" or rough effect
> that some isosurfaces demonstrate.  That can cause a lot of trouble for ray
> tracing.
> [...]

I have never seen anything like this when working with isosurfaces, could
you give an example?

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