[vtk-developers] New directory structured for VTK?

[Blue, Russell S (CRD)]

Is there any expectation to how this will affect the incremental building on the PC?  I've just
barely looked at the email... I apologize if the answer is obvious.  

Rusty

		-----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




		_______________________________________________
		vtk-developers mailing list
		vtk-developers at public.kitware.com
		http://public.kitware.com/mailman/listinfo/vtk-developers