Tools adapted: I took the source code for the MPEG2 decoder written by the MPEG Software Simulation Group and converted it from K&R C to ANSI C++. I attempted to modify it to allow decoding of an arbitrary frame from an arbitrary group of pictures. This worked, briefly, but stopped working (probably due to an inadvertent change on my part) early in exam week. I wasn't able to repair it in time for the final presentation.
Code modified: I changed the MMR system to take the
images for textured depth meshes from the MPEGDecoder class
mentioned above. In particular, I modified SceneMgr to handle
the MPEG streams for the user's current location, and modified
TexMgr to load images from the decoders instead of PNG files on
disk.
Since the decoder wasn't working, I put together a simple image
library class that loads all of the MPEG frames at program start
and then simply returns a particular one instead of decoding it
on the fly. I claim that the performance increase from this is,
at best, minimal: software MPEG decoders are perfectly capable
of decoding an image in 30-50ms on modern processors, which is
less than one frame time in the MMR.
New tools: I wrote a utility to analyze the cell graph
from the power plant. First, I found connected components (at
least one per floor) using a modified breadth-first search that
runs in O(V + E) time. Then, I computed an NxN distance matrix
for each connected component containing the Euclidean distances
between each cell center. To construct an ordering within each
connected component, I used an O(n log n) approximation
algorithm to the traveling salesman problem.
To help deal with MPEG streams, I wrote several small utilities
including an offline decoder, a frame-type analyzer, and an
indexing program (to find locations within the bitstream).
These were fairly minor modifications of the C++ decoder.
Data generated: I dumped textures for floors 6, 9, and 46 of the power plant, then generated six MPEG streams (one per cell wall) for each connected component on those floors. I only wound up using the Floor 9 streams for lack of time.
Most of the graph techniques I used owe more to COMP202
(algorithm analysis) than to computational geometry; however,
the path-generation problem (which is equivalent to the
traveling salesman problem) is certain to arise in areas such as
robot motion planning.
MPEG encoding has within it the notion of image search:
given a region of one frame, the encoder attempts to predict the
motion of those pixels in the next frame. The techniques used
for this borrow heavily from computer vision, being closely
related to the correspondence problem, but it might be possible
to apply geometric search techniques for motion prediction.
The graph algorithms I implemented behaved roughly as advertised: the connected-component search ran in time roughly linear in the graph size (which agrees with its O(V + E) bound since the cell graph is sparse) and the path-ordering algorithm ran in time linear in the size of the connected component. (It has a bound of O(n log n).) However, path generation was dominated by the time taken to fill out the N x N distance matrix between cells.
See the Future Work section of the final report. Most of these are matters of hacking instead of theoretical problems to be solved, although techniques of visibility computation could be employed to determine sample points for far-field representations. (The idea is to acquire as much of the far field as possible using the minimum number of samples.) This may actually be part of Walkthrough's work next semester.