Why does `intersect_with_mut` takes `Fn`?

[WaDelma]

I wanted to call it with FnMut and was surprised that it didn't work. Is there reason why it's using Fn?

[WaDelma]

Also would it make sense to have method that takes in another Tree and goes through all intersections between the two trees?

[WaDelma]

Basically here I am trying to optimize by splitting moving and static entities to two groups. If I could just construct two Trees and check intersections in the movable entities tree and intersections between moving and static entity trees I would be golden.

[tiby312]

@WaDelma that is a great idea to accept another tree, but I'm not sure exactly how to do it. My notes in the source:

   pub fn intersect_with_mut<X: Aabb<Num = T::Num>>(
        &mut self,
        other: &mut [X],
        func: impl Fn(PMut<T>, PMut<X>),
    ) {
        //TODO instead of create just a list of BBox, construct a tree using the dividers of the current tree.
        //This way we can parallelize this function.
        //Find all intersecting pairs between the elements in this tree, and the specified elements.
        //No intersecting pairs within each group are looked for, only those between the two groups.
        //For best performance the group that this tree is built around should be the bigger of the two groups.
        //Since the dividers of the tree are used to divide and conquer the problem.
        //If the other group is bigger, consider building the DinoTree around that group instead, and
        //leave this group has a list of bots.
        //
        //Currently this is implemented naively using for_all_intersect_rect_mut().
        //But using the api, it is possible to build up a tree using the current trees dividers
        //to exploit the divide and conquer properties of this problem.
        //The two trees could be recursed at the same time to break up the problem.

        for mut i in PMut::new(other).iter_mut() {
            let rect = i.rect();
            self.for_all_intersect_rect_mut(rect, |a| {
                func(a, i.borrow_mut());
            });
        }
    }

As for the reason it doesnt take FnMut? Mistake. I will fix that!

[tiby312]

That said the naive implementation that's in there right now is not ideal, but its not that slow in that its just linear time, unlike a naive for_ever_colliding_pair which is n^2.

[WaDelma]

You could start with more naive implementation that is convenient and then later on create more optimized one if possible.