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