a library for generating 2d colliders, for bevy apps, from images with transparency

by default, both bevy_rapier2d and avian2d (formerly bevy_xpbd_2d) are enabled. this is to help with the out of box experience, specifically, being able to run both examples and tinker.

but you'll probably only want to just use one of the physics engines supported so when you use it in your own crate fill in in the bevy_collider_gen dependencies with something like this for bevy_rapier2d

[dependencies.bevy_collider_gen]
# replace "*" with the most recent version of bevy_collider_gen
version = "*"
features = ["rapier2d"]
default-features = false

or this for avian2d

[dependencies.bevy_collider_gen]
# replace "*" with the most recent version of bevy_collider_gen
version = "*"
features = ["avian2d"]
default-features = false

to see this in action you can run the example, with no args it generates a scene with various colliders using pngs in the assets/sprite directory

cargo run --example rapier2d_colliders

cargo run --example avian2d_colliders

you can also specify a path to an image yourself the example will attempt to generate one or more convex_polyline colliders for the objects it finds

i was looking for a way to iterate on some 2d scenes with colliders on things with more sophisticated shapes than simple geometry, i figured there should be enough info in an image with transparency to generate colliders, and... there is! so i packaged up my approach here in case anyone else could benefit.

😄 head on over to the edges crate to learn more https://github.com/shnewto/edges

• as mentioned here and there in these docs, this implementation requires images to have transparency in order to distinguish object from non-object :)
• i imagine for generating things at a larger scale, i.e. colliders for sets of sprites bigger than pixel counts in the hundreds, this implementation won't be performant to do at runtime. i'll suggest serializing the colliders you like and deserializing in your app instead of doing all the number crunching on load when you need a performance boost

(as in pictures of the sort of thing you can expect, not the runnable bevy app example. that's a couple headings up)

the current implementation does best if the image you're generating a heightfield from is either centered in the image or spans the entire width of the image...

I didn't add support for convex decomposition directly because when sprites were small, and collisions were forceful, they were sort of unreliable (occasional panics because of bounds indexing in rapier's dependencies 💀). But if you wanted to use convex decomposition colliders you could construct them with the edge coordinates from your image with something like this

let sprite_image = image_assets.get(sprite_handle.unwrap()).unwrap();
let edges = Edges::from(sprite_image)
let edge_coordinate_groups = edges.multi_image_edge_translated();
for coords in edge_coordinate_groups {
    let indices: Vec<[u32; 2]> = (0..coords.len()).map(|i| [i as u32, i as u32]).collect();
    let collider = Collider::convex_decomposition(&coords, &indices);
    commands.spawn((
        collider,
        RigidBody::Fixed,
        SpriteBundle {
            texture: sprite_handle.unwrap().clone(),
            ..default()
        },
    ));
}

all code in this repository is dual-licensed under either:

• MIT License (LICENSE-MIT or https://opensource.org/licenses/MIT)
• Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)

at your option.