octave-maintainers
[Top][All Lists]
Advanced

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

Re: basic implementation for isosurface, isocolors, isonormals


From: Martin Helm
Subject: Re: basic implementation for isosurface, isocolors, isonormals
Date: Tue, 14 Apr 2009 23:37:39 +0200
User-agent: KMail/1.10.3 (Linux/2.6.27.21-0.1-default; KDE/4.1.3; x86_64; ; )

> Thomas Treichl wrote:
> > David Bateman schrieb:
> >> Martin Helm wrote:
> >>> First of all,
> >>>
> >>> thank you for your effort David. I can confirm the errors reported
> >>> by Thomas. To be precise they happen with the first two examples in
> >>> the "subplot" example group which use the syntax
> >>> patch ("Faces", f, "Vertices", v, "EdgeColor", whatever)
> >>>
> >>> The other two examples which use "FaceVertexCData" and facecoloring
> >>> work well.
> >>>
> >>> If I simply add the "FaceColor" attribute with some value to the
> >>> failing patch command, the problem disappears, so the bug seems to
> >>> be trivial (a misssing default value for "FaceColor")
> >>>
> >>> e.g.
> >>>
> >>> patch ("Faces", f, "Vertices", v, "FaceColor", "blue","EdgeColor",
> >>> "none")
> >>>
> >>> works well. I'll look through the code.
> >>>
> >>> - mh
> >>
> >> The old 3.0.x behavior was that the default facecolor was [0,1,0]. I
> >> presume that is the compatible behavior and so re-established that as
> >> the default with the attached patch. The demo in the help string then
> >> works correctly for the gnuplot CVS. But there appear to be some
> >> issue with colormap with gnuplot 4.2.4 and the x11 terminal in a
> >> multiplot environment.. I suppose I should try 4.2.5 and see if that
> >> works
> >>
> >> D.
> >
> > Hi David, Martin,
> >
> > thanks again for this work. I'd say that this is really a very cool
> > new feature that then comes with 3.2...
> >
> > Some time ago I also was working on the help text of isonormals.m and
> > __marching_cubes__.m (Martin already knows because I wrote him an
> > email some time ago offside the lists to preserve double-work ;)
> > David, can you please apply the attached changeset?
> >
> > Thanks and best regards,
> >
> >   Thomas
>
> The __marching_cube__ function is an internal function as far as I can
> see. If you are going to document it as you have we should change its
> name to marching_cube instead.. That being said I made your changes but
> kept __marching_cube__ officially undocumented.. You'll have to look at
> the code to get the documentation.... Should this be changed?
>
> D.

>From my point of view it is really an internal function. So it is ok to keep 
the documentation "hidden" in the sourcecode. The user shall call isosurface 
(which is more or less a wrapper around it).

- mh




reply via email to

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