basic implementation for isosurface, isocolors, isonormals
Thomas Treichl
Thomas.Treichl at gmx.net
Wed Apr 15 11:37:37 CDT 2009
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
More information about the Octave-maintainers
mailing list