Geometry Rendering

The sensing techniques described above produce a collection of point samples
on the surface of objects. The point cloud is usually transformed into a triangle
mesh for graphical rendering via standard mesh rendering techniques. Laser
scanning, stereo vision, and spacetime stereo can additionally capture images
of the scene which can be used to associate color with the point samples or as
a texture map for the resulting mesh. The simplest approach is to create
a triangulation of the points by connecting a point with its neighbors as determined
by the sensor layout. For example, a point corresponding to a pixel in the
camera of a structured light, stereo vision, or shaped light pulse system would
be connected to points corresponding to the neighboring pixels.

More advanced and complex procedures can fill holes, align, and merge multiple
depth maps of the same object. This creates a model that has more
complete geometry. A single depth map will only show the geometry of one
side and will have holes wherever there is occlusion. Multiple depth maps from
different viewpoints will reduce occlusion and the merging algorithm can also
guess to fill in holes. Unfortunately, most of these techniques do not work
with deformable objects because aligning the depth maps depends on the object
being rigid. A recent advance in geometry processing is able to extract
correspondences and merge point clouds of deforming objects. However, the
size of the dataset that can be processed is limited.

Updating Relational Data by SPARUL Statements

In many cases, an RDF view contains quad map patterns that maps all columns
of some table into triples in such a way that sets of triples made from different
columns are “obviously” pairwise disjoint and invoked IRI classes are bijections.
E.g., quad map patterns for RDF property tables usually satisfy these restrictions
because different columns are for different predicates and column values are
used as object literals unchanged. We are presently extending SPARUL
compiler and run-time in order to make such RDF views updatable.

The translation of a given RDF graph into SQL data manipulation statement
begins with extracting all SQL values from all calculatable fields of triples and
partitioning the graph into groups of triples, one group per one distinct extracted
primary key of some source table. Some triples may become members of more
than one group, e.g., a triple may specify relation between two table rows. After
integrity check, every group is converted into one insert or delete statement.

The partitioning of N triples requires O(N lnN) operations and keeps data in
memory so it’s bad for big dump/restore operations but pretty effecient for
transactions of limited size, like individual bookeeping records, personal FOAF
files etc.

IP Address Allocation

A new node will be assigned randomly one of the lowest free addresses
contained in the FAT, which means that the IP address is assigned in an
increasing order from a randomly chosen IP Address Block. We impose to
the new joining node to obtain its IP address from at least K nodes. We
use for this purpose the threshold signature described above and the new
concept of ‘On-line Joint IP address and Public Key Certificate’. Each
allocated IP address in the network is bound to node’s identity by means
of this certificate which must be signed by the On-line CA.

After having received a signed IP Address, the new node must broadcast
a signed registration message to all nodes to be able to participate actively
in the network. Any assigned IP address which is not registered yet is
removed from the FAT and kept in the PAT, either by the K signer nodes
after having assigned this address or by all nodes after having received a
registration message for a higher IP address in the same IP Address Block.
If the registration message is received the IP address is removed from the
PAT and put in the RAT.

Figure 1. Functional Blocks of TCSAP and DPKI modules