Switching from VTK to JOGL

Need to implement: 

  • trackball tumbling, zoom, translation, etc. 
  • bounding boxes 
  • dragging objects
  • save to AVI
  • switches for different shading modes, and show/hide objects
  • changing color, transparency
    • need back to front draw order for transparency
  • wireframe, flat shaded, smooth shaded
  • picking
  • reading in and displaying bones (need to triangulate them?)
    • should we change format?
  • model offset
  • are there any threading issues with JOGL??

Running JOGL examples

  • set PATH to include the jogl-1.1.0-windows-i586/lib directory, and run:
    java -classpath ".;./jogl-demos-data.jar;./jogl-demos-util.jar;./jogl-demos.jar;jogl-1.1.0-windows-i586/lib/jogl.jar;jogl-1.1.0-windows-i586/lib/gluegen-rt.jar" demos.gears.Gears

Repainting with VTK in Java

  • ViewDB.getInstance().repaintAll() schedules a repaint for later, while ViewDB.getInstance().renderAll() renders immediately. The former tends to not refresh the view often enough (e.g. during the dragging of a muscle point, lots of other events saturate the queue so repaint barely happens). The latter seems better in those cases.
    • Not sure if the latter will work if use JOGL instead.
    • From this page:
      A component never calls its update() method directly. Instead, when a component requires redrawing, it schedules a call to update() by invoking repaint(). The repaint() method asks AWT to schedule the component for repainting. At some point in the future, a call to update() occurs. AWT is allowed to manage these requests in whatever way is most efficient. If there are too many requests to handle, or if there are multiple requests for the same component, AWT can reschedule a number of repaint requests into a single call to update(). This means that you can't predict exactly when update() will be called in response to a repaint(); all you can expect is that it happens at least once, after you request it.

Problems with VTK

Java3D information