Software architecture for a Virtual Environment for Nano Scale Assembly

Journal of Research of the National Institute of Standards and Technology, March-April, 2004 by Yong-Gu Lee, Kevin W. Lyons, Shaw C. Feng

[FIGURE 11A OMITTED]

[FIGURE 11B OMITTED]

[FIGURE 11C OMITTED]

Since all the platforms supported OpenGL, the OutputManager generates all the graphics scenes optimally suited to OpenGL with codes that depend on OpenGL. This deviated from the philosophy of not depending on external toolkits. But since all graphics devices were based on OpenGL, it was not justifiable to define a new neutral graphics scene descriptor and have the output devices convert it to OpenGL primitives. However neutral data was used for the audio and haptics. Obviously they were much simpler to define than graphics.

This paper does not discuss using toolkits that provide advanced algorithms needed for VE, such as collision detection. These advanced toolkits differentiate themselves from the functions of the VE toolkits that are utilized in VENSA that are mostly device interfaces and device state propagation. These advanced toolkits require direct links to the application objects and sometimes may require some change in the application data structure. Certainly, combining the application program with these toolkits can destroy the modularity. The quick solution that we have implemented is to duplicate the application objects. One is used internally and the other is used for the specific advanced toolkits.

The application objects and input and output device objects are all static in VENSA. Dynamic object creation and destruction are not provided. For VENSA to be a dynamic environment, this functionality is essential. Note in cluster computers environment, all distributed applications must work coherently and must allocate or free objects as necessary.

4. Conclusion

Software reuse is important as it saves time and costs. By effectively reusing existing components, more effort can be put into problem solving. There exists a plethora of toolkits for VE today. However, no single toolkit could satisfy the needs of the application described in this paper. Multiple toolkits were needed to satisfy the needs. It is desired and beneficial to selectively choose certain features from a toolkit without the constraints associated with its framework. This is generally not possible as most toolkits are provided as part of a framework, which makes it very difficult, or impossible, to isolate a feature. Another approach is to use multiple toolkits together. However, using multiple toolkits requires that application code contain multiple interfacing codes to the toolkits, hence further complicating the modularity. Some toolkits are more problematic as they contain their own control loop and never return to the caller. The architecture of VENSA is designed such that it can incorporate existing VE toolkits without interfering with the application program code. Although VENSA runs on three VE toolkits, the VENSA classes show no dependence to on any of the toolkits. Any existing toolkits can be substituted for other toolkits without requiring the rewrite of the application code.

Accepted: March 17, 2004

Available online: http://www.nist.gov/jres