[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 13:08:36 -0400 |
On Mar 31, 2012, at 12:01 PM, Ben Abbott wrote:
> 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
After looking more closely, I realized I got it wrong.
Try the attached version instead.
Ben
__go_draw_axes__.diff
Description: Binary data