help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: marching cubes and isosurface


From: Martin Helm
Subject: Re: marching cubes and isosurface
Date: Mon, 23 Feb 2009 22:28:58 +0100
User-agent: KMail/1.10.3 (Linux/2.6.27.7-9-default; KDE/4.1.3; x86_64; ; )

> martin_helm schrieb:
> > Hello,
> >
> > this post was first on the graphics list, but I deleted it by accident,
> > since I noticed that the graphics list seems to be allmost dead I put it
> > here.
> >
> > The situation:
> >  I could not find an isosurface function similar to matlab or marching
> > cubes algorithm in octave. So I recently made my own one. It creates a
> > triangulation from a scalar function on a meshgrid (it can be found at
> > http://www.mhelm.de/octave/m/marching_cubes.m).
> > If it is usefull to someone I would be glad to receive a feedback. I
> > preferred a pure .m file implementation since the performance is good
> > enough for my needs and I will enhance it to a complete isosurface
> > function compatible with matlab.
> > Since I do not intend to event the wheel twice, can someone point me to
> > an existing implementation if there exists one?
> > Can someone give me the information if "trisurf" will be implemented in
> > the next version of octave (3.2) or in octave forge, I couldn't find out,
> > although I found discussions about trisurf in mailing lists?
> > For the moment I use octaviz for things like that because it still gives
> > me interactive graphics with vtk_trisurf even for large datasets (e. g.
> > triangle meshes with >1.6 M triangles). I wonder if something similar
> > will be available with the new fltk backend.
> > I checked the development sources but could not find trisurf. The
> > enhanced patch function with fltk and jhandles gives a similar
> > functionality but seems to have some problems with the shading settings.
>
> Hi Martin,
>
> I recently have started to implement isosurface.m to create some volumetric
> output with Octave but it still is in a very early stage and not good
> enough to be posted here - don't know how long it will take me to finish it
> but maybe I even must not finish it: Are you planing to work on isocaps,
> isonormals, etc. too? If yes, then I will rethink my effort for iso* and go
> on with something else?
>
> Best regards,
>
>    Thomas

Dear Thomas,

in fact this is the intention ( my question was mainly that I want to avoid to 
implement something which is already available). 
As a first step I need isosurface and isonormals so I will implement them 
soon. Then I will think about isocaps (my background is visualization of post 
processed medical datasets), so I guess I will implement it too. The limiting 
factor was until now the relatively slow and somewhat limited  3d drawing 
functions with octave (not everyone uses octaviz and it has a special syntax 
so it is not directly portable to other octave users). As far as I can see 
this will no longer be a real problem in the near future since we have now 
opengl backends available in octave where the syntax is unified.
My plan is first to implement everything as .m files and if there are severe 
performance problems with something (I hope not) reimplement critical 
functions as oct files.

- mh


reply via email to

[Prev in Thread] Current Thread [Next in Thread]