Holodeck - 2
Project Holodeck
Created by Maksim Fridberg, Mark Tulewicz, and Wiktor Kopec on 04/28/04 for the Virtual Reality Undergraduate research Project Laboratories
(VRUPL)
Table of contents:
I. Introduction Page 3
II. Current Goals Page 4
III. Problem to be solved Page 5
IV. Work/Results Page 6
i. Project Hierarchy Page 7 - 8
ii. Utility Classes Page 9 - 10
iii. Packer / Converter Page 11 - 17
iv. Event Handling Classes Page 18 - 24
v. User Interface Classes Page 25 - 32
vi. Object Classes Page 33 - 34
vii. Model Page 35 - 37
viii. Manipulator Classes Page 38 - 41
ix. Holodeck Page 42 - 43
V. Analysis Page 44
VI. Conclusions Page 45
VII. Shortcomings/Recommendations Page 46
VIII. Future Goals Page 48
IX. Future Work Page 49
X. Bibliographic Information Page 50
XI. Acknowledgements Page 51
XII. Appendix A: File Format Specifications Page 52
XIII. Appendix B: UML Class Diagrams Page 53
I. Introduction:
The Holodeck, just like its Star Trek branded counterpart, is a virtual reconstruction of space. In the world of Star Trek, the Holodeck is a holographic environment simulator. Holograms, visual projections of 3D objects, are far from a consumer reality. When looking at consumer electronics, most computers have a graphics unit capable of rendering virtual worlds. These virtual worlds can depict a scene just like Star Trek’s holodeck was able to.
Throughout Star Trek’s lengthy run, the holodeck has been used numerous ways. These ways include: user-user interaction within a virtual environment, user-simulation interaction within a virtual environment, virtual recreations of scenes and locations, as well as virtually constructed simulations. For the fictional characters of Star Trek, the holodeck was a useful simulation tool. We believe that the idea behind the holodeck can be extended to the current state of technology in order to create a program bearing the same name.
It is the goal of our Holodeck to have the same function as the fictional one had with the simulations and interactions stated above. We believe that these have many present-day uses. Several include: teaching tools to aid instructors in the student learning process, communication tools to allow users to interact virtually, and planning tools to allow users to better organize spaces. Researchers have had access to powerful virtual reality tools and have used them to increase productivity. The goal of this project is to develop a tool that would do the same thing for consumers.
II. Current Goals
· To design a virtual reality system that is accessible and usable by consumers
· Develop a general system that gives users the ability to load, manipulate, and save objects in three-space
· Design open common file formats for scenes and models
· Create a conversion tool to allow for Alias Maya model exportation and conversion to the common model format
· Provide a framework which allows the converter tool to be extended to support other file formats
· Create a common simplified user interface for end users.
· Create an XML based file format to account for a web based database of objects
III. Problem to be solved
Outside of gaming, consumers have no access to virtual-reality programs. That is, a use for virtual-reality programs in consumers’ daily lives has yet to be developed. It is our belief that virtual reality programs should be more readily accessible and useful to these end users. Such programs can have several practical applications. A virtual environment can be used as a teaching tool, allowing teachers to show their students environments that cannot be presented in a conventional classroom setting. For instance, a physics teacher, instead of telling his class about a nuclear reactor can take his class on a guided tour of the protons and their interactions in the reactor itself. First-hand learning experiences, even if virtual, may be a more potent tool in teaching than just presentation.
A virtual environment may also be useful for designers. This can range from set design, space utilization, to interior decorating. This is particularly useful in a web-based setting where numerous users need to view the organization of a scene and provide active feedback.
In the long run, as the Holodeck program progresses, the program could be used as a modeling tool to represent complex data useful for consumers. For example, a user may wish to see all of his images on his or her computer in a three-dimensional gallery, browse through his or her email in three-space as a function of time, or listen to his or her music in a virtual concert hall.
IV. Work/Results
i. Project Hierarchy
ii. Utility Classes
iii. Packer / Converter
iv. Event Handling Classes
v. User Interface Classes
vi. Object Classes
vii. Model
viii. Manipulator Classes
ix. Holodeck
i. Project Hierarchy
Hashtable
List
List::Iterator
List::ConstIterator
Vector
String
Math: By Maksim Fridberg, Wiktor Kopec, and Mark Tulewicz
MVector3
WMath
Packer: By Maksim Fridberg and Wiktor Kopec
mainForm
Log
Converter: By Wiktor Kopec
Converter
Win32: By Wiktor Kopec
Console
Controller
Display
Time
Delegate
++KeyDelegate
++GloveDelegate
++DirectDelegate
++++KeyboardDelegate
++++MouseDelegate
UI3D: By Maksim Fridberg and Mark Tulewicz
Button3d
Cursor3d
ListBox3d
Window3d
Menu
MenuBar
Slider3d
TextBox3d
UserInterface
Objects: By Maksim Fridberg, Wiktor Kopec, and Mark Tulewicz
Model
Texturizer
Object
++DisplayableObject
ModelManipulator
Holodeck: By Maksim Fridberg, Wiktor Kopec and Mark Tulewicz
InputHandler
View
++ denotes one level of inheritance from the class above.
ii. Utility Classes
ADT Overview:
The adt module of this program is a collection of general-purpose classes that are designed to supersede some of the standard template library classes. Included classes are String, Hashtable, Vector, and List. There is also a utility function for splitting strings.
The primary motivation for these collection classes is to provide greater specialization to suit the needs of this program. Also, the STL classes were slower in most cases involving creation, traversal, or addition of elements in a collection. The STL classes are very general which would probably account for this (although deletion is drastically faster in the STL classes; the reliability of these tests however is not very high since the results may change greatly under different optimization levels and usage scenarios). One of the main reasons for creating a new Vector class was to replace the STL’s implementation with an indexible array as opposed to a linked list. STL’s implementation makes access time much slower than a dynamic array, but resize-time much faster. Since fast access time is preferred when traversing extremely large collections of vertices or other data, STL’s vector was not very suitable. Detailed documentation for these classes is not provided since they parallel STL very closely. For details on the String class, see the HTML Code Comment Report.
Math Overview:
The math module consists of two classes, WMath and MVector3. The latter is a class that represents a vector or a point in three-space. It provides the necessary mathematical operations to manipulate vectors, such as the dot product, cross-product, and rotation code. WMath consists of helper functions which are designed for doing mathematical calculations in a minimal amount of time. See the Code Comment Report for details on these functions.
iii. Packer / Converter
Packer Overview:
The packer module of the Holodeck project is used to convert Maya objects to the 3dbin
file format (for a detailed specification of this format, see Appendix A). The Packer is written in CSharp, and therefore requires the .Net Framework to be executed.
Packer Usage:
The following is an example step-by-step exportation of a Maya Binary file using the current state of the converter. The packer UI is overdeveloped, and under functioned therefore certain UI elements have no current function but are in place, for when the function gets added.
/ After a model is created, properly triangulated, and in this case saved in *.ma or *.mb format. The user can load the packer program and specify the path and project name in the global settings of the project about to be created./ The user then specifies the filename of the low, medium, or high quality model. The user may then specify a folder to look in, for a preview icon of the object loading. This will most likely be a rendering of the object.
/ The user may then set the attributes of the model by clicking on the attributes tab where the user may choose the object name, its author, and add comments to it. In the section below the user may set the dynamics, physics, or scripts associated with an object.
/ Once the attributes are set, the user moves into the final conversion tab in which he picks the converting application. The program will then display the command to be run at the command line level (although actually through C#’s process launching).
/ The User may then complete the final step and generate to the project path the necessary documents. The program appears to hang while it launches a new process.
/ Upon completion, a message box informs the user of the conversion’s success and returns.
/ The final tab contains information vital to the project.
Packer Implementation:
The Packer, after collecting all relevant information from the user through its user interface, generates a header for a new object file. The header is written by the GenerateHeader method, which begins the 3dbin file. After the header is written, the Packer invokes the selected converter, passing in the correct arguments. Currently there is only one supported converter, which converts Alias Maya models to 3dbin. It is the converter’s responsibility to perform two tasks:
1) Append all vertex, texture, color, and normal data, in conformance to the 3dbin standard. See Appendix A for a detailed description of this standard.
2) Create an ASCII texture file list which enumerates all the textures.
After the converter successfully finishes, the Packer opens the texture files listed in the ASCII texture listing and appends the actual texture data to the 3dbin file. CSharp supports a variety of texture formats, and after opening a texture file it converts all the texture information to standardized RGBA texels, which can be easily interpreted by the Holodeck program.
The packer, along with the converter, also generates an x3dml file, (using the GenerateX3dml function) which is an ASCII version of the object information. This file is meant for reference purposes.
Packer Limitations:
While the Packer supports multiple levels of detail, it is currently not a feature supported by the Holodeck. The Packer, however, will generate additional information for all three levels of detail, if specified. It is important that texture sizes be a multiple of 2n, where n is some nonnegative integer. This is a constriction of OpenGL, and cannot be changed.
Since the 3dbin file is interpreted in binary, the byte ordering of the system (little endian vs. big endian) will impact how the data is interpreted. The current converter will only work on fully triangulated polygon meshes with file based textures.
Converter Overview:
The Converter class is designed to convert Maya model files into 3dbin files. It uses the Maya API, provided by Alias, which facilitates the traversal of Maya files, and the extraction of relevant model data.
Converter Usage:
The Converter class is actually compiled into another executable which is launched by the packer. This executable takes very specific arguments that instruct the Converter class as to what it should be converting. The arguments are as follows:
-lMayaFileLo [-mMayaFileMed] [-hMayaFileHi] -dOutputDir -oProjectName
Where MayaFileLo is the low level of detail file, MayaFileMed is the medium level of detail file, and MayaFileHi is the high level of detail file, OutputDir is the output directory for the 3dbin file, and ProjectName is the name of the final 3dbin output file.
Converter Implementation:
The Converter is implemented by using the Maya API to traverse the Directed Acyclical Graph to gather the required information about the scene. The data gathered includes vertex information, UV-coordinate information, normals, and color information. The converter opens the file passed to it in append mode, anticipating that the file already has an existing header written by the packer. More details on the Converter can be obtained in the HTML Code Comment Report, and Maya API documentation.
Converter Limitations:
The converter currently supports only polygon-based triangulated meshes. The textures must also be file textures, and there are difficulties when the textures are converted from shaders other than Lambert.
iv. Event Handling Classes
Controller Overview:
The Controller class is used to handle events that occur between the user and the system. This typically includes mouse movement, keyboard input, as well as input from specialized hardware. Currently, there is support for only one controller.
Controller Usage:
The Controller class is a template class. Instead of extending the controller class or modifying it directly, events are handled by a user-specified, user-defined class that’s passed in as a template argument. Controller cannot be instantiated, which means all of its functions are static. The user must pass the class that is to handle events on every function call as the template argument.
The controller is responsible for creating the Window handle, which means it is one of the first classes to be initialized. This is done through the Init function (See the Code Comment Report for details). After initialization, the desired event handlers must be registered with the Controller. This is done through the AddHandler function call. The handler takes a Delegate as a parameter. For a discussion on Delegates see the Delegate Technical Specification.
After the desired event handlers are registered with the system, a message loop must be created. A message loop is essentially a sentinel controlled loop that continues to execute until the process quits. Below is a typical example of a message loop:
The MSG structure is actually a Win32 API structure designed to handle user messages. The controller calls PeekMessage, which returns true assuming a message exists on the message queue. Otherwise it returns false. TranslateMessage and DispatchMessage are Win32 API calls used to send the message to the windows procedure. See Implementation for details.