Known Problems

  1. The default values for the "min" and "max" entryfields in the Motion View are 1 and 100 respectively. These are not stored as part of the GUI state in source files, so you must manually set them again whenever you load a source file.
  2. The "progress" indicator in the Motion View grows in proportion to the difference between "min" and "max". This appears to be a problem with the underlying Megawidget.
  3. In the Motion View, an attempt to "Revisit" a frame that has not been fixed results in errors that are not informative. This button is actually redundant as the "<<" and ">>" buttons provide the functionality.
  4. Currently, TSIPP is only available statically linked into wish (tksipp) or tclsh (tsipp). The complicates the distribution process, and means that users cannot incorporate the widgets they have created into their programs without changing their interpreter.
  5. With tksipp, unlike wish, if the window manager exit button is used then the program does not exit cleanly but generates a core dump and the message:
    1.  
      called Tcl_FindHashEntry on deleted table
      Aborted (core dumped)
    TSIPPwb does not provide an exit button, so this is unavoidable.
  6. Applications requiring random access to frames rather than playing them in sequence will experience delays in selecting frames as the RLE file must be read to that frame either from the current position if this is earlier, or otherwise from the beginning of the file. This is accelerated as much as possible by copying the unwanted frames to /dev/null. However, an RLEseek command is wanted here.
  7. Tcl expressions should be bracketed where possible. This has not been done.
  8. An application cannot find out the number of frames in an RLE file. RLE files support comments which could be used for this.
  9. Saving an image as a PBM file requires that it be rendered again, even if it is visible on the screen. This is unnecessary as the rendered image can be kept in a pixmap. However, this was made more complicated due to the solution implemented for another problem. It was found that a rendering line image to a pixmap resulted in a core dump, so these are rendered to the RLE file and the Perspective View canvas separately, and not to a pixmap.
  10. TSIPP uses the terms "Block" and "Ellipsoid", while TSIPPwb uses the terms "Cuboid" and "Ellipsoid". Since TSIPPwb users are intended to have visibility of TSIPP documentation, and may well wish to access TSIPP directly as well as through TSIPPwb, consistency is desirable.
  11. When items are selected in the orthogonal views, they are automatically selected in the Shader/Light view, but not vice-versa. Therefore the selections can be made inconsistent by changing it in the Shader/Light view last, which is a confusing state.
  12. Cylinders can be edited so that they have different dimensions in the axes orthogonal to the axis, which should not be possible.  The mean of the two dimensions is actually used as the diameter of the rendered result.
  13. The representation of cylinders in the Orthogonal views gives no indication of which direction is the axis.

Planned Future Enhancements

  1. Reduce the footprint of the GUI by collapsing many of the views into a "tabbed notebook", or exporting them as separate "top levels" which can be managed by the window manager. This will support low resolution monitors and individual views to be larger.
  2. Greater integration with the GIMP; possibly making it a GIMP plug in.
  3. Add context-sensitive on-line (balloon) help.
  4. It is planned to make the MultiView, VisualEdit, MotionEdit and GlobalEdit widgets true MegaWidgets, and to further increase their independence and usability for other applications than TSIPPwb.
  5. Make all TSIPP features available. Features not yet available include the grouping of objects together into hierarchies, directional lights, aborting rendering operations, showBackFaces, Prisms, Torus, Bezier Curves, Texture Mapping options, multiple cameras, SippLineColor, global scaling so that the planet shader is useful.
  6. Need higher speed playback, exploiting graphics hardware, or 'C' implementation of the display of the RLE files.
  7. Need to be able to find the position of objects in the rendered image, so that text can be attached to objects, to embed widgets in the image, so that interactive widget behavior, rather than just display is possible.
  8. Divergence handles to be visually differentiated from vertex handles.
  9. Some code could be implemented in 'C', for example the rotation and handle motion routines, to make the interactive response snappier.
  10. Implement side handles (one-dimensional motion) on the mid-point of sides.
  11. Shaders and lights should have a textual tag as an alternative to their object names shown in the listbox of the Shader/Light view.