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 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

Attachment: __go_draw_axes__.diff
Description: Binary data






reply via email to

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