|
From: | Thomas Treichl |
Subject: | Re: basic implementation for isosurface, isocolors, isonormals |
Date: | Wed, 15 Apr 2009 18:37:37 +0200 |
User-agent: | Thunderbird 2.0.0.21 (Macintosh/20090302) |
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. - mhThe 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, ThomasThe __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
[Prev in Thread] | Current Thread | [Next in Thread] |