View source for Kitware Scene Graph Meeting April 6, 2010 KHQ

=== Kitware Scene Graph Meeting April 6, 2010 KHQ ===

1. Presentation by Michel of slides briefly describing JHU and existing Kitware requirements for KWScene. 
[https://docs.google.com/a/kitware.com/present/edit?id=0AZZGdYgzhGhJZHNiZDQ3OF85MGduMmhibWRt&hl=en]

2. Description by Julien Finet at KRS of requirements for ParaView for transforms, which led to a description by Luis of transforms in KWScene. The possibility of reusing the IGSTK spatial relationships model, where every object is connected to a parent was evoked. IGSTK uses rigid transforms, which could be expanded here. He presented two potentially conflictint use-cases, namely a large collection of small objects, such as the Computer Vision group's requirement, or a small collection of large objects, as is the case for JHU.

3. Amitha presented a Computer Vision group usecase in more detail, which would involve a reprojection on a 3D space onto where an image came from on the ground. Also a possibility of affixing avatars to 3D space. A rapid refresh rate, 30 Hz, would be needed. 

4. Berk boiled down the Scene graph use-cases to two: i) representation of a hierarchy of objects, and ii) input/output of that hierarchy. He suggested that the Scene graph should not compete with VTK. It was later pointed that VTK flattens the representation, and that KWScene would bring something complementary. Berk's use-case involved multi-block rendering, featuring block-wise differences in color, opacity, and so on. 

5. Aashish indicated that a requirement of his is to make the scene graph fast, in cases where the scene data does not change (often). 

6. Will listed 4 requirements of the Scene Graph: i) representation, ii) rendering, iii) attributes, and iv) association with annotation (e.g. labeled anatomical atlas).

7. The discussion moved to space-time representation. It was suggested that one efficiency that would be useful is the iterative estimation of the tree at time T_N on the basis of that tree at time T_N-1. Will also alluded to piecewise-linear paths featuring time, in the context of a previous project: Visual Journal, in which Rusty was also involved. (It would be useful to describe this project in the wiki, and its relevance to KWScene...)

8. Use-cases by other groups were fleshed out somewhat... Utkarsh indicated that Paraview requirements would be of an intermediate layer that manages the visualization. 

9. The possible adoption of a proprietary file format for KWScene was suggested by Will, in part because of this time component in the information. The Visual Journal project also had a file format.

10. Bob stressed the need for a formalism of what flows through the tree. His application for KWScene emphasized Computational Model Building. He indicated that a lot of responsibility may fall on the generator. 

11. The discussion turned to funding. We should described how much is JHU funding. Other potential clients of the scene graph, whose use-cases were described above, would apply for funding as well.

12. During the discussion all agreed that we need to investigate more on this using two approaches. 1) KWScene becomes true SG 2). KWScene uses third party SG libraries such as OpenSG or OpenSceneGraph.