Shape component should be on the parent entity, not the child entity

[MarkDDR]

Currently, an entity's shape is stored on a child entity, when it could just as well be stored directly on the parent entity itself. While storing it directly on the parent loses the ability for an entity to have multiple collision shapes, having multiple collision shapes is fairly rare. Plus having it be on the parent makes more intuitive sense

// Before, shape on child
 commands
        .spawn(SpriteComponents {
            material: materials.add(icon.into()),
            ..Default::default()
        })
        .with(
            RigidBody::new(Mass::Real(1.0))
                .with_status(Status::Semikinematic)
                .with_position(Vec2::new(0.0, 0.0))
        )
        .with_children(|parent| {
            parent.spawn((Shape::from(Size2::new(30.0, 30.0)),));
        });

// After, shape on parent
 commands
        .spawn(SpriteComponents {
            material: materials.add(icon.into()),
            ..Default::default()
        })
        .with(
            RigidBody::new(Mass::Real(1.0))
                .with_status(Status::Semikinematic)
                .with_position(Vec2::new(0.0, 0.0))
        )
        .with(Shape::from(Size2::new(30.0, 30.0)));

[sim-the-bean]

I think having only shapes as entities or only shapes as components are both bad choices. I'll take a look if both options can be supported simultaneously (I think it's possible with no extra run-time cost).

In my opinion having the shape be a component on the parent greatly simplifies the API, so it's A Good Thing™.

[troligtvis]

Disclaimer, I am not that familiar with child entities. But if you are allowed to have multiple of the same component I think it make perfect sense.

If you make a platformer where as the player can detect ground, wall jump, edge grab (like dead cells) etc, then you might need collision for ground, side collision and then perhaps a separate for edge detection. Also one might need a shape to detect damage 🤷‍♂️

But if that can't be solved with child entities then I rest my case :)

[sim-the-bean]

@troligtvis Good point. When you have multiple child shapes, you sometimes want them to do different things (not always, sometimes). In the current architecture this would be only possible by having multiple bodies attached to the "main body" through fixed (or some other) joints. I'll also take a look if the API wouldn't be too complex if manifolds also included some data on which collision shape actually collided with the other thing, like the wall or edge, like you say.