Known Problems
-
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.
-
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.
-
If you attempt to edit in the Shader/Light View with no item selected,
errors are generated which are not informative. Fixed
in 1.3. When no item is selected, the ColorDial, and other entry widgets
are put into a disabled state.
-
If you select the StdCamera0 in the Shader/Light View then errors result.
The underlying problem is the class structure. StdCamera is treated as
a Shader/Light so that it can take advantage of the same "DirectedTriangle"
representation in the MultiView widget as the SpotLight. However, StdCamera
cannot be edited meaningfully in the Shader/Light view, while the SpotLight
can. Fixed in 1.3. Components are responsible for
adding themselves to the listbox from their constructors, and removing
themselves from their destructors. StdCamera never puts itself in the listbox.
-
Rotating objects in the Plan or Side Views may not actually result in rotation
in the Perspective View if no rotation has been performed in the Front
View. If this happens, then as a workaround, rotate the component in the
Front View and then rotate back. Suspected problem is integer division
occurring where floating point is required.
-
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.
-
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.
-
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:
called Tcl_FindHashEntry on deleted table
Aborted (core dumped)
TSIPPwb does not provide an exit button, so this is unavoidable.
-
Error vectors are loaded from source files with commands that contain hard-coded
pathnames to the canvas widgets inside the MultiView widget .v. This would
prevent the files being sourced by a MultiView widget with a different
pathname.
-
Motion interpolation produces strange results - see the weatherVane example.
It is believed that the problem is that when TSIPPwb decides on the angle
by which an object should be rotated using the command SippObjectRotate,
the value returned is modulo-(2 * pi). If wraparound occurs between two
adjacent points, then the object adds an extra revolution, in the opposite
direction, into its traversal between them.
-
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.
-
Tcl expressions should be bracketed where possible. This has not been done.
-
An application cannot find out the number of frames in an RLE file. RLE
files support comments which could be used for this.
-
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.
-
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.
-
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.
-
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.
-
The representation of cylinders in the Orthogonal views gives no indication
of which direction is the axis.
Planned Future Enhancements
-
Add balloon help.
-
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.
-
Make all TSIPP features available. Features not yet available include the
grouping of objects together into hierarchies, directional lights, aborting
rendering operations, showBackFaces, Prisms, Cones, Torus, Bezier Curves,
Bumpy Shader, Texture Mapping options, control of the number of polygons
used for curved surfaces, multiple cameras, SippLineColor, global scaling
so that the planet shader is useful.
-
Need higher speed playback, exploiting graphics hardware, or 'C' implementation
of the display of the RLE files.
-
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.
-
Divergence handles to be visually differentiated from vertex handles.
-
Some code could be implemented in 'C', for example the rotation and handle
motion routines, to make the interactive response snappier.
-
Implement side handles (one-dimensional motion) on the mid-point of sides.
-
Need to be able to generate images of different sizes.
-
Need to be able to zoom in and out in the orthogonal views.
-
Shaders and lights should have a textual tag as an alternative to their
object names shown in the listbox of the Shader/Light view.