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 17:05:48 -0400

On Mar 31, 2012, at 4:29 PM, Martin Helm wrote:

> Am 31.03.2012 19:08, schrieb Ben Abbott:
> 
>> After looking more closely, I realized I got it wrong. Try the
>> attached version instead. Ben
> 
> Thanks, that looks close. It works for me with 1 or 2 patches but seems
> to have some weird effect when I create many tetrahedral patches (the
> different colors seem to be mapped to the two extremal values, at least
> I can only see red and blue tetrahedrons with colormap jet).
> 
> Looking again at passing rgb values I can avoid spurious triangles with
> wrong colors by avoiding FaceVertexCData at all and using FaceColor
> instead. By a microscoping shrinking of every terahedron ( which is of
> course an incredibly ugly hack) I can also avoid the flaky switching of
> which face is visible when rotating (gnuplot seems to have heavy
> problems sorting the triangles when the have common points, which is
> logical since it uses no z-buffer for rendering in contrast to the
> opengl backend).
> You can see it in the attached test function which uses for the moment
> this workaround until I find a better solution.
> 
> <tetramesh.m>

The m-file __go_draw_axes__.m is a bit of a mess. I'm finding it nearly 
impossible to follow some of the code.

It doesn't surprise the that there are some esoteric bugs for patch objects.

I've started trying to clean it up. I suspect it will take a while.

Ben



reply via email to

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