Two proposals for using ElevationGrids in VRML

[<heiko.grussbach@crpht.lu>]

Hi,

during the last days, I've been experimenting with ElevationGrids in VRML.
Two problems come up again and again. These are:

1) Content is too large for small-bandwidth download to work. Sometimes
even high-bandwidth isn't enough...
2) ElevationGrids of reasonable size lead to very large triangle counts, in
turn leading to very bad performance in the browser.

GeoVRML currently deals (amongst other things) mainly with the first
problem by putting ElevationGrid data into tiles, which are loaded only
when actually needed. I would like to make two additional proposals and
hear what people have to say about it.

1) Binary encoding for EG-data.
Instead of proposing yet another binary format for geometries, I would
propose to use one of the existing 2D compressed image formats. I've tested
8bit PNG format and got a factor of 2 decrease in filesize. This is
compared against gzipped content of course. Since many DEM's cannot be
encoded losslessly in 8bit and 1m accuracy, there are two solutions.
     1a) use smaller tiles, thus decreasing the probability of high
altidude variations within the EG. This solves the problem only partly,
because of large         altitude variations within small distances.
     1b) Use 16 bit formats. 16 bit is more than enough for height data
accuracy of 1m.
An additional advantage of this method could be, that browsers have
decoders for these graphical formats already build in. Once we could access
these decoders, theres no need to add special decoders as is needed for
other binary geometry. Additionally, taking a look at the various (wavelet
based) JPEG 2000 proposals for a new JPEG format, I expect the compression
rates to increase dramatically also for DEM-data.

2) Triangularization using the accuracy of the data.
Currently, within the ElevationGrid as well as the GeoElevationGrid node,
there is no possibility to store the vertical accuracy of the data. This
value could be used by the renderer to do some mesh reduction. I've done
some preliminary experiments with TIN generation and found, that although
it can take quite a bit of CPU time and memory, it generally reduces
triangle count by up to a factor of 10 while keeping accuracy. The
requirements for CPU-time and memory can be reduced quite a bit, if the
grid-size would be small enough.

Note, that both proposals require modification of the current
GeoElevationGrid node. The first would need an URL instead of the height
values, whereas the second would need at least an SFFloat providing the
vertical accuracy of the data.


Regards

Heiko Grussbach
Heiko.Grussbach@crpht.lu