Physics API improvements

[philpax]

As requested by @SK83RJOSH and with other suggestions by me. I'm publicly sketching these out before I implement them:

• [ ] #162
• [ ] #161
• [ ] #182
• [ ] Reading / setting mass through the component
• [x] physics::get_velocity_at_position: a way to read the velocity of a physics object at a given position relative to the object. Need to make it clear what coordinate space it's in.
• [x] physics::apply_force should have ForceMode parameter (Acceleration, Force, Impulse, VelocityChange)
• [ ] (maybe) control over whether the object should be woken for both physics::apply_force/physics::apply_force_at_position
• [x] physics::apply_force_at_position or an optional position parameter for apply_force. Need to make it clear what coordinate space it's in.
• [ ] physics::toggle_collisions_between(ent1, ent2, enabled): there's quite a bit of nuance here. Not sure if this is the API we should expose, or if we should expose collision layers, or if users should be able to register their own collision handlers. Need to study what other engines do here.
• [ ] physics::sweep: like raycast, but tells you if an object will collide with something else.
• [ ] sweep and raycast: Expose all available information. At present, we return the collided-with entity and the distance at which the collision should occur. PhysX also provides us with the exact position, normal, and information about the face index/terrain UV. The normal especially is useful for gameplay.
• [ ] inertia_tensor: Vec3 component, like Unity's inertiaTensor.

Something else to keep in mind that whatever we expose should be portable to other physics engines, too. We may support other physics engines to enable certain applications / deployments.

Feel free to suggest other features of interest that you would like exposed. I'd like to ensure that they all have a consistent interface, which is why I'm not going to nail any of these down until I have a good idea of what should be implemented.

[SK83RJOSH]

For collision filtering, we're going to need to make some refactors to the physics set up in the ECS:

• [ ] Remove physics_shape(): PxShape, and instead create a new entity for each shape
• [ ] Add a new component to each physics entity physics_shapes(): Vec<EntityId>
• [ ] Add a new component to each physics shape physics_filter_data(): PxFilterData
• [ ] Devise a solution for user defined physics layers
• [ ] Store filtering data for layers in PxFilterData using word0/word1 (layer, mask; or entity_id?)
• [ ] Devise a solution for filtering collisions between shapes (likely using a resource: Map<entity_id, Vec))
• [ ] Store filtering data for shapes in PxFilterData using word2/word3 (entity_id?)

If we do the first half of this list, we can clean up a number of things, which will make things like mass() a lot easier to implement / more fine grained. It will also mean we have a good basis to do raycast filters in the future.

Some suggestions for refactoring raycasts:

• [ ] Raycast functions should accept a list of layers that are either blocking or non-blocking
• [ ] physics::raycast() should return the first blocking hit, and ignore non-blocking
• [ ] physics::raycast_multi() should return all hits, up to the first blocking hit

With these changes, we can significantly reduce the complexity of things like:

• Visibility queries (for say, highlighting objects in our vicinity) using raycast_multi() to add a penalty for each objects in a "foliage" layer, and bail out if we hit a blocking layer
• Bullet penetration logic using raycast_multi() to decrease damage for every object in a "bullet_penetration" layer, and apply damage to the first blocking entity
• Etc

[philpax]

All that sounds good to me. @FredrikNoren ?

[FredrikNoren]

Yup sounds great!

[droqen]

Physics collisions: I'd like to request customizable individual collision behaviours. My use case is a plane_collider that I'm using to detect where on the water's surface the player has clicked, but I don't want this to collide with anything else, at all.

It's purely for this one raycast, so toggling everything to not collide with it would be pretty annoying.

Most commonly I see collision layers. Godot has "layer" and "mask" as separate bitwise flags, so I can say my entity is a layer 2&3&4 entity and hits layer 1&2 entities. I don't exactly get why it works that way, but it has always worked well for every use case that I've encountered.