Racquetball game physics collisions "fail"

[webGLmmk]

I need some general help on physics bodies and collisions. This is the closest I've gotten to my first game, and first time dealing with physics engines.  I really dont know much about physics engines aside from what I've read in the BJS tutorials and classes. Any advice or pointing out what I'm missing is appreciated.

I've working on this racquetball game. Its a combination of racquetball and 3D pong. I'm calling it RacquetPong for the time being. Once I get the physics right, I'll have to learn how to make it 2 player or whatever else I'm going to do with it.

Here's the playground.

http://www.babylonjs-playground.com/#2B1VM

Note you can left click and drag to move the blue square "racquet" around once the ball comes back.

I was pretty excited at this point, but as soon as I tried to make it bounce more by increasing restitution, the ball bounces increasingly, and then too much, and it goes through either the floor or the ceiling. If I increase the restitution of the ground/walls etc, it does the same thing.

Incidently, the front wall, the one closest to us, is there, its just invisible as seen from the back. The camera attachControls is commented out because I dont really want the camera view moving during gameplay- its meant to be static. The engine is Oimo, haven't tried Cannon yet.

I dont know what makes the ball go through the floor/walls/ceiling. Its like a "collision fail" - goes right through. I'd like to know how to avoid that, and be able to make the ball bounce around all over. Similar to actual racquetball.

Another thing: in the current settings saved above, when the ball bounces back toward the camera and you move the racquet in front of it, it doesn't really bounce "back" the other direction. I'm pretty sure thats because I'm not using the  linear velocity and impulse correctly...this was my first attempt. So I've got 2 main issues.

EDIT:

I realize that if I allowed the racquet to move along the Z axis at least a little ways, it would be able to hit the ball further forward. I may branch off into 2 versions of this game. But for now I'd like  to make the ball bounce enough to reach across the room and back with around one bounce on the ground/walls. Either way I seem to have the same issues...how to set my impulse correctly, and not allow the ball to go down through the floor.

[Wingnut]

Holy cow, Gson... you're doing GREAT!  And what a fun and wise use of the physics engine!  Well done. 

First, "ball thru wall" has been a problem for our physics engines from day #1.  I bet there are 20 posts in the forum... about ball-thru-wall or ball-thru-ground.  The reason it happens is something technical, I hear.  Something about sampling/update speeds.  I think there are ways to reduce the occurrences.  One way that you MIGHT try... is to make the walls be boxes and not planes.  At least it is worth a test, eh?

Restitution, yeah, it's seriously sensitive and can get out of control, fast... especially in Oimo.  Your wise idea of giving the paddle some z-movement... is perfect.  In a real racquetball game, the amount-of... and velocity-of Z movement... is a big factor in the game.  Perhaps there is ALSO "English" in racquetball, too.  That's advanced stuff.    You might be able to add that to your game, eventually, gson.  Maybe WASD keys for top/bottom/left/right English/spin.

Ahh... let's see, how to let the user control the distance and speed of the paddle's Z-movement.  hmm.  Maybe distance of Z-movement is not important.  Maybe only velocity of z-move is the important thing.  Let's imagine that we keep controls... near the user's left hand.  The user is already "hand hovering" the WASD keys... to use ball spin (English)... so... hmm. 

How about the 1,2,3 keys?  Perhaps 1 = a slow/small z-move, 2 = medium spike, 3 = power slam.     SO... the user could be holding down 's' and '3' at the same time (back-spin power spike) or maybe 'd' and '1'... (right-spin lob).  The user's right hand would only be concerned with getting the paddle aligned with the ball.

Speaking of aligning with the ball... you COULD pretend that a bright directional light is shining from back-court... towards the camera... and set paddle to receive shadows.  This would put a shadow of the ball... onto the paddle... whenever the ball was X/Y aligned.  This would be a type of user-feedback and help the user align with the ball at paddle impact-time.  The whole thing could be "faked" by using a circle texture on the paddle... and using texture uOffset and vOffset to move the texture any distance vertical or horizontal... even enough amount where the circle is not upon the paddle anymore.  Our decal system could also do it.

Okay, that's just a few thoughts I have.  We also have paddle "tilt" (aiming) to deal-with, before it's all said and done.  I'm not sure that the users have enough fingers to play this game.    But I like it... nice PG... good game start, lots of fun experiments ahead.  I will try to help, if/where I can.  All your questions are good ones, gson.  I'll keep thinking.  Others will have comments soon, too, I suspect.

[webGLmmk]

@wingnut thanks again! will have to take some time with this. Will try the boxes first.  I agree about having some kind of other power slam  control ..maybe the space bar, to generate velocity on the zmove..just during the hit. Like, space bar makes it shoot forward and back to get the ball going other other way.  If i'm going more for racquetball than pong, a person moves back and forth on the court..so the racquet should move a little ways, but needs to be constrained. I could just factor that back into the onPointerMove.  Will probably need help figuring out what I have wrong with the impulse. I have a linear velocity set up, and impulse, and i think i only need one or the other...

*afterthought*  If 'im standing on the racquetball court, and i just hold my racquet up passively for the ball to strike, the ball isn't going to go very far... *humor*

I feel like the games not going to work though unless I can get the ball bouncing more without going through the floor. Might try a version with cannon to see how it goes.

Once I feel its "done" to some degree, I"d love for them to add it to the playground selections...It has event listeners and physics together, and games typically have both. I'm going to improve the materials eventually.

[webGLmmk]

On 5/3/2016 at 5:43 AM, Wingnut said:

 

First, "ball thru wall" has been a problem for our physics engines from day #1.  I bet there are 20 posts in the forum... about ball-thru-wall or ball-thru-ground.  The reason it happens is something technical, I hear.  Something about sampling/update speeds.  I think there are ways to reduce the occurrences.  One way that you MIGHT try... is to make the walls be boxes and not planes.  At least it is worth a test, eh?

Restitution, yeah, it's seriously sensitive and can get out of control, fast... especially in Oimo.  Your wise idea of giving the paddle some z-movement... is perfect.  In a real racquetball game, the amount-of... and velocity-of Z movement... is a big factor in the game.  Perhaps there is ALSO "English" in racquetball, too.  That's advanced stuff.    You might be able to add that to your game, eventually, gson.  Maybe WASD keys for top/bottom/left/right English/spin.

...

@Wingnut

haven't had as much time as I've liked to work on this, but I switched from planes to boxes, and it did make a difference. The racquet isnt working right now, because I commented out the front wall...I dont know how to make the front wall invisible, as a box..will work with that this week- I tried the alpha value at 1..anyway. I could keep front wall as a plane, because if it hits, the front wall, its supposed to be a loss anyway. I need it there for the racquet, unless there is another way to drag and drop an object without a surface underneath

if you notice, it does bounce around more, but if I still set the restitution too high, on either the ball, walls ,or combo of both, it will still go through the floor. It is bouncing a lot better though.

http://www.babylonjs-playground.com/#RYXIT#0

[Wingnut]

Hi again, g-man!  Yep, you had the right idea. 

http://www.babylonjs-playground.com/#RYXIT#3

Alpha = 0 in line 45, and the wall is invisible.  Also notice line 50... that works, too.  Lookin' good!

For fun, I tried switching to CannonJS physics in line 97.  It didn't do so well.  PG error... this.isSupported is not a function.  That's not healthy-sounding.    More soon.

 

[webGLmmk]

8 hours ago, Wingnut said:

Hi again, g-man!  Yep, you had the right idea. 

http://www.babylonjs-playground.com/#RYXIT#3

Alpha = 0 in line 45, and the wall is invisible.  Also notice line 50... that works, too.  Lookin' good!

For fun, I tried switching to CannonJS physics in line 97.  It didn't do so well.  PG error... this.isSupported is not a function.  That's not healthy-sounding.    More soon.

 

garcias    ...I'm trying to figure out what you did to make the ball in your playground go so SLOW...are you seeing what I'm seeing? its bouncing like super slo-mo

I updated my visibility and it slowed it down a bit, but not as bad as your example..., but i dont see you changed the physics settings.

http://www.babylonjs-playground.com/#RYXIT#4

maybe i'm blind right now (too many different things going on), going to look at this another day

[Wingnut]

Ahh... line 95.  scene.enablePhysics(new BABYLON.Vector3(0,-9.81, 0), new BABYLON.OimoJSPlugin());   I removed the word 'new' cuz it was underlined in green and causing a little green marker on the right side of the PG editor.  Do you see the green things (in #0)? 

I removed the word 'new'... and the green marks went away... but then, yes, the physics speeds died, eh?

hmm.  Maybe physics god @RaananW will visit our thread, and lend us his advice.  Have you read his new physics "overview", gson?  He's been doing a ton of work on our physics plugins, recently.  But, them darned physics engines are sometimes grumpy and unpredictable.

I hear rumor of another physics engine in the vicinity... called EnergyJS.  Sammy "Ragdoll" Girardin (a friend of the forum and swell coder) has been giving us sneak peeks.  But the ball will STILL fall through the floor sometimes, I bet.  heh  https://www.google.com/search?q=physics+engine+"through+floor"

Update:  http://www.babylonjs-playground.com/#RYXIT#6

Notice the impulse and set velocity lines you have at line 125 area?  Well, I don't think they were working at all.  Not sure why, yet.  It seems that you were applying force before the physics impostor on ball... had time to warm-up.  (like an old tube-type tv set)   

I moved them to lines 145-147.  Click anywhere, anytime, and it sends the ball flying.  AND, I'm not seeing very many ball-thru-floor problems, so far.  There might be hope. 

Another Update:  http://www.babylonjs-playground.com/#RYXIT#7

Now, the ball eases out of the floor, then 2 secs later (2000 ticks later)... poom, ball fires itself.  And, you can still click to fire the ball.  Using lots of random()... goofing around... having a good time with your playground.    Increase the 'ballpower' variable, and you will get more "thru the wall" problems.  hmm.  Still thinkin'.  Ok, bye again. 

Ok, one more:  http://www.babylonjs-playground.com/#RYXIT#8

Emergency ball-rescue func...  lines 200-205  Party!!!

[RaananW]

Hi!

Oh, it's nice to be back

Anyhow - here is my take on things - http://www.babylonjs-playground.com/#2B1VM#1

Technically what I did was to give the ball an initial impulse, and preserve the energy from the impulse throughout the game. I also removed the collision of the front wall and left only the racquet object to be in charge of hitting the ball back (also increasing its size - not-so-skilled-me couldn't hit the ball that fast). 

The engine in this case doesn't really matter - both oimo and cannon should work correctly. Oimo had a bit of a problem with the collisions for some reason, so I used cannon.

Giving the racquet a higher restitution - 1.2 for example, and removing friction will give the ball more energy during the game. 

A few questions, as I changed quite a lot - 

1) Why do you need gravity? This kind of game will probably work wonderfully without gravity.

2) Why set a restitution lower than 1 to the walls? What it means is that the ball will forever "bounce" and not lose any energy during collisions. If it does lose energy, it will eventually slow down and the hitting object will have to provide more energy for the ball to continue bouncing happily. 

3) Setting linear velocity and applying impulse is (almost) the same, especially on inainmated objects. So either apply impulse, or set the velocity. Doing both will add more velocity to the velocity you already set. It's not bad, just not needed.

@Wingnut the error ("isSupported missing") is because you removed the "new". Not sure why it is marked with a green line, but it is certainly not an error.

 

[jerome]

@RaananW is back \o/

[Wingnut]

Thanks @RaananW!  http://www.babylonjs-playground.com/#RYXIT#9

I went with a HUGE racquet.  Ball eventually loses its enthusiasm.    Kinda fun!

[RaananW]

7 minutes ago, Wingnut said:

Thanks @RaananW!  http://www.babylonjs-playground.com/#RYXIT#9

I went with a HUGE racquet.  Ball eventually loses its enthusiasm.    Kinda fun!

Set the racquet's restitution to 1.2 and the fun starts   

[webGLmmk]

15 hours ago, RaananW said:

Hi!

Oh, it's nice to be back

Anyhow - here is my take on things - http://www.babylonjs-playground.com/#2B1VM#1

Technically what I did was to give the ball an initial impulse, and preserve the energy from the impulse throughout the game. I also removed the collision of the front wall and left only the racquet object to be in charge of hitting the ball back (also increasing its size - not-so-skilled-me couldn't hit the ball that fast). 

The engine in this case doesn't really matter - both oimo and cannon should work correctly. Oimo had a bit of a problem with the collisions for some reason, so I used cannon.

Giving the racquet a higher restitution - 1.2 for example, and removing friction will give the ball more energy during the game. 

A few questions, as I changed quite a lot - 

1) Why do you need gravity? This kind of game will probably work wonderfully without gravity.

2) Why set a restitution lower than 1 to the walls? What it means is that the ball will forever "bounce" and not lose any energy during collisions. If it does lose energy, it will eventually slow down and the hitting object will have to provide more energy for the ball to continue bouncing happily. 

3) Setting linear velocity and applying impulse is (almost) the same, especially on inainmated objects. So either apply impulse, or set the velocity. Doing both will add more velocity to the velocity you already set. It's not bad, just not needed.

@Wingnut the error ("isSupported missing") is because you removed the "new". Not sure why it is marked with a green line, but it is certainly not an error.

 

  I was honestly just kind of flying by the seat of my pants.. I read your overview and wasn't sure how either impulse or velocity really differed in terms of what it would look like. I copied from one of your examples, and tried both. Since the ball seemed to move, i left it there to deal with later..although looking back I didn't realize it was only the bounce and gravity that made the ball move. Having the linear velocity work makes the ball move the way I wanted it to. I only lowered the restitution because I was playing around with trying to get the ball not to fall through the floor.

Speaking of which...do we know what exactly fixed that? Doesnt' seem to be happening anymore. Is it related to the velocity fix?

I guess I don't really need gravity. I was going to create an onclick "serve" function to start the game off anyway.

I had planned to put lines on the floor as per an actual racquetball court, but with the game as is, it is fun, and its a great demo. It's kind of like " 3D Solitaire Pong". Thanks for finishing my game yall!  Although its not quite done for me. I want to set up scoring somehow. Maybe a slider to change racquet size for difficulty? Slider for velocity for difficulty? Anyway I'm leading this into being my first legit contribution. One thing I do want to do, down the road, is create a 2 player game  out of this....like PONG. No idea if thats possible, I haven't read up yet. 2 opposing camera views on the same scene? Would be pretty awesome right? hashtag think big

 

7 hours ago, Wingnut said:

Thanks @RaananW!  http://www.babylonjs-playground.com/#RYXIT#9

I went with a HUGE racquet.  Ball eventually loses its enthusiasm.    Kinda fun!

 

There's only one man on earth who could play this game with a smaller racquet...  Terry Cavanagh....creator of Super Hexagon...   dude's nutcase crazy monkeys:

 

 

[Wingnut]

  Gotta say one thing... you must be a pretty good game designer, Gson.  Your game became a local hit while you were still working on the pre-alpha version.  There's not many game designers/programmers that can claim such.  Congratulations on that, Gson! 

Your demo also helps teach our physics system to others, and that helps BJS popularity and ease-of-use.  I think it also helps Raanan field-test his recent physics plugin work and successes, but I shouldn't speak for him.

I think I still see SOME ball-thru-racquet issues.  Why ball-thru-floor/wall is reduced now, unknown to me.  Maybe others have theories.  Perhaps we were doing something that fought-with the physics engine's natural flow, and we eliminated that fighting, somewhere, somehow.  *shrug*  Teach us what you learn as you build future versions, ok Gson?  Thx! 

Cool video, too... that guy is an insane gamer.     I would have had a nervous breakdown after 8 seconds of that.

[webGLmmk]

On 5/18/2016 at 2:37 AM, Wingnut said:

  Gotta say one thing... you must be a pretty good game designer, Gson.  Your game became a local hit while you were still working on the pre-alpha version.  There's not many game designers/programmers that can claim such.  Congratulations on that, Gson! 

Your demo also helps teach our physics system to others, and that helps BJS popularity and ease-of-use.  I think it also helps Raanan field-test his recent physics plugin work and successes, but I shouldn't speak for him.

I think I still see SOME ball-thru-racquet issues.  Why ball-thru-floor/wall is reduced now, unknown to me.  Maybe others have theories.  Perhaps we were doing something that fought-with the physics engine's natural flow, and we eliminated that fighting, somewhere, somehow.  *shrug*  Teach us what you learn as you build future versions, ok Gson?  Thx! 

Cool video, too... that guy is an insane gamer.     I would have had a nervous breakdown after 8 seconds of that.

Thank you so much!  The commendation means a lot. I'm entirely a self taught coder from the beginning, and I'm still in the beginning. (ackknowledgments to those like yourself).    I really am going to put scoring up though.

I think because the ball is going further with fewer bounces, we're just not seeing it go through the floor - fewer opportunities. I wondered if putting in MeshBuilder instead of Mesh made a slight difference (still goes through sometimes). In fact, I think the racquet is still Mesh.createPlane. Will fix it and try. I notice its after a few bounces, like if the restitution is up and it gradually bounces higher...it will go through the floor. or when it hits two walls. It's like it seems random, but its not entirely. I need Nate Silver. Someone get me Nate Silver. STAT THIS!

I have a feeling it will be figured out eventually though. I liked your fix. I wondered if something similar but more involved could be set up...like, a mini module...it would take in locations along the X, Y, and Z, and detect if the ball exited those boundaries...then put the ball at that point just inside on that axis... It would definitely take more than a few lines, and it wouldnt' really solve WHY its happening in the first place. And then the angle of the bounce back would be off, or that would have to be figured out...

Another somewhat sillier idea I had was, what if i set up another box and box imposter like, another floor 1 pixel beneath the current floor....lol....like if this floor fails maybe it will bounce off the next one.. i have no clue how the engine is built, what is causing the issue, or if the number of floors will have any correlation...I was just thinking, decrease likelihood? like, in real life, if we had problems like balls going straight down through solid surfaces, thats exactly the kind of solution I would come up with. "Lets put another floor just beneath the floor, in case the first one fails! "  But thats more code, bigger files.

I think I've only gotten through about  30 seconds of Super Hexagon... was pretty excited....and that still only put me at level 3.

[webGLmmk]

@RaananW   @Wingnut

tagging you guys on this same thread as you're the ones I've talked to about this, but anyone else that wants to chime in:

I"m on the last step of the front end of this game (aside from scoring db stuff i'll do down the road).

I set it up so the ball doesn't launch until you click "serve"    woot woot(!)

It works the first time. The problem is that once I serve the ball AGAIN, the velocity/impulse is all crazy.. as if it has the impulse on it from last serve, and then this next serve, so it just rattles back and forth between the walls.

IRL id almost say it was doubling up on the impulses...in code terms i dont know what its actually doing. 

http://www.babylonjs-playground.com/#1PKWOP

I dont know much about how impulse or force works so I have two trains of thought:

1. fix the impulse/force/velocity issue on the one ball

--will need help here. would like to understand what the issue is and more about it in the process

 

2. discard the ball and launch a new one  (creating a new mesh in the GUI serve function instead of createScene)

--is that what AbstractMesh.dispose() is for ?

--or do i even need to do that, should I just  create a new mesh each time?..the old balls are lost in cyber space like the my golf balls at the driving range

 

I'd like to do it the simplest most make-sense way

 

so I guess you could say I have an issue with ....impulse control    BWAHAHAHAHAHAHAHA

[Wingnut]

Hi again, @webGLmmk.  Funny post. 

Yep, I see what you see.  Linear velocity on the ball... suddenly going crazy.

http://www.babylonjs-playground.com/#1PKWOP#4

No real improvement, but some, maybe.  I tried something similar to your #2 idea.  Each serve, I remove the ball's old physicsImpostor, and install a new one.  The new impostor should have no residual velocity (from previous ball energy).  I also put some randomness on your ball-serve impulse-direction.  Nothing very exciting.  I also added a scene.onDispose function that removes old eventListeners and old gui each time RUN is clicked.

Generally, there's two forces on a physicsImpostor...  linearVelocity (travel speed) and rotationalVelocity (spin speed).  I changed the ball to a lower resolution wireframe model, so we could see if we had any rotational velocity (spin).  There is none, or little.  That is acting correctly.  Spheres do not have enough surface area at impact points... to allow friction to have much affect.  Besides, all your friction values are set to zero.

All is working good for rotational velocity.  Linear velocity... that's a different story.  Somewhere, somehow, it is being amplified (added-to).

I set the paddle to a 1.1 restitution, so that the ball would pick-up speed just a little... with each paddle hit.  But the "jump" in linear velocity is not being caused by the paddle.  It is happening after impacts (collisions) with the walls.  I don't know why, but I will keep thinking, and perhaps do some more testing.  The issue would be much easier to troubleshoot IF it wasn't inconsistent.  Why only SOMETIMES... does the velocity go crazy?  Hmm.  I wish I was more help.

And yes, mesh.dispose(), which all mesh inherit from BABYLON.AbstractMesh class... is the way to delete mesh.  I don't think it is needed, though.  Deleting/overwriting the old impostor... should do what we want... kill old physics energy that is still active on the lost ball.  hmm.  Darn, sorry this is being such a problem.  Let's ping @schteppe, too, the programmer of CannonJS.  Maybe he has a moment to offer some advice.

[adam]

http://www.babylonjs-playground.com/#1PKWOP#5

[webGLmmk]

12 hours ago, adam said:

http://www.babylonjs-playground.com/#1PKWOP#5

ball.physicsImpostor.physicsBody.velocity.x = 0;
ball.physicsImpostor.physicsBody.velocity.y = 0;
ball.physicsImpostor.physicsBody.velocity.z = 0;

Thanks! I thought about something like this but didn't know there was a way to do it. Basically zeroing out the velocity. I seem to forget that its the imposter we're dealing with in physics, not the mesh. This will help ingrain that in hopefully

[webGLmmk]

12 hours ago, Wingnut said:

Hi again, @webGLmmk.  Funny post. 

Yep, I see what you see.  Linear velocity on the ball... suddenly going crazy.

http://www.babylonjs-playground.com/#1PKWOP#4

No real improvement, but some, maybe.  I tried something similar to your #2 idea.  Each serve, I remove the ball's old physicsImpostor, and install a new one.  The new impostor should have no residual velocity (from previous ball energy).  I also put some randomness on your ball-serve impulse-direction. 

@schteppe

used the randomness with some adjustments. I"m going to add something to the GUI to adjust the x and y impulse to increase difficulty. I get about the linear vs angular..i just forgot to look around in the physicsImposter class. I'm pretty sure I"ll use all this in future demos. This has really been quite the learning experience.

I try not to have IMPOSTER SYNDROME  [ha!]  about all the help I've gotten. what do bootcamps do, anyway?

get it... imposter syndrome #gamedevHumor #keepEmComin #budumpPSSHHHHH

[georage]

I'm late to the game ... ahem ... but I too had problems with collisions not seeming to work. The advice I got was to make everything bigger. Originally my moving object was a cylinder less than 1.0,but increasing the size to 1.5 seemed to give the physics engine a better chance of catching the collision.

Also, I used boxes for static objects (walls) instead of planes or ground. Increasing the thickness of the walls a bit seemed to help but there are still random non-collisions.

There seems to be a hard limit on how fast things can move ... I have a max impulse speed of 20 and that keeps things in the ballpark ... literally. 

 

 

 

 

 

[RaananW]

Hey!

Quick solution - recreate the ball each time - http://www.babylonjs-playground.com/#1PKWOP#7

There is a better solution, but the performance gain from resetting the velocities is nothing when it comes to recreating a sphere.