Is there a way to customize bounce behavior?

[Alic]

I'm having a bit of trouble with CollisionResponseSettings.BouncinessVelocityThreshold. If I set it high enough that objects stop bouncing on the ground as soon as I want them to, then objects which are flying at walls often simply stop and fall to the ground, or slide along the wall, instead of bouncing off the wall. The reason I'm trying to set BouncinessVelocityThreshold so high (around .3 to .5, with most objects in the sim scaled between .5 and 10 units) is that if I don't, objects continue to bounce very minutely for several seconds after they seem like they should have come to rest on the ground. This also makes on collision events which fire off things like sound effects not work very well, because the sounds trigger over and over again every few frames from the tiny, invisible bouncing. This behavior is probably mostly due to my setting the gravity vector at somewhere between -26 and -40 -- I'm leaning toward the latter to get a nice, non-floaty jump feel.

Anyway, I'm wondering if there's a way to provide the engine a new method for bounce response, or some way to distinguish between y velocity (vertical for me) versus x and z horizontal velocity for the purpose of bouncing response. If not, should I just check for the speed that things bounce on the ground with and dampen/remove their y velocity if its below a certain speed? Thanks a lot Norbo,


Alex


p.s. Also, I am aware I could simply limit bounce sound effects and graphical effects and whatnot to when a certain collision force of bounce with the ground has occurred, thus discounting the tiny bounces. The problem I have with this is that I have, for example, a creature I want to detect when it has completely stopped bouncing and then launch itself into the air again. So in other words, I am basing some AI behavior off of the bounce behavior, in addition to aesthetic effects.

[Norbo]

Before I go into bounciness:

This behavior is probably mostly due to my setting the gravity vector at somewhere between -26 and -40 -- I'm leaning toward the latter to get a nice, non-floaty jump feel.

If the character is about 2 units tall, a gravity with a magnitude of around 10 units should produce a completely realistic result. Did you just want a much faster fall (perhaps because the character can jump huge distances compared to a real human, like in a platformer), or did 10 units of gravity feel insufficient for a regular humanly-jumping character?

If it's the latter, there may be something wrong with the time step rate that makes the game feel like it's in slow motion because less simulation time is passing per unit of real time.

This also makes on collision events which fire off things like sound effects not work very well, because the sounds trigger over and over again every few frames from the tiny, invisible bouncing.

Even if you address the bounciness behavior, it may still be worth taking into account the contact impulse strength to modulate the sound volume (part of the ContactInformation contained in Pair.Contacts lists). Tiny impacts would be quieter, heavy impacts would be louder. Edit: Oops, wrote this before the p.s.

The reason I'm trying to set BouncinessVelocityThreshold so high (around .3 to .5, with most objects in the sim scaled between .5 and 10 units) is that if I don't, objects continue to bounce very minutely for several seconds after they seem like they should have come to rest on the ground...

Anyway, I'm wondering if there's a way to provide the engine a new method for bounce response, or some way to distinguish between y velocity (vertical for me) versus x and z horizontal velocity for the purpose of bouncing response. If not, should I just check for the speed that things bounce on the ground with and dampen/remove their y velocity if its below a certain speed?

Unfortunately, there's no built in support for custom bounciness behavior. You could, however, make a modification to allow it.

At line 191 in ContactPenetrationConstraint (in the development fork, at least), it looks like this right now:

Code: Select all

                    if (relativeVelocity > CollisionResponseSettings.BouncinessVelocityThreshold)
                        bias = MathHelper.Max(relativeVelocity * contactManifoldConstraint.materialInteraction.Bounciness, bias);

You want the bounciness velocity threshold to be higher for contact normals aligned with the y axis, so one option is to just scale the CollisionResponseSettings.BouncinessVelocityThreshold by the y value of the normal. This will reduce the threshold to zero when the normal is horizontal (you may want to add a little bit to keep it above zero).

Code: Select all

                    if (relativeVelocity > SomeExtraToKeepItAboveZero + Math.Abs(contact.Normal.Y) * CollisionResponseSettings.BouncinessVelocityThreshold)
                        bias = MathHelper.Max(relativeVelocity * contactManifoldConstraint.materialInteraction.Bounciness, bias);

Damping the object when it's slow could help some too. This already exists in the engine; you could increase the Space.DeactivationManager.VelocityLowerLimit so that stabilization will take effect more often (and objects will go to sleep more aggressively), but this is not a direct approach.

If there's sufficient CPU budget, you may find that increasing the frequency of time steps (perhaps a Space.TimeStepSettings.TimeStepDuration of 1/120f or even 1/180f instead of 1/60f) improves the simulation quality a whole bunch without having to do any of the above. The core problem is the large size of gravity relative to the object size and time step, after all.

[Alic]

brilliant, thanks a lot Norbo! I am indeed going for very unrealistic, platformery physics. The game is basically like A Link to the Past, or perhaps Secret of Mana, except obviously, with far more complex physics and jumping integrated into the gameplay... so maybe the Ys games would be a more apt comparison. And with a nice new art style (if I do say so myself) hopefully running at 1080p

Sound volume modulation for impacts is definitely on my to-do list. Right now I am resisting implementing too much of the sound because of the constantly changing monogame library and its several different approaches to sound. (Started out using XACT which is not monogame compatible, haven't rewritten that yet.)

I will probably modify the source code. Exciting! Up until now BEPU is the only open source project I'm using which I haven't modified to my own ends... but maybe that ends today! (Frankly if you hadn't posted the code yourself, I would have been too scared to attempt it. I know you hear it a lot, but BEPU really is an amazing and complex piece of work.) Thanks so much for all of your time!

Alex