[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC project: new graphics backend
From: |
Jonathan Stickel |
Subject: |
Re: GSoC project: new graphics backend |
Date: |
Thu, 26 Mar 2009 19:25:51 -0600 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
On 03/26/2009 address@hidden wrote:
Date: Thu, 26 Mar 2009 17:25:26 +0300 From: Arseniy Lartsev
<address@hidden> Subject: Re: GSoC project: new graphics backend To:
address@hidden Message-ID:
<address@hidden> Content-Type: text/plain;
charset="iso-8859-1"
> On Tuesday 24 March 2009 15:33:59 Eric S. Carlson wrote:
> > I think that it is a very bad idea to make it a general
requirement for
> > octave. That said, making these packages options as part of
separate shells
> > or IDEs may not be so bad.
Mayavi seems to rely on VTK so I'd better use VTK directly, for both
3D and
2D.
If you are not already familiar with Octaviz, please take a look:
http://octaviz.sourceforge.net/
Octaviz is a 3D visualization "add-on" to octave that uses VTK.
Development and maintenance for Octaviz has recently stalled due to lack
of a developer who knows c++ and bison.
In regard to JWE's comments that graphics should not be provided as an
add-on, I would like to point out a couple things that have been
bothering me for some time now:
Plotting in Octave is pathetic, in my opinion. Among other things, 2D
plotting should provide complete control over the style of data points
and lines. Mouse control for things like zooming would be nice. Octave
has experienced some regression here. 3D plotting should look great,
provide text, and have mouse controls. Octave plotting is OK for quick
plots to see what my data looks like, but I've come to realize recently
that to get publication quality plots, I must resort to saving my data
and plotting in a 3rd party program (gnuplot, matplotlib, mayavi, etc).
Until there is serious improvement, users/developers will continue to
try to implement various hacks to get plotting to work how they think it
should. Mostly this includes attempts to interface with plotting and
visualization systems *that already work*. Why reinvent the wheel? Why
not use libraries like VTK that provide a well established and well used
interface for providing visualizations with axes, text, and mouse controls?
I know what you will say: it won't happen without volunteer help. I am
interested in helping, but the graphics system has become so
complicated, due to the effort to implement handle-graphics, that it is
practically impossible for me to get started. I say forget handle
graphics, at least for now. Instead, effort should be made to get
plotting and visualization to work first, in whatever form, and then add
handle graphics or other Matlab compatible features.
Regards,
Jonathan
- Re: GSoC project: new graphics backend, (continued)
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/28
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/29
- Re: GSoC project: new graphics backend, Michael Goffioul, 2009/03/29
- Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/30
- Re: GSoC project: new graphics backend, Przemek Klosowski, 2009/03/30
Re: GSoC project: new graphics backend, Arseniy Lartsev, 2009/03/22
Re: GSoC project: new graphics backend,
Jonathan Stickel <=