Creating multiple Levels of Detail for Molecular surfaces

Goals: 

    Ultimately, the goal of this part of the project was to create a continuous, or dynamic, level of detail (LOD) control for generated surfaces. As an object in a scene moves farther away from the viewpoint, smaller details in an object become insignificant. As a result of this, only the larger details of images are needed as it moves farther away from the viewpoint. This result is also similar to human vision. If a car is very far away, we could recognize it solely by its shape, and not fine details such as the license plate or words on the car. In computing, we would like to mimic this ability so that when details of objects are less significant, the level of detail changes so that it is simpler to compute. Furthermore, this will not detract from the computation of larger or more significant objects.

Tools and Resources: 

    A few tools and resources were available to work from, but I mainly used one too to construct the structures.  

    QSlim - This is a program developed by Dr. Michael Garland at The University of Illinois Urbana-Champagne. It takes as a triangular mesh and returns a simplified mesh with a specified number of triangles.  

    DAG-based multi-resolution libraries - This is a library used to create and work with the DAG structure for dynamic LOD computation. 

    t-dag viewer - A Java package that uses the T-DAG structure to perform dynamic LOD. 

    OpenGL Performer manuals - This resource was used to help understand how to read and write performer code for perfly. 

Procedure: 

    This part of the project was split into two parts. All the extra programs and scripts used in the procedure can be found in my CS395T directory. 

Part 1: Creating a discrete LOD model

1. Obtain input files from which to create a discrete number of LODs for a given model.       

    Being the 4th step in the chain to complete this project, I had to be prepared to receive files to generate models from. 

2. Convert the model into a format that QSlim can read and use it to generate simplified surfaces

    QSlim only allows inputs in the SMF format. This format, short for Simple Model Format, was created by Dr. Garland specifically for use in QSlim. Since this is the only supported graphic file type, it was necessary to convert all the other forms into this one. Specifically, A utility to convert from an IV file to an SMF file was created. In great detail, first the program ivcon was run to convert the iv files into smf files, and then QSlim was run 7 times per model, to generate all the levels of detail.

3. Link together with the LOD node

    Both VRML and IV support an LOD node. In more detail, this was done by running the genLOD program, which simply takes in a file and generates an iv file with an LOD node combining all the models associated with it. This node works by keeping a reference to a sequence of files and a range, an array of values. Performer works by keeping a graph structure to determine visibility. Each node in this graph represents some object that is assumed to be bound by some volume. Each node can also have a set of children which contain the actual geometry. The LOD node works by referring to a different child in the geometry based on the distance to that bounding volume from the viewpoint. If this distance is strictly between two consecutive elements in the range, n and n+1, then Performer chooses the (n+1)th child to display. (ie. if array[n] < distance of object < array[n+1], then Performer displays the (n+1)th child. If the distance straddles some value in the range, then it merges the two geometries associated with each side of the range. Due to the nature of this node, nothing restricts it to being used for discrete LOD. Therefore, it could also be used to completely switch out independent elements based on some distance. 

Part 2: Creating a dynamic LOD model

1. Obtain input file from which to create a visibility graph for a given model.

    Like in Part 1, it is necessary to obtain input files for use.

2. Alter perfly to allow support the DAG structure and read into it

    At this point in time, perfly does not have any type of extension that supports use of a DAG structure for multi-resolution. It would first be necessary to alter the source code to first support this structure. As a preliminary to this step, the code of both perfly itself and the java t-dag viewer was studied to get ideas on how to implement this. The best way would be enable some sort of TDAG node in an input file, but this would require a lot of extra work. The other solution was to make the TDAG the native structure perfly would use to store geometry. Once these changes are made, one would only need to input a standard file that perfly supports and it would do the dynamic LOD. 

Results:

    On the other hand, Part 1 was completed for many models. All the necessary files for using discrete LOD in conjunction with an animated secondary structure of a protein were created. In all, for each of the 103 time steps seven levels of detail were created along with one file to link them all together. Thus, 824 iv files were generated to work with this part. Also, some LOD files were setup for some of the isosurface meshes generated. 

   Due mainly to time restraints, all of Part 2 was not able to be completed. Some ideas got put in place, but no concrete work was completed.

Examples:

The Secondary structure of 1ACC with about 21000 triangles

Same as above, but with about 15000 triangles about 75% of the original

Even though the second image has about 6000 less triangles, it still closely resembles the above image. This trend holds try for all the simplified surfaces.

Lessons learned:

Many things, both from an academic and mental standpoint have been gained throughout working on this project. Most of the things learned were in regards to various methods for fast visualizations.

• I learned about how important controlling level of detail can be in generating and interacting with complex scenes. It can help immensely in reducing the processing power required for a given object and therefore speeding up the entire scene.
• I've learned about two different techniques for creating a changing LOD in a scene. This is the discrete method, by generating static models from QSlim, and the dynamic method, by generating a dynamic model.
• I've also learned how tedious it can be to not have a standardized graphic file format. Many different formats and not many conversion utilities leads to a lot of tedious work.
• I've realized that the computing that goes into preparing scenes of this sort is immense. Not only could the models take a while to generate, but each of the models used in the LOD takes some amount of time. For time-dependent data, this highly increases the necessary computation. Therefore, prior to the execution of a demo, a large amount of work needs to be done for even a small scene. 
• Also, I've learned about what tools are out there to assist in creating decimated surfaces and how to use those tools.