<html>
<body>
The problem with a roadmap is that is assumes that you know where you
want to go :-) To some extent VTK is a creative expression of emerging
visualization technology, so we (meaning the community) are creating the
map as we go. But rather than leave you with some vague pleasantries,
here are some possibilities:<br><br>
- Tcl, Python, Java - no intention of dropping any one of these<br>
- Support for AMR (mulit-res grids see
http://seesar.lbl.gov/AMR/Overview/ for an overview)<br>
- More 3D widgets<br>
- Improvements to the pipeline update mechanism including support for
multiresolution<br>
- Possible support for multi-block and composite grids<br>
- I'd like to rework the polydata and unstructured grid structures
(vtkMesh ??)<br>
- Lots more parallel support, including parallel compositing
algorithms<br>
- Algorithms like LIC, maybe a couple terrain-decimation algorithms<br>
- Further integration of STL and other important C++ constructs (like
templates)<br>
- Maybe unstructured grid volume rendering<br><br>
However, one of the biggest changes I'd like to see are the manner in
which VTK is managed. Ken Martin has proposed an ARB; we'd also like to
find a quality Enforcer. This should bring greater stability and maturity
to the software, and provide things like roadmaps :-) <br><br>
Will<br><br>
At 09:37 AM 3/19/2003 -0300, Marcio Antonio Mathias (EDB)
wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>Hi,</font> <br>
<font size=2>Does someone know about a "VTK roadmap". I am
afraid about thousands of line code written in Tcl/Tk, if this
interpreter (or even another core languages) became not supported in
further VTK releases.<br>
</font><br>
<font size=2>Cheers,</font> <br><br>
<font size=2>Marcio</font> </blockquote></body>
</html>