[solved] Player want to stand/move on moving box

[Wingnut]

http://playground.babylonjs.com/#2ACS0V#7

I did a few more tests on scaled shapes (all MESH class, no MeshBuilder). 

I THOUGHT the problem was .scaling that is inherited from the parent.

But even with no scaling on the railings...

http://playground.babylonjs.com/#2ACS0V#10

...the railing impostors are having problems stopping player slide.  I'll keep thinking.

Update:  http://playground.babylonjs.com/#2ACS0V#11

Essentially, thou shalst not scale parents... when using physics.   

Cursor keys are fast and smooth on that one, huh?  *nod*  WASD for cam, as always.

[Hans]

Sooo .... after a long downtime ... I`m back

@Wingnut I worked yesterday on the jitter problem:

Here you can see the problem again with a speeded up scene: Bad jitter in action

Here is my solution for that: Jitter solution

Important here are the lines: 77,78 and 127 - 136.

In this solution you can also move both meshes with: i,j,k,l   and the arrow-keys.

Mind: The scenespeed is still 1/20

[fenomas]

Hey,

I can help with physics but it's hard to scan this long thread and see what still need solving. So I hacked up your previous demo into a simple version of what I'd think of as the "right" way to do a physics-based moving platform:

http://playground.babylonjs.com/#2CC4HX#1

The big differences from your demo:

• In a game like this you want to fix the player's and platform's rotation - so that when you apply a sideways force they translate around, rather than rolling. In Cannon I believe the correct way to do this is by setting angularDamping to 1, as in my link.
• In my link the platform behavior is handled by simply putting the player on the platform, and allowing friction to keep him in place. This avoids any need to detect collisions and so forth.
• I cleaned up the movement code so that the player moves while keys are pressed, rather than on each key event, and add jump (on space)

I also added a little hack that I use in my game - I lower the player's friction when a movement key is pressed, and raise it again otherwise. This lets the player move around easily, but still come to a stop when not moving.

Hope this helps!

[Hans]

Hey @fenomas this is a very good supplement, thx for that! 

My last post approach the jitter problem. The player will fall down after a certain time without moving. This happens also when the platform is not moving.
Maybe we can combine our solutions
I will try to make a playground these days.

[fenomas]

1 hour ago, Hans said:

My last post approach the jitter problem. 

Avoiding jitter in physics engines is a matter of tuning parameters. In your case, just remove the line where you increase the timestep (to 1/20).

[Hans]

This do not remove the jitter problem. Unfortunately this mitigate only the jitter problem.

I tested my jitter solution from above, but it doesn't work. A sleeping object has no friction. So if the player body sleeps, he slides downwards.

[fenomas]

Same answer - tune parameters. It's impossible to remove jitter from an integrated physics simulation - you can only minimize it, and tuning parameters is the best way to do that.

Personally I don't see any jitter in the link I made for you, and I don't see any in your link if a timestep of 1/60 is used. But if you're not happy with them, try a timestep of 1/120, or try smaller gravity, lighter bodies, or try changing the physics engine's other parameters. 

But I don't think you'll have much luck manually sleeping and waking up the bodies. That's not fixing jitter, it's just turning the simulation on and off.

[Wingnut]

@fenomas, what IS sleepSpeedLimit, allowSleep, sleepTimeLimit, sleepState supposed to be used-for, then?  When is the auto-sleep system SUPPOSED to be used?  For what?  Why do these parameters exist... if they are not used to stop forever-jitter?  I'm confused.  (thx for clarification)

By the way, I turned-off all the before-render animation in your demo:  http://playground.babylonjs.com/#2CC4HX#2

Although I didn't watch it... I estimate about 5 minutes until the green box jitters-off the platform.

Fenomas, can you (kindly) clarify?  Auto-sleep cannot work... when gravity is a constant force?  Do you know?  (This was talked-about in previous areas of thread.  I think Hans saw sleepState = true IF he reduced gravity to zero.)  Or maybe, sleepState NEVER had ANYTHING to do with jitter?  Maybe it's not intended for that.  (these are some thngs we could use answers-to, everyone).

Hans has been a delight to work-with, too.  Kind, extremely patient, entertaining, willing to experiment and invent, reports all discoveries, just a great guy.  I highly suggest we try to treat him kindly, in return.

Yes, multiple issues have been addressed, here, but still... topic is on-subject with... WHY no-sleep/why jitter-off? 

Perhaps Hans and I are on a wild goose chase. 

[Hans]

On 2/13/2017 at 5:38 AM, Wingnut said:

Auto-sleep cannot work... when gravity is a constant force?  Do you know?  (This was talked-about in previous areas of thread.  I think Hans saw sleepState = true IF he reduced gravity to zero.)  Or maybe, sleepSate NEVER had ANYTHING to do with jitter? 

@Wingnut You are not right anymore Change the sleepState with constant force ist possible. Look in my solution from above: http://playground.babylonjs.com/#ZNRGG#2 . Both objects sleep. There is no jitter! You can also move both objects. (with arrow-keys and i,j,k,l) The objects fall to sleep again.

(I didn´t checked the sleepState. I think the sleepState is buggy or works diffrent. But the sleep and wakeup methods working.)

The big problem in this solution is: Sleeping objects have no friction. So, the platform moves without the player again.

BTW, Thanks for keep me motivated

[Wingnut]

You are using a tranquilizer dart for sleep, and "smelling salts" to re-awaken!  heh.  That's not the same as "falls asleep" 

Comedy aside, I think all should be automatic.  There should be no need to test for intersection, and no need to force sleep().  It should be magically done FOR us.  (maybe)  hmm.  I'm going web reading about this - see if I can learn something before I fall asleep. 

[fenomas]

15 hours ago, Wingnut said:

@fenomas, what IS sleepSpeedLimit, allowSleep, sleepTimeLimit, sleepState supposed to be used-for, then?  When is the auto-sleep system SUPPOSED to be used?  For what?  Why do these parameters exist... if they are not used to stop forever-jitter?  I'm confused.  (thx for clarification)

Sorry, let me back up.

When I say it's impossible to eliminate jitter, I just mean that (discrete, integrated) physics engines are inherently inexact, so there's always some jitter going on (if the objects are awake). The only difference between a stable scene and an unstable scene is whether the jitter is noticeable or not. It's certainly possible to avoid noticeable jitter!

As for auto-sleep, you should think of it as a CPU-saving feature, not a way to avoid jitter. The "sleep" feature in physics engines isn't supposed to perceptibly affect the simulation - it's supposed to skip bodies whose movement is imperceptibly small.

In other words, auto-sleep isn't a good way to fix jitter because bodies should only be falling asleep when their jitter is too tiny to see. 

 

15 hours ago, Wingnut said:

I highly suggest we try to treat him kindly, in return.

I don't know what you're referring to, but I didn't mean to be unkind. Since there are a lot of non-native speakers here, I try to keep my answers brief and clear, that's all.

That said, there is no wild goose chase here - it's a very simple scene and it should be working fine, with no need for manually turning stuff on and off. All it needs is a suitable timestep!

[fenomas]

6 hours ago, Hans said:

The big problem in this solution is: Sleeping objects have no friction. So, the platform moves without the player again.

Sleep is a way of temporarily ignoring objects that aren't affecting the physics simulation. So if you want the platform to affect the simulation, it can't be sleeping. 

It would be easier for me to help solve your problem if you could explain what you don't like about the working demo I posted.

[fenomas]

Oh, almost forgot:

5 hours ago, Wingnut said:

There should be no need to test for intersection, and no need to force sleep().  It should be magically done FOR us.

 

scene.getPhysicsEngine().getPhysicsPlugin().world.allowSleep = true

 

Magic! 

[Wingnut]

AllowSleep on world.  Wow, I didn't expect that.  Cool, thx.  Does it affect anything in our 5-minute jitter-off scene?

On 2/13/2017 at 10:07 PM, fenomas said:

you don't like about the working demo I posted

 

On 2/13/2017 at 5:38 AM, Wingnut said:

By the way, I turned-off all the before-render animation in your demo:  http://playground.babylonjs.com/#2CC4HX#2

Did you test it, @fenomas?  This is your "working" demo, with both renderLoop anims disabled.  The green box falls-off-of the red platform... after about 4.5 minutes (on my desktop machine).   Is that "working"?

Hans has done lots of "parameter-tuning", already.  Telling him that incorrect solve... TWICE... well... seemed a bit hard-nosed to me. 

Then again, you didn't back-read the thread, so you didn't know what was already tried.  *shrug*  It's all cool.  Hans has been waiting a long time... for better help than I... and we have both done some begging for help... for about what?  3 weeks now, Hans?  A month? 

Not many forum helpers wanted to come to this campfire.  We're glad you visited, Fenomas!  Sorry for the long thread... but... it's been THAT long unsolved.  We just kept experimenting and trying things... and failing.  But we were also working on an issue about scaling physics mesh-shapes, too.

Thx for the reminder about world.allowSleep.  I think that is the solve we were looking-for.  http://playground.babylonjs.com/#2CC4HX#4

Added that line at 157.  That demo now shows a quick-change to player.sleepState = 2.  And, I'm not seeing any indication of jitter-off.  YAY!  Perhaps we can learn about auto-sleep, now that it is activated and apparently working. 

Who would have expected world.allowSleep to be false by default?  hmm.  Okay, we have things to work-with, now.  New life for our dead-end thread.  Thx @fenomas, well done.

[Wingnut]

Hey @fenomas... notice that we (Hans and I) are not concerned about seeing the jitter, and we are not concerned about reducing CPU load.  We just want to keep the player box atop the platform.    But a THEORY we have is:  Jitter affects friction.

AND... we have a new issue that Hans has raised:  Friction is asleep on sleeping bodies.  So, if we move the platform while player box is asleep, platform-player friction will not work, and player will not move WITH platform.

AND... we would like to learn about LOCAL linearVelocity and see if we can impulse the green box from side-to-side ATOP the platform... without affecting the platform (other than maybe tiny platform tilt due to mass position-change). 

NOW we're tuning some parameters.    Ground-platform mass/friction, platform-player mass/friction, etc.

But still, we have studies to do on auto-sleep... and when to wake, and why.  If we slowly tilt platform... with sleeping player atop, will player EVER start sliding?  hmm.  Perhaps player box will wake when tilt starts.  Tests ahead.

[fenomas]

Um. Could we keep this light, and on the topic of physics please? I'm sorry to hear that Hans has been waiting a long time and I'm sorry if my demo didn't address every question in the thread. It was meant to be a starting point, not a solution to every question.

I'll try to answer your questions (omitting the bits not related to physics):

3 hours ago, Wingnut said:

Did you test it, @fenomas?  This is your "working" demo, with both renderLoop anims disabled.  The green box falls-off-of the red platform... after about 4.5 minutes (on my desktop machine).   Is that "working"?

My link was an example of how one could make a moving platform. Jitter between stationary objects over several minutes is a completely different problem - if you need to solve that, then auto-sleep is the answer. I understood Hans to be wanting a moving platform, and sleep() isn't very useful for things that need to move.

3 hours ago, Wingnut said:

But we were also working on an issue about scaling physics mesh-shapes, too.

I saw that, but don't think I have anything useful to add. I understood it to be an issue with BJS giving incorrect data to Cannon, right? If there's an issue that's specific to the physics engine then maybe I can help.

3 hours ago, Wingnut said:

That demo now shows a quick-change to player.sleepState = 2.  And, I'm not seeing any indication of jitter-off.  YAY!  Perhaps we can learn about auto-sleep, now that it is activated and apparently working. 

Auto-sleep basically just looks at each body's velocities (linear and angular), and if they're below some threshold for a certain amount of time then the engine skips over those bodies in some parts of the simulation. Notionally, it's similar to temporarily making the object static.

This is getting long so I'll split into a second post.

[fenomas]

Now for what might (I hope) be the crux of the matter:

On 2/14/2017 at 7:15 AM, Wingnut said:

Hey @fenomas... notice that we (Hans and I) are not concerned about seeing the jitter, and we are not concerned about reducing CPU load.  We just want to keep the player box atop the platform. 

Okay. The thing that's keeping me from helping is, all the demos I've checked in this thread are simulating a player on top of a platform, with the platform accelerating, and both bodies having a coefficient of friction less than one. For that scene, the physically correct result is that the player will slide around - and possibly fall off - the platform. I.e. it's not a Cannon issue, it's what would happen in real life!

To make this clearer, here's a simpler revision of the demo: http://playground.babylonjs.com/#2CC4HX#5

As before, that's a "working" demo - by which I mean, the engine is correctly (within some small tolerance) simulating a free body on top of a moving body. Sure, the player slides back and forth on the platform a little, but again, that's what would happen if you jumped on a moving platform wearing shoes with a coefficient of friction less than one.

Now, if Hans wants behavior "sort of" like that demo, except maybe with more or less friction, then great - maybe that kind of setup will work. If not, then what we need to change depends on what specifically he wants to be different. For example, if the player jumps upwards while the platform accelerates sideways, should the platform move out from under him, or should the player stay still relative to the platform? Or if the platform were to move upwards or downwards, should the player naturally separate from it, or stay stuck, like he was wearing velcro shoes? These are all different kinds of scenes to simulate.

As examples of solutions, one option would be: when the player lands on the platform, re-parent the player's physics impostor to be a child of the platform's. Or alternatively, change the player body to be static, and manually move it's position around in sync with the platform. Another option would be: if the platform is a boat, and you want the player to (locally) act as if the boat was regular ground, you could make the boat stationary as far as the physics engine is concerned (and make the player think the boat moving by moving the background in relation to it).

Or, again, maybe the link I posted before can work, with some dynamic editing of friction values. It all depends on the details of what needs to change.

The tricky thing about using physics engines in games is that very often we want games to have non-physical behavior. The demo I linked is, more or less, "physical behavior". When I asked Hans what he didn't like about it, what I meant was, what needs to behave non-physically?

[Hans]

@fenomas your first working demo is very good. The only bad thing is in my view,  that the player jitters downwards. The player have to move to keep standing on the platform. I dont want also to set the worldspeed down to give the player more time on the platform. My idea was to set the player to sleep, but it does not work how we know now Do you have another idea for this problem?

- Maybe we can set the platform temporary  as parent?

- Or we can remember the relative player position if he does not move and correcting it with small impulses if he jitter away from this?

20 hours ago, fenomas said:

I don't know what you're referring to, but I didn't mean to be unkind. Since there are a lot of non-native speakers here, I try to keep my answers brief and clear, that's all.

You don't have to write short answers for me. I am ready to read long answers to learn more about the issue and english. So dont restrain

 

11 hours ago, Wingnut said:

Hans has been waiting a long time... for better help than I... and we have both done some begging for help... for about what?  3 weeks now, Hans?  A month? 

@Wingnut You are right. This thead has a long lifespan, but I did not expect that i got a fast solution. To discuss about the issue is already a big help for me. This keeps me motivated, gives me ideas and sometimes a solutions. The best of all is that this happens with nice and capable people

11 hours ago, Wingnut said:

But we were also working on an issue about scaling physics mesh-shapes, too.

Yes. I will create a new topic later for this. I think we solve one problem after another. So much problems ... we will work together for a long time 

[fenomas]

3 hours ago, Hans said:

@fenomas your first working demo is very good. The only bad thing is in my view,  that the player jitters downwards. The player have to move to keep standing on the platform. I dont want also to set the worldspeed down to give the player more time on the platform. My idea was to set the player to sleep, but it does not work how we know now Do you have another idea for this problem?

I have several! 

If you don't want sliding like in my second demo, then maybe the closest thing to what you've been trying would be to clamp the player to the platform with a lock joint.

To see how that works, check how I move the platform in my second demo. You could do something similar - make an invisible static body that is locked to the platform, and when the player touches the platform, make another lock joint between the hidden body and the player.

This would hold the player still on the platform, and then to move the player you would move the hidden body around, relative to the platform.

The drawbacks to this I can think of are:

1. The player's motion on the platform would be nonphysical - it would feel different from when he moves on the ground because on the ground you're moving him with forces and friction, and on the platform you're manually changing his position. 

2. You'll have to manually detect any case where the player needs to separate from the platform. E.g if the player jumps, or he gets hit by an explosion or a monster or whatever.

I can't write any demos at the moment as I seem to have a cold, but I hope that gives you some ideas. 

Incidentally as a general piece of advice, when you want to change the behavior of bodies in the physics simulation, rather than directly manipulating their position or velocity, it's better to create a hidden static body, attach it to your target with a joint (like a spring or a lock), and then move the hidden body instead. When you directly manipulate properties, it will tend to break the simulation in unpredictable ways.

[Hans]

This behavior with the joints is interesting.

I will try something with your ideas and I will return later. Thanks!

Edit:

@fenomas I tried to realize your idea, but there is a strange behavior.

Here is my not working demo: http://playground.babylonjs.com/#2CC4HX#7

Dont know why, but some lockJoints dont work. I think i understand something wrong.

How can i move the static body relatve that is locked to the platform? This moves also the platform then or the platform will set back from the static lock body.

[fenomas]

On 2/14/2017 at 10:17 PM, Hans said:

@fenomas I tried to realize your idea, but there is a strange behavior.

Here is my not working demo: http://playground.babylonjs.com/#2CC4HX#7

Dont know why, but some lockJoints dont work. I think i understand something wrong.

How can i move the static body relatve that is locked to the platform? This moves also the platform then or the platform will set back from the static lock body.

Hm. Originally I was thinking of digging around in the lock internals to change the bodies' relative positions, but after some tinkering I think this can be done more simply.

I coded this up: http://playground.babylonjs.com/#2CC4HX#8

On collision, it creates a lock joint to hold the player still WRT the platform. Then on move/jump it unlocks, and doesn't re-lock for least 100ms.

It would need some tweaking - move speeds and friction, etc, but see if this is similar to what you're aiming for.

[Hans]

Very good! Exactly what i want Thanks a lot!

I have just some small questions:

Wherefore are this lines:

player.physicsImpostor.physicsBody.fixedRotation = true;
player.physicsImpostor.physicsBody.updateMassProperties();

And what is the diffrent between angularDamping and fixedRotation? Can I use angularDamping = 1 instead?

[fenomas]

11 hours ago, Hans said:

player.physicsImpostor.physicsBody.fixedRotation = true; player.physicsImpostor.physicsBody.updateMassProperties();

And what is the diffrent between angularDamping and fixedRotation? Can I use angularDamping = 1 instead?

In principle they should do the same thing, but in practice I found that using angular damping made the player "skip" a little when moving laterally, as if the corner was getting caught up on the ground's friction. I think this is probably due to cannon.js internals - I'm guessing that fixedRotation prevents rotations entirely, while angular damping means rotations sort of happen, and then get zeroed out later in the loop, or something.

Anyway I changed it because it seemed to fix an issue I assume you don't want, but of course you can give them both a try and see what you like!