Collision with walls using Cannon

[aponty]

Hello all,

I've been working through a project (using a lot of advice I've found from lurking here) and I've run into an issue. My goals are pretty modest; I'm trying to 1) have a natural jumping mechanism, and 2) have collision detection between the camera, ground, walls, etc.

At first I did this just using Babylon's .checkCollisions, which works very well for camera vs object and camera vs wall collisions. However, I couldn't get this to work properly for jumping. Even following other's tutorials, (http://www.html5gamedevs.com/topic/12198-camera-jump/) I wasn't getting the results I wanted; on my computer, at least, all of those playground sketches still "hang" at the top of the jump until other arrows are pressed. So, I switched gears and tried using Oimo and Cannon. I still can't get Oimo to work, for some reason ( "this.world.worldscale is not a function" ring a bell for anyone? I can't find anything on that) but I've had decent results with Cannon.

In short, I have the jump working, but now the collisions vs the walls are all...funky. Check out the playground sketch here- if you hit the wall, everything spins like mad.

https://www.babylonjs-playground.com/#GYZQLK#3

I'm pretty stuck. I don't see how this collision detection is any different than between the ground and the camera, but something is obviously off. I've tried vs other horizontal objects (boxes, spheres) and had the best results setting the camera's physics imposter to a box (which makes turning all jittery).

Any suggestions or ideas? Thanks all!

[Wingnut]

Hi aponty, welcome to de-lurked mode.    Let's see...

On 8/7/2017 at 5:36 PM, aponty said:

still "hang" at the top of the jump until other arrows are pressed

That is sometimes fixed by setting camera._needMoveForGravity = true;

In your physics engine playground...

...the camera is not a mesh, so it cannot have a physics impostor, as far as I know.  BUT, the camera COULD have a parent that is a (possibly-invisible) mesh which COULD have a physicsImpostor.  Besides, attaching physics impostors to cameras, or to parents of cameras... is not easy to control.  You could easily get sea-sick from all the violent motion. 

My advice is to return to non-physics engine, with no camera parent mesh or gizmo... and try-out that newly-learned  _needMoveForGravity = true... see if your camera will fall back to Earth after jumps.  I think it will. 

The .checkCollisions and camera.ellipsoid/camera.applyGravity system... is a NICE one.  There is also a handy function called mesh.moveWithCollisions() that will do what it says.

BUT, keep in mind that mesh.moveWithCollisions() was a later add-on to the built-into-BJS .checkCollisions system.  The .checkCollisions system was designed-for cameras colliding with mesh, and not for mesh colliding with mesh.  It might be wiser to use our "intersectsMesh" stuff (or physics engine) when you need to check-for mesh colliding with other mesh.

But for cameras colliding with stuff... .checkCollisions is fast and nice.  Sometimes it takes some "tweaking" for camera.ellipsoid size, though.  Also keep in mind that mesh have ellipsoids, too.  For example, by "fattening" the z-thickness of wall.ellipsoid, you can make the camera collide differently... and "rub off" differently.  It's all part of the fun.    Again, welcome, keep showing us your playgrounds... if you wish.  We like looking at playgrounds.

Extra crap: Myself and Tommy Furca did some experiments with some collisions of two cylinders (with each other)... and we had a simple .showEllipsoids activated, and a lot of keypresses using .moveWithCollisions()... just a whole lot of fun.  Better read the post before you hit the playground.  No camera collision or gravity, just two cylinders and wasdqe/shifted-wasdqe moveWithCollisions() stuff... which you don't need, yet.   

This is a good PG to test "scrub-off" or "rub-around", and "climb-over" and "dive-under".  It happens when two collision ellipsoids push-on each other (moveWithCollisions - held keypress) ...when they are not perfectly aligned.  The mesh doing the pushing will go-around, dive-under, or climb-over... the other mesh/ellipsoid.  With the cursor controls and readouts of this playground, it is easy to test/see those "scrub-offs".   With me?  I hope so, cuz I'm just barely with me.   

Notice that the dive-unders and climb-overs are 50% too high, Y-wise?  We haven't yet determined why.  Try this PG.  Use SHIFTED-Q to move top barrel downward.  Collide too early?  *nod*  Reload and use 'E' to move lower barrel upward.  Collide too late?  *nod*.  Likely a Wingnut mistake, probably within my setEllipsoidPerBoundingBox() func.

[gryff]

@aponty : I I'm curious about whether you need to use physics. Will it be part of something more complex? Or could you just use  gravity and collisions with normal BJS functionality?

Jump Example

Spacebar to jump.

And I was also curious about your  nic - but I had to look after some dogs for the day so my response is delayed   I'm a crap coder so I'm sure it can be improved - with the ActionManager maybe?

@Wingnut: Ok so what is with this

5 hours ago, Wingnut said:

_needMoveForGravity = true

I can't find any reference in the docs

cheers, gryff

[Wingnut]

7 hours ago, gryff said:

Or could you just use  gravity and collisions with normal BJS functionality?

Hi Gryff/others!  Hey, there's an echo in this thread.   

But yeah, I forgot to ask if he/she NEEDED physics.  From the words of the post, some non-physics attempts were made before the physics engines were tried, so I'm thinkin' physics engines not needed.

In the same breath, I think the camera in your demo... could do a "more exciting" jump, Gryff.  Something with some parabola, ya know?    Probably some camera.animations with some ease in/out.  Do jumps have forward movement?  I think so.  It depends upon the game, I guess.

But there are lots of questions, because so few have built decent test cases or analyses.  For example, we have no animateWithCollisionsAndGravity(), right?  If user tries to do a jump using camera animation, and if the ceiling (with .checkcollisions) is too low to allow jumping, what happens?  Do we have an animation feature that aborts the animation upon collision?  hmm. 

------------

I can't remember where/how I learned about _needMoveForGravity, but it seems that it was learned from a post by me!  How the hell can that be?   

But yes, it needs to be documented, even though its a private/internal property.  I just keep forgetting or something.  Actually, I am reluctant to publicly-expose (document) properties whose name begins with underscore.

Sometimes I think it should default to true, but starting scenes with a falling camera... is not always the most "clean" and welcoming way to introduce someone to a new BJS scene.  I don't have the full story on that property.

Thoughts, anyone?

[aponty]

Hey ya'll, thanks for the insights!

So, there's a lot here. First off, do I NEED a physics engine? Not necessarily, I suppose. I don't really NEED a game, either  

But, all the attempts at making a camera "jump" using the Babylon collision detection look...well, kinda bad. No offense Gryff, and thanks again for the example, but that jump doesn't really have the feel I'm looking for; something a bit more fluid and natural. I pulled off a similar one without using a physics engine...and it just feels weird. You move linearly up, and then stop, and then either hang out there until you hit an arrow key or crash back to the ground. I think results might be a bit computer-variable with that, but I don't have a good way to test that theory unfortunately.

A furthermore, I'd like to have physics interactions between other meshes in the game, so I'm going to be using one for something. In the spirit of parsimony, I figured why use two things to do the same thing? 

Oh, and while the camera isn't a mesh, I have set an ellipsoid around it. That's a mesh, correct? I tried using different shapes, using the normal mesh constructor methods, and had variable results. But they all had trade-offs. Using a square resulted in better collisions, but the camera 'bounced' when you turned it, for example. 

I'll give that _needMoveForGravity method a shot, and I guess I'll abandon my lovely cannon.js-powered jump for the sake of sane camera collisions. I just figured there was a simple way to do it by setting the bounces for the camera to 0 or changing the camera ellipsoid mass to something really high, but it's not really looking like it.

 

[Wingnut]

Good thinkings.  Yes, if you have a sphere mesh somehow attached to your camera, and THAT has an impostor set... then yeah, physics will work on the sphere, and it can be the camera's parent.  Don't confuse this with camera.ellipsoid, though.  Camera.ellipsoid is a vector3, and not a mesh.  (Sorry for over-explaining)    A camera can never be a mesh.  It can only be a child or parent of a mesh.

Jumping is a fairly complicated thing, especially if you allow position/rotation-nav DURING the jump-flight (user can change direction of jump... anytime during the flight).

Ouch, huh?  *nod*

The difficult part about using physics for player or camera... is the nav controls.  Boxes have friction, so you can thrust them and they will eventually skid to a stop.  Spheres want to roll, when impulsed/moved.  Even if set with fixedRotation, they have no significant friction - no surface area at point of contact. 

Note:  .moveWithCollisions is NOT the method used to move physics bodies.  Physics bodies are moved with .setLinear(Angular)Velocity, or applyImpulse.

Can you make a player's movement look "real"... by using setLinearVelocity or applyImpulse?  Not easy.  Players tend to slide-along too far, and come to a stop real slowly with ease-out, and start spinning with the slightest wall bump, etc etc.  It can be done, but you need to be a "pro" at setLinearVelocity, then kill linearVelocity, then set, then kill, etc etc.  And watch out for player tip-over.    (sometimes needs invisible heavy mesh, parented to player's feet).  Then there's ground fall-thru, and wall move-thru problems.... with physics engines.

Yep, weaknesses with ONE way, weaknesses with the OTHER way, all part of the fun.   hmm. 

Freecameras have an ._updatePosition() thing.  hmm.  Animations... umm... "derive" an interpolation "table" before they start animating.  Therefore... they are not an easy thing to interrupt while mid-animation (except for animation events - by  @Temechon).

Then there's path3D and curve3D... a couple of goofy things that @jerome dreamed-up.  They can be logarithmic and parabolic, so, a camera "jump" might consist of a curve3d and the use of camera._updatePosition().  As you step thru this live curve3D camera flight, you "poll" your own custom collision checker (cameraCollisionObservable?), to see if the camera flight needs interrupting, and to see if user is holding an arrow or WASD key WHILE the flight is happening.  Fully-powered, custom camera jumper... v1.0. 

[aponty]

Hey! Success! Took a bit of combining ideas, but I have something that looks right, and doesn't hang at the top of jumps! Thanks a ton for that hidden property advice, I haven't seen anything about that anywhere else.

Just in case anyone else is struggling with this, here's a playground (with some extra baggage, I trimmed most things out for clarity but not everything)

http://www.babylonjs-playground.com/#NMPK63

Basically I'm using iiceman's example from here-

(thread) http://www.html5gamedevs.com/topic/12198-camera-jump/

(playground) http://www.babylonjs-playground.com/#XN87O

and also Wingnut's suggestion of changing camera._needMoveForGravity = true successfully keeps the camera from 'hanging' at the top of jumps.

It sounds like it would do the opposite, right? But whatever. It's not perfectly smooth- but it it's good enough for moving forward at least

 

Thanks again Wingnut! Very helpful and much appreciated

 

[Wingnut]

Cool!  Well done!

But but but... will the camera jump-through a pink .checkCollisions=true low ceiling?

https://www.babylonjs-playground.com/#NMPK63#1

Yep.    Oh, it uses animations.  Cool.  *nod*  I forget what animationEvents are used-for.  I think its talked about in the animation docs.  Perhaps it can interrupt animation if collision event is seen.  Not sure.

[gryff]

@aponty : No offense taken - as I said I am not in the same coding league as a lot of people around here

I'm glad you are progressing with Wingy's ideas

@Wingnut : And yeah, the jump is not exciting or parabolic.   However, if I was trying to build a "Commander Keen" game I would probably play with animations, and the value of gravity etc.

By the way the little "Iggy" that I'm using for an icon under my name - you should that dog jump - almost straight up

cheers, gryff

 

[aponty]

I'm sure there's something you could do based on the collision event with the ceiling, but that sounds like a nuisance. I feel like there should be a more straightforward solution to what I presume is a pretty common issue (perhaps building default camera settings into Cannon, so you don't have to use multiple physics engines?), but hey- for a first project I'm just going to avoid using ceilings at the moment

 

[Wingnut]

*nod*.  Yeah, Cannon and Oimo were written (by 3rd party people, not involved in BJS) to be used with ANY JS webGL.  But still, cameras will never be mesh, so cameras are not something that physics engines care about.  But the .checkCollisions system (not a 3rd party, built-into BJS) does check for freeCamera collisions (but is not a fully-fleshed physics engine).  No friction, mass, restitution, joints, or other slow things... in the .checkCollisions system.  Just gravity and basic colliding.

The .checkCollisions is not near as powerful as Oimo or Cannon, but is much much faster.

Difficult to explain, but I think you get the idea.   I think your "hybrid" system (a little .checkCollisions, a little CannonJS)... is a pretty good idea.  Your animation is currently bringing the camera back to the ground, right?  What happens if the animation takes the camera into the air, and then quits?  Does gravity bring it back down after the animation ends?  *shrug*

Curious.  I'd test it myself, but I'm busy as hell at the moment.  Try to keep us posted on things you learn and experiments you try, ok?  Thx!

[Raggar]

If you do choose to change to physics at some point, here's an example with jumping (Using native CannonJS):

https://www.babylonjs-playground.com/#FZZV7K#15