[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: basic implementation for isosurface, isocolors, isonormals
From: |
Daniel J Sebald |
Subject: |
Re: basic implementation for isosurface, isocolors, isonormals |
Date: |
Sat, 11 Apr 2009 10:33:43 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
David Bateman wrote:
Thomas Treichl wrote:
David Bateman schrieb:
Thomas Treichl wrote:
David Bateman schrieb:
I don't think the hiding of the axis is a really major issue though
I also see some other artifacts that seem to be due to some weird
issue in gnuplot with the depthorder, and I don't see the fix for
it at the moment. Also it appears that FaceVertexCdata is not
really implemented yet and so these values aren't respected at all.
In fact the patch properties have a number of derived properties
that should be treated specially, like the differences between the
[xyz]data and vertices and faces data.. The derivation of one of
these properties from another is currently handled in the patch
function itself.. However this doesn't make sense as then if the
user uses the "set" function to change one of these properties the
others won't be changed appropriately..
The way to fix it is either to treat the issue in the set/get
methods of the patch type or to add callbacks in the patch
functions.. Callbacks are probably the easiest method as we can
stay in the scripting language.. I'll look at this as I'm
interested in getting the iso* functions into Octave..
Hi,
I just wanted to know, what the final maintainers' decision about
inclusion of the iso* into the core Octave sources is? I think that
I can work on creating a changeset because I don't want these codes
get forgotten...
If you say you currently can't decide or you think it is better to
not include the files right now or whatever then I think we should
at least host Martin's functions at OF right now?
I'm working on rewriting the __patch__ to add listeners such that
changes to the {x|y|z|c}data properties also changes the faces,
vertices and facevertexcdata properties appropriately. Without this
the previous code was buggy and so not of a quality to be included in
Octave.. In fact I have most of this going now and hopefully will
send something soon (tonight if I'm fast). I also in passing added
the trisurf function.
Ah, ok, thanks. And absolutely *don't stress* to make that happen ;)
Thomas
Ok, well it was a little bit harder than I thought for a few reasons
1) gnuplot's depth order pm3d code only works for a single surface and
so a set of patches that need to be depth sorted need to be plotted with
a single splot command
2) The gnuplot binary file format doesn't support "index" for splot and
so constraint 1) means the data has to be written as ASCII
It's been a long time since I looked at the binary mode of gnuplot, but my memory is that I
implemented almost all the same features and syntax as for ASCII. There is a binary mode for which
"index" doesn't work and that is the original gnuplot matrix format. (If the data in the
file is in a matrix format, "index" makes no sense.) However, Petr reported some gnuplot
problems with binary mode just recently, and he posted a code snippet change related to a matrix
flag. You may be getting an error message when you shouldn't.
3) As pm3d uses the color palette, any fixed color patches need to have
their color added to the colormap, and then the other things plotted
with the colormap need to be treated carefully..
In any case I committed the attached patch that appears to work fine
for all the tests I ran with the gnuplot CVS version. One issue I have
is with gnuplot 4.2.4 I see the attached for the command
"demo('patch',6); colorbar" for the X11 terminal. This appears to be a
gnuplot bug as it works for other terminals like png, eps, etc and it
works for the CVS version of gnuplot.. Should I care about this bug?
No, but if you have a moment, please post a bug report at:
http://sourceforge.net/tracker/?func=add&group_id=2055&atid=102055
and attach the figure.
Dan
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/03
- Re: basic implementation for isosurface, isocolors, isonormals, Thomas Treichl, 2009/04/08
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/08
- Re: basic implementation for isosurface, isocolors, isonormals, Thomas Treichl, 2009/04/08
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/11
- Re: basic implementation for isosurface, isocolors, isonormals,
Daniel J Sebald <=
- Re: basic implementation for isosurface, isocolors, isonormals, Thomas Treichl, 2009/04/11
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/12
- Re: basic implementation for isosurface, isocolors, isonormals, Martin Helm, 2009/04/12
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/14
- Re: basic implementation for isosurface, isocolors, isonormals, Thomas Treichl, 2009/04/14
- Re: basic implementation for isosurface, isocolors, isonormals, Martin Helm, 2009/04/14
- Re: basic implementation for isosurface, isocolors, isonormals, David Bateman, 2009/04/14
- Re: basic implementation for isosurface, isocolors, isonormals, Martin Helm, 2009/04/14
- Re: basic implementation for isosurface, isocolors, isonormals, Thomas Treichl, 2009/04/15