SWIFT can be extended and added to in numerous ways. Likely, not all will be feasible or possible but future versions will hopefully comprise some. We are always looking for ways to improve SWIFT. If you have any ideas of things we could add to the system that we have not mentioned here or in the Features in Detail section, please let us know.
To use non-convex polyhedral models, check out
SWIFT++.
There exists a pretty efficient computational geometry algorithm to determine what the penetration depth in a given direction is.
The computation of exact penetration depth (over all directions) is a quadratic problem. Various approximations can be made to make a minimum penetration depth query feasible.
To improve performance, it is desirable to create a hierarchy of convex pieces of a non-convex object using a convex hull to bound the geometry in each subtree. Deviations could then be computed which would allow for faster query. Instead of making the application specify exactly what this hierarchy is, it would be desirable to make it an automatic thing given the decomposition.
It may be possible to choose the bounding box type dynamically. Even if the extremal feature of an object never changes, the dynamic bounding box type must still do a considerable amount of work to update itself compared to the cube bounding box type. If the type could be determined at each frame, substantial savings may be procured. There is still the problem of reinitializing the dynamic box when it is needed. Another area of interest is applying a bound on the orientation change required to update the box' extremal vertices.
Allow a scene graph representation for multiple piece objects. In addition, have the option of detecting self-collision or not.
Currently transformations are set by giving a list of rotations along with a list of translations. Some applications may benefit from not having to copy to and from arrays at each query. If a state vector is maintained which describes the motion of all the objects, no conversion should be required. There can be a rotation field, a translation field, and finally an ignored field for any other variables that may be in the application's state vector.
Alternatively, the application may provide a list of pointers to its motion data. This could be precomputed then linked in before query time or set during query time.
Applications may have use of different combinations of query patterns or optimizations. It is desirable to provide such functionality. If the given query functions do not fit the application's needs in terms of optimization, please send us a description of the application, and the functionality that is desired.
Quaternions are preferable to rotation matrices when describing orientations. Support for this type of data would seem to be useful.
Allow transformations similar to a scene graph which could be composed at runtime to allow for less geometry replication if multiple pieces use the same geometry.
Author: Stephen Ehmann
Maintained by: ehmann@cs.unc.edu
Copyright 2000
Last Modification: Aug 15, 2001