Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support slippery ground #10

Open
idanarye opened this issue Apr 3, 2023 · 3 comments
Open

Support slippery ground #10

idanarye opened this issue Apr 3, 2023 · 3 comments

Comments

@idanarye
Copy link
Owner

idanarye commented Apr 3, 2023

No description provided.

@idanarye
Copy link
Owner Author

idanarye commented Jun 5, 2023

This may be implemented as part of #11.

@dror-g
Copy link

dror-g commented Feb 1, 2024

Hi, small problem that might be related to this - Rapier collider friction seems to be ignored / overridden.
If using rounded colliders like ball or a capsule on its side - entities with such colliders can climb on top one another.
Biggest effect on this behaviour is basis acceleration. the default of 60 gives snappy response, but is also strong enough to climb a rounded shape.
Setting the sensor to a shape, even rounded, rather than the default ray makes it even worse as the entity can walk past the "edge" of the rounded entity it's on even further.
When setting tilt_offset_angacl to a low value like 100 or 10, one entity will roll off another, but it still won't slide off as expected from a frictionless sphere.
Perhaps the problem is the StandingOn property detection?

Reducing acceleration is an easy workaround but characters will be not as snappy.
Of course one could avoid setting AI entities to walk to the same exact point (that's how I get "stacking"), or use a very tall collider perhaps...

But if there's a way to respect friction / slippery colliders that would be great.
Thanks!

@idanarye
Copy link
Owner Author

idanarye commented Feb 1, 2024

Rapier's collider friction is neither ignored nor overridden - it simply does not take effect to begin with, because the character's collider is floating above the ground, not touching it.

I don't have a clear design for this feature yet, but one thing is for certain - it'll have to involve reading the collider entity and the normal from the ray/shape cast, and deciding based on that. This means there are two big decisions to make:

  1. Should Tnua read the physics backend's collider friction parameters?
  2. Should this be done inside Tnua's systems, or inside the user control system (which also has access to the ray/shape cast data, and which can alter the TnuaBuiltinWalk basis using that information)?

I'm leaning toward not relying on the physics backend's collider friction parameters, and through implementing this in the user control system (and provide helpers, of course) - but I'm not sure what exactly I want it to pass to the basis...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants