You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,6 +33,7 @@ Rust-optimized quadtree with a clean Python API
33
33
- Fast KNN and range queries
34
34
- Optional object tracking for id ↔ object mapping
35
35
- Fast [serialization](https://elan456.github.io/fastquadtree/benchmark/#serialization-vs-rebuild) to/from bytes
36
+
- Support for multiple data types (f32, f64, i32, i64) for coordinates
36
37
-[100% test coverage](https://codecov.io/gh/Elan456/fastquadtree) and CI on GitHub Actions
37
38
- Offers a drop-in [pyqtree shim](https://elan456.github.io/fastquadtree/benchmark/#pyqtree-drop-in-shim-performance-gains) that is 6.567x faster while keeping the same API
Copy file name to clipboardExpand all lines: docs/future_features.md
+13-12Lines changed: 13 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,27 +9,19 @@ The features will likely be implemented in the order they are listed below, but
9
9
10
10
## 🚧 Planned Features
11
11
12
-
### 1. Configurable Quadtree Coordinate Type
13
-
14
-
Currently, the point quadtree only uses f32 for point coordinates, limiting precision in favor of better performance.
15
-
To make the quadtree more flexible, we could allow users to specify the coordinate type (e.g., f64, i32, etc.) when creating a quadtree.
16
-
The f32 will remain the default, but users will be able to specify a different type if needed.
17
-
18
-
If the type cannot be made truly generic, then only the following types would be supported: f32, f64, i32, i64
19
-
20
-
### 2. KNN with criteria function
12
+
### 1. KNN with criteria function
21
13
22
14
Currently, KNN only supports finding the nearest neighbors based on euclidean distance.
23
15
By adding a criteria function, we could allow users to define custom criteria for finding neighbors by passing a function that
24
16
takes in a point and returns a score. The KNN algorithm would then use this score to determine the nearest neighbors.
25
17
26
-
### 3. KNN in rectangle quadtree
18
+
### 2. KNN in rectangle quadtree
27
19
28
20
Currently, KNN is only supported in the point quadtree. By adding KNN support to the rectangle quadtree, we could allow users to find the nearest rectangles to a given point. This would be to the nearest edge of the rectangle, adding complexity to the algorithm.
29
21
However, it will allow for really quick collision detection between a point and a set of rectangles as the point can just do
30
22
robust-collision handling with the nearest rectangles.
31
23
32
-
### 4. Circle support
24
+
### 3. Circle support
33
25
34
26
Currently, we support points and rectangles in two separate quadtrees.
35
27
For example, in the ball-pit demo, we use a point quadtree, but then query a larger area to account for the radius of the balls.
@@ -41,6 +33,15 @@ A good alternative is to use the rectangle quadtree and insert the minimum bound
41
33
42
34
Once a feature from above is completed, it will be moved to this section.
43
35
44
-
### Quadtree serialization
36
+
37
+
### Configurable Quadtree Coordinate Type (1.3.0)
38
+
39
+
Currently, the point quadtree only uses f32 for point coordinates, limiting precision in favor of better performance.
40
+
To make the quadtree more flexible, we could allow users to specify the coordinate type (e.g., f64, i32, etc.) when creating a quadtree.
41
+
The f32 will remain the default, but users will be able to specify a different type if needed.
42
+
43
+
If the type cannot be made truly generic, then only the following types would be supported: f32, f64, i32, i64
44
+
45
+
### Quadtree serialization (1.2.0)
45
46
46
47
By serializing the quadtree, we can save its state to a file and load it later. This will allow us to persist the quadtree structure and data across sessions. For example, you could pre build a quadtree with all the walls in your video game level, serialize it to a file, and then load it when the game starts. This will heavily reduce the game load time since you won't have to rebuild the quadtree from scratch every time.
0 commit comments