I was using trace on an iso last night, and I got to wondering how this works,
given that the iso-surface has not yet been created. I figured it out (I think),
and I assume that the same solution applies to reflected isos. My question is,
when isos or similiar are reflected, is any of the information re-used, or do
all appearences of an iso in a scene require that all calcs. are redone from
scratch?

Hope that makes sense.

--
#macro G(D,E,F)#local I=array[3]{D,E,F}#local B=0;triangle{#while(
B<3)#while(I[B])A[mod(I[B],10)]+#local I[B]=div(I[B],10);#end<-5,-
2,9>#local B=B+1;#end}#end #local A=array[7]{x,x*2,x*4,y,y*2,y*4,z
}light_source{-x*6-z*9,1}mesh{G(105,10,146)G(105,246,10)G(105,56,
146)G(105,1256,246)G(1256,126,220)G(22156,2216,201)pigment{rgb 1}}//TM

Post a reply to this message

Tom Melly wrote:
> 
> I was using trace on an iso last night, and I got to wondering how this works,
> given that the iso-surface has not yet been created. I figured it out (I think),
> and I assume that the same solution applies to reflected isos. My question is,
> when isos or similiar are reflected, is any of the information re-used, or do
> all appearences of an iso in a scene require that all calcs. are redone from
> scratch?
> 
> Hope that makes sense.
> 

I don't think so.  ;-)

Tracing an isosurface always works the same way, no matter if it's
directly visible, visible as reflection or you use 'trace()' in your
scene.  

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.

Note that megapov had problems using 'trace()' on isosurfaces since some
parts of the isosurface intersection routines were not initialized at
parse time yet.

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" <chr### [at] gmxde> wrote in message
news:3C3D6ECB.36B29487@gmx.de...

> Note that megapov had problems using 'trace()' on isosurfaces since some
> parts of the isosurface intersection routines were not initialized at
> parse time yet.
>

I remember - wasn't sure if this was fixed in 3.5 and was very pleasantly
surprised.

Post a reply to this message

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