[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