VTK/ARB Notes/May 2014: Difference between revisions
(Created page with "'''May 6, 2014'''") |
No edit summary |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
'''May 6, 2014''' | '''May 6, 2014''' | ||
Discussed the NIH VTK Maintenance Grant. Reviewed in detail Aims 1, 2, 3. which is the focus of the work. | |||
* Will provided overview. | |||
* Ken provided more details about rendering work (Aim 1). Basically now we are retaining the current architecture and rewriting the innards with modern OpenGL practices (relying on shaders, ditching the fixed pipeline approach). Once this preliminary work is done we will consider whether issues like scene graph, many actors, etc. need to be addressed. In which case we may have to build a new subsystem (TBD). | |||
* Berk discussed the AMR composite dataset for handling hierarchical volume representation, processing, and rendering. (Part of the large data Aim 1 work.) | |||
* Will discussed Aim 2 (community) and requested feedback from the ARB to assist Dave DeMarle and Chris Mullins in their work. | |||
* We briefly touched on Aim 3 and the interface with our five medical application subcontractors. As an FYI Steve P, and Bill L. were quite pleased at how well VTK6 ported to Slicer, kudos to JC and J2. | |||
Some suggestions in random order during the discussion: | |||
* Carrying coordinate transform information through the pipeline is important. This is necessary for imaging (Bill, Steve), and for assembly transformations (Stephane). The basic metadata representation is probably easy to do; the concern is for data processing and rendering. It may be a simple approach works well, and relying on ITK for more advanced medical computing may make sense (meaning improving our interfaces to VTK <-> ITK so data can flow more easily). | |||
* During the rendering rework need to make sure that support for efficient parallel rendering is maintained (Ken M., David R. expressed this concern). | |||
* Volume rendering label maps is an important requirement (Bill, Steve) | |||
* There was concern about proper support for large polydata rendering. Meaning culling mostly, although LOD and other techniques were discussed. (Stephane) | |||
* We are planning on improving VTK's support for higher-quality rendering; e.g., shadows, reflections, etc. | |||
The plan is to hold the next ARB meeting in about a month (early June). Will will set up a Doodle poll. Also next time we will invite individuals to the hangout separately to avoid permission issues with Google Hangout. | |||
We had a follow on conversation related to "correctness" of marching cubes. Silva et al. have reported some issues with marching cubes, which are not bugs but really just due to a 30-yr old algorithm (which may not be as advanced as current algorithms). There was also discussion on the way to respond to this information in terms of community outreach, etc. |
Latest revision as of 20:52, 7 May 2014
May 6, 2014
Discussed the NIH VTK Maintenance Grant. Reviewed in detail Aims 1, 2, 3. which is the focus of the work.
- Will provided overview.
- Ken provided more details about rendering work (Aim 1). Basically now we are retaining the current architecture and rewriting the innards with modern OpenGL practices (relying on shaders, ditching the fixed pipeline approach). Once this preliminary work is done we will consider whether issues like scene graph, many actors, etc. need to be addressed. In which case we may have to build a new subsystem (TBD).
- Berk discussed the AMR composite dataset for handling hierarchical volume representation, processing, and rendering. (Part of the large data Aim 1 work.)
- Will discussed Aim 2 (community) and requested feedback from the ARB to assist Dave DeMarle and Chris Mullins in their work.
- We briefly touched on Aim 3 and the interface with our five medical application subcontractors. As an FYI Steve P, and Bill L. were quite pleased at how well VTK6 ported to Slicer, kudos to JC and J2.
Some suggestions in random order during the discussion:
- Carrying coordinate transform information through the pipeline is important. This is necessary for imaging (Bill, Steve), and for assembly transformations (Stephane). The basic metadata representation is probably easy to do; the concern is for data processing and rendering. It may be a simple approach works well, and relying on ITK for more advanced medical computing may make sense (meaning improving our interfaces to VTK <-> ITK so data can flow more easily).
- During the rendering rework need to make sure that support for efficient parallel rendering is maintained (Ken M., David R. expressed this concern).
- Volume rendering label maps is an important requirement (Bill, Steve)
- There was concern about proper support for large polydata rendering. Meaning culling mostly, although LOD and other techniques were discussed. (Stephane)
- We are planning on improving VTK's support for higher-quality rendering; e.g., shadows, reflections, etc.
The plan is to hold the next ARB meeting in about a month (early June). Will will set up a Doodle poll. Also next time we will invite individuals to the hangout separately to avoid permission issues with Google Hangout.
We had a follow on conversation related to "correctness" of marching cubes. Silva et al. have reported some issues with marching cubes, which are not bugs but really just due to a 30-yr old algorithm (which may not be as advanced as current algorithms). There was also discussion on the way to respond to this information in terms of community outreach, etc.