[vtk-developers] New directory structured for VTK?

Volpe, Christopher R (CRD) volpecr at crd.ge.com
Thu Apr 5 10:32:40 EDT 2001


Good points, Ken. Yes, I remember the dependency problems in LYMB. Thanks for explaining in detail
the motives and rationale.

-Chris

> -----Original Message-----
> From: Ken Martin [mailto:ken.martin at kitware.com]
> Sent: Thursday, April 05, 2001 10:07 AM
> To: Volpe, Christopher R (CRD); vtk-developers at public.kitware.com
> Subject: RE: [vtk-developers] New directory structured for VTK?
> 
> 
> 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
> 
> 
> 




More information about the vtk-developers mailing list