'anbul 2004
function of
present the
cells) too.
r rendering
tions of the
ally, actors
en. At this
ct with its
citly in a
le to render
ties of the
coordinates
se from the
ame way, a
and so etc.
ns between
to “build
> following
use object.
table with
irface area,
* variables
ox of the
for picking
ng related
icks one or
(es) of the
coordinate
tes of the
ouseObject
Seld of the
ik. between
ted. Label
the house
pology are
le to make
xible way.
jn color of
it changes
and when
indivudial
.. Thus this
ecomposed
omponents
ss instance
s and their
yuble sided
the house
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B3. Istanbul 2004
— >| root
y
» | Ist house »| 2nd house
La . . . .
object with object with
member member
variables variables
end
-——-iprev |. next prev | next A
Figure 1. Organisation of house object in a binary tree
In Figure 1, each node of binary tree corresponds a house object
and each node shows where the previous and next houses are in
the memory, by using prevHouse and nextHouse pointers. With
these pointers, each nodes are linked each other for the fast
search tasks. In the above tree, a new house object can easily be
added at the end of the tree by allocating necessary memory and
linking this new memory area with the previous house object.
Now, we can give the detailed description of one individual
house object by defining both its geometry and topology. As
mentioned before, points, cell arrays, poly data, mappers and
actors are used. Mapper and actor is used for 3D visualization
purposes, in order to present the data to graphical environment
for rendering purposes and well known from computer graphics
and 3D visualization libraries such as OpenGL, and
visualization toolkit, (Scroeder, 1998). Relations between points
and cells are shown in Figure 2.
Coord | ID ID typeo nCells,
X
y 0 n offset, cells
Z
x Po typei nCells;
y | ffse cells
Z ww P, offset, elis,
: n
X typem-1 nCells,.,
y n-1 4 Po N
Z offset, cells,
points cells cell types cells links
Figure 2. Implicit representation of geometry and topology
By using cell types, random access to each cell is provided.
Above structure can easily be converted to relational model in
our tool. For this purpose, from the main menu, “build
topology" command should be selected. In this case, the
topological relations of objects are written to relational tables.
3D City-VAQS, supports dBase and Paradox relational
database management systems. In Figure 3, firstly we give the
general representation of geometry and topology of 3D objects
used in 3D-City VAQS and then in Figure 4, we give the
relational database model representation.
561
I
Picking
——
Geometry and
implicit topology
Texture 4 4
map Topology in
relational
qp
VII
query results
IH
vy VI SalI made)
= 5 (explicitly
Show geometry of ES do stored)
picked primitives =
query
—P
€
id
v
V *
Attribute Attribute
information of information in
relational
object attribute table |a
(can be indexed
another tables)
database with
indexed tables
Rendering properties
Texture image
Figure 3. General representation of geometry and topology
With the representation shown in Figure 3, it is possible
to manage the visualization tasks and database tasks in a
flexible manner (independing and depending to each
other). The box with number i in the figure represents the
houseObject entities in the binary tree of visualization
memory. This box wholly contains all of the member
variables of houseObject entity. At this stage, even if the
relational tables aren't created, the operations which are
shown in the boxes with the numbers v, vi and vii are
ready and effectively can be performed in the 3D
visualization pipeline. I.e. this means, one can query the
geometry of houseObject's geometric features such as
point coordinates, id of any cell (face, edge, surface etc.)
by picking on it with mouse on the render window. Here
at this stage, only the volume and area of the houseObject
can not be listed, since it requires additional volume and
area computations and these computations are performed
during the "building topology" process. Here, rendering
properties of the objects can also be changed. For
example; color, transparency, illumination conditions
such as light, shading, reflection etc. Again at this point,
only artificial textures can be mapped on to houseObject.
Photorealistic texture mapping requires computation of
texture coordinates, so photorealistic texture mapping can
not be performed at this stage. It can be performed after
building topology and with photogrammetric
computations for obtaining texture coordinates.
During topology building, object attribute table (OAT) is
created. Each column of the OAT represents one attribute
feature and each row represents one houseObject. In
OAT table, “Internalld”, “Userld”, “FacetArea” and
“Volume” items are created by the software