Been back to this lately. So once in a while the ball “escapes” past the walls, which are plane meshes set with box physics imposters. This happens when the velocity of the ball increases, which happens every time the racquet and ball have a collision. This happens repeatedly of course which increases the velocity every time. I could tweak that of course, but I kind of like the increasing velocity as a difficulty option, which I plan to add to the GUI. Sometimes, if the ball is kept going long enough, it escapes past the other imposters. With any real increase in ball velocity, it happens more quickly. IE, if you change the linear velocity set on line 183 in the callback up to 1.5, it happens pretty fast.
any tips on why this happens for what can prevent this? I could almost swear I asked this before, but yeah, no, its gone.
Update: just saw this post @Wingnut
Will work on changing to plane meshes to boxes, although the imposters are already set to box. Physics world scaling, and step speeds, I’ll have to learn, as I dont know anything about them (yet). I can slow down the ball with friction or mass, but of course I like the idea of an increasingly faster ball.
issue: collision detection between imposters at higher velocity.
That being said, anything else known about how to purposefully increase velocity without these “pass throughs”? Any improvement using Oimo or Ammo? If it’s a limitation of the current engines, I’ll just polish this and call it a demo
This happens because on a specific iteration the sphere moves so fast that in one iteration it is behind the object, and on the other iteration it is beyond the object, so the physics engine doesn’t register that as a hit/collision.
There are two ways of dealing with that - increase the number of physics iterations per frame or make the mesh thicker.
The first variant will keep the scene as it is but might hurt performance (more calculations on each frame). But will be cleaner and will fit the use case. - this is the playground with 100 iterations - racquetball demo | Babylon.js Playground
The second variant will force you to use boxes instead of planes when constructing the racquet (or any other object in the scene). If you want to visually still use a plane, the impostor should be attached to an invisible box the moves along with the plane.
Got it. I can probably incorporate boxes into the scene even to make visual improvements. Thanks.
OK one small followup question, or for @trevordev . Posting here since it involves the same scene.
Does PointerDragBehavior not work when physics is enabled? It seems that way based on this thread, and the fact that it didn’t work in my scene:
MY scene currently has scene.pick observables implementing the drag behavior, because I wrote this ages ago and thats what was available (and apparently that works out better anyway). After reading through the docs I thought I would test out PointerDragBehavior- commented out lines 254-258. I’ll keep all the scene.pick listeners if thats the case, I just liked how much simpler the drag behavior code looked. Thought I would check if i was just missing something, or if there is something else more up to date (that works with physics).
Disabling/enabling physics within listener callbacks probably not a great idea, not sure how that would affect the scene. no need to reinvent the wheel.
I’m not sure about the drag behavior (there is no reason for it not to work), but I think you are missing the easiest option that is already partly implemented for you - mesh picking and the standard pointer system. The onPointerObservable of the scene will notify on every pointer even in the scene. It also incorporates a pickingInfo object that lets you know what object was picked by this event, if any. No need for an extra scene.pick, it’s already done for you.
Without the drag behavior working, the racquet’s position is updated by applying the difference between previous and new pick points. I used the observables pickingInfo object within the pointerDown event type, and got rid of a lot of unnecessary code.
But within the pointerMove event case, it wouldn’t work with that same pickingInfo.pickedPoint - so i passed in the point from scene.pick instead. Is that because its the same point referenced, from the same pointerInfo object passed to onPointerObservable.add() ?
Or anything else I missed? I’m looking through the observable methods and my understanding of the API is at its limit in helpfulness. I’m sure I’ll keep playing with it but I feel like this would be pretty key in many situations. Thanks to anyone