Open philpax opened 1 year ago
For collision filtering, we're going to need to make some refactors to the physics set up in the ECS:
physics_shape(): PxShape
, and instead create a new entity for each shapephysics_shapes(): Vec<EntityId>
physics_filter_data(): PxFilterData
PxFilterData
using word0
/word1
(layer, mask; or entity_id?)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:
physics::raycast()
should return the first blocking hit, and ignore non-blockingphysics::raycast_multi()
should return all hits, up to the first blocking hitWith these changes, we can significantly reduce the complexity of things like:
raycast_multi()
to add a penalty for each objects in a "foliage" layer, and bail out if we hit a blocking layerraycast_multi()
to decrease damage for every object in a "bullet_penetration" layer, and apply damage to the first blocking entityAll that sounds good to me. @FredrikNoren ?
Yup sounds great!
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.
As requested by @SK83RJOSH and with other suggestions by me. I'm publicly sketching these out before I implement them:
mass
through the componentphysics::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.physics::apply_force
should haveForceMode
parameter (Acceleration, Force, Impulse, VelocityChange)physics::apply_force
/physics::apply_force_at_position
physics::apply_force_at_position
or an optionalposition
parameter forapply_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
: likeraycast
, but tells you if an object will collide with something else.sweep
andraycast
: 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'sinertiaTensor
.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.