Advice for cup shape?

[omegagames]

Hello, first let me say thanks for providing this system, it sure is fun! My issue is I'm trying to make a game of 'beer pong' which involves throwing a ball into one of many cups. I'm not sure if my concave shape is messing everything up or I'm not using the components correctly.

First, I tried dynamic cups and ball, but it seemed that even small movements of the cups led to them colliding in strange ways (they suck each other in essentially, not all the time but often enough to dissuade me from using)

Now I am using Kinematic cups (InstancedMesh) and a dynamic ball. Even still, I am having problems when I launch the ball, where sometimes the ball will get completely stuck in the edge of the cup, sit there for about a second, then get launched out quickly.

I'm also trying to simulate a bouncy ball (bounce = 0.8 ) but have the cups 'soften' the blow a bit (bounce = -0.4) maybe I did this the wrong way? Would it be better to use a single-polygon-thick cup shape? Build the cup out of primitives, like Boxes?

In the 'harder' cases of the ball bouncing around the walls of the cup, BEPU is doing very well. I just need to get it bouncing off the edge of the cup better. Thank you for any help you can provide!

[Norbo]

First, I tried dynamic cups and ball, but it seemed that even small movements of the cups led to them colliding in strange ways (they suck each other in essentially, not all the time but often enough to dissuade me from using)

Now I am using Kinematic cups (InstancedMesh) and a dynamic ball. Even still, I am having problems when I launch the ball, where sometimes the ball will get completely stuck in the edge of the cup, sit there for about a second, then get launched out quickly.

It sounds like something about the geometry may be confusing collision detection.

Inconsistent winding is one possibility; if the triangles don't have the same winding and Counterclockwise or Clockwise winding is used for the mesh, some triangles will be transparent to objects and others will not. An easy test for this is drawing the mesh with backface culling on or seeing if the DoubleSided mesh sidedness fixes the issue.

Degenerate triangles (a triangle with three collinear points, for example) could also trigger some weird behavior. The contact generator will have a hard time figuring out which direction to use as the normal and might end up going against neighboring triangles. The occasional constraint-fight would be expected.

If you are currently using DoubleSided winding, consider using one of the one-sided options. They're generally a little cleaner. At the very least, when objects do manage to get inside, they can get back out very quickly as nothing is stopping them.

If it's not related to the geometry, it may have something to do with the speed and size of the ball allowing it to penetrate the surface of the model in one step. In this case, try setting the ball.PositionUpdateMode = PositionUpdateMode.Continuous. This will perform swept collision detection between the ball and the mesh, preventing it from flying through the surface due to high speeds.

Now I am using Kinematic cups (InstancedMesh) and a dynamic ball.

Small side note to avoid some possible confusion: An InstancedMesh is considered static, which is distinct from kinematic. Kinematic implies the object is capable of motion defined by velocities while ignoring forces. Dynamic means they can move according to forces and respond to collisions. In BEPUphysics, Entity objects are capable of being either kinematic or dynamic since the defining feature of the Entity class is its mobility. In constrast, static objects like the Terrain, InstancedMesh, and StaticMesh are incapable of motion.

I'm also trying to simulate a bouncy ball (bounce = 0.8 ) but have the cups 'soften' the blow a bit (bounce = -0.4) maybe I did this the wrong way? Would it be better to use a single-polygon-thick cup shape? Build the cup out of primitives, like Boxes?

Negative bounciness isn't physically possible. If the coefficient of restitution between two objects was negative, they would get sucked into each other or generally behave strangely. If you're using v1.1, setting a bounciness of 0.8 on the ball and a bounciness of (positive) 0.4 on the environment mesh would average to 0.6 bounciness. In the development version, the default property blender is multiplicative; 0.8 and 0.4 would become 0.32 bounciness. Just by having a lower bounciness, the cup will soften the bounce without the need for negative values. (Note that the blending approach can be changed in the MaterialManager.)

[omegagames]

Thank you for your reply!

When I used dynamic cups earlier, it is possible that there were some degenerate triangles, as I found some of these on one edge when reviewing the model later. Everything else you mentioned I checked (sidedness) but this one edge might have been the problem.

However to make things a bit easier on myself I am now designing this with (not kinematic, sorry!) static mesh shapes, as moving cups don't add much except headaches. I have tried a ball using Continuous updates mainly, but I did test discrete once or twice and saw little difference. The more I continue the less I've noticed the problem though, so maybe it's gone now...

I'll report more if I can get it to happen consistently, but thank you very much for the help so far.

[omegagames]

Hello again! I'm closer than ever to finishing my beer pong game, and I wanted to get some last-minute advice that might help me tighten my physics. I'll start by saying it is already going quite well, such that I could release it with the current issues. Some interesting effects make me think I'm still a bit misconfigured, and I wonder if there's anything I can still do.

For instance, a small gap is formed between three cups in a triangle shape in the game. I have seen all of the possible outcomes when throwing a ball directly at the hole: bounces away, goes through, and just once it bounced slightly up then rested right on the spot.
The other effect, reported earlier, was the ball simply going through the cup altogether when a shot should have been made. It seems that if you hit the edge of a mesh directly the ball can pass through. However, I fixed the issue with a model adjustment. In the space between my outer and inner cup walls I added a second inward-facing wall, hidden 'inside' of the cup's walls. The second wall was rotated such that the first wall's edges match the center of the second wall's faces. Since then I have not seen a single ball go through a cup, which is great for my purposes.

You mentioned using continuous updates to help with high speeds. I have set both MotionSettings.DefaultPositionUpdateMode and the ball's update mode to continuous, but I don't think the ball is actually being moved in such a manner (based on the effects listed above). Is it possible I'm using objects too small for the default collision system, and if so, what would I want to alter? (I tried to be realistic and use meters for my measurements, ie. the ball's radius is about 0.025, the table is 1.5 x 0.75)

Thanks again for the help and engine, and like I said these aren't game breaking issues so even if no one can figure out why I'm getting this, it's ok by me

[Norbo]

Is it possible I'm using objects too small for the default collision system, and if so, what would I want to alter? (I tried to be realistic and use meters for my measurements, ie. the ball's radius is about 0.025, the table is 1.5 x 0.75)

That scale, without further configuration, would indeed cause problems. Check out the ConfigurationHelper.ApplyScale method in the BEPUphysicsDemos. It modifies a bunch of tuning factors that are affected by the scale interpretation. The ScaleDemo shows it in use.

The default scale interpretation likes dimensions between 0.5 and 10 units or so. It's possible to go outside of that range, but going significantly higher or significantly lower can run into problems with contact manifold management factors. 0.025 qualifies as significantly lower. The fact that it is a sphere saved it from the worst problems, but it's still likely having issues.

Experiment with some ApplyScale values to see what produces better effects. Something like 0.025f would be a good starting point for experimentation. That would basically make the ball behave like it was 1 unit in radius under the default scale interpretation.

This scale problem likely contributes to the other observed problems too. However:

The other effect, reported earlier, was the ball simply going through the cup altogether when a shot should have been made. It seems that if you hit the edge of a mesh directly the ball can pass through.

If an old version of the engine is being used, this may be caused by a now-fixed bug. If an old version of the engine is being used, try updating to v1.2.0 or the development version.

[omegagames]

Thank you for all the help so far. I copied the ApplyScale method to my own code and I'm seeing something strange when I move the value down from 1 toward the 0.025 you suggested. It actually is noticeable sooner, around 0.5, so I think I need you to correct one more mistake of mine

Also full disclose, I'm still on the previous (I think) version so I had to remove a couple settings which don't exist in mine. The ones which compiled were:
CollisionResponseSettings.BouncinessVelocityThreshold *= scale;
CollisionResponseSettings.StaticFrictionVelocityThreshold *= scale;
CollisionDetectionSettings.MaximumContactDistance *= scale;
CollisionDetectionSettings.DefaultMargin *= scale;
CollisionDetectionSettings.AllowedPenetration *= scale;

The issue surrounds simulating the 'water' in each cup. I looked at the buoyancy demo and thought it looked a bit heavy for my needs, but maybe that's the correct choice. What I need is 1) a detector which tells me if a ball rested in a certain cup and 2) a method for heavily decelerating the ball when it is in the bottom of a cup. This is because some shots will fly straight down into a cup and bounce out otherwise.

My solution was to just use one detector volume which halved the ball's linear velocity and linear momentum (and plays a sound for confirmation) when the InitialCollisionDetected event occurred on the detector. This works very well before scaling below 1.0 (about one collision per good shot), but as I do this it seems to create more new contacts with the detector and at the lowest values essentially acts as a force field pushing the ball away (continuously firing the event and playing sounds).

On the plus side, the bounces off of the cups look better as I do this scaling, so if you could help me correct my hacks, I would truly appreciate it!

[Norbo]

It sounds like the version of the engine you're using is over 6 months old. I'd first recommend updating to either the latest stable version or the latest development version and making sure that every part of the ApplyScale method is accounted for- all of them are important. (The two properties were renamed back in January. There are equivalents in that version you could use, but updating to the latest version has a lot of other benefits.)

If the hacks still aren't operating as desired at that point, then another look is warranted. Right now though, I'm not entirely clear on the exact form of the hack, so I couldn't say what to change with any great specificity. Halving momentum alone shouldn't have a repulsive effect or anything like that. I can say, however, that a FluidVolume would indeed be overkill doesn't quite fit the need.

[omegagames]

Hello again! Let me first start by saying thank you - even with all the issues described until now, Drinkards Beer Pong is doing very well on the Xbox LIVE Marketplace, and it wouldn't be possible without your awesome physics powering it!

So now that I've finally caught up with myself, so to speak, I'm trying to upgrade to the latest physics engine. It appears to be the May version 1.2.0, correct?

I checked my old version and believe it was v1.1.0

I simply replaced the reference from the old version to the new, and it compiled without issues. In fact, the entire game is performing as before, and the physics seem even better when the ApplyScale method is actually used.

There is only one thing I need to correct, which is my bounciness setting. If I am understanding correctly, this used to be done by taking the average of the two objects (so a ball w/0.6 bouncing off a table w/0.2 would be 0.4?). Now however the ball never bounces (it has been set to 0.6) so I think I should be updating it and possibly the other objects (table, cups, floor)? Is the new blending mode for bounciness multiplicative?

Please let me know if this material change is the only thing I'd be concerned with. I checked the changelog but its so long its hard to know which items would affect me. And always thanks for the support!

[Norbo]

Hello again! Let me first start by saying thank you - even with all the issues described until now, Drinkards Beer Pong is doing very well on the Xbox LIVE Marketplace, and it wouldn't be possible without your awesome physics powering it!

Thanks and you're welcome! Glad to hear it's doing well

So now that I've finally caught up with myself, so to speak, I'm trying to upgrade to the latest physics engine. It appears to be the May version 1.2.0, correct?

The very latest is technically the development version, though I do not put individual commits on the development fork through significant testing. So, while it may have some bugfixes which v1.2.0 does not have, it may include some changes that aren't quite ready yet (in this case, inverse kinematics is still very much incomplete/broken).

There is only one thing I need to correct, which is my bounciness setting. If I am understanding correctly, this used to be done by taking the average of the two objects (so a ball w/0.6 bouncing off a table w/0.2 would be 0.4?). Now however the ball never bounces (it has been set to 0.6) so I think I should be updating it and possibly the other objects (table, cups, floor)? Is the new blending mode for bounciness multiplicative?

It does indeed default to multiplicative in v1.2.0. You can set the MaterialManager.MaterialBlender to anything, though.

Please let me know if this material change is the only thing I'd be concerned with. I checked the changelog but its so long its hard to know which items would affect me. And always thanks for the support!

One that comes to mind is the Matrix3X3.CreateQuaternion fix which results in the OrientationMatrix setter being consistent with the Quaternion.CreateFromRotationMatrix behavior. In v1.1.0 and before, it would actually set an inverse orientation erroneously. This subtle change bit me once and I know of at least one other person who ran into it. There may be other changes, but if the simulation works as expected, then there's not much to worry about

[omegagames]

Actually I'm still working through a couple upgrade issues, and I'm hoping you can give me some advice.

To fix my bouncing issues I decided to make the non-moving objects have bounciness near 1 (actually 0.95), and kept the ball roughly the same as it was previously (about 0.6).

However the number of times the collision events fire has increased dramatically, leading to my sound effects playing too often. I'm using the ball's InitialCollisionDetected event and playing a table sound or cup sound depending on what the other object is. Before, I would hear about 3-7 cup sounds in the process of sinking a shot, now it is about 8-20.

Also when a ball 'rolls' across the table (Y-velocity should be [near]zero) it never ceases to bounce producing a constant bouncing sound.

But as I adjust the ApplyScale constant from 0.025 back toward 1.0, these effects happen less. However the quality of physics simulation drops (ball pops outside the walls of the cup at high speeds)

The sounds can be fixed easily enough, but I'm worried about the number of collision events increasing by a lot. This might also be the source of new slowdown I am experiencing since the upgrade.

I've looked at the individual settings in Apply Scale, but besides the one with Bounciness in the name I have no clue what to change - and even if that is one setting that should be altered.

I think the combination of tweaks I need is to make my bounces 'die' quicker (is multiplicative blending best for this, or maybe should I go back to linear?), and have fewer events generated. But I'm not even sure if that makes sense to you, so please ask any questions that might help you help me.

Also eternal thanks for all the great support you provide for this engine!

[Norbo]

However the number of times the collision events fire has increased dramatically, leading to my sound effects playing too often. I'm using the ball's InitialCollisionDetected event and playing a table sound or cup sound depending on what the other object is. Before, I would hear about 3-7 cup sounds in the process of sinking a shot, now it is about 8-20.

It sounds like the combined bounciness coefficient is higher. If you want the same behavior as before, I'd just recommend changing the MaterialManager.MaterialBlender to average the properties and use the old coefficients.

Also when a ball 'rolls' across the table (Y-velocity should be [near]zero) it never ceases to bounce producing a constant bouncing sound.

But as I adjust the ApplyScale constant from 0.025 back toward 1.0, these effects happen less. However the quality of physics simulation drops (ball pops outside the walls of the cup at high speeds)

With a higher combined bounciness coefficient, the ball will be more prone to bouncing. Increasing the CollisionResponseSettings.BouncinessVelocityThreshold will increase the velocity required to trigger a bounce. Increasing this may be valuable even if the coefficients are returned to their previous values.

Also eternal thanks for all the great support you provide for this engine!

You're welcome

[omegagames]

I'm now trying the game on xbox, and getting more slowdown than the older engine. This is mostly my fault for writing inefficient code, but unless you can help me figure it out I need to revert to the old engine.

Just to remind you this is my physics world:
2 Boxes for a table and the floor
1 Sphere for the ball (it is reused everywhere)
Variable number of InstancedMeshes for cups (for my tests it was 20 or 30)

So the problem is I wrote a routine that does a full 'toss' every frame, to create a "shadow trail" of balls to guide the player while their power moves from min to max. The most useful part of this is seeing a ball actually on the back wall of the cup when you hit "throw", which basically means you can't miss (yet people still do!)

So essentially I have a for-loop that runs about 20 times and pretends to throw the balls at the cups, tracking the ball's position after each update. I can understand why this sounds slow, but with the old engine I could do all of this in about 5-8ms, as opposed to now it taking up to 20ms.

Ok here's what I've tried so far:
First I just did the same simulation as before. It's too slow whenever the trail touches the cups (lots of contacts made I presume) and it's visually jarring to see the trail after hitting the cup's rim, as it bounces in all sorts of directions.
Next I tried to quit my simulation (ie exit the for loop) as soon as a collision occurred (by using first InitialCollisionDetected, later CreatingContact). This seems to be slower due to all the events firing.
Then I tried just removing the cups from the equation. It's super-fast but too hard to aim the shot, since there isn't a 'ghost ball' showing you actually hitting the cup.
So I got super-fancy and tried to make Cylinders that stand in place of the cups for this part. The idea was that the player would see a ghost ball right at the top edge of the cup, but since I used a primitive shape the collision would be faster. However for some reason this was by a large margin the slowest of all.

So I removed the cylinders and went back to the event-based solution but I'm stumped now. When the trail bounces off the table only it goes fast in all cases, so it's something with the cups specifically. Maybe is there a way to short-circuit the simulation upon the first collision with a known object?

I understand if you can't help me because of how strangely I'm using the engine, but I hope you can understand why I can't change it at this point. Wish me luck

[Norbo]

v1.2.0 and newer should not be slower than v1.1.0. There were no changes which would explain a significant decrease in performance, even on such a small simulation. If anything, you should generally expect things to get faster with the newer versions.

I would recommend working on the assumption that this decrease in performance is anomalous and has some shenanigans behind it. Trying to optimize without addressing the source will probably fail.

Here's a couple of the performance observations which seem strange/unexpected, and so may be helpful hints at the source of the problem:

Next I tried to quit my simulation (ie exit the for loop) as soon as a collision occurred (by using first InitialCollisionDetected, later CreatingContact). This seems to be slower due to all the events firing.

Unless the event handler's logic is expensive, event management should be a vanishingly small cost compared to the rest of the stuff going on in the engine. The act of checking for and dispatching events is a matter of nanoseconds total for a given pair. Collision detection/solving for a single pair can easily take hundreds of times longer.

Additionally, simply hooking an event when there aren't collisions is completely free. So, if the event handler simply stops the simulation on impact, you should have at most one update where the event is actually called. This cannot be the true source of the slowdown unless the content of the event handler is doing something slow.

So I got super-fancy and tried to make Cylinders that stand in place of the cups for this part. The idea was that the player would see a ghost ball right at the top edge of the cup, but since I used a primitive shape the collision would be faster. However for some reason this was by a large margin the slowest of all.

This is not at all expected behavior, particularly if the simulation terminates on impact. While triangle-sphere has a special case, it takes quite a bit of work to determine what triangles need to be tested against the incoming sphere and there will likely be more than one triangle-sphere test. The pruning followed by narrow-phase testing should easily take longer than a simple sphere-cylinder collision, even though sphere-cylinder falls back to the general convex-convex case.

In the presence of severe scale issues, the default epsilons may be so small as to significantly increase the cost of the MPR/GJK loops by preventing them from terminating. None of this changed in v1.2.0, though.

Here's a few suggestions:
-Make sure the compilation is set up properly for performance. For example, if the engine is built with CHECKMATH defined, it will insert NaN/infinity tests all over the place which can impact performance. Make sure it's built in release mode with optimizations and running without a debugger.
-Make sure that all engine configuration is identical, or as close as you can get it to the previous implementation, so that the comparison is apples-to-apples. Make sure all the bounciness coefficients and scaling factors are the same. You could even temporarily revert to using v1.1.0's prescaled ContactMinimumSeparationDistance of 0.1 instead of v1.2.0's 0.03, though this probably won't matter.
-Grab a profiler and look at where the time is actually being spent. If the PC is producing similar results, use the tools available on the PC (like SlimTune, ANTS, dotTrace, etc.) to collect data. If it only happens on the Xbox360, that's a hint in itself- but you can still collect data by instrumenting the code manually with timing logic (compiling BEPUphysics with PROFILE and checking out stage timings can help here).

[omegagames]

Could you explain further how to use the "PROFILE" compilation symbol? I cannot find any references to it in the project (I just did a ctrl+f search for the phrase) and adding the symbol didn't seem to change anything (same performance afaik, nothing output).

I've been trying to profile manually with the stopwatch class, and what I learned was that the simulation runs very quickly until the first collision begins. Then that single loop takes a very long time, and sometimes the event isn't fired right away (maybe because the collision didn't occur yet, it's just one frame away or something) leading to a second long frame. Here's an output I collected showing how many ticks pass for each update of my for-loop. The key things to notice are the 0's showing where the simulation was short-cut, and the large jump in times (for two frames) right before this:
11, 361, 431, 497, 563, 628, 693, 758, 823, 888, 953, 1018, 1085, 2483, 3760, 0, 0, 0, 3762, 3763

(These are pc numbers, on xbox they are larger but following the same pattern)

So when the ball flies through the air I do an update in about 100 ticks or less, but once the cups are nearby everything is slowed about 10-20x. I'll do more profiling to see what I can find, but I wanted to ask about the compiler option and give more info in case this helps.

[Norbo]

The PROFILE compilation symbol is available in the development version: http://bepuphysics.codeplex.com/SourceC ... evelopment

So when the ball flies through the air I do an update in about 100 ticks or less, but once the cups are nearby everything is slowed about 10-20x.

Collisions and their associated costs are the primary source of slowdowns in a simulation, so this is a potentially reasonable result. However, the same should be true of v1.1.0 given the same simulation; if it's not the same, shenanigans are afoot.