Closes: #170

Added the StagedPhysicsPlugin which allows you to pass in stage labels for the main physics schedule, the post physics stage, and tick stage.

The main physics needs to be a schedule and not just a stage since it uses sub stages. The other two are fine as just stages.

Creating as a draft since I'm not sure the best way to add tests for this. I made an example custom_schedule.rs which is basically just the demo example using the new plugin.

I'm still somewhat new to bevy/heron so let me know if the comments I added don't make sense

This PR adds an additional field to the PendingConvexCollision to set collision layers. I realized that setting default collision is needed only for the generated collision. In all other cases user can define needed collision layer explicitly. Closes #217.

Closes #207.

I added a component that automatically filled with colliding object entities.

Things to discuss:

• I used CollidingEntities because the suggested Collision could be confusing (and already used in Bevy, but not in prelude). Is this okay name?
• Should we provide Deref for CollidingEntities?

Should fix #145 also help with #142 test not passing and replace #146.

Fixed the problem by reusing update_rapier_velocity for dynamic and made for all bodies that can_have_velocity. So removed redundant apply_velocity_to_kinematic_bodies in favor of update_rapier_position.

I think this should be a bit urgent since it's a somewhat 'core' functionality and a few people have asked help on why it wasn't working in the bevy discord.

Adds normal data from ContactManifoldData::normal to the CollisionData struct.

Benefits

• Normal vector added to collision data

Downsides

• I had to remove Copy from CollisionData due to the normals being in a Vec<Vec2>. We could just provide the first normal Vec2 as an Option<Vec2>, but I'm not sure whats the best option for this.

Fixes https://github.com/jcornaz/heron/issues/188

Resolves #35 .

Untested, but it should provide a very convenient and easy-to-use API for ray and shape casting. Extra queries such as intersection queries can be added easily later, too.

I'll add a example to test that it's working before marking it ready to merge.

Currently, the heron crate doesn't expose anything unless either the 2D or 3D features are enabled, but enabling either of those features also enables the debug renderer. This makes it impossible to use heron without enabling the debug rendering crates.

My projects use Bevy Retrograde, which uses a custom renderer on top of Bevy that won't compile when bevy's rendering features are enabled. Because the debug crates require Bevy's rendering features, there's no combination of features under which I can compile heron for use in Bevy Retrograde.

This change makes it required to pass in the debug-2d or debug-3d features in order to actually include the heron_debug. This allows me to run my project without including bevy's rendering features.

I'm not sure this is the best way to do it and I'm totally open to any other options, as long as there is some way to compile without needing heron_debug.

When I enable the debug-2d feature transform scales seem to stop working, also I have a little system to zoom in and out the camera that also stops working. With this it becomes a bit hard to debug because the size of the debugs don't match the sprite.

Opening this as a draft for https://github.com/jcornaz/heron/issues/41 and as a place to ask for help with potential issues regarding it.

In it's current state i'm faced with the following errors.

thread '<unnamed>' panicked at 'index out of bounds: the len is 128 but the index is 128', C:\Users\domen\.cargo\registry\src\github.com-1ecc6299db9ec823\rapier3d-0.5.0\src\dynamics\solver\interaction_groups.rs:89:21

I noticed that this feature is under the 'parallel' feature and tried to disable it. Once I did that I got the following error.

thread 'main' panicked at 'assertion failed: proxy.aabb.mins[dim] <= self.max_bound', C:\Users\domen\.cargo\registry\src\github.com-1ecc6299db9ec823\rapier3d-0.5.0\src\geometry\broad_phase_multi_sap.rs:171:13

As of now all the code required to produce the Vec and Vec<[u32; 3]> pair from Asset lives in my project https://github.com/Dmajster/radwars. So if you wish to reproduce this errors or help out I think this would be the fastest path.

I also think this would be a great feature to move this into Heron down the road.

Just a simple method call also events were already activated so the collision types was basically the same. Had to do it in 3 commits because I'm not getting any intellisense and no compile errors so I wen't for trial and error. Should be able to fix #140.

Resolves #62

Some notes:

• I went with a Vec<Vec<f32>> to define the heights, both in 2D and 3D (and only take the first sub-vec in account in 2D). I couldn't get #[cfg(features)] to work as I wanted
• I'm not sure about the debug implementation, because I don't know much about lyon. I'll probably add a heightfield to the debug example to see if it does what I expect.
• The scale that rapier expects is actually more the dimensions of the field, so I had to do a little conversion.
• Also, it looks like rapier/parry always centers the heightfield. Is there anything I need to do to update the transform of a collision shape in rapier when it is updated in bevy?

i have 4 physics layers in my app, the entitys that can collide have collision layers like below, the player, and the enemys have collision shapes on child entitys, im not sure if its because i have the physics layers organized wrong or if i have some other thing shooting me in the foot, but ive tried quite a few different combos of groups/masks/layers to no real effect. i also noticed that no matter what i do my players/enemys always collide, even when both have CollisionLayers::none() or i mask them out

i took the collision detection event system from the examples to test the sensor and i noticed that my player and skeleton entitys have an obscenely large amount of groups/masks

heres the output from an event reader for collisionevent

Collision started between CollisionData { rigid_body_entity: 2729v0, collision_shape_entity: 2729v0, collision_layers: CollisionLayers { groups: 8, masks: 2 }, normals: [] } and CollisionData { rigid_body_entity: 2812v0, collision_shape_entity: 2813v0, collision_layers: CollisionLayers { groups: 4294967295, masks: 4294967295 }, normals: [] }
Collision stopped between CollisionData { rigid_body_entity: 2729v0, collision_shape_entity: 2729v0, collision_layers: CollisionLayers { groups: 8, masks: 2 }, normals: [] } and CollisionData { rigid_body_entity: 2812v0, collision_shape_entity: 2813v0, collision_layers: CollisionLayers { groups: 4294967295, masks: 4294967295 }, normals: [] }

im marking my Sensor entity with :

collision_layers: CollisionLayers::none()
					.with_group(PhysicsLayers::Sensor)
					.with_mask(PhysicsLayers::Player)

im marking my walls with:

collision_layers: CollisionLayers::none()
                    .with_group(PhysicsLayers::World)
                    .with_masks(&[PhysicsLayers::Player, PhysicsLayers::Enemies])

im spawning my player with:

collisionlayers: CollisionLayers::none()
                    .with_group(PhysicsLayers::Player)

and im marking my enemies with

collisionlayers: CollisionLayers::none()
                                .with_group(PhysicsLayers::Enemies)

physicslayers is my enum for things that can collide

#[derive(PhysicsLayer)]
pub enum PhysicsLayers {
	Sensor,
    World,
    Player,
    Enemies,
}

I've made an example project where a collision event should fire. It does not fire in 9/10 case though

https://github.com/stillonearth/bevy_dice/tree/c18abc62eb490aa0418d824bd23c2662eea7f48d

I've collider issues when colliding objects on high velocities, but it seems somehow related here. Collision itself happens, though no events.

~~The screenshot above was taken by using CodeLLDB and stepping through the execution of Rust code.~~

~~As you can see, pre-normalization the ray vector is about (12, 15, -98) which is actually a unit vector with its magnitude x100.~~ ~~That means we'd expect the normalized vector to be around (0.12, 0.15, -0.98)~~

~~After normalization (assigned to direction) the vector is (-0.98, 0, 0).~~

~~The -0.98 value placed in the x scalar slot should be placed in the z scalar slot, and the x and y scalars are not present at all.~~

~~Now, CodeLLDB isn't perfect, it may not be mapping the memory values correctly, so this may essentially be a visual bug with the debugger.~~

~~However, I am experiencing a bug where I'm casting a ray through some collider shapes, and the ray cast always returns None, even when I confirm the start and ray vectors would correctly cause the ray to pass through the location of the collider shapes.~~

~~The vector normalization misalignment is the best lead I have so far.~~

For the sake of completeness,, I've attached below a copy a post I made asking for help in the Bevy Discord server. If there's an obvious bug there that would cause the raycast to not detect the collision shapes, then I think it's reasonable to chalk up the erroneous vector normalization to a debugger memory layout bug.

However, if the attached code looks correct, then as above, this vector normalization bug is the best lead I have for a root cause.

help.md

when using Heron 2dDebug feature flag, there is a conflict with a shapes stage that exist in bevy_prototype_lyon = "0.5.0"

thread 'main' panicked at 'Stage already exists: Shape.',

@bit-garden rightfully explained here why it is important to not use the pixel as a unit, but rather meter* instead.

*: it is not really about "meter", but rather using a unit for simulation so that object sizes are close to 1. So a game that simulates planetary bodies may use Mm, and a game at a microscopic scale may better use µm.

But that is not so intuitive for users who just start with heron, and they can encounter strange behavior (like #276).

So, here is what we should do to improve heron in this area:

• [ ] Update documentation to recommend using SI units as well as discourage using pixel as a unit
• [ ] Update heron examples to follow that recommendation and show how to use a different unit-scale for the physics than pixels
• [ ] Provide a metric-scale resource, so that heron automatically translates the pixel-unit of transforms into meters in the rapier simulation (something inspired by bevy_rapier's solution)