Re: basic implementation for isosurface, isocolors, isonormals

[Thomas Treichl]

Martin Helm schrieb:
> > 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).

Yes right, I agree with both of you, don't know what I was thinking when I did 
it. David, can you please make that change in the __marching_cube__.m function?
Thanks,
  Thomas