Deprecating and removing group?

[ckaran]

I want to get your opinion before I start work on a small task, just to see if you'd be open to a pull request for it afterwards.

In my earlier pull request, I changed how the cell_width and padding values are given to collider; they are no longer hard-coded when you create HbProfile types, but are passed as arguments to Collider::new. The upshot is that you can create and destroy Collider instances on the fly. Combined with a library like rayon, you can now have code like the following:

extern crate rayon;
use rayon::prelude::*;

let mut collider_set = Vec::new();

// Create and add colliders to collider_set, add hitboxes, etc.

fn set_all_hitbox_vel(&mut collider_set, id: HbId, vel: HbVel) {
    collider_set.par_iter_mut()
         .for_each(|c| c.set_hitbox_vel(id, vel));
}

fn next_time(&collider_set) -> f64 {
    collider_set.part_iter.min().unwrap()
}

// Etc.

which means that all Collider instances will execute concurrently. This may be a significant speed boost over what collider is currently doing.

collider doesn't need to depend on rayon, futures, or anything else, and the behavior I'm describing would work fine with the pull request I made already, but I figure anything that can make execution faster is a good thing, which is why I want to know if I should work to remove the group at all. Are you open to that idea?

[SergiusIW]

Hi, thanks for your interest in Collider! I'll take a look through your pull requests in a moment. I've recently finished another project I've been working on and I'm planning to re-visit and cleanup Collider in the coming months. The group system will either be reworked or removed at that point anyway. Groups were part of Collider when it was originally a Java project, but I haven't used them since porting the project over to Rust.

I think you might be misunderstanding the original purpose of groups, though. The use case is a little niche. But consider for example a manic shooter game, where the screen is filled with bullets, e.g. 40 bullets per grid cell depending on how big the grid cells are. Bullets do not interact with each other but do interact with ships and walls, which occur much more sparsely. Without groups, if a new bullet enters a grid cell, it will have to go through the 40 bullets already there and invoke the can_interact method, which returns false in each case. This is essentially a quadratic cost in the number of hitboxes that is completely unnecessary in this case. Groups can prevent this cost. Though as I said, the use case is fairly niche, and I'm not sure whether the performance gains are as relevant in Rust as they were in my old Java tests.

[ckaran]

Thanks for making and distributing collider! Assuming I can hack code fast enough, it will form the core of the simulator I'm writing for my PhD. dissertation.

I see where the groups come in now; I guess I was a little too focused on my use case, where if things are a part of the same group, then they definitely interact with one another (I'm using Collider in a radio simulator to determine when two moving nodes come into, and go out of, radio communications range with each other).

A thought just came to me, and I haven't looked deeply at the code yet, so if you've already taken care of this, please forgive me. Imagine that you have 3 groups, 1, 2, and 3. 1 interacts with 2, 2 with 3, and 3 with 1. Now have 3 balls rolling at each other, each in a different group; what happens? What should happen?

If you are planning on removing groups, an alternative might be to use rayon within the grid code, making each cell be a different work unit. I'm not sure if it will work yet or not, it was just a thought that I came up with now.