[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