hi,

i found some c code for the marching cube algorithm
(http://astronomy.swin.edu.au/pbourke/modelling/polygonise/) and translate
it into a pov3.5 macro. This algorithm creates a mesh given a scalar
function of (x,y,z) and an iso-level (so it tesselates an isosurface..)

don t know if this can be useful (in fact i m sure it s useless, but it was
fun to programm :)

the macro and an example can be found here :
http://195.221.122.126/tmp/marching.html

usage :
#include "marching cube.inc"
marching("my_function",thresold,box_min,box_max,steps,file_out)

my_function : a string, the function of the isosurface (you must put it into
"")
thresold : a float, the iso level you want
box_min,box_max : two vectors = bounding box
steps : a vector with the number of steps in each direction x,y,z
file_out : a string, the output file , at the end it will contain the mesh

ex :
marching("dodca",1.5,<-10,-10,-10>,<10,10,10>,<50,50,50>,"poly.inc")

the algo computes the function for all points of a steps.x*steps.y*steps.z
grid , so don t use too large values for the number of steps !
i ve not done too much tests, so it might be buggy..

M

Post a reply to this message

Mael wrote:
> 
> hi,
> 
> i found some c code for the marching cube algorithm
> (http://astronomy.swin.edu.au/pbourke/modelling/polygonise/) and translate
> it into a pov3.5 macro. This algorithm creates a mesh given a scalar
> function of (x,y,z) and an iso-level (so it tesselates an isosurface..)
> 
> don t know if this can be useful (in fact i m sure it s useless, but it was
> fun to programm :)
> 
> [...]

I previously considered writing such a macro, but i thought it would be
much faster if done internally in POV - like the tesselation patch, which
is still buggy (wasn't there someone who fixed that bug using a different
algorithm recently?)

BTW, it would be really nice if passing function names to macros worked,
this string method looks quite horrible...

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

in news:3BB344D2.8D680A43@gmx.de Christoph Hormann wrote:

> BTW, it would be really nice if passing function names to macros
> worked, this string method looks quite horrible...
> 

Ron posted something like this:

  #macro Foo( Bar, X )
    #declare Y = Bar(X);
    #declare Z = Bar(Y);
  #end

  #declare FUNC=function(n){n+2}

  Foo(function(n){FUNC(n)}, 1)

  #debug str(Y,5,5)
  #debug "\n"
  #debug str(Z,5,5)
  #debug "\n"



Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

ingo wrote:
> 
> Ron posted something like this:
> 
> [...]

Thanks, but i still have problems with things like this:

  #macro Foo( Bar, X )
    Bar(n-X) 
  #end

  #declare FUNC=function(n){n*2}

  #declare FUNC2=function(n){ Foo( function(n){FUNC(n)} , 1) }

  #debug str(FUNC2(12),5,5)
  #debug "\n" 


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

On Thu, 27 Sep 2001 18:35:09 +0200, Christoph Hormann wrote:
>
>
>ingo wrote:
>> 
>> Ron posted something like this:
>> 
>> [...]
>
>Thanks, but i still have problems with things like this:
>
>  #macro Foo( Bar, X )
>    Bar(n-X) 
>  #end
>
>  #declare FUNC=function(n){n*2}
>
>  #declare FUNC2=function(n){ Foo( function(n){FUNC(n)} , 1) }
>
>  #debug str(FUNC2(12),5,5)
>  #debug "\n" 

Not having rendered it, I don't know what problems you have, but another
known bug is that returning a local (including a parameter) from a macro
is bad juju.  You might try returning it by way of a global variable.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Ron Parker wrote:
> 
> Not having rendered it, I don't know what problems you have, but another
> known bug is that returning a local (including a parameter) from a macro
> is bad juju.  You might try returning it by way of a global variable.
> 

If you mean the 'X' - it does not help anything to remove it.  

BTW it gives 'Parse Error: Unknown user defined function.'

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

Good addition!

Thanks.

How does your macro compare to the isosurfacing capability already in
POVRay?  How is it the same?  How is it different?

Jim

"Mael" <mae### [at] hotmailcom> wrote in message
news:3bb33e2f$1@news.povray.org...
> hi,
>
> i found some c code for the marching cube algorithm
> (http://astronomy.swin.edu.au/pbourke/modelling/polygonise/) and translate
> it into a pov3.5 macro. This algorithm creates a mesh given a scalar
> function of (x,y,z) and an iso-level (so it tesselates an isosurface..)
>
> don t know if this can be useful (in fact i m sure it s useless, but it
was
> fun to programm :)
>
> the macro and an example can be found here :
> http://195.221.122.126/tmp/marching.html
>
> usage :
> #include "marching cube.inc"
> marching("my_function",thresold,box_min,box_max,steps,file_out)
>
> my_function : a string, the function of the isosurface (you must put it
into
> "")
> thresold : a float, the iso level you want
> box_min,box_max : two vectors = bounding box
> steps : a vector with the number of steps in each direction x,y,z
> file_out : a string, the output file , at the end it will contain the mesh
>
> ex :
> marching("dodca",1.5,<-10,-10,-10>,<10,10,10>,<50,50,50>,"poly.inc")
>
> the algo computes the function for all points of a steps.x*steps.y*steps.z
> grid , so don t use too large values for the number of steps !
> i ve not done too much tests, so it might be buggy..
>
> M
>
>

Post a reply to this message

> How does your macro compare to the isosurfacing capability already in
> POVRay?  How is it the same?  How is it different?

isosurface in pov :
they are directly ray traced,
they do not need memory,
but they are slow to render

if you use the macro to create a mesh :
it is slow to generate (but you only have to do this once),
it renders way faster than the isosurface (because it's only triangles),
if you want a smooth result you need a lot of triangles
it uses more memory than an isosurface

the macro is not really usefull to render isosurface in pov, but maybe it
can help someone who would want to convert an isosurface for another
programm

M

Post a reply to this message

Christoph Hormann wrote:

> I previously considered writing such a macro, but i thought it would be
> much faster if done internally in POV - like the tesselation patch, which
> is still buggy (wasn't there someone who fixed that bug using a different
> algorithm recently?)

If you are speaking about my experiments, I'm sorry to say that the bug is
still in, unless I use an alternate tesselation technics which approximate
the object with a set of little cub or a variant.
But then the mesh is usually ugly, because there is at most 3 or 34 normals
( x/y/z and their rotation by 50 grades around all axes).
It's better than the walking tetrahedron ONLY when tesselating a box,
or a similar shape. For other shapes, the size of triangles must be so small
to get something smooth that's really long to parse and the need of memory
is huge. 
Warps approach was very good for smoothness without too much memory.

The link: http://astronomy.swin.edu.au/pbourke/modelling/polygonise/
looks interesting, because it is similar to my approach but pushes the
number of possible normals further, thus providing probably smoothness 
at a lower resolution. 

I will give it a try when I have some time :-)

Post a reply to this message

> I previously considered writing such a macro, but i thought it would be
> much faster if done internally in POV - like the tesselation patch, which
> is still buggy (wasn't there someone who fixed that bug using a different
> algorithm recently?)

yes it is very slow if you use a small grid.. May be the macro can be
enhanced by using some sort of adaptive grid rather than a fixed one, but i
m afraid this is beyond my capacities :(

> BTW, it would be really nice if passing function names to macros worked,
> this string method looks quite horrible...

i agree :)

M

Post a reply to this message