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

Mon Jan 25 17:43:28 EST 2010

Point taken. Would it be worthwhile talking to them about this?

On Tue, Jan 26, 2010 at 9:34 AM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> 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
>>
>>
>

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