Lehrveranstaltungsinhalt aus - Institute for Computer Graphics and ...

0.12. COPING WITH LARGE DATASETS 17
Using vegetation for rendering, like in the picture of the Schloßberg of Slide 0.115, is not trivial
either. How do we model vegetation in this virtual habitat? The Schloßberg example is based on
vegetation that is photographically collected and then pasted onto flat surfaces that are mounted
on tree trunks. This is acceptable for a still image like Slide 0.117, but if we have some motion,
then vegetation produces a very irritating effect, because the trees move as we walk by. Another
way, of course, is to really have a three dimensional rendering of a tree, but they typically are
either very expensive or they look somewhat artificial, like the tree in the example of Slide 0.118.
Vegetation rendering is thus also an important research topic.
0.12 Coping with Large Datasets
We have a need to cope with large data sets in the administration, rendering and visualization
of city data. The example of modeling Vienna with its 220,000 buildings in real-time illustrates
the magnitude of the challenge. Even if one compresses the 220,000 individual buildings into
20,000 “blocks”, thus on average combining 10 buildings into a single building block, one still has
to cope with a time-consuming rendering effort that is not possible to achieved in real-time. A
recent doctoral thesis by M. Kofler (1998) reported on algorithms to accelerate the rendering on
an unaided computer by the factor of 100, simply by using an intelligent data structure.
If the geometric data are augmented by photographic texture, then the quantity of data gets even
more voluminous. Just assume that one has 220,000 individual buildings consisting of 10 facades
each, each facade representating roughly 10m × 10m, photographic texture at a resolution of
5cm × 5cm per pixel. You are invited to compute the quantity of data that results from this
consideration.
Kofler’s thesis proposed a clever data structure called “LOD/R-tree”. “LOD” stands for level
of detail, and R-tree stands for rectangular tree. The author took the entire city of Vienna and
defined for each building a rectangle. These are permitted to overlap. In addition, separate
rectangles represent a group of buildings, even the districts are represented by one rectangle each.
Actually, the structure was generalized to 3D, thus we are not dealing with rectangles but with
cubes.
Now as this is being augmented by photographic texture one needs to select the appropriate data
structure, to be super-imposed over the geometry. As one uses the data one defines the so-called
“Frustum” as the intanstaneous cone-of-view. At the front of the viewing cone one has high
resolution, whereas in the back one employs low resolution. The idea is to store the photographic
texture and the geometry at various levels of detail and then call up those levels of detail that
are relevant, at a certain of distance to the viewer. This area of research is still rapidly evolving
and “fast visualization” is therefore another subject of on-going research for Diplomarbeiten and
Dissertationen. The actual fly-over of Vienna using the 20,000 building blocks in real-time is now
feasible on a regular personal computer producing about 10 to 20 frames per second as opposed
to 10 seconds per frame prior to the LOD/R-tree data structure. Slide 0.129 and Slide 0.130 are
two views computed with LOD/R-tree. The same LOD/R-tree data structure can also be used to
fly over regular DEMs - recall that these are regular grids in (x, y) to which a z-value is attached
at each grid intersection to represent terrain elevations. These meshes are then associated with
photographic texture as shown in three segmential views. We generally call this “photorealistic
rendering of outdoor environments”.
Another view of a Digital Elevation Model (DEM), super-imposed with a higher resolution aerial
photograph, is shown in Slide 0.135 and Slide 0.136.