search

playcanvas / engine

Powerful web graphics runtime built on WebGL, WebGPU, WebXR and glTF
https://playcanvas.com
MIT License
9.73k stars 1.36k forks source link

Beta release of JointComponent #7135

Open willeastcott opened 2 days ago

willeastcott commented 2 days ago

Releases the JointComponent API in beta. For anyone with physics experience, please take a look and offer your thoughts/comments.

Also added a new rope bridge engine example:

https://github.com/user-attachments/assets/aeccddca-2350-4636-89b4-7335dd0a1f78

API reference:

image

I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

LeXXik commented 11 hours ago

I always welcome a constraints component, which I think was missing for a while. There are so many cases where it could be used for interactivity. However, I am not sure of the design. Not that it is wrong, but that there is no definite standard for it so far, so it is up to discussion.

For example, if the ball falling on the bridge disables an entity it touches, then I would expect the bridge would behave as if it would have been cut in the middle. However, that is not the case, since a constraint is its own entity and lives its own life. The bridge would probably fall apart with a constraint still alive that is very soft, like a chewing gum.

Also, I remember making a game for one company, where you would draw a wheel for a vehicle to traverse a terrain. Once you drew a wheel, it would replace the old one, which was connected with a hinge constraint. There was an Ammo crash, when PlayCanvas was trying to destroy a rigidbody (due to hierarchy change) before the constraint. There should be a test case to cover that at least.

willeastcott commented 10 hours ago

@LeXXik The main things I'm still unsure of relate to the following:

  1. Should I collapse the X, Y, Z number properties into Vec3 properties? e.g. angularDampingX, angularDampingY and angularDampingZ becomes angularDamping. This will collapse the API into something much simpler, of course. But I'm wondering whether this might be annoying if you only are concerned with configuring a one or maybe two axes. Maybe there'd be other down sides I'm not considering?
  2. The current implementation just wraps the btGeneric6DofSpringConstraint. Ammo has specific classes for handling other joint types (like hinge, ball-socket, etc). I'm wondering if those specialized joint types are more stable than the generic 6dof joint.
  3. At the moment, it is assumed the joint component's entity is neither entityA or entityB (so you have to create a separate entity for joints). But should the JointComponent be placed on entityA and entityB would be connectedEntity perhaps? I could add jointOffset too (with reference to the owner entity's transform).
Maksims commented 1 hour ago

I think join should be created on any entity, event on third one, and by defining entityA and entityB, which can be self, would work. Otherwise it might be too constraining to the user. Also, it will make it easier to copy joints and re-use them between different rigidbodies.