[vtk-developers] New directory structured for VTK?

[Ken Martin]

Hi Chris,

Thanks for looking it over. I purposely made the tree deep instead of wide
to avoid dependency problems. LYMB (a previous system) had a wide tree and
it led to a number of problems and circular dependencies. There are
surprising dependencies you might not expect. For example...

Rendering requires image processing filters to make textures a power of 2 in
size (or you duplicate the code) same thing for converting a texture from
single value float to rgba. DataMapper requires a geometry filter to convert
unstructured grids into polydata. Now IO isn't required for rendering right
now, so it could be moved to be parallel to it if you think that makes
sense.

With local if you make it so that it doesn't depend on rendering, or hybrid
then people can only use local to add non rendering related classes. Having
it depend on most everything increases its flexibility. It might be possible
to make local dependent on rendering only if the person selected rendering
to be built. That should be possible although I haven't tried a make process
like that yet.

Also, my goal is not to encourage people to build part of VTK, there are
other ways to build a reduced footprint VTK that are more effective. I would
like to make rendering required except that it requires a rendering library
(OpenGL etc) which can be problematic sometimes when all someone wants to do
is process data.

Ken

-----Original Message-----
From: Volpe, Christopher R (CRD) [mailto:volpecr at crd.ge.com]
Sent: Thursday, April 05, 2001 9:45 AM
To: 'Ken Martin'; vtk-developers at public.kitware.com
Subject: RE: [vtk-developers] New directory structured for VTK?

Hi Ken-

I agree that breaking up Graphics is a good idea. However, the tree in your
pdf document seems to
have a surprising amount of depth and very little breadth. Do the
dependencies really need to cascade
like that? For example, do the rendering classes really depend on I/O? The
renderers don't care
where, specifically, their input comes from eventually (programmatic or file
source) so why don't
they merely depend on the base filter classes? And what hybrid algorithms
actually depend on the
renderers, as opposed to merely depending on both graphics and imaging
filters themselves? And why is
local assumed to depend on everything, when it is a placeholder for
individuals to add their own
classes? If I want to create one graphics filter, and I'm only building
common, filtering, and
graphics (in theory I don't even need rendering if I'm only building an
analysys filter that spits
out some statistics rather than a new dataset), why should I be forced to
build hybrid algorithms?

-Chris

-----Original Message-----
From: Ken Martin [mailto:ken.martin at kitware.com]
Sent: Thursday, April 05, 2001 9:16 AM
To: vtk-developers at public.kitware.com
Subject: [vtk-developers] New directory structured for VTK?



Hello All,



Could folk take a look at the attached pdf? Another issue I forgot to
mention, is there a better
place for the examplesTcl, examplesPython, examplesCxx  code? New users seem
to have trouble finding
it and it adds quite a bit to the source code tree? Any ideas?



-        Ken