On 13 Jan 2003 19:39:06 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> > Sure, you can. So what is the first? I have also some isosurface
> > related ideas and I would like to listen your proposition before
> > coding anything. 
>
> Most simple - to buid complex bounding boxes, or rather bounding shapes. 
> And to use 2 shapes. Bound and InnerBound. 

Full intersection test is required to get normal, so it means your proposition
is useles for reflections and camera rays (and probably for photons). It might
be worth to test your proposition of curiosity for shadow tests (of all
objects, not only isosurfaces) but then I do not know how it should behave for
inverted objects and/or csg. Also the problem is that images are usually
focused on object itself and not on its shadow, micro-shadows made by
displaced isosurface on itself are hard to catch by such 'inner bounding'.

ABX

Post a reply to this message

On 13 Jan 2003 19:43:49 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> oh and I forgot, Imho for shapes where calculations are *very* expensive 
> (like isosurfaces) we whould use comples shapes to bound them, or even 
> hierarchies

you can't ?

> isosurface is bounded with:
>  ..a very complex mesh (10,000 faces[1])
>    ..and this compelx mesh is bounded with simple mesh (100 faces)
>     ..and simple mesh is finaly bounded by box

mesh over mesh? have you actually measured difference between rendering of
square builded from two trinagles and from thousend of triangles?

> [1] - this complex mesh can be builded automaticly

'builded automaticly' means probably tesselation process, are you aware how
good tesselation is complicated? some methods are even patended! tesselation
needs a lot of calculations, too.

> by trace funcion

using 'trace' function you can get points _on_ isosurface but bounding
requires surface _around_ isosurface. moreover 'trace' sends ray to get
intersection, so you probably will need more intersection tests with your
'optimization' than without.

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote in
news:amo72vsdloua9hc895825p54ljgthcmfva@4ax.com 

> 'builded automaticly' means probably tesselation process, are you
> aware how good tesselation is complicated? some methods are even
> patended! tesselation needs a lot of calculations, too.

But we don't need ideal tesselation. We will get object that +/- is a 
tesselation of isosurface, and then we will "inflate" this mesh, it would 
be hmm "bolder" or "more thick". Inflate will by by some size, that would 
be error_bound. Ofcourse this algoritm can produce error, because it is 
based on heuristics, like. i.e. radiosity.
 
> using 'trace' function you can get points _on_ isosurface but bounding
> requires surface _around_ isosurface. 

inflate

> moreover 'trace' sends ray to
> get intersection, so you probably will need more intersection tests
> with your 'optimization' than without.

save / load


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 14 Jan 2003 07:27:48 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
>ABX <abx### [at] abxartpl> wrote in
>news:amo72vsdloua9hc895825p54ljgthcmfva@4ax.com 
> > 'builded automaticly' means probably tesselation process, are you
> > aware how good tesselation is complicated? some methods are even
> > patended! tesselation needs a lot of calculations, too.
>
> But we don't need ideal tesselation. We will get object that +/- is a 
> tesselation of isosurface, and then we will "inflate" this mesh

"inflate" in what direction? returned by normal in trace()? how do you want to
verify that the new place for vertex is not again inside isosurface? of course
with another evaluation. in case it is inside where will you move your vertex?
and how do you want to guarantee that new  triangle does not cross isosurface
surface? of course with set of evaluations. IMO there is no efective way to
get it automated for general cases.

It seems you really think it is easy, I can hardly see small advantage from
this. In case you still don't want to touch POV-Ray source code feel free to
provide algorithms using POV-Ray SDL. There are isosurfaces, trace() and
meshes. You can define input parameters and output mesh. Then your help will
be appreciated.

> > using 'trace' function you can get points _on_ isosurface but bounding
> > requires surface _around_ isosurface. 
>
> inflate

outside.

> > moreover 'trace' sends ray to
> > get intersection, so you probably will need more intersection tests
> > with your 'optimization' than without.
>
> save / load

Yes. I'm waiting for your SDL version of this stuff.

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote in 
news:cj382vk1n1410nijhvn0p8stgg9vi5o64a@4ax.com

>> > using 'trace' function you can get points _on_ isosurface but bounding
>> > requires surface _around_ isosurface. 
>> inflate
> outside.

inflanting *mesh* is possible - basing on normlas of mesh, not isosurface.

(some examples in attachment, images 3-5 is case 'hardeer' - when some 
parts of inflanted object interect, but it is possible to merge mesh)


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Attachments:
Download 'inflate.gif' (7 KB)

Preview of image 'inflate.gif'

On 14 Jan 2003 10:35:33 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> inflanting *mesh* is possible

Obviously, but ...

> basing on normlas of mesh, not isosurface.

...this does not change that whatever direction of normals is used then you
can't guarantee placement of vertices and triangles without intersecting
isosurface surface. those images you provided are easy to draw becouse you see
shape you are bounding. it is hard to read universal algorithm from those
pictures. please provide algorithm in readable form (POV-SDL could be best)

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote in
news:ble82v0gl5ps049hbfjuk3v3a4o2mka8uo@4ax.com 

>> basing on normlas of mesh, not isosurface.
> ...this does not change that whatever direction of normals is used
> then you can't guarantee placement of vertices and triangles without
> intersecting isosurface surface. those images you provided are easy to
> draw becouse you see shape you are bounding. 

As I said before, I know that this algorithm may results in errors. But 
same might i.e. using adaptive in area_lights etc.

> it is hard to read
> universal algorithm from those pictures. please provide algorithm in
> readable form (POV-SDL could be best) 

ok...


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 14 Jan 2003 11:48:20 -0500, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> > it is hard to read
> > universal algorithm from those pictures. please provide algorithm in
> > readable form (POV-SDL could be best) 
>
> ok...

What I would like to see is a macro Inflate_Object_To_Mesh() as follow:

Input:
  Object   - the mesh should be builded outside of this object (isosurface)
  Accuracy - some intuitive handled float or vector accuracy
  ...      - other settings you need
  FileName - name for outputing mesh definition

Output:
  file with mesh definition as weel as returned mesh which can be assigned on
  located within scene.

ABX

Post a reply to this message