Mice)
nbers, etc.)
ther spatial
of Ljubljana
Modelling
. interactive
owsers (e.g.
n browser
at. It defines
today's 3D
ght sources,
perties, and
ilti-platform
iotivated by
(enced three
e types of
, and user
able with a
VRML was
Internet and
ible, even if
those standards have some shortcomings when used with
VRML. Using existing standards instead of inventing new,
incompatible standards makes it much easier for the Web
developer, who can use existing tools to help create VRML
content. It also makes it much easier for somebody
implementing the VRML standard, since libraries of code for
popular standards already exist. VRML files may contain
references to files in many other standard formats. JPEG, PNG,
GIF, and MPEG files may be used as texture maps on objects.
WAV and MIDI files may be used to specify sound that is
emitted in the world. Files containing Java or JavaScript code
may be referenced and used to implement programmed
behaviour for the objects in your worlds. Each of these is an
independent standard, chosen to be used with VRML because
of its widespread use on the Internet.
4 DATA MANIPULATION
41 Combining data
The initial form of data is not very real-time friendly and during
conversion process, a variety of speed-up techniques were used.
As terrain data was only available in form of geo-located leafs,
each same size, with around 11011 vertices, we decided to take
advantage of its initial form by using abstract spatial data type,
already implemented in in-house developed EV8 software. All
ortophoto images from the database were available in a same
form, covering each terrain leaf exactly, so calculating texture
mapping of a terrain leaf, was rather straight forward, and can
be done completely automatically. Corresponding ortophoto
image was assigned to corresponding terrain leaf. If additional
raster image is available in the same manner (covering same
area), it can be easily assigned as main image or layered in
user-defined order. Additional operations with per-pixel
accuracy can be done between those images with usage of
multitexturing or with use of fragment shaders, where complex
operations can be accomplished.
42 Data conversion
Terrain data was converted to losses compressed format to
speed up the loading times and reduce storage requirements.
Each image was in pre-process resized from its initial size to a
size of 8192*8192 pixels due to hardware limitations. Whole
mipmap sequence was created at the same time. Images were
saved on disk in compressed format, suitable for real-time
rendering, reducing memory and storage requirements from 72
MB to 48 MB per image, all mipmaps included.
Buildings were combined together in one mesh, so that meshes
don't exceed 32K indices limit, thus solving specific issues with
rendering of large meshes on 32-bit platform. Bounding borders
of meshes are at the same position as borders of underlying
terrain leaf. On terrain leafs with very high density of buildings
more meshes of buildings are required.
43 Structuring data
Data is at loading time organized in blocks of equal size called
nodes in following manner. Each terrain leaf is a node in a
spatial data structure, defining minimum and maximum in XZ-
plane of its boundary. To each page, a list of buildings is
attached, defining new height to a node in spatial data structure,
forming quad-tree structure. In rendering loop, this structure is
traversed, rejecting unneeded nodes, as its organization is
135
suitable for fast frustum culling, while node's list specifies
possible visibility set of buildings. Visible nodes are then
rendered according to mesh material.
More advanced techniques for terrain rendering can easily be
added to rendering loop; such as view dependant multi
resolution meshes (Hope, 1998). We have a working demo of
475 leafs, approx 5.5 million vertices, 180MB compressed
vertex data, rendering at interactive speed on a PC, covering
area of a quarter of Slovenia. Data was converted automatically.
Extensibility of underlying platform enables us to simply add or
change rendering technique for any primitive. Thus
visualization of large data sets in interactive time can be
achieved.
4.4 Optimisations issues
Each different type of data was optimised either in pre-process
or is optimised at load time. Images were converted to hardware
friendly compressed format with mipmap sequence allowing
software to choose maximum supported size for the hardware.
Mesh vertices are welded together, removing duplicates. Each
mesh is optimised for hardware cache when loaded, and
converted to triangle strips. Those techniques enable our
software to render whole Ljubljana at interactive speeds on a
PC. With new, more capable hardware, higher frame rates are
achieved and more data can be visualized.
Further optimisations are possible. There is plenty of overhead
data in buildings data, that could further be optimised and even
removed. If terrain data initial form would be different, we
could further reduce memory consumption. Different types of
rendering could also be used, more appropriate for terrain
rendering.
But even with this type of resource management and data
overhead, there is still plenty of CPU time available for
additional computational tasks, simulation or database queries.
4.5 Data linkage
During conversion of mesh data, a lot of swapping of vertices
and faces usually occurs, so any indices to faces or vertices
won't work, if they were assigned to data prior to conversion.
And we want buildings to have some data attached to it.
Luckily, there is one type of data in a mesh that can stay the
same during whole conversion process if it is done properly and
that is texture coordinate of an vertex. Encoding indices into
texture coordinates helped us to keep proper index value for
each vertex, eliminating any need for tracking of the swapping
of the vertices, that can occur in pre-process. Each vertex can
have an index that can be used as an index to a record,
expanding the usage of such a system to limitless possibilities.
Within such a virtual world of geolocated data, availability of
measuring tools is obvious.
4.6 System configuration for presentations in mono and
stereoscopic techniques, adaptable for various needs
The architecture of software has been structured to enable
various kinds of presentations beside the fast display of data
and the interaction with data environment to satisfy users'
needs. Such results were made possible with the help of the
modular structure concept, whereby a separate module is in fact
the computer. The system supports links to the greater number