Commit graph

3 commits

Author SHA1 Message Date
Rémi Verschelde
49646383f1
Update copyright statements to 2021
Happy new year to the wonderful Godot community!

2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.

We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)

Here's to a great year 2021 for all Godot users 🎆

(cherry picked from commit b5334d14f7)
2021-01-13 16:17:06 +01:00
lawnjelly
690e07b509 Dynamic BVH for rendering and godot physics
Complete rewrite of spatial partitioning using a bounding volume hierarchy rather than octree.

Switchable in project settings between using octree or BVH for rendering and physics.
2021-01-12 12:12:10 +00:00
lawnjelly
667c970b77 Optimize octree and fix octree leak
Prevents adding new octants until a limiting number of elements have been added to the current octant. This enables balancing the benefits of brute force against the benefits of spatial partitioning. The limit can be set per octree.

Project settings are added for rendering octree to set the best balance per project depending on number of tests per frame / tick, and the amount of editing of the octree.

Fixes octants being leaked when removing elements.

Optimize octree with cached linear lists

Storing elements in octants using linked lists is efficient for housekeeping but very slow for testing. This optimization stores additional local_vectors with Element pointers and AABBs which are cached and only updated when a dirty flag is set on the octant.

This is selectable with 2 versions of Octree : Octree and Octree_CL, Octree being the old behaviour. At present the cached list version is only used for the visual server octree (rendering) as it has only been demonstrated to be faster there so far.

This uses slightly more memory (probably a few kb in most cases) but can be significantly faster during testing (culling etc).

Co-authored-by: Sergey Minakov <naithar@icloud.com>
2020-08-18 11:02:21 +01:00