[vtk-developers] Scope of VTK and it's potential as a common research language

[Andrew Maclean]

Actually Eigen looks quite good. I wonder how much work would be
needed to refactor VTK to use this?


Andrew


On Tue, Jan 26, 2010 at 1:55 AM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
> To revisit this question :
>
> I'd like to see VTK adopt a decent vector+maths library under the hood, a dependency on something like Eigen would not be a problem AFAIAC (Especially if it was inside Utilities and compiled along with VTK). VTK shouldn't reimplement these things, but should not introduce too many hard to solve dependencies. Using Utilities/Mathlibrary-1,2,3 etc is not a problem for me. There are many algorithms in VTK which mess round with points and the code is not very readable. A decent vector/matric template calss would make things much better.
>
> In an ideal world all things like boost would work out of the box with cmake too and we could replace huge amounts of smartpointer stuff, lists, and the rest with stl/boost objects.
>
> JB
>
>
>> -----Original Message-----
>> From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org]
>> On Behalf Of David Doria
>> Sent: 11 January 2010 03:50
>> To: VTK Developers
>> Subject: [vtk-developers] Scope of VTK and it's potential as a common
>> research language
>>
>> A recent discussion has raised, again, a point which has come up
>> several times - that is, how much math should VTK include? I agree
>> that it is very important to address. Here are my thoughts:
>>
>> Although VTK is a visualization toolkit, I believe it can and should
>> act as much more than that. It serves as a common language for
>> scientists and engineers to share code (clearly within reason -
>> typically in the computer graphics/computer vision/image processing
>> fields). This is critically important as technology continues to
>> advance at an accelerating rate. While yes, we don't strive to provide
>> a full mathematics toolbox, I believe we should not hesitate to
>> provide things to make it easy for people to share code. If a few
>> simple matrix multiples force someone to include yet another 3rd party
>> library, it makes it significantly harder to give to a colleague. If
>> one says "here is my code, you'll need VXL, VTK, ITK, LAPACK, Boost,
>> etc. etc", that will discourage people from actually use the code, as
>> they will likely have to spend a week getting it to compile and link.
>> If one says "I have implemented all of my research as VTK filters",
>> the next researcher can simply use it as a building block for the next
>> year's research. I've never seen an actual survey, but I bet the
>> *majority* of most students (and probably professional's, too) time is
>> spent re-implementing things that have already been written at least
>> once (probably hundreds of times) and should already be
>> "plug-and-play". The problem is 100% that the code is not written in a
>> form that is compatible with the next guy's code base. If we strive to
>> setup an environment in which this problem is alleviated, it would be
>> a massive step in the right direction for the success of all future
>> scientists. The Insight/VTK journal's are already in place to then
>> make this work in a common environment/language easy to share and
>> find.
>>
>> That said, there is still clearly a line that needs to be drawn. We
>> should probably not provide everything that is available in a
>> mathematics package such as Maple. However, again, we shouldn't
>> hesitate to provide things that are reasonably linked to the research
>> fields that people who use VTK are involved with. If the logic is "VTK
>> is only a visualization toolkit", then all of the readers and writers
>> do not fit the description, which we all know to be critically useful.
>> None of the mathematics functions should be exposed, which would make
>> things much harder. My point is, we have already taken a giant step
>> over the "only a visualization toolkit" line, so why restrain
>> continued development in reasonable directions?
>>
>> I realize I'm the "new guy" to VTK, but I think this allows me to
>> bring a nice perspective to the table. Being a current PhD student,
>> I'm experiencing first hand the "state of the art" of code sharing
>> and, frankly, it is failing miserably.
>>
>> I'd like to hear what some of you veteran VTK-ers and scientists think
>> about this.
>>
>> David D.
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>



-- 
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________