A strategy for repetitive neighbor finding in octree representations

A strategy for repetitive neighbor finding in octree representations

Image and Vision Computing 18 (2000) 1085–1091 www.elsevier.com/locate/imavis A strategy for repetitive neighbor finding in octree representations J...

174KB Sizes 88 Downloads 499 Views

Image and Vision Computing 18 (2000) 1085–1091 www.elsevier.com/locate/imavis

A strategy for repetitive neighbor finding in octree representations J. Vo¨ro¨s* Department of Automation and Control, Faculty of Electrical Engineering and Information Technology, Slovak Technical University, Ilkovicova 3, 812 19 Bratislava, Slovakia Received 14 August 1998; revised 20 December 1999; accepted 15 May 2000

Abstract An effective strategy for repetitive neighbor finding in octrees is presented. It is based on a new method which uses a matrix representation for octrees and some auxiliary locational codes for neighbors’ generation. This approach is universal and generates all neighbors (larger, smaller, equal) for any octree node using only simple algebraic operations. 䉷 2000 Elsevier Science B.V. All rights reserved. Keywords: Octrees; Neighbor finding; Locational code

1. Introduction An octant tree or octree is a memory saving structure for a spatial or three-dimensional (3D) scene representation [1–3]. Many of the special operations in 3D scene analysis involve the so-called neighbor finding procedure, i.e. the examination of octree nodes whose corresponding cubes are spatially “adjacent” to the cube corresponding to the node being processed [3]. Note that adjacency in space does not imply any simple relationship among the nodes in the octree. Neighbor finding is seldom a ‘per se’ activity. In many practical applications, sequences of neighbors of different type are to be found. It means that not only all the immediate neighbors of a node, but also the neighbors of these neighbors, etc. must be generated and examined. Moreover, this process is often followed by proper (re)marking or (re)labeling of found neighbor nodes to denote their specifics (e.g. distances from a point by a distance transform, pertinence to a volume by connected component labeling). Such actions are coupled with updating the given octree data and require strategies on how to cope with these combined procedures effectively. Clearly, a proper repetitive neighbor finding strategy may significantly reduce time and/or memory requirements. There are several references to neighbor finding or neighbor generation for regular octrees and linear octrees. The proposed methods in both cases have benefits and drawbacks, but no reference focuses on specifics of repetitive * Address: Nabrezna 91, 940 73 Nove Zamky, Slovakia. Tel.: ⫹421-8176410-572. E-mail address: [email protected] (J. Vo¨ro¨s).

neighbor finding. Nevertheless, two classic approaches are worth mentioning because of their relevance to the presented approach. In the neighbor finding approach proposed by Samet [4], a neighbor is computed in the given direction for pointer octrees. The basic idea is to ascend the tree until a common ancestor is located, and then descend the tree in search of the neighboring node. The proposed algorithm uses several special functions/relations defined by tables. This approach ignores the situation in which a neighbor may not exist (e.g. when the node is located on the border of the scene). In the neighbor finding using linear octrees, as proposed by Gargantini [5], two cases are distinguished: in the first, two neighboring nodes belong to the same octant relative to the nth subdivision; in the other, they do not. The neighbors of a node are generated using separate algorithms for every direction. The linear code of a neighbor is obtained by changing the digits of the given node’s linear code according to their values and applying a modulo 8 addition with constants depending on the direction. The procedures can be used only to find nodes adjacent to an internal node. This method, in its original form, has a severe drawback: one does not know if the found neighbor belongs to the object or not. This, in turn, means that a search has to be carried out, requiring substantial calculations. The presented strategy benefits from both the above mentioned approaches and improves some of their aspects. First, by using the matrix octree, where each row-entry is a gray node, and the eight column-entries carry information on the nodes’ children, the memory requirements decrease compared to the records of node type with 10 fields as used in Ref. [4] (e.g. pointers to parent nodes are not needed because no common ancestor is of interest). Second, the

0262-8856/00/$ - see front matter 䉷 2000 Elsevier Science B.V. All rights reserved. PII: S0262-885 6(00)00049-4

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

1086

Table 1

Fig. 1.

neighbor generation is performed by auxiliary locational codes using simpler operations than those used in Ref. [5]. Once the locational code of a neighbor is found, each of its octal digits provides a strategy for searching the matrix octree. In the following sections, both forms of octree representation are characterized. Then the new neighbor generation method is described. Finally, the strategy of repetitive neighbor finding is presented.

Fi =Sij

0

1

2

3

4

5

6

7

1 2

⫺1 ⫺1

⫺1 ⫺1

⫺1 0

0 0

⫺1 ⫺1

0 ⫺1

2 0

0 0

defined as an octree whose eight leaves represent octants of this space, labeled FULL, VOID or GRAY (mixed) in accordance with the labeling of the corresponding volume. Each node is associated with a cube of the object space (resulting from successive subdivisions into eight octants), with the root representing the entire space. The octree corresponding to a …2N × 2N × 2N †-dimensional object space can be characterized as an ordered list of GRAY node descriptions V ˆ ‰F1 ; F2 ; F3 ; …; FL ŠT

where L is the number of GRAY nodes [6]. The record describing a GRAY node consists of eight entries. For the ith node this record is Fi ˆ …Si1 ; Si2 ; Si3 ; …; Si8 †

2. Octree representations 2.1. Matrix octree Let a 3D object space be defined in a coordinate system O…x; y; z†: We assume it contains a …2N × 2N × 2N †-dimensional array of volume elements—voxels. A voxel or unit cube is assumed to contain a homogeneous volume of material or to be empty. Hence each voxel can be associated with a label, either FULL or VOID, which is analogous to the BLACK or WHITE classification used in binary images. The voxels labeled FULL represent a solid object. The octree representation of a 3D object space can be

Fig. 2.

…1†

…2†

where Fi denotes the parent node and Sim, m ˆ 1; …; 8; denote its children. If the node Sim is a terminal node, two distinct non-positive integers can be used to designate this entry in Eq. (2); e.g. ( ⫺w; for FULL octant …3† Sim ˆ 0; for VOID octant If Sim is a non-terminal node, an eight-tuple must exist later in Eq. (1) describing the corresponding octant. Hence, it is appropriate to substitute Sim ˆ r;

for GRAY octant

…4†

where r ˆ 2; 3; …; refers to the position (row) in vector (1) where the record Fr corresponding to this GRAY octant is described. As Eq. (2) consists of eight integers, the octree description (1) is an …L × 8†-dimensional matrix, subsequently named the “matrix octree”. For example, if the order of octants is chosen according to Fig. 1 and w ˆ 1, the object in Fig. 2a (with the corresponding octree in Fig. 2b) is described by the matrix given in Table 1. All negative and zero entries in the matrix denote terminal nodes, while a positive integer, say r, means that the suboctant associated with the given column is non-terminal and is described in the rth row of the matrix. An important feature of the matrix octree is that the substitutions for terminal nodes given by Eq. (3) can significantly extend the possibilities of octree representations. Besides giving the locations of 3D objects, they allow to store further relevant information such as different negative integers to distinguish among several objects, to specify

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

1087

Fig. 3.

Fig. 4.

colors or labels for connected volumes and to store distance data [7].

neighbors in a chosen direction. The neighbors of a node A can be of any type (FULL, VOID, GRAY). The 6 directions will be classified as Dx ˆ ‰1; 0; 0Š for left and right, Dy ˆ ‰0; 1; 0Š for back and front, and Dz ˆ ‰0; 0; 1Š for up and down (see Fig. 4).

2.2. Linear octree—locational codes In the linear octree, each leaf node is described by a unique locational code corresponding to a sequence of directional codes encoding the path from the root to that node. Each leaf (FULL or VOID) node is encoded as A ˆ …A0 A1 …AN⫺1 †

…5†

with digits 0; 1; 2; …; 7 for Ai. Each successive digit represents the octant subdivision from which it originates. The linear octree is defined as the collection of FULL nodes and is usually represented as a list of sorted locational codes [5]. Such an ordering is useful because it is the same order in which the FULL nodes of a pointer-based octree would be visited by a depth-first traversal. A variant of cube encoding is shown in Fig. 3. The locational codes are represented by a number in base 8, i.e. ‘n’ digits for a node at the nth level of octree. For example, the scene in Fig. 2a can be described by the set {0,1,2, 4,60,61,64,65}. This method of encoding indicates the size of a cube implicitly (relative to the image dimensions) by the number of digits. The base 8 digits of locational code can be represented in binary form 1 0 x0 y0 z0 C B Bx y z C B 1 1 1C C B …6† AˆB C .. C B C B . A @ xn yn zn where xi, yi, zi are 0 or 1 and 0 ⱕ n ⬍ N: This form of locational codes will be used in this paper to simplify the neighbor generation. 3. Neighbor generation Node B is said to be a neighbor of node A in direction D if B corresponds to the cube adjacent to A in direction D and is equal, larger or smaller than the cube corresponding to A. Hence a node can have no neighbor, one neighbor or several

3.1. Equal sized neighbors Assume a neighbor B of the node A in direction D is to be found. Two cases occur: (a) A and B belong to the same octant relative to the nth subdivision, hence B is an inner neighbor of A; (b) A and B do not and hence B is an outer neighbor of A. In the first case, let A’s locational code in binary form be {xi ; yi ; zi }; i ˆ 0; 1; …; n: There exists one equal sized inner neighbor B in the direction Dx and its binary locational code {xi ; yi ; zi } is xj ˆ xj ;

j ˆ 0; 1; …; n ⫺ 1

…7†

xn ˆ comp…xn †

…8†

yj ˆ yj ;

j ˆ 0; 1; …; n

…9†

zj ˆ zj ;

j ˆ 0; 1; …; n

…10†

where comp(·) means the complement. The equal sized inner neighbors in the directions Dy and Dz are defined analogously, but yn ˆ comp…yn †

…11†

zn ˆ comp…zn †

…12†

with all other codes remaining unchanged. For example node A ˆ …011† in Fig. 5 has equal sized inner neighbors B ˆ …015† in the direction Dz, and C ˆ …013† in the direction Dy. The locational codes are 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 C B C B C B C B C B C AˆB @1 0 0A B ˆ @1 0 0A C ˆ @1 0 0A 1

0

0

1

0

1

1

1

0

Thus only the last digit of the locational code of node A has to be changed to obtain B and C. In fact, node A and its inner neighbors always differ in one bit.

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

1088

from that of A after changing three bits in the first (x) column of the locational code 0

0

B BˆB @1 1

0 0

1

C 0 0C A

0

1

B EˆB @0

0 1

0

0

0

1

0

C 0C A

0

1

Similarly, if ky ⬎ 0; kz ⬎ 0 are integers such that yn ˆ yn⫺1 ˆ … ˆ yn⫺ky ⫹ 1 苷 yn⫺ky

…18†

zn ˆ zn⫺1 ˆ … ˆ zn⫺kz ⫹ 1 苷 zn ⫺ kz

…19†

then the binary locational code of equal sized outer neighbor in the direction Dy will differ from that of node A only in the entries yn⫺i ˆ comp…yn⫺i †;

i ˆ 0; 1; …; ky

…20†

and in the direction Dz only in the entries zn⫺i ˆ comp…zn⫺i †;

Fig. 5.

In the second case, more digits of the locational code of A are to be changed. The number of required changes to obtain the locational codes of its outer neighbors is uniquely determined by the locational code of node A. Let kx ⬎ 0 be an integer fulfilling xn ˆ xn⫺1 ˆ … ˆ xn⫺kx ⫹ 1 苷 xn⫺kx

…13†

Then, if kx ⱕ n; there exists one equal sized outer neighbor B in the direction Dx and its binary locational code {xi ; yi ; zi } is given as follows: xn⫺i ˆ comp…xn⫺i †;

i ˆ 0; 1; …; kx

…14†

xi ˆ xi ;

i ˆ 0; 1; …; n ⫺ kx ⫺ 1

…15†

yi ˆ yi ;

i ˆ 0; 1; …; n

…16†

zi ˆ zi ;

i ˆ 0; 1; …; n

…17†

The value of kx reflects the level of common ancestor for the pair of neighboring nodes A and B, which are not in the same octant. If two equal sized nodes of an octree are neighboring in a direction D, then the corresponding direction-relevant bits of locational codes (i.e. xi and xi in this case) are of complementary values up to the common ancestor node, while the other bits are identical. For example, node B ˆ …015† in Fig. 5 has kx ˆ 2 and hence the locational code of its outer neighbor E ˆ …104† in the direction Dx is obtained

i ˆ 0; 1; …; kz

…21†

while all the other codes will be identical to A’s. The values resulting from Eqs. (13), (18) and (19) are called the k-values of nodes for the corresponding directions. By the generation of equal sized outer neighbors, exactly k ⫹ 1 bits must be changed. At the same time the k-value serves to determine whether it is possible to find an outer neighbor: if any k-value is greater than n, no outer neighbor exists in the corresponding direction, because the common ancestor would be ‘above’ the root node and hence out of the 3D scene. Node J ˆ …002† in Fig. 5a with the following locational code 0

0 0

0

0 1

0

B JˆB @0 0

1

C 0C A

has no outer neighbors in the directions Dx and Dz, because the k-values for both directions are 3, i.e. greater than the node level (n ˆ 2). Node G ˆ (000) has no outer neighbor in any direction for the same reason.

3.2. Larger sized neighbors Using the locational code of the equal sized neighbor B of node A, all the potential neighbors of larger dimensions can be derived. The larger sized outer neighbors of a node A in the direction D are the nodes j B ˆ {j xi ; j yi ; j zi }; whose binary locational codes are generated from the code of the corresponding equal sized outer neighbor by successive canceling the least significant digits up to the …n ⫺ k†th

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

level, i.e. 0 j x0 B j B x B 1 B j BˆB B B @ j xn⫺j

j j

y0 y1 .. .

j

yn⫺j

j

z0

where d is 0 or 1, while

1

C j z1 C C C C C C A j zn⫺j

…22†

where j ˆ 1; …; k; and k is given by Eqs. (13), (18) or (19). Hence the number of larger sized outer neighbors in a direction D is equal to the corresponding k-value of node A, i.e. there is at least one larger sized outer neighbor for an existing equal sized one. It follows from the fact that all the parents j B of the neighboring node B up to the common ancestor determined by the k-value are also the neighbors of the given node A. For example, the equal sized outer neighbor of B ˆ …015† in the direction Dx is E ˆ …104†, and there are two (GRAY) larger outer neighbors in this direction: 1 E ˆ …10† and 2 E ˆ …1†, because its kx ˆ 2: However, B has only one (VOID) larger sized outer neighbor in Dz, namely (05) resulting from the corresponding (VOID) outer node (051), because its kz ˆ 1: 3.3. Smaller sized neighbors The smaller sized neighbors of octant A are the quadruples of adjacent octants, suboctants,… of its equal sized neighbor sharing a common face with A. Again inner and outer smaller sized neighbors can be distinguished in each direction. They are derived from the locational code of the corresponding equal sized inner or outer neighbor B ˆ {xi ; yi ; zi }; i ˆ 0; 1; …; n: The binary locational codes for the quadruple of smaller sized neighbors at the (n ⫹ 1)th level in the direction Dx are 1 0 j j j x0 y0 z0 C B j j j B x z1 C y1 C B 1 C B C B j . C B . …23† BˆB C . C B C B j j j B x zn C yn A @ n j

xn⫹1

j

yn⫹1

j

zn⫹1

j ˆ 1; …; 4; where the codes of outer neighbors are j

xn⫹1 ˆ xn

…24†

j

yn⫹1 ˆ d

…25†

j

xi ˆ zi ;

i ˆ 0; 1; …; n

…30†

j

yi ˆ yi ;

i ˆ 0; 1; …; n

…31†

j

zi ˆ zi ;

i ˆ 0; 1; …; n

…32†

The y- and z-values (the combinations of 0s and 1s) in the last row of Eq. (23) reflect that 1B, 2B, 3B, and 4B constitute a quadruple of contiguous nodes. The x-values in the last row, given by Eq. (24) or (27), result from the location of equal sized neighbors. For example, the quadruple of smaller sized inner neighbors of B ˆ …015† (Fig. 5a) in the direction Dy is (0170), (0171), (0174), (0175), with the following locational codes: 1 1 0 0 0 0 0 0 0 0 C C B B B1 0 0C B1 0 0C C C B B 1 2 C C BˆB BˆB C C B B B1 1 1C B1 1 1C A A @ @ 0 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 C C B B B1 0 0C B1 0 0C C C B B 3 4 C C BˆB BˆB C C B B B1 1 1C B1 1 1C A A @ @ 0 0 1 1 0 1 Evidently, these nodes are the suboctants of the corresponding equal sized inner neighbor of B, namely (017). Further quadruples of smaller sized neighbors at the (n ⫹ 2)th level can be generated for all the above nodes in the same way. Generally, the smaller sized neighbors at the …n ⫹ k†th level in the direction Dx are all the nodes j B; j ˆ 1; 2; …; 4k ; with the following binary locational codes: 1 0 j j j z0 x0 y0 C B j j j B x z1 C y1 C B 1 C B C B .. C B C B . C B C B j j j j C …33† BˆB   x y z  n n C B n C B C Bj j j B xn⫹1 yn⫹1 zn⫹1 C C B C B C .. B C B . A @ j

j

zn⫹1 ˆ d

1089

…26†

and those of inner ones are j

xn⫹1 ˆ comp…xn †

…27†

j

yn⫹1 ˆ d

…28†

j

zn⫹1 ˆ d

…29†

xn⫹k

j

yn⫹k

j

zn⫹k

where for all outer neighbors j

xn⫹i ˆ xn

…34†

j

yn⫹i ˆ d

…35†

j

zn⫹i ˆ d

…36†

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

1090

and for all inner neighbors

Table 2

j

xn⫹i ˆ comp…xn †

…37†

j

yn⫹i ˆ d

…38†

j

zn⫹i ˆ d

…39†

where i ˆ 1; 2; …; k; while j

xi ˆ xi ;

i ˆ 0; 1; …; n

…40†

j

yi ˆ yi ;

i ˆ 0; 1; …; n

…41†

j

zi ˆ zi ;

i ˆ 0; 1; …; n

…42†

Analogously, the locational codes of smaller sized neighbors in the directions Dy and Dz can be derived. From the implementation point of view it is worthy to note that the generation of inner and outer neighbors can be incorporated into one algorithm, where the problem of inner neighbors (changing one bit) is considered as the partial problem of outer neighbors (changing more bits). 4. Repetitive neighbor finding strategy Two things are of main importance for repetitive neighbor finding in octrees: a fast neighbor generation method and a flexible octree representation for storing and updating relevant data. Analyzing the known octree representations and neighbor finding methods, none of them is able to meet both requirements satisfactorily. The presented strategy is based, similarly as in the 2D case [8], on the use of two forms of octree representation, namely the matrix octree and the locational codes. This approach may notably simplify the solution of the above-mentioned tasks. Computing locational codes of nodes takes only a small fraction of the total execution time required by the neighbor finding in the linear octree based approach. Searching the node list to determine the type of generated node usually takes up the vast majority of execution time. Moreover, the linear octrees are not very proper for storing additional information on the nodes. Therefore, it is not the best choice to use the linear octree for 3D scenes if repetitive neighbor finding or the labeling of components is required. The matrix octree is superior with respect to labeling and updating. Furthermore, the search for the desired (neighbor) node type, if given by its locational code, is relatively simple, when it is performed using the corresponding matrix octree. The first digit of the locational code identifies a column-entry; this column-entry supplies a row-entry. The second digit gives a new column-entry in the just found row, etc. For example, the type of node given by the locational code (105) from the scene in Fig. 5a can be determined using the corresponding matrix octree in Table 2 as follows: the entry in the 1-column of the first row (root node) points to the third row, where the entry in the 0-column points to

Fi =Sij

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7

2 4 6 ⫺1 0 0 ⫺1

3 5 0 0 ⫺1 0 ⫺1

0 0 0 ⫺1 0 0 0

0 0 0 0 ⫺1 0 0

0 0 0 0 0 ⫺1 ⫺1

0 0 0 0 ⫺1 0 ⫺1

0 0 0 0 0 0 0

0 0 0 0 7 0 0

the sixth row and here the entry in the 5-column indicates that this node is VOID. Finally, the following strategy can be used for repetitive neighbor finding and the labeling of components. 1. The 3D scene is represented by a matrix octree, where the terminal nodes of interest are labeled by a proper negative integer according to (3). 2. The locational code for the (starting) node of interest is computed in the form (6) as auxiliary data for neighbors’ generation. 3. The neighbor generation of required type and direction is performed using the corresponding rules of above described method. The result is the neighbor node’s locational code. 4. The generated neighbor node is sought in the matrix octree by following the matrix columns in accordance with the neighbor locational code. At the end one gets a value of: (i) ‘0’, meaning that the neighbor is VOID; (ii) ‘⫺w’, meaning that the neighbor is FULL and of same or larger size than the original one; or (iii) a positive value, which means that the neighbor is of smaller size. 5. The original matrix entry (negative integer) corresponding to the located neighbor node can be updated or relabeled if required. 6. The process can continue with returning to the step (3) seeking for further neighbor(s). In the applications of repetitive neighbor finding process, the neighbors of found neighbors (and further their neighbors, etc.) are to be determined and examined [7]. After computing the locational code for the initial or starting node, the codes for all the other (neighbor) nodes are directly generated by the above algorithm and need not be computed from the octree. Hence the locational codes play the role of auxiliary data while the matrix octree serves for examination of the generated neighbor nodes and their eventual relabeling. The following example of connected component labeling in a 3D scene illustrates the application of the above algorithm. The label is an integer number and is identical for all voxels in the same connected component but is different from labels given to voxels of other components. The scene according to Fig. 5a is described by the matrix octree in Table 2. Starting with the first FULL node, i.e. G, its

J. Vo¨ro¨s / Image and Vision Computing 18 (2000) 1085–1091

1091

Table 3 Fi =Sij

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7

2 4 6 ⫺2 0 0 ⫺3

3 5 0 0 ⫺3 0 ⫺3

0 0 0 ⫺2 0 0 0

0 0 0 0 ⫺3 0 0

0 0 0 0 0 ⫺3 ⫺3

0 0 0 0 ⫺3 0 ⫺3

0 0 0 0 0 0 0

0 0 0 0 7 0 0

locational code is found and the label ⫺1 in the matrix (column 0, row 4) is changed to the label for the first object, say ⫺2. Then the locational codes of the neighbors of G are generated and only one FULL neighbor J is found and relabeled. As J has no other FULL neighbors, the first step of component labeling is completed and we proceed to search for further objects in the scene, i.e. for matrix entries still labeled with ⫺1. The next such entry (column 1, row 5— corresponding to node A) belongs to the second object and is now relabeled as ⫺3. Using the locational code of node A two inner (i.e. B and C) and one outer neighbor (E) are found and the corresponding entries are also changed to ⫺3. Then the neighbors of B, C and E are searched, using their locational codes already generated. In this case node B has further neighbors, i.e. four smaller sized neighbors …B1 ; …; B4 †; hence after their relabeling the whole process terminates. The relabeled matrix octree is shown in Table 3 and the labeled objects are shown in Fig. 6. Finally some remarks on time and space complexities of the proposed approach may be in order. Generating a neighbor can be carried out in O(N) time, where N is the number of levels. This result is comparable with the method given in Ref. [5]. However, while the worst-case given in Ref. [5] for determining the node type (color) is O…log M ⫹ N†; where M is the number of leaf nodes, in the presented approach it is only O(N). From the space complexity point of view, the table-driven method described in Ref. [4] requires records of 10 fields for all octree nodes for locating the nearest common ancestor, while the matrix octree uses only eighttuples and only for non-terminal nodes. 5. Conclusions The proposed strategy using matrix octrees and locational codes for repetitive neighbor finding profits from both forms of representation and may lead to significant saving in execution time and memory space. The linear locational codes as auxiliary data simplify the generation of neighbor nodes, while the determination of the generated node type and eventually its further processing is performed in the matrix octree. It is very advantageous in applications involving octree distance transforms, connected component labeling, path planning algorithms, etc. where a large

Fig. 6.

number of neighbor nodes are to be generated and further processed. The benefits of this strategy can be summarized as follows: • the 3D scene is represented in matrix form, thus enabling easy processing and manipulation; • the neighbors are generated in the form of locational codes using simple algebraic operations with binary data; • neighbors of equal, larger or smaller size can be generated for internal and border nodes of the given octree; • only the first (starting) node must be transformed into its binary locational code, while all other neighbors are generated directly in their locational codes.

Acknowledgements The author would like to thank the reviewers for their valuable comments and suggestions significantly improving this paper. The author also gratefully acknowledges financial support from the Slovak Scientific Grant Agency. References [1] C.L. Jackins, S.L. Tanimoto, Oct-trees and their use in representing three-dimensional objects, Computer Graphics and Image Processing 14 (1980) 249–270. [2] D. Meagher, Geometric modeling using octree encoding, Computer Graphics and Image Processing 19 (1982) 129–147. [3] H. Samet, The Design and Analysis of Spatial Data Structures, Addison Wesley, Reading, MA, 1990. [4] H. Samet, Neighbor finding in images represented by octrees, Computer Vision, Graphics, and Image Processing 46 (1989) 367–386. [5] I. Gargantini, Linear oct-trees for fast processing of three-dimensional objects, Computer Graphics and Image Processing 20 (1982) 365–374. [6] J. Vo¨ro¨s, Approximate quadtree and octree representations for manufacturing tasks, Preprints 3rd IFAC Symposium on Low Cost Automation, Vienna, 1992, pp. 391–396. [7] J. Vo¨ro¨s, Trajectory planning in 3D workspaces represented by octrees, Preprints IFAC Workshop on Manufacturing Systems: Modelling, Management and Control, Vienna, 1997, pp. 331–336. [8] J. Vo¨ro¨s, strategy for repetitive neighbor finding in images represented by quadtrees, Pattern Recognition Letters 18 (1997) 955–962.