Christoph Hormann schrieb in Nachricht <3C3D6ECB.36B29487@gmx.de>...
>A trace of an isosurface never reuses information of a previous one, this
>is of course a point of possible improvements, but right now that's just
>the way things work.


Yes it would be nice to have something like save/load for radiosity data for
Isos, too. It's probably not as simple as it sounds, but it would shorten
rendertimes a lot if at least the shape of the Iso could be reused. Is this
possible at all?

Marc-Hendrik

Post a reply to this message

On Thu, 10 Jan 2002 14:07:30 +0100, Marc-Hendrik Bremer wrote:
> 
> Christoph Hormann schrieb in Nachricht <3C3D6ECB.36B29487@gmx.de>...
>>A trace of an isosurface never reuses information of a previous one, this
>>is of course a point of possible improvements, but right now that's just
>>the way things work.
> 
> 
> Yes it would be nice to have something like save/load for radiosity data for
> Isos, too. It's probably not as simple as it sounds, but it would shorten
> rendertimes a lot if at least the shape of the Iso could be reused. Is this
> possible at all?

I think there's a fundamental misunderstanding here about how isosurfaces
work.  It's not as though we're tesselating the thing at render time or
something.  There's no "shape" to save or reuse.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
>
> I think there's a fundamental misunderstanding here about how isosurfaces
> work.  It's not as though we're tesselating the thing at render time or
> something.  There's no "shape" to save or reuse.
>

Care to enlighten? ;)

Personally, I see them as a sort of blobby sheet constrained to a series of
points - I've never assumed that this image is accurate, just logical...

Post a reply to this message

Ron Parker schrieb in Nachricht ...
>I think there's a fundamental misunderstanding here about how isosurfaces
>work.  It's not as though we're tesselating the thing at render time or
>something.  There's no "shape" to save or reuse.


I know that it's not tessellated. Talking of the "shape" was probably not
that good. But the function forming the isosurface is calculated and the
most accurate point is found where a given ray intersects the object. This
is information which is needed in every render of the scene containing the
isosurface (at a given location). As long as the  camera does not move nor
the Iso, the result should be the same. Of course the actual color of that
"point" depends on other things in the scene and the Iso might be hidden by
other objects, too. But those intersection points could be reused, I think.
There is an isosurface cache already, isn't it? Perhaps it would suffice or
at least help to save and load  its contents?
I don't want to calculate the iso once and forever to use it in any given
scene. I just thought it would be good to reuse isosurface calculations from
one render in following once - just like radiosity data.
Don't know. Perhaps it's total nonsense.

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> [...]
> I don't want to calculate the iso once and forever to use it in any given
> scene. I just thought it would be good to reuse isosurface calculations from
> one render in following once - just like radiosity data.
> Don't know. Perhaps it's total nonsense.

I have already thought about such possibilities, not so much about storing
intersection information but function values, but the whole thing is far
from being simple, for example the render result could depend on the
previously acquired data.

Another general speedup approach this idea could lead to is to use
previously calculated depth information to accelerate the render.  This
would not be limited to isosurface objects, but i'm not sure if this would
be very efficient.  Does anyone know if this has already been implemented
in a raytracer in the past?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Tom Melly wrote:
> 
> Care to enlighten? ;)
> 
> Personally, I see them as a sort of blobby sheet constrained to a series of
> points - I've never assumed that this image is accurate, just logical...

For finding the intersection of a ray with the object (trace) Povray
successively subdivides the distance the ray crosses the container object
to find where the function value is crossing the threshold value. The
accuracy and max_gradient values stop this process at some point.  

I think Mr. Suzuki gave a much better explanation somewhere, but i could
not find it.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann schrieb in Nachricht <3C3DB2A0.79C5D860@gmx.de>...

>I think Mr. Suzuki gave a much better explanation somewhere, but i could
>not find it.


A more technical description by Mr. Suzuki is in
<news://news.povray.org/3b984214@news.povray.org>, there was another one in
p.b-t.

Marc-Hendrik

Post a reply to this message

"Marc-Hendrik Bremer" wrote:
>There is an isosurface cache already, isn't it?

Yes, there is an isosurface cache.   But that is not for hidden isosurfaces.
That is for non-intersecting rays.  The cache is especially effective to
small(or thin) isosurfaces in a large isosurface container.
For example,
  isosurface{
    function{f_torus(x,y,z,0.9,0.05)}
    contained_by{ box{-<1,0.1,1>, <1,0.1,1>}}
  }

The statistics is
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Isosurface                       37426            4648     12.42
Isosurface Bound                80874           37434     46.29
Isosurface Cache                 28748           24664     85.79
----------------------------------------------------------------------------
In this case, the cache hit ratio is 66% (24664/37426).

This cache technique uses a function value of the previous ray and eliminates
unnecessary calculation.  Maybe I will to explain that technique with figures...

R. Suzuki

Post a reply to this message

"R. Suzuki" wrote:
> 
> [...]
> 
> This cache technique uses a function value of the previous ray and eliminates
> unnecessary calculation.  Maybe I will to explain that technique with figures...
> 

Sounds interesting, some more details would be appreciated.

I suppose since it only uses the previous ray it's much less efficient if
for example radiosity or reflection are involved.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

R. Suzuki schrieb in Nachricht <3c3ec00d@news.povray.org>...

>That is for non-intersecting rays.  The cache is especially effective to
>small(or thin) isosurfaces in a large isosurface container.


That is, if you have a "fitting" container-object the cache does not help
that much? Now I understand why the cache-hit percentage is often quite low
with rawly poxed shaped objects.

>This cache technique uses a function value of the previous ray and
eliminates
>unnecessary calculation.

And couldn't this cache not be saved and reloaded (both at will and command
of the user), to eliminate the need of recalculating all these missing rays?
Or is nothing saved and only the function value of the one previous ray is
stored and used?

Marc-Hendrik

Post a reply to this message