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

[Bill Lorensen]

I would be concerned about the lgpl license.

On Mon, Jan 25, 2010 at 5:30 PM, Andrew Maclean
<andrew.amaclean at gmail.com> wrote:
> 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/
> ___________________________________________
> _______________________________________________
> 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
>
>