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

When you see that "holey" effect- it appears that there are steps or holes
in the isosurface and you have to increase the max_trace value to help eliminate
them.  I have had a few do that and curing it steps up the render time a lot.
What is the source of that anyway?  You may be the right person to tell me.

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

On Thu, 11 Apr 2002 17:22:27 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I have never seen anything like this when working with isosurfaces, could
> you give an example?

perhaps he means something like http://www.abx.art.pl/pov/nonlinear/twist.jpg
but it of course is my fault becouse object pattern in megapov was used

ABX

Post a reply to this message

Slime wrote:
> 
> 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.

It's not that hopeless, you could store all function values evaluated and
use them later for new rays, together with the known max_gradient you can
reduce the number of necessary new function evaluations this way, but you
would have to design efficient methods and data structures for accessing
the stored values and the memory requirements can be enormous.

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

"Sir Charles W. Shults III" wrote:
> 
>     When you see that "holey" effect- it appears that there are steps or holes
> in the isosurface and you have to increase the max_trace value to help eliminate
> them.  I have had a few do that and curing it steps up the render time a lot.
> What is the source of that anyway?  You may be the right person to tell me.

I can only assume you are having problems with max_gradient and accuracy,
apart from that i don't know about any general problems with the
appearance of isosurface objects.

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

"Hugo" <hua### [at] post3teledk> wrote in message
news:3cb5791a@news.povray.org...
> 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.)

A mosaic preview using something like adaptive sampling could speed up an
isosurface ;)
This would only be effective if the isosurface took only a small portion of
it's contained_by object.  Test all four corners of a box, and use those for
ray tests within a certain distance of the box(es).
This could be adapted to allow reflection/transparency.
--
__________________
 RAY

Post a reply to this message