Crates.io | grid-tree |
lib.rs | grid-tree |
version | 0.2.0 |
source | src |
created_at | 2022-01-17 22:45:52.007664 |
updated_at | 2022-08-27 02:31:53.508097 |
description | Pixel quadtrees and voxel octrees. |
homepage | |
repository | https://github.com/bonsairobo/grid-tree-rs |
max_upload_size | |
id | 515806 |
size | 73,959 |
Pixel quadtrees and voxel octrees.
Store any type in an OctreeI32
, OctreeU32
, QuadtreeI32
,
or QuadtreeU32
, all of which are specific instances of the generic Tree
. A
Tree
represents a map from (Level, Integer Coordinates)
to T
. Thus it is useful for storing pixel or
voxel data with level-of-detail. The tree also requires that if a node slot is occupied (has data), then all ancestor slots
are also filled.
Tree
has its own internal allocators, any pointers are completely local to the data structure. In
principle, this makes it easy to clone the tree for e.g. uploading to a GPU (although we haven't tried it for ourselves).[T; CHUNK_SIZE]
. The alternative "pointerless" octrees take up less memory, but are also more complex
to edit and traverse.NodePtr
is simply an array lookup.NodeEntry
and Tree::child_entry
APIs allow for very simple code that fills entire trees with a
single visitor closure.VectorKey
for a custom key type, the addressable range can be extended to
coordinates of arbitrary precision.This structure is optimized for iteration speed and spatial queries that benefit from a bounding volume hierarchy (like
raycasting). Finding a single node by NodeKey
starting from the root should be minimized as much as
possible, so you might find it useful to cache NodePtr
s or amortize the search with a full tree
traversal. Memory usage is decent given the simplicity of the implementation, and the pointer overhead is easily amortized
by using dense chunk values.
NodeKey
: O(depth)NodePtr
: O(1)size_of::<T>()
bytessize_of::<T>() + CHILDREN * 4
bytesCHILDREN=4
for a quadtree and CHILDREN=8
for an octreeLicense: MIT OR Apache-2.0