POV-Ray : Newsgroups : povray.general : isosurface -> mesh? Server Time
7 Aug 2024 05:17:36 EDT (-0400)
  isosurface -> mesh? (Message 7 to 16 of 16)  
<<< Previous 6 Messages Goto Initial 10 Messages
From: Tom Melly
Subject: Re: isosurface -> mesh?
Date: 24 Dec 2001 13:26:15
Message: <3c277347@news.povray.org>
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3c2755a2@news.povray.org...
>
> There are infinitely many points in space.
> There are also infinitely many points on the surface.
>

The thought had occurred - along with the thought that POV can't evaluate an
infinate number of points for an iso....

> Finding the right points for the mesh vertices is not a trivial task...
>

Can't it just use the points it checks for the iso? What would be the
defect? (I'm not argueing - I'm curious)...


Post a reply to this message

From: Christopher James Huff
Subject: Re: isosurface -> mesh?
Date: 24 Dec 2001 15:34:53
Message: <chrishuff-6133BE.15350324122001@netplex.aussie.org>
In article <3c277347@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk> 
wrote:

> > Finding the right points for the mesh vertices is not a trivial task...
> 
> Can't it just use the points it checks for the iso? What would be the
> defect? (I'm not argueing - I'm curious)...

The points wouldn't be evenly distributed, and there is still the 
problem of figuring out which points to connect with triangles. The 
points from the intersections with the camera rays could be connected 
together to make a height_field-like structure, but it would have all 
the limitations of the height_field.
A collection of random points won't be so easy to connect together into 
a surface...I don't think there is any foolproof algorithm to do that, 
and all of the algorithms are pretty complex. It would probably be 
better to stick with something more like marching tetrahedrons, or some 
method that scans the surface.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>


Post a reply to this message

From: Warp
Subject: Re: isosurface -> mesh?
Date: 24 Dec 2001 15:56:46
Message: <3c27968e@news.povray.org>
Christopher James Huff <chr### [at] maccom> wrote:
: A collection of random points won't be so easy to connect together into 
: a surface...I don't think there is any foolproof algorithm to do that, 
: and all of the algorithms are pretty complex. It would probably be 
: better to stick with something more like marching tetrahedrons, or some 
: method that scans the surface.

  AFAIK the marching triangles algorithm is one of the best algorithms
for this purpose. I think that it generates nicely distributed triangles
(ie. you don't get extremely thin triangles, for exampe) and it can also
nicely calculate more triangles in highly curved parts. Besides, it's
completely free (not patented anywhere). Of course that doesn't mean it is
trivial.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

From: Tom Melly
Subject: Re: isosurface -> mesh?
Date: 24 Dec 2001 19:02:32
Message: <3c27c218@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c27968e@news.povray.org...
> Christopher James Huff <chr### [at] maccom> wrote:

Yeh - thanks C and W. Thinking about it more I began to realise some of the
problems with working out which points to connect (i.e. it's no good just
connecting the three closest points).

I know nothing about the marching triangles algorithm except that it always
is mentioned in tesselation threads, but the name fits the nature of the
problem and the intuitive solutions. Ah, what the hell I'm online, I'll do a
search and read up.
Happy Christmas to one and all.


Post a reply to this message

From: Mike Williams
Subject: Re: isosurface -> mesh?
Date: 25 Dec 2001 00:24:47
Message: <GzdmTKAZ44J8EwD5@econym.demon.co.uk>
Wasn't it Tom Melly who wrote:

>It occured to me that getting an iso-surface function to output a mesh-file
>rather than generating a scene could be a fairly trivial patch. Is this correct?
>What am I missing?

Such a facility is available for parametric isosurfaces.

Is it possible to convert an arbitrary isosurface function into
parametric co-orinates?

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Ruy
Subject: Re: isosurface -> mesh?
Date: 26 Dec 2001 07:14:26
Message: <3c29bf22@news.povray.org>
> Such a facility is available for parametric isosurfaces.
>
> Is it possible to convert an arbitrary isosurface function into
> parametric co-orinates?

I've been there. There is no trivial method for achieving this. It gets ugly
just as soon as you leave the trigonometric domain.

Ruy


Post a reply to this message

From: Mike Williams
Subject: Re: isosurface -> mesh?
Date: 27 Dec 2001 13:19:30
Message: <wF1LeAA3MuK8Ew$Y@econym.demon.co.uk>
Wasn't it Ruy who wrote:
>> Such a facility is available for parametric isosurfaces.
>>
>> Is it possible to convert an arbitrary isosurface function into
>> parametric co-orinates?
>
>I've been there. There is no trivial method for achieving this. It gets ugly
>just as soon as you leave the trigonometric domain.

I think it might be possible for functions that can be solved for one of
the variables. I.e. if you can convert from

                F(x,y,z) = 0
to
                z = G(x,y)

Then you should be able to express the function as the parametrics

                x = u
                y = v
                z = G(u,v)

For example, the sphere given by

        #declare  F = function {x*x + y*y + z*z - 1}

can be converted into the two sets of parametrics

        #declare Fx=function(U,V){U}
        #declare Fy=function(U,V){V}
        #declare Fz=function(U,V){sqrt(1-U*U-V*V)}
and
        #declare Fx=function(U,V){U}
        #declare Fy=function(U,V){V}
        #declare Fz=function(U,V){-sqrt(1-U*U-V*V)}

(One using the +ve sqrt and one the -ve)

Parts of this can be converted into a mesh using Ingo's include file.
Unfortunately it freaks out when asked to interpret regions of <U,V>
where the surface doesn't exist.

#include "functions.inc"

camera { location  <1, 1, -2> look_at <0, 0, 0>}

sky_sphere { pigment {
    function{abs(y)}
    color_map { [0.0 color blue 0.6] [1.0 color rgb 1] } 
  }
}

light_source {<-100,200,-100> colour rgb 1}


// a sphere
#declare  F = function {x*x + y*y + z*z - 1}

//converted to a parametric
#declare Fx=function(U,V){U}
#declare Fy=function(U,V){V}
#declare Fz=function(U,V){sqrt(1-U*U-V*V)}

#declare Umin=-0.7;
#declare Umax=0.7;
#declare Vmin=-0.7;
#declare Vmax=0.7;

#declare Iter_U = 20;
#declare Iter_V = 20;

//Converted to a mesh
#include "param.inc"
Parametric()

object {Surface
  pigment {rgb 0.9}
  finish {phong 0.5 phong_size 10}
  no_shadow
}


//The other side
#declare Fz=function(U,V){-sqrt(1-U*U-V*V)}

Parametric()

object {Surface
  pigment {rgb 0.9}
  finish {phong 0.5 phong_size 10}
  no_shadow
}

-- 
Mike Williams
Gentleman of Leisure


Post a reply to this message

From: Warp
Subject: Re: isosurface -> mesh?
Date: 27 Dec 2001 14:26:05
Message: <3c2b75cd@news.povray.org>
Mike Williams <mik### [at] nospamplease> wrote:
: if you can convert from

:                 F(x,y,z) = 0
: to
:                 z = G(x,y)

... then it's just a heightfield which is pretty easy to create. You
can even use the function image feature for creating an actual height_field
object (which should render even faster than a mesh).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: John D  Gwinner
Subject: Re: isosurface -> mesh?
Date: 28 Dec 2001 12:17:55
Message: <3c2ca943@news.povray.org>
Just as a thought, I think tha'ts true, but not all isosurface's are
representable with heightfields .. many of them are concave.

I think that gets back to 'tesselation isn't trivial'.

However, for many ISO's, I think this would be a good idea; it could reduce
rendering time.

                  == John ==

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c2b75cd@news.povray.org...
> Mike Williams <mik### [at] nospamplease> wrote:
> : if you can convert from
>
> :                 F(x,y,z) = 0
> : to
> :                 z = G(x,y)
>
> ... then it's just a heightfield which is pretty easy to create. You
> can even use the function image feature for creating an actual
height_field
> object (which should render even faster than a mesh).
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -


Post a reply to this message

From: Warp
Subject: Re: isosurface -> mesh?
Date: 28 Dec 2001 14:39:14
Message: <3c2cca61@news.povray.org>
John D. Gwinner <jgw### [at] dazsicom> wrote:
: Just as a thought, I think tha'ts true, but not all isosurface's are
: representable with heightfields .. many of them are concave.

  All functions that can be reduced to z = G(x,y) are. Those that can't
be reduced to that, arent'. Simple :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

<<< Previous 6 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.