To-Do List for the Dynamic Scene Generator

There are plenty of tasks that still need to be done to make the DSG everything we want it to be. Here's a list of the ones that come to mind.

Known Bugs

• Disappearing scenes. When playing with the DSG, occasionally a scene that has models in it will go completely black. This often happens when you zoom in or when you look at a particular structure. Why? It seems that the camera's "diameter" parameter, which controls the front and back clipping planes, gets set too small and then clips everything out of the scene.

  One way to fix this with the "look at" function is to remember the diameter before calling :frame-things on the object of interest, and then restore the diameter value after the call. I'm not sure how to deal with the zooming in case.

• OBJ model problems. The OBJ models generated by Shawn's bodygen program have a couple of problems as far as Skandha is concerned. First, facet vertices are listed in clockwise order instead of counter-clockwise. Since the convention for Skandha (and for OBJ files in general) is counter-clockwise ordering, the normals that Skandha generates for these surfaces will be reversed.

  Second, each point on the surface gets listed twice---once for the ribbon above it, once for the ribbon below. This makes it more difficult to compute point normals for the surface. When loading OBJ files, I included a call to xvol-merge-redundant-points to deal with this, but it would be better dealt with when the OBJ file is generated.

  If you want to experiment with an OBJ model, I have set up a "lung-demo" model set. (See modeldb.lsp, corr-lung-demo.lsp, and ~hinshaw/work/3d-formats/rlung.obj for details.)

Feature Wish List

• Connect to the new FMA server. Peter Mork and JJ are working on a new FMA server, which will connect to the current Protege knowledge base instead of the very old and out-of-date one it currently uses. Once they have it working, we want to change the DSG server to use it. The Lisp-like query syntax will be identical. However, the representation of some knowledge has changed (e.g. part-of relationships have gotten more complex). Some DSG code will need to change as a result.

• Unify term-server.lsp with xfms.lsp. There are two different pieces of skandha code that connect to the FMA server: xdada/lsp/term-server.lsp and xscanner/lsp/xfms.lsp. There a couple neat tricks in xfms.lsp that should be merged in with term-server.lsp, in particular the xfms-define-wrappers function.

• Switch to PNG images. Have the DSG generate PNG images instead of TIFF images. This would avoid the buggy TIFF problems we have, and would also bypass the current TIFF-to-JPG conversion step.

• Add brain models. As soon as the DSG is talking to the new FMA server, it will be able to access knowledge about brain anatomy. A set of primitives and the list of correspondences are available in /usr/local/data1/brain/Cadaver/primitives. You'll need to copy correspondences.txt into the xdada module's lisp directory, and edit it to match the current file format, which lists structure name on one line, followed by the model name on the next.

• Make a real 3D model database. The current "model database" is just the set of correspondence files that link an FMA concept name with its 3D model. This information should be in a true database.

• Read/write better scene description files. We are thinking of using X3D as our default scene description language. This is the next generation of VRML, but using XML to describe 3D scenes. This means we'll need Skandha code that can import and export X3D format. Code for XML import/export might be a useful first step in this direction.

• Create better clients. The forms-based client is difficult to extend and maintain because of the difficulty of maintaining state between web clicks. Alternatives for new clients include:
  • Java applet clients. Bruce Campbell created the start of a Graphics Server Componentization (GSC) project, which implements an interface builder kit, in which widgets can be associated with each dsg Lisp command, and dragged onto a canvas to create a custom application. A description of this can be found from Bruce's SIG home page. Click on the Graphics Server Componentization Project link. The source code is checked into CVS as src/scenes/GSC.
  • 3-D client-side viewers. Eventually we will want to allow rendering on the client side in order to permit rapid user interaction. In this case we will want the dsg to simply generate a scene description as note above. Then a client program could read in the scene and permit user action. Current efforts in this direction include a C-based viewer being developed by Shawn Bonham, and explorations of the feasibility of Java3D, which now has hardware acceleration.

Return to the DSG project page.