[VTK ARB] VTK NIH Maintenance grant

Tue Aug 3 12:23:45 EDT 2010

Hello,

Regarding this part:

"Functionality to Expand or Refactor
    * GL 4? support (e.g., new mobile devices)
"

First of all, mobile devices support OpenGL ES 2, not OpenGL 4.0. I
guess the idea is to avoid the use of deprecated functions (since
OpenGL 3.0) like glBegin() which are still available in an OpenGL
compatibility context but removed from a forward compatible context
and removed from OpenGL ES 2. That's in the case you want to use the
same classes for desktop and PDA. However, I don't thing it will work
for all the classes using OpenGL as OpenGL ES is only a subset of
OpenGL. On the desktop side, there is no advantage to move to
forward-compatible OpenGL contexts. The major vendors said they will
never removed the compatibility contexts.

As a matter of fact, because I keep the files glext,glxext,wglext
up-to-date from opengl.org. VTK can already support OpenGL 4.0
features (with the limitations I explained in my proposal from May
2010).

Regarding any GL refactoring, I would like to re-enforce my proposals
from May 2010 to the ARB:

The first one is required to be able to move forward:
"Rework the OpenGL extension mechanism":
http://public.kitware.com/pipermail/arb/2010-May/000093.html

The second one is really relevant for the medical side to allow
sharing the same big dataset between different windows:
"Framework for sharing OpenGL resources between several
vtkOpenGLRenderWindows":
http://public.kitware.com/pipermail/arb/2010-May/000094.html

On Mon, Aug 2, 2010 at 7:54 PM, Andrew Maclean
<andrew.amaclean at gmail.com> wrote:
> Sorry for the late reply.
>
> Under the heading to expand or refactor:
> Definitely modularisation, I would also think consideration of using
> namespaces is also important. One other refactorisation we could
> undertake is looking at groups of files to see if they are in the
> appropriate places. For example vtkParametricFunctionSource is in
> Graphics, but the parametric surfaces such as vtkParametricTorus are
> in Common - my feeling is that they really should be in Graphics. This
> was done years ago because there was some limitation in VS6 about the
> number of files that could be processed to form a library.
> As regard to namespaces, I think this will be inevitable in the
> future. NOTE: I am NOT proposing renaming functions or classes, (I
> like the current naming convention). But looking towards the future I
> can see us inventing longer and longer names for classes of similar
> functionality that could happily live in different namespaces. As an
> example the recent e-mail about splitting
> vtkSurfaceReconstructionFilter into two classes, to me implies a
> vtk::SurfaceReconstruction namespace. Thus people who want to do
> surface reconstruction know that these algorithms reside in this
> namespace. We could have vtk::ImplicitFunction, vtk:ParametricFunction
> namespaces etc... I feel this will substantially assist in
> modularisation and documentation.
>
> Of course there is a huge code base out there, but I wonder if an
> automated script in python could also be developed as part of this
> proposal to look at the source files and insert the appropriate
> namespaces based on the include files to ease transition.
>
> Regards
>   Andrew
>
>
> On Sat, Jul 31, 2010 at 2:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>> My first interest is definitely in refactoring the VTK widgets, but it
>> looks like it is already on the list.  Do you just want the ideas, or
>> some sort of write-up?
>>
>>  David
>>
>>
>> On Fri, Jul 30, 2010 at 9:45 AM, Will Schroeder
>> <will.schroeder at kitware.com> wrote:
>>> I am working with Brad Davis to put together a proposal for VTK-focused,
>>> biomedical computing work (a so-called NIH maintenance
>>> grant http://grants.nih.gov/grants/guide/pa-files/PAR-08-010.html). We'd like
>>> to hear any ideas you might have, but be forewarned the number of specific
>>> aims will be limited to 3-5, so most ideas I'm afraid won't make the final
>>> cut. Nonetheless, any suggestions for VTK improvements that would benefit
>>> biomedical computing are welcome. I've pasted a rough list that we've
>>> collected thus far..
>>> Will
>>> --
>>>
>>> Process
>>>
>>> Tools and process for distributed community involvement/support/use of VTK
>>>
>>> Functionality to Expand or Refactor
>>>
>>> Widgets
>>> GL 4? support (e.g., new mobile devices)
>>> Expanded image support
>>>
>>> Non-contiguous, non-axis aligned
>>> Expand itk/vtk connection support with good examples
>>>
>>> New Stuff
>>>
>>> Arbitrary precision geometry routines (casey)
>>> Introspection layer (pat)
>>>
>>> Software Process Improvements
>>>
>>> Incorporate static analysis into nightly/weekly process
>>>
>>> Pure Maintenance
>>>
>>> Triage & Fix Bugs (see issue tracker)
>>> Clean up build process (some funding already from Berk)
>>>
>>> Documentation & Outreach
>>>
>>> Improve number, scope, number of languages for examples
>>> Support VTK users list
>>> Courses?
>>> Provide support for community members to contribute (e.g., provide grant to
>>> cover a month of work)
>> _______________________________________________
>> Arb mailing list
>> Arb at vtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>>
>
>
>
> --
> ___________________________________________
> 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/
> ___________________________________________
> _______________________________________________
> Arb mailing list
> Arb at vtk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>

-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA