VTK/GSoC 2016: Difference between revisions
DaveDemarle (talk | contribs) |
DaveDemarle (talk | contribs) |
||
Line 87: | Line 87: | ||
=== Better Package management Support for Java and Python === | === Better Package management Support for Java and Python === | ||
'''Brief explanation:''' VTK has bindings to languages other than its native C++ but lacks strong integration with package management systems like Maven for Java and PIP for Python. As such every project written in those languages | '''Brief explanation:''' VTK has bindings to languages other than its native C++ but lacks strong integration with package management systems like Maven for Java and PIP for Python. As such every project written in those languages solves the problem of how to provide VTK's runtime libraries in their own way. Updating VTK's build system to be compatible with the standard resources for different languages will make VTK more approachable for large groups of users and simplify life for application developers. | ||
For Java, the task will be to smooth out the bumps and complexity to run a VTK application inside a Java environment. The first step would be to embed within the VTK Java library a better native library loading mechanism similar to what was done with Jogl. Next we would provide prebuilt versions of VTK for the 3 major platforms and publish them on a public Maven repository. Similarly for Python we would extend VTK's Superbuild CMake infrastructure for making python executables to make libraries are suitable for distribution and installation via PIP. | |||
'''Expected results:''' Automatic publication of pre-compiled VTK library across all platform (OS X, Windows, Linux) via Maven with an automated system library loading and deployment of the VTK library with its native counter part managed via pip install for usage within the system Python or a Python Virtual Environment. | '''Expected results:''' Automatic publication of pre-compiled VTK library across all platform (OS X, Windows, Linux) via Maven with an automated system library loading and deployment of the VTK library with its native counter part managed via pip install for usage within the system Python or a Python Virtual Environment. |
Revision as of 14:28, 19 February 2016
Project ideas for the Google Summer of Code 2016
Guidelines
Students
These ideas were contributed by developers and users of VTK and ParaView. If you wish to submit a proposal based on these ideas you should contact the community members identified below to find out more about the idea, get to know the community member that will review your proposal, and receive feedback on your ideas.
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors. Ideally students will have submitted a patch or two to their project, [instructions are here] as they will have to soon after being accepted, but it is not a requirement for the proposal. VTK makes extensive use of mailing lists, and this would be your best point of initial contact to apply for any of the proposed projects. The mailing lists can be found on the project pages linked in the preceding paragraph. Please see GSoC proposal guidelines for further guidelines on writing your proposal.
Adding Ideas
When adding a new idea to this page, please try to include the following information:
- A brief explanation of the idea
- Expected results/feature additions
- Any prerequisites for working on the project
- Links to any further information, discussions, bug reports etc
- Any special mailing lists if not the standard mailing list for VTK
- Your name and email address for contact (if willing to mentor, or nominated mentor)
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.
Project Ideas
Project page, mailing lists, dashboard.
Templated Input Generator for VTK
Brief explanation: Build up an infrastructure that makes it straighforward to bring new scientific data formats into VTK. The infrastructure will handle the complexities of temporal support, parallel processing, composite data structures, ghost levels and the like, and provide easy to use entry points that bring data from the file or other source and populate VTK arrays.
Expected Results: A set of classes that can take an input specification and produce vtk data objects correctly and relatively efficiently. The input specification should be sufficiently abstracted from VTKs data types that users who understand the input format well won't have to understand VTK's complexities in order to use it.
Prerequisites: C++ and probably a scripting language such as Python or Lua.
References: http://www.paraview.org/Wiki/Writing_ParaView_Readers
Mentor(s): Robert Maynard (robert dot maynard at kitware dot com) and/or David DeMarle (dave dot demarle at kitware dot com)
Supporting Solid Model Geometry in VTK
Brief explanation: Traditionally VTK has addressed the visualization needs of post-processed simulation information. Typically in these cases a tessellated mesh represents the geometric domain. This project will extend VTK's role in the simulation lifecycle by investigating approaches that will enable VTK to visualize the parametric boundary representation information used in solid modeling kernels such as CGM and OpenCASCADE (http://www.opencascade.org), which is typical pre-processing description of the geometric domain.
Expected results: A VTK module that interfaces with one or more solid modeling kernels.
Prerequisites: Experience in C++, and data structures. Some experience in VTK, parametric surfaces and solid modeling kernels ideal but not necessary.
Mentor: Bob O'Bara (bob dot obara at kitware dot com).
KiwiViewer on VTK and Google Cardboard support
Brief explanation: KiwiViewer (http://www.kiwiviewer.org) is a model viewer for VTK datasets that runs on iOS and Android devices. It is built from a cross compiled version of an older release of VTK coupled with VES (http://www.vtk.org/Wiki/VES), a lightweight rendering library that runs on OpenGL ES. The most recent release of VTK supports iOS and Android directly, so bringing KiwiViewer up to date with full featured rendering would open up many visualization capabilities.
Once VTK has been updated on KiwiWiewer, Google Cardboard support could be added. Google provides a SDK to implement VR features in OpenGL applications for Android and iOS (https://developers.google.com/cardboard/unity/). It will be great to visualize scientific results in a VR environment.
Expected results: A new version of KiwiViewer.
Prerequisites: Experience developing for mobile platforms and C++.
Mentor: Tim Thirion (tim dot thirion at kitware dot com).
OpenFOAM Catalyst adaptor
Brief explanation: OpenFOAM (http://www.openfoam.org) is a premier open source Computational Fluid Dynamics (CFD) simulation package. ParaView/Catalyst (http://www.paraview.org/Wiki/ParaView/Catalyst/Overview) is a VTK based in-situ visualization framework that tightly couples visualization capabilities to arbitrary simulation code. Updates to the data import path between OpenFOAM and VTK would give extreme scalability to OpenFOAM because data products would never need to be written to disk. It would also facilitate live data and computational steering connections that let the scientist see new results while they are being generated.
Expected results: A Catalyst adaptor contributed to either the OpenFOAM or ParaView communities. Two feasible starting points to begin the work are the existing vtkOpenFOAM readers and and the vtkFOAM FOAM-to-VTK exporter.
Prerequisites: Experience developing in C++, experience with CFD.
Mentor: Andy Bauer (andy dot bauer at kitware dot com) and Takuya Oshima (oshima at eng dot niigata-u dot ac dot jp)
Direct mapped Polyhedral input cells from OpenFOAM
Brief explanation: OpenFOAM is an Open Source Computational Fluid Dynamics (CFD) package. OpenFOAM runs on unstructured meshes that are composed of polyhedral cells. Polyhedral support is now provided with VTK although this is not supported by all filters. The default option within the OpenFOAM reader is to decompose polyhedral cells into the other VTK primitive types. The OpenFOAM reader also lacks support for ghost cells when reading in parallel.
Expected results: An updated OpenFOAM reader with support for ghost cells when reading in parallel where the default output is a polyhedral cells. Test cases should be created for many of the common filters and polyhedral related bugs should be fixed.
Prerequisites: Experience developing in C++.
Mentor: Paul Edwards (paul dot m dot edwards at intel dot com)
Better Package management Support for Java and Python
Brief explanation: VTK has bindings to languages other than its native C++ but lacks strong integration with package management systems like Maven for Java and PIP for Python. As such every project written in those languages solves the problem of how to provide VTK's runtime libraries in their own way. Updating VTK's build system to be compatible with the standard resources for different languages will make VTK more approachable for large groups of users and simplify life for application developers.
For Java, the task will be to smooth out the bumps and complexity to run a VTK application inside a Java environment. The first step would be to embed within the VTK Java library a better native library loading mechanism similar to what was done with Jogl. Next we would provide prebuilt versions of VTK for the 3 major platforms and publish them on a public Maven repository. Similarly for Python we would extend VTK's Superbuild CMake infrastructure for making python executables to make libraries are suitable for distribution and installation via PIP.
Expected results: Automatic publication of pre-compiled VTK library across all platform (OS X, Windows, Linux) via Maven with an automated system library loading and deployment of the VTK library with its native counter part managed via pip install for usage within the system Python or a Python Virtual Environment.
Prerequisites: Experience with C++, Java and Python.
Mentor: Sebastien Jourdain (sebastien dot jourdain at kitware dot com)
VTK/ParaView integration into Jupyter / iPython notebooks
Brief explanation: VTK and ParaView are native scientific libraries used for data processing and visualization. Beeing Python Wrapped, VTK/ParaView can be used within any Python environment such as iPython notebooks. But currently nothing is done to ease interactive 3D visualization within an iPython notebooks. Relying on the VTK/ParaViewWeb stack, we want to enable it.
Expected results: Provide an integration path into iPython notebooks while enabeling a set of helper commands to start/stop/edit interactive visualization within a notebook either for VTK or ParaView or both.
Prerequisites: Experience with Python, VTK and Web.
Mentor: Sebastien Jourdain (sebastien dot jourdain at kitware dot com)
Half Baked Ideas
(contact Dave DeMarle if you would like to work on one of these or an idea of your own and I will find you a good mentor to work out a solid GSoC proposal with)
- make concave polydata "just work" (i.e. render correctly) with minimal impact on common case speed
- an add on framework to help VTK using applications keep track of units
- anything from vtk user voice http://vtk.uservoice.com/forums/31508-general, except documentation (unfortunately) since docs effort is explicitly ruled out of GSoC
- anything from paraview user voice http://paraview.uservoice.com/forums/11350-general
- lua wrapping, lua programmable filters
- advanced rendering algorithms with OpenGL2 back end - Ambient occlusion, Reflection, etc etc.
- interface to modern high quality rendering engines
- select point cloud workflow such as surface reconstruction, and fundamental algorithms for curvature estimation, etc.
- flying edges extended for other structured data types (structured grids, rectilinear grid) and also to structured clipping