help-octave
[Top][All Lists]
Advanced

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

Re: possible bug in gnuplot backend when using 3d patches


From: Ben Abbott
Subject: Re: possible bug in gnuplot backend when using 3d patches
Date: Sat, 31 Mar 2012 12:01:11 -0400

On Mar 31, 2012, at 11:15 AM, Martin Helm wrote:

> Am 31.03.2012 17:03, schrieb Ben Abbott:
> 
>> On Mar 30, 2012, at 7:59 PM, Martin Helm wrote:
>> 
>>> Dear all,
>>> 
>>> I would like to have some feedback on the following problem (octave 3.6.1)
>>> 
>>> This code works as expected when using the fltk toolkit
>>> 
>>> patch ("Faces", [1 2 3; 2 3 4; 3 4 1; 4 1 2], \
>>> "Vertices", [1 0 0; 0 1 0; 1 1 0; 0 0 1],\
>>> "FaceVertexCData", [32; 32; 32; 32])
>>> 
>>> and shows as expected a tetrahedron with color 32 of the current colormap.
>>> 
>>> The same code when used with the gnuplot backend leads to this error
>>> 
>>> error: horizontal dimensions mismatch (4x3 vs 2x1)
>>> error: called from:
>>> error:   /usr/share/octave/3.6.1/m/plot/private/__go_draw_axes__.m at
>>> line 752, column 37
>>> error:   /usr/share/octave/3.6.1/m/plot/private/__go_draw_figure__.m at
>>> line 167, column 19
>>> error:   /usr/share/octave/3.6.1/m/plot/__gnuplot_drawnow__.m at line
>>> 86, column 5
>>> 
>>> while it works somehow when I feed rgb tripplets to the patch
>>> colormap()(32,:)
>>> ans =
>>> 
>>>  0.46825   1.00000   0.53175
>>> 
>>> patch ("Faces", [1 2 3; 2 3 4; 3 4 1; 4 1 2], \
>>> "Vertices", [1 0 0; 0 1 0; 1 1 0; 0 0 1], \
>>> "FaceVertexCData", [ 0.46825   1.00000   0.53175;\
>>> 0.46825   1.00000   0.53175;\
>>> 0.46825   1.00000   0.53175;\
>>> 0.46825   1.00000   0.53175])
>>> 
>>> But also not as I would expect, there is some spurious red-brown
>>> triangle there which I cannot explain.
>>> 
>>> Has anyone an idea if that's a bug or some feature I do not understand?
>> The problem is that the patches are 3D, and gnuplot has limited ability to 
>> render 3D patches.
>> 
>> h = findobj (gca (), "type", "patch");
>> get (h, "zdata")
>> ans =
>> 
>>   0   0   0   1
>>   0   0   1   0
>>   0   1   0   0
>> 
>> Take a look at how David Bateman implemented isosurface.m
>> 
>>      demo isosurface 1
>>      h = get (gca (), "children")
>>      get (h, "type")
>>      ans = patch
>> 
>> There remains some minor problems with isosurface. The edge color is [0 0 
>> 0], but should be "none".  However, when the edgecolor is an RGB value, 
>> gnuplot does not render the edge.
>> 
>> Ben
> 
> Hi Ben, I know the problem with isosurface and gnuplot (since I
> implemented it, it is just not checked in by me). I will have a look
> into the source code for the 3d patches in gnuplot (but feel a bit
> lost), I remember I could work around that problems a few years ago by
> directly creating pm3d gnuplot code and passing it to gnuplot directly
> which did not have all of that problems, though I do not remeber if I
> ever found a solution for the edge color problem.
> Maybe I find a solution, if I can find out what I did at that time.

I've attached a patch that works for me, but haven't verified it doesn't break 
anything else.

Ben

Attachment: __go_draw_axes__.diff
Description: Binary data


reply via email to

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