SWIFT++ Future Versions |
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.
Exact Penetration Depth in a Given Direction
|
There exists a pretty efficient computational geometry algorithm to determine what the penetration depth in a given direction is for a pair of convex polyhedra. However, it might be inefficient to do this for non-convex polyhedra.
Approximate Minimum Penetration Depth over all Directions
|
The computation of exact penetration depth (over all directions) is an O(n^6) problem for a pair of non-convex polyhedra. It may be possible to make various approximations in order to be able to compute a minimum penetration direction and depth feasibly.
Dynamic Bounding Box Choosing
|
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.
Articulated Bodies
|
Allow a scene graph representation for multiple piece objects. In addition, have the option of detecting self-collision or not.
Improved API
|
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.