Physics Movement

[MackeyK24]

What is the BEST or PREFERRED way to move your character with physics so it should respect the surface walking on ...

If I use mesh.imposter.setLinearVelocity(moveVector) it is NOWHERE as precise when moving diagonally using something like:

mesh.position.addInPlace(moveVector)... I was having a problem with the direction and moving EXACTLY forward from what the character is currently facing... And when that angle was more like 0, 45, 90 etc... it worked good with setLinearVelocity... But if was point at something like a 30 degree angle it would NOT MOVE EXACTLY forward... but I I use that same moveVector and ADD TO my current position (so using translation to move and not setting the physics linear velocity) it moves PERFECT... All Angles of rotation are then respected... what ever angle I am at and I res the up arrow key... It goes exactly forward...

Now is there something wrong with setLinearVelocity or is it just not PRESICE enough to handle angles in between 45 degrees ???

PROS AND CONS from what I see.

Using mesh.position to move a character with physics state enabled (mesh.checkCollision = false ... Dunno if that matters but I thought if we are using physics collision we should turn off mesh.checkCollision as that is for camera collision... I think)

===================================================================

PROS:

1... Exact precise movement

2... Respects collision with other objects that have a physics state... so can walk up ramps and such

3...  I image a bit faster just moving the position and letting the physics engine account for that actual 'Ending' Position... I guess that why I can walk up ramps based on just horizontal and vertical inputs.

CONS:

1... No imposter.getLinearVelocity values that I was using to determine is falling (isFalling = mesh.imposter.getLinearVelocity() < 0.1)

       but can be switched to just movement vector I guess... Dunno

2... Gotta change how I apply gravity when jumping or falling from something

 

====================================================================

Using mesh.physicsImposter.setLinearVelocity to move a character with physics state enabled (mesh.checkCollision = false ... Dunno if that matters but I thought if we are using physics collision we should turn off mesh.checkCollision as that is for camera collision... I think)

 

PROS:

1... Gravity code works from what I got using imposter.getKinearVelocity

 

CONS:

1... Movement (at least for me) seems what to imprecise with angle not quite 45 degrees in between (say I'm point at 30 degrees and press forward does not go exactly that way... at least for me it does not)

So if you were making a THIRD PERSON CONTROLLER for your REAL GAME (not just a quick snippet in a playground that moves you around with something like mesh.position.z += 0.1... but making a real game)

What do use use to moving your guy around respecting physics and what not... being to move and run and jump and what not... A full character controller...

What do you use for the actual movement of a game object with physics state enabled ???

mesh.position or mesh.physicsImposter.setLinearVelocity ???

Or am I way off and it should totally be something else

Anyways... Pinging @Deltakosh and @davrousand @Sebavan and @JCPalmer (who looks like h changed his icon, I hope that him) and @adam and of course 'Wingy' @Wingnut...

Yep... I'm asking the whole crew... What would you do when making a real game ???

[Wingnut]

This is pretty much the exact same issues I just raised in The Wingnut Chronicles. 

Obviously, we need a song.  "Ohhhh... Mackey ragdoll sing this song... friction... friction.  Mackey ragdoll 12 bones long, ohhhh... do dah day.  Gonna thrust all night, gonna slide all day.  Bet my money on a quat transform, somebody bet on the ray."

Goofy.  What did @fenomas tell us?  Or was it @adam.  Or maybe @RaananW? 

He said "Anytime ya force a position or rotation upon an impostor, you 'dis' the physics engine."  In other words, we need to work "with" the engine, and not against it.  SO... he suggested that a joint be incorporated... between any force-moved thing, and the actual physics-active thing.  Force-by-joint. 

Will we see precise/accurate move-distances and rotation angles on the physics-active player... doing this?  No.  We'll get some "springy-ness".  I don't think you can EVER expect a physics-active player or vehicle... to sit perfectly still, or position/rotate precisely.

I think the secret... is in allowSleep and sleep delays.  And recently, I experimented with the cannon lock joint... because it has such nice springy-ness.  Springyness is not something you would expect to see... in a "lock" joint, right?  These lock joints tend to orient themselves along one of the 3 main axes... and this is EXACTLY what you would want... from a joint that connects a player to an invisible "mover mesh" that is just ABOVE or BELOW the player.  An invisible physics active box, hovering above the player... with a lockJoint going straight down into the player's head or vehicle's roof.  Or, from beneath the floor/ground.  Move the invisible mesh with pure positional force, and then let the joint "pull" the actual player to the new position.  *shrug*

Always use Quaternions to rotate physics-active mesh, I'd say.  Yaw, pitch and roll.  A Quat should be able to rotate an impostor very accurately, but again, we might rotate the invisible "controller" and then let the joint carry those forces to the actual player.  Sleep it fast, and sleep it easily, so player doesn't rock back and forth on the rotation or move axis very long.  Also, the dampening/stiffness IS a working setting on a lockJoint.  You won't want much "slop" between the mover and the movee. 

But, we all know where it's going... in the near future.  Walking ragdolls... with kinematics transferring forces from the ragdoll's feet... up through its bodily bones.  And then, the body bones react (joints/mesh-colliding), and then send their forces back to the feet.  Our ragdolls will need umm...  hehe...

"Sense of balance or equilibrioception is one of the physiological senses related to balance. ... Balance is the result of a number of body systems working together: the eyes (visual system), ears (vestibular system) and the body's sense of where it is in space (proprioception) ideally need to be intact."

hmm, that seems like a lot of work... to keep a ragdoll from tipping over. 

Mackey, can we assume your player is still a box or something easy?  I hope so.    Still... to make a physics-active player... accelerate to full speed RIGHT NOW, then stop RIGHT HERE... phew... not easy.  Too much forcing.  With power-forcing, you might as well turn OFF the physics, because if the player bumps something during the move... the physics reaction won't seem realistic.  If you turn on MASSIVE velocity RIGHT NOW (to avoid taper-up to full move speed)... you will send heavy (high mass) rocks flying-away... if your player bumps one during the move.  You need high-horsepower instantly... to get a good, quick move to happen... and then shut it off QUICK.  But during that moment of high horsepower... you can move entire skyskrapers if player accidentally bumps one during the move.  Not good.  Incorrect physics reaction.

Phew.  Anyone following this?  Let's hope not.     I'm not sure how to get a nice player physics move, leg-animation happening or not. 

In real life humans, the bottom impostor splits into 2 pieces (left leg/right leg).  Then all mass is transferred onto ONE of the legs, while the other... steps (raises and moves to a new location upon the ground).  Then the mass is equalized across both legs again (standing).  Walking uses very little impulse/force, and uses LOTS of mass-transferring from leg to leg (along with balance).  hmm.

Others will surely comment soon.

[MackeyK24]

Wow @Wingnut ... Thats OVER MY HEAD...

Let me ask this... Before I even came and found BabylonJS and started using the toolkit for everything... How was this done regular Babylon javascript ???

Has there ever been a game made with BabylonJS where you had a full humanoid character walking and running and jumping (the basic things you would get when making a unity game). And I mean a full (or even mini) game (don't get me wrong, I love the playground). But I sure would like to see how a full game is made in BabylonJS ... What api's is doing what... what techniques are used for 3rd person movement... a full 3rd person camera (all the Babylon cameras work very well, especially for first person views). But would love to see 3rd person in action with Babylon code... Things like follow the player and being to orbit around the player when not moving (like unreal 3rd person template)...

So again, I gotta use Unity as a resource... So as far as getting the toolkit to produce something like you have in unity... Well a lot of the time I am just making shit up. How I see the "OUTCOME" or "RESULT" in Unity and try do whatever I can to make the "RESULT" look and work as much as possible as if making a unity game...

Now sometimes I don't know if its wrong or right... should I even be doing this or no in Babylon or even is there already an implementation in Babylon (just called something completely different) and I just plain snd simply don't know how to use

Anyways... To Clarify ... How would you move your guy around in game with what got now in babylon... ???

[Wingnut]

8 hours ago, MackeyK24 said:

Has there ever been a game made with BabylonJS where you had a full humanoid character walking and running and jumping (the basic things you would get when making a unity game).

I don't think so.  If there HAS been, it's likely a trade secret.  I'd say @Dad72 has been the closest to a PUBLIC version of that, and his system did not use physics.  It uses moveWithCollision and builtin-ellipsoid colliders.  I doubt you are interested in that.  It doesn't jump, and I don't think Dad72 activated a run.

@satguru also created a fine demo... but it doesn't use the physics engines, either.  http://www.html5gamedevs.com/topic/32052-terrain-slope-problem/?do=findComment&comment=184534

@AndyBeaulieu made a physics avatar kick some things, one time.

@Raggar ported @Samuel Girardin's ragdoll into a playground.  Sammy's original ragdoll demo had great standing, walking, and running poses, but fell to the ground in a clump of bones... when physics/gravity was applied.  Otherwise, his ragdolls needed to be "hung" by the head... to remain standing.  Sam likely used an invisible anchor mesh, and a joint extending down to the top of the head (same as what I mentioned). 

I'm not sure if Sam's original demo (Oimo) is still on the web... but Raggar's playground version can be seen here:  http://www.html5gamedevs.com/topic/29464-ways-to-achieve-ragdoll-effect-using-cannonjs/?do=findComment&comment=180514

I'm sure I have forgotten some.  Sorry authors/coders.

I have not seen a BJS physics-active walking, running, jumping, humanoid-like game character.  It is probably a difficult endeavor.  But if you build one, I think @Mythros would love to hear from you.    He/She is looking for something similar... for their sliding-down-hills project.

@MackeyK24... try to keep in mind... that BJS is a JS-based framework.  I don't think we will see machine-language speeds or Bullet-speed physics in these games anytime soon.  Is Unity written in JS?

[MackeyK24]

Unity is native... Although they have a IL to JS converter for html... I think they go C# to Cpp then Cpp to JS (emscripten).

I realize it JS and not native... the whole toolkit is based around "Javascript" or "Typescript" and creating "BabylonJS Game Ready Assets" ready for running in WebGL.

[MackeyK24]

2 hours ago, Wingnut said:

I don't think so.  If there HAS been, it's likely a trade secret.  I'd say @Dad72 has been the closest to a PUBLIC version of that, and his system did not use physics.  It uses moveWithCollision and builtin-ellipsoid colliders.  I doubt you are interested in that.  It doesn't jump, and I don't think Dad72 activated a run.

@satguru also created a fine demo... but it doesn't use the physics engines, either.  http://www.html5gamedevs.com/topic/32052-terrain-slope-problem/?do=findComment&comment=184534

@AndyBeaulieu made a physics avatar kick some things, one time.

@Raggar ported @Samuel Girardin's ragdoll into a playground.  Sammy's original ragdoll demo had great standing, walking, and running poses, but fell to the ground in a clump of bones... when physics/gravity was applied.  Otherwise, his ragdolls needed to be "hung" by the head... to remain standing.  Sam likely used an invisible anchor mesh, and a joint extending down to the top of the head (same as what I mentioned). 

I'm not sure if Sam's original demo (Oimo) is still on the web... but Raggar's playground version can be seen here:  http://www.html5gamedevs.com/topic/29464-ways-to-achieve-ragdoll-effect-using-cannonjs/?do=findComment&comment=180514

I'm sure I have forgotten some.  Sorry authors/coders.

I have not seen a BJS physics-active walking, running, jumping, humanoid-like game character.  It is probably a difficult endeavor.  But if you build one, I think @Mythros would love to hear from you.    He/She is looking for something similar... for their sliding-down-hills project.

@MackeyK24... try to keep in mind... that BJS is a JS-based framework.  I don't think we will see machine-language speeds or Bullet-speed physics in these games anytime soon.  Is Unity written in JS?

Another Holy Shit... Then I might the first one...

I got a Character System 'Workflow' ... I can walk, run, jump, strafe etc... using raw animation clip, or manually calling animator.setCurrentState or even using my 'Mini' state machine transition system to play animations like you would in Unity.

It working great so far (I keep asking how you this type of thing in Babylon like the rotateTowards to maintain some 'PARITY' with 'HOW' unity does something).

My original thought for this post... I am newbie... I am just making up shit and I don't know if it RIGHT or WRONG.  I wanted to see some real BabylonJS game code to see if I am doing things right or not... I don't wanna put my toolkit out and 'Create' a Third Person Controller for ALL to use and someone comes back and says... 'Your a dumb ass... you SHOULD NOT be doing things that way'

But all in all... I got different version of movement going with Linear Velocity and I guess what you would call 'Forcing The Physics' by using mesh.position to move around a game object with physics state...Seems easier and is VERY precise movement...

I got animations and state machines working, and most important... The Kick Ass WORKFLOW the toolkit gives you for making games..

Again just worried bout some of the shit I am just making up. Is WRONG or RIGHT... IS THERE A BETTER WAY TO DO SOMETHING and if BabylonJS already does something like it, I just don't know about it or how to use it.

I will ping @Mythros when I finish my first fully moving Third Person Controlled Character

As ALWAYS @Wingnut ... Thanks for the info

 

[fenomas]

18 hours ago, MackeyK24 said:

What do use use to moving your guy around respecting physics and what not... being to move and run and jump and what not... A full character controller...

What do you use for the actual movement of a game object with physics state enabled ???

mesh.position or mesh.physicsImposter.setLinearVelocity ???

So, there are a few issues stacked up, and there's no "one true" answer to any of them. (Which is to say, Unity might have a single implementation for some part of this but Babylon and programming generally don't.) The fine details depend on what kind of movement you want and maybe on the engine.

But at a high level:

1. You should generally never touch a physics object's position or velocity directly. Apply forces and impulses, use constraints, change friction, etc, but let the engine figure out where to put the objects - that's what it's for.
2. The main exception to (1) is, it's fine to zero out velocity to stop a character, or multiply it by 0.99 to slow them down, etc. Things like that make physical sense.
3. Your post mentions touching mesh.position, but that's probably not useful - that just moves the mesh around, disconnected from its physics impostor. Apologies if that was a typo. The only position relevant here is the impostor's position, the mesh position should just be copied from the impostor.
4. The simplest way to hack up physics based movement is usually to (A) read the user input and construct a vector for which direction to move, (B) scale that vector by some value representing how fast the character moves, and (C) apply that vector as a force to the player body. You do this every frame.
5. For jumps you probably want to apply an upwards impulse, not a force.

The steps in (4) are the minimum naive way to move a character that's controlled by a physics engine, but they probably won't give you the kind of movement you want. For example, you probably want the character to stop moving fairly quickly after the user releases the move button, but that will only happen if there's significant friction, and if there's a lot of friction, it will take a lot of force to move the character, making things very twitchy.

For those kinds of reasons, "real" controllers usually do more stuff, and take some tuning to get what you want.For me in my current project, I do approximately this:

1. First I poll the user input and construct a vector for which direction the player wants to move, scaled up by a value representing their maximum speed.
2. I read the character's current velocity vector, and subtract it from the "desired movement" vector to get a "correction" vector representing which way the player must push themselves to end up moving in the desired direction. I then clamp this vector by some value representing the character's maximum move force, then I apply the result as a force to the player body.
3. Whenever a movement key is pressed, I zero out the player's friction with the ground. When the key is released, I turn friction back on so they stop naturally. I think I also apply a counter-force to help them stop - I don't remember offhand.
4. If the player is airborne, all the above stuff still applies, the player just has much lower move force to represent limited ability to affect their movement, and also apply a drag force for air friction.

Incidentally, I think (2) above, with the correction force etc., is something I got from the Quake sourcecode. (3) about turning off player friction during movement is something I got from an article about Sonic The Hedgehog's movement physics.

But that's all just one way to do it. You could also, for example, get very precise movement by creating an invisible anchor, moving the anchor precisely where the player directs, and attaching the player body to the anchor by some constraint, like a damped spring. Or lots of other things, if you have a pretty clear idea of what kind of movement you want, and you can envision what sort of physical realities would cause that movement to happen.

 

Anyway that's the vague hand-wavey version. If you were having issues with things like diagonals not working, you probably have a bug somewhere much lower down, like in calculating the movement vector. This can be fairly tricky, since you normally need to do some transforming between world and camera coordinates (that is, pressing "right" probably means move "right relative to the camera", not "move East"). So this high-level rundown may not help much off the bat, but let me know if you have questions about it.

[fenomas]

Side note: native-vs-JS has nothing to do with any of this. Getting natural movement with a physics engine is tricky, but it's not computationally expensive.

[MackeyK24]

@fenomas ... hey man thanks... That sounds really great above...

You know after some more researching the Unity Basic Character Controller really uses its own 'Pseudo Physics' in a few place to help with its own internal movement. But DOES NOT use rigid body of any real physics controls to move the character... they say its best (when using character controller) to be able to program out all the character movement and if you really need physics interacting you could always check collision and addForce/impulse via code. 

So to give that same type of feel for the toolkit... I am able to get pretty GREAT movement and correct rotations using moveWithCollisions... I actually just made all three types of movement as Scene Manager Helper functions for movement... So you could easily use whatever you want now in toolkit with your guy... use physics, collisions or translation to move your guy... by default I am going to make the Character Controller Component use moveWithCollisions (with some other code wrapped around that to give the look and feel I want)... I was also able to blend in with Animation State Machine... Start and Stop type animations... So if you run one way full speed and directly change to the other way... is can play run to stop and turn 180 animation and using the various State Machine transitions and conditions including 'hasExitTime' can control which animation need to run to completion or can be interrupted and can be offset as well for timing out sequences.... CAN GET VERY COMPLEX state machine panel (kinda like Unreal Blueprints can get spaghetti looking)... If we can EVER get blend trees going... We can really SIMPLFY that by grouping some of our states into thing like "Grounded" and "Airborn" and "Crouching" and just main those very few actual state/transitions and let the blend tree play via its input what of the blend tree branch motions it should playing when in that state.

Anyways... Thanks for the info ... Like @Wingnut ... it was very helpful

 

[Aerion]

@MackeyK24 When are you planning on doing this controller? I've been looking for a terrain slope controller with sliding camera & multiple animated character FOREVER now!

Thank you so much sir! <3

Mythros

 

[Wingnut]

7 hours ago, fenomas said:

Side note: native-vs-JS has nothing to do with any of this. Getting natural movement with a physics engine is tricky, but it's not computationally expensive.

  It is when a single player-move collides with 20 different items, which EACH collide with 20 different items, etc.  JS physics will get a tumor.  PhysX might be able to handle it.  It is not the move that is "heavy", it is the 1000 things that can interrupt the move. 

Thx for all the great info, @fenomas! 

If I may remind Mackey and others, don't forget about allowSleep and other sleep-related settings... regarding stopping a physics object (and preventing further movement drifting).  Possibly useful.

Btw, when using moveWithCollisions, keep in mind that it was designed to collide CAMERAS with mesh, not mesh with mesh.  I believe nobody has ever used collision ellipsoids to jump atop another ellipsoid.  Even if the object jumped-upon is a box, its collider is an ellipse, and so is the player.  Ever try to balance a bowling ball atop another bowling ball?    But collider.epsilon might help.

Ellipsoids have glance-off.  If two ellipsoids are forced together precisely centered upon one another, the forcer will be stopped dead.  IF, however, the two ellipsoids do not collide with aligned centers, and force continues, the forcer will slide-around the sides, or dive-under, or climb-over the other ellipsoid (glance-off).  I believe there is a setting on collider class called .epsilon, and I think that can be used to set the amount of allowed mis-alignment of two colliding ellipsoids... before this "glancing off" happens.  Possibly, collider needs an allowGlancing bool flag.

"Glance" might not be the right term.  Smear?  Rub?  Scrub?   *shrug*

What happens when a moving mesh.ellipsoid... runs into TWO (or more) other ellipsoids at the same time?  What if the left ellipsoid is centered high, and the right ellipsoid is low.   Continued player.ellipsoid force against these two differing-Y-position blocking ellipsoids... will cause the player to TRY to dive-under the left one, and climb-over the right one.  erf.

AND, last I checked, the top/bottom of ellipsoids have an issue (jumping upon a box). 

https://www.babylonjs-playground.com/#WWCK0#41

WASDQE to move left barrel, SHIFTED-WASDQE to move right barrel.  Try this:

1.  Use 'E' key to elevate barrel1 (left barrel) to around 28 units high.
2.  Use 'D' key to move barrel1 rightward until it is directly above barrel2.  Check your readouts.
3.  Use 'Q' key to lower barrel1 onto top of barrel2.

It didn't go down far enough, right?  Troubles for using collision ellipsoids for jumping atop things.  (Wingnut mistakes possible/likely)

Remember... it is not designed for mesh-to-mesh collisions.  It is designed for camera-to-mesh.  So, we got trouble... right here in River City.    It's all good, though.  These kinds of issues... spur inventors/innovators... but I'm not really such.  I just try to build playgrounds that show the issues, and remind folks of them occasionally, like right now. 

The above PG is a great little testbed to experience "glancing", too.  Use 'W' key to move barrel1 to approx 22 units Z.  Now hold-down 'D' key... and you will see barrel1 ellipsoid "glance-off" or rub-around... the barrel2 ellipsoid.  Again, I suspect that the amount of ellipsoid offset necessary... before glancing happens... can be adjusted with collider.epsilon and also engine.collisionsEpsilon, if that is settable. 

Also, I don't think mesh.ellipsoidOffset is working at all.  In this special version of the testbed, lines 264-266 slowly move .ellipsoidOffset +x.  Wait for 5-10 seconds until collision ellipsoid is well-away-from the mesh.  Then use up-arrow to drive camera into mesh.  It still collides!  I don't think this is correct behavior.

The camera also jitters with continued up-arrow forcing.  We limp researchers believe that the jitter is caused by climb-over glancing (it is a LOW collision) fighting against camera.applyGravity.  The up-arrow tries to make the camera climb-over the blocking ellipsoid (which should NOT be there AT ALL due to the offset), but the gravity pulls the camera back-to the ground... keeping it from completing its climb-over.  Wild, eh?   Party on.

[MackeyK24]

Yo @Deltakosh ... What it better for 'Collision Detection' using a Simple box as the geometry and having ALOT of boxes in scene...

mesh.checkCollision = true or using physicsImposter... Just for performance ... I am curious to know which is the MORE expensive ...

Would it be better in the long run to use simple mesh.chechCollision and moveWithCollision with a bunch of simple objects all using BOXES as the geometry

or 

Apply physics state to the same simple BOXES as geometry and let the physics engine do work... but does that cost more than the camera based mesh.checkCollision algorithms for general movement...

Plus you get 'anonymous' type collision detection event.... Can you get a collision event for mesh.checkCollision... I know you can check for mesh.intersection in an update loop, but I don't think you get and event you can act upon like in the physics on collision event.

What would you use if making a Third Person Character Controller that is going to interact and run up slopes and jump and climp on things... Would you use moveWithCollisions (if it was good enough and precise enough movement to do the job) or just with physics all the way ???

Ping @Wingnut and @fenomas as well ???

[MackeyK24]

Hey yo @fenomas You mention moving with joints... How do you do that??? Are there docs for doing that ???

 

[fenomas]

2 hours ago, Wingnut said:

It is when a single player-move collides with 20 different items, which EACH collide with 20 different items, etc.  JS physics will get a tumor.  PhysX might be able to handle it.  It is not the move that is "heavy", it is the 1000 things that can interrupt the move.

This could happen in principle, but I haven't seen it - Babylon performance dies before physics is a problem. I mean sure, your scene with 1000 things will be slow, but if you profile it I think you'll find the bottleneck is Babylon doing mesh selection and calculating world matrices.

 

36 minutes ago, MackeyK24 said:

Would it be better in the long run to use simple mesh.chechCollision and moveWithCollision with a bunch of simple objects all using BOXES as the geometry

or 

Apply physics state to the same simple BOXES as geometry and let the physics engine do work... but does that cost more than the camera based mesh.checkCollision algorithms for general movement...

As I've written before, moveWithCollision is fine if you are moving one thing and you want to detect collisions with other things which are all static. If you have two dynamic things that can collide with each other, use a physics engine.

[fenomas]

1 minute ago, MackeyK24 said:

Hey yo @fenomas You mention moving with joints... How do you do that??? Are there docs for doing that ???

 

https://doc.babylonjs.com/overviews/using_the_physics_engine#physics-joints

A joint is anything that imposes a constraint between two physics bodies. E.g. a distance joint constrains the distance between them, a hinge joint constrains the angle, etc. Details of how to apply and tune them will depend on which physics engine you're using.

[GameMonetize]

moveWithCollisions will be cheaper but less precise

[MackeyK24]

1 hour ago, Deltakosh said:

moveWithCollisions will be cheaper but less precise

Yo @Deltakosh man I don't know bout this one... I know it me not knowing how to properly move with physics ... Must not be the same MOVE VECTOR you would use to move with translation or the mesh.moveWithCollision which also takes a 'VELOCITY' vector.... Please watch this video and tell me what I am doing wrong... If I am supposed to calculate the movement vector differently... please show me how... This one is SHORT ... at least SHORTER than NORMAL

My Moving With Psychics Problems

[MackeyK24]

Hey @fenomas ... Can I disable gravity on a physics imposter... I don't wanna disable gravity for the whole scene ... just for my player physics imposter...

I got my own code for applying gravity... so I can get a bit of a hover at the top of jump... Right now I am applying it but I am fighting against the gravity the physics imposter native apply... I still nee collision events though

Please tell me this can easily be done

Pinging @Wingnut and always @Deltakosh 

[Pryme8]

@MackeyK24

Impostor Mass = 0;

[Wingnut]

Hi guyz.  Won't mass: 0 cause the player to have no "impact reaction" on any bumped-into objects? 

Sure, you'll still have collision events, but mass is very important to the physics solver, me thinks.  Without mass, player might hit a snowflake mid-jump, and the snowflake will refuse to move (cuz it has mass .001)... and then the snowflake might crush the player into the ground, and perhaps not stop sinking until it hits the Earth's core! 

Yuh yuh yuh, Pryme8, don't tell him these things... or he will code a shitty jumper.    The player weighs 225 LBs, end of discussion.  Now get your jumper working via methods OTHER THAN sawing fat off-of the player with a chainsaw.  heh.  Get your newtons in order, eh? 

ahhh... I've been in a goofy mood, lately.  It is SO FUN to mess with Mackey's mind... but I really like the guy/gal/thing.  I think he might be a robot... not sure yet.  He sure is enthusiastic about his cool Unity Unifier.  Mackey and Mythros both have a touch of "please give it to me on a silver platter" disease... but they're lovable just the same, eh? 

Yuh, player controllers.  What a monster subject THAT is... ouch.

[MackeyK24]

1 hour ago, Pryme8 said:

@MackeyK24

Impostor Mass = 0;

That sets it to STATIC ... then it falls thru the ground and has no collision events... I need collision detection... the the ONLY reason I am even using physics state with

my third person controller... I need to be able to detect when i am grounded after jumping... Right now I using the collision event... check the contact normals within threshold and reset jump state to grounded...  Please... if you know of a technique I can use to detect when I am grounded (not just standing on terrain or a object called 'ground' but standing or made contact with another object that could be stood on... like boxes and platforms as well as terrain)... I would really appreciate that

 

[MackeyK24]

1 minute ago, Wingnut said:

Hi guyz.  Won't mass: 0 cause the player to have no "impact reaction" on any bumped-into objects? 

Sure, you'll still have collision events, but mass is very important to the physics solver, me thinks.  Without mass, player might hit a snowflake mid-jump, and the snowflake will refuse to move (cuz it has mass .001)... and then the snowflake might crush the player into the ground, and perhaps not stop sinking until it hits the Earth's core! 

Yuh yuh yuh, Pryme8, don't tell him these things... or he will code a shitty jumper.    The player weighs 225 LBs, end of discussion.  Now get your jumper working via methods OTHER THAN sawing fat off-of the player with a chainsaw.  heh.

ahhh... I've been in a goofy mood, lately.  It is SO FUN to mess with Mackey's mind... but I really like the guy/gal/thing.  I think he might be a robot... not sure yet.  He sure is enthusiastic about his cool Unity Unifier.  Mackey and Mythros both have a touch of "please give it to me on a silver platter" disease... but they're lovable just the same, eh? 

Yuh, player controllers.  What a monster subject THAT is... ouch.

 I am overriding movement with position... so I just need the collision event... I would like to NOT apply gravity to that one imposter so I can use my own gravity code to handle Y movement... I use a jump with terminal velocity and gravity multiplier to create jumps with slight hover at top of jump... I use that on moveWithCollision to implement gravity... I would like to use in the overriding of the position I am using with physics... Now I have to "go along' with the gravity cannon is applying to bring back down... I wanna control that part

 

[Wingnut]

http://doc.babylonjs.com/classes/3.0/groundmesh#getheightatcoordinates-x-z-rarr-number

(interesting method to get height of groundMesh under player - for hilly heightMaps)

Um... you can "watch" the impostor's getLinearVelocity().y and null it out, or freeze it when player has reached jump-arc apex.  This has to be done in the render loop, so it will slightly slow the jump speed.  Or... even impostor.position.y can be watched in the render loop.  If impostor.position.y < previousPosition... then player is at top of jump arc and has begun falling.  What to do then... I dunno.  I guess you can freeze the impostor.position.y for oh... 3/4 second... to get some "hang time".  But yeah, then you need to bring him down, somehow.  Just thinkin'... probably badly.

I didn't perfectly understand your use of .moveWithCollisions... along with a physics engine.  Different system, as you likely know.  Physics impostor won't "come along" if you use .moveWithCollisions... at least i don't THINK they will.  MoveWithCollisions uses .ellipsoid colliders, not impostors.

[fenomas]

3 hours ago, MackeyK24 said:

I don't wanna disable gravity for the whole scene ... just for my player physics imposter...

I got my own code for applying gravity... so I can get a bit of a hover at the top of jump... Right now I am applying it but I am fighting against the gravity the physics imposter native apply...

Gravity is basically a downwards acceleration of G, which is the same thing as a downwards force equal G * M (the object's mass). So the easy way to cancel gravity for one object is to apply an upwards force on it equal to G*M, and they'll cancel out.

However, rather than canceling gravity and then re-applying your own custom gravity, it would probably be easier to just apply forces that result in the floatiness you want. E.g for some time period near the top of the jump apply an upwards force of (G * M / 2), which would make the jump more floaty but not completely weightless. (You then probably want to turn off this force if the jump button is released, allowing the player to control the height of the jump.)

Some physics engines also have a gravityMultiplier kind of property, letting you make different objects more or less floaty, but Cannon doesn't.

 

1 hour ago, Pryme8 said:

Impostor Mass = 0;

dude...

[MackeyK24]

3 minutes ago, fenomas said:

However, rather than canceling gravity and then re-applying your own custom gravity, it would probably be easier to just apply forces that result in the floatiness you want. E.g for some time period near the top of the jump apply an upwards force of (G * M / 2), which would make the jump more floaty but not completely weightless. (You then probably want to turn off this force if the jump button is released, allowing the player to control the height of the jump.)

Thanks @fenomas  ... That kinda of make sense with what I found:

 

var g = this.settings.gravity;
   this.world.gravity.set(0,g,0);
   for(var i = 0; i < this.world.bodies.length; i++) {
      var b = this.world.bodies[i];
      if(b.type === CANNON.Body.DYNAMIC) {
         b.force.y -= b.mass*g; // this will make the net gravity zero

         // apply your custom gravity here

      }
   }
   //then...
   this.world.step(this.settings.timeStep);

 

Something like that they are using to cancel out and then apply own gravity.

Still a bit beyond me to easily implement in the toolkit (I still a newbie... I would have to really study that process to make code code for toolkit)

 

Shit... I don't even wanna use physics to move my character ... I don't know if you saw other post I made but I am only really using the physics because I need some kind of collision detection event so detect if I am 'GROUNDED' after a jump... I thought about try to keep a empty object slightly below my feet and ray cast down to that position... check check for contact normal on hit... But that seems like that won't really work because I would have to LAND EXACTLY CENTER for the recast to pick up... if I land ENOUGH to stand on a boxes but the center recast is not QUITE over box it would miss... In unity they a "Sphere" raycast that cast a ray or rays the volume of the sphere downwards so that would hit... Do We Have Something like "Sphere" Raycast ??? Or you seem REALLY good at Babylon... Do know of a good way to detect "IS GROUNDED" ???

PLEASE