BasicPlayerController - slippery, strange behavior [Solved]

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

BasicPlayerController - slippery, strange behavior [Solved]

Postby rystills » Fri Jun 21, 2019 4:40 am

I finally got around to testing the Newton PlayerController in my game engine. After adapting the code from the BasicPlayerController demo, things more or less work; my player can move forwards/backwards and left/right based on the camera's yaw, falls due to gravity, and is stopped by floors, walls, ceilings, and other objects. However, the PlayerController seems to have a number of issues:

-When moving, the Player increases or decreases speed gradually over a few seconds, making it very sluggish to control (I would expect a kinematic controller to start and stop moving rather quickly).
-When strafing into a wall, the Player slides up the wall, rather than simply stopping.
-When colliding with high-poly static meshes, the Player will sometimes crash the application entirely.

My question is: are all of these things expected behavior, or did I do something wrong when adapting the BasicPlayerController? I attempted to build the sandbox demos so that I could see how the BasicPlayerController demo functions, but after my build failed to run I realized I'll need to go back and manually build the sandbox dependencies first. I suspect this is all a result of me doing something wrong when integrating the PlayerController, but I'd like to get some input on how the PlayerController should be working before diving deeper.

Thank you, and my apologies for asking a somewhat vague question.
Last edited by rystills on Fri Jun 21, 2019 10:23 pm, edited 1 time in total.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior

Postby Julio Jerez » Fri Jun 21, 2019 6:40 am

No it should no do any of that. The controller do what ever you tell it to do. The controller is not a one fix all solution, after you set up the functionality you need to do your own game play logic . But it is very easy, methodical and predictable.
I do not understand what you mean by build the dependencies manually. The sdk comes with a visual studio solution that build all the dependencies.
And also with a cake script that build all the dependencies.
Everything it need is on the archive. What dependencies are you talking about?

Are you on Windows?
Please try building the demos sandbox and play the basic player, see if that is what you look forward.
The sfk should compile out of the box.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior

Postby rystills » Fri Jun 21, 2019 3:40 pm

You are correct about the dependencies; I took another look at it today and discovered that the reason the demos would fail to run after building is because I was using Visual Studio 2019, rather than VS2015. When using VS2015 the demos build and run just fine, and I can see how the player controller should be operating. The demo controller still increases and decreases speed gradually, but does not slide up walls and did not crash on me, so those problems are likely on my end. I'll have to see if I can link a version of newton built in VS2015 with my project, which uses VS2019.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior

Postby Julio Jerez » Fri Jun 21, 2019 3:45 pm

the sdk fail to build with vs 2019?
Are you using the cmake script?
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior

Postby rystills » Fri Jun 21, 2019 3:56 pm

I did not try any cmake script. I simply opened applications\demosSandbox\projects\visualStudio_2015\demosSandbox.sln in Visual Studio 2019, and said yes to upgrade the project to windows SDK 10 / platform toolset v142. I then built the solution in debug mode (which was successful) and ran it, at which point I was met with an assert failure. I'm afraid I am still far from an expert with regards to building, linking, and dependencies in C++.
Attachments
Annotation 2019-06-21 155545.png
Annotation 2019-06-21 155545.png (17.21 KiB) Viewed 457 times
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior

Postby rystills » Fri Jun 21, 2019 4:31 pm

I disabled WholeProgramOptimization and built Newton in VS2015, then tried that in my engine rather than the VS2019 Newton build I was previously using, and now strafing into walls no longer causes the player to slide up the wall. I guess the bugs I was experiencing were a result of me building Newton incorrectly after all. Thank you for helping me to resolve this, I should have tried reverting to VS2015 first thing.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior

Postby Julio Jerez » Fri Jun 21, 2019 7:28 pm

so you have it working?

the way you control the about of player traction traction is by implementing
dFloat ContactFriction(dCustomPlayerController* const controller, const dVector& position, const dVector& normal, int contactId, const NewtonBody* const otherbody) const

there if you have material id in your mesh, you can associate the ID with friction coefficients.
for a quick test you can simply return 3.0 I believe is the max friction, but that can be changed.

the second way you can tweak it, is by make the gravity stronger. Make games do this kind of things. play with it and you will see how flexible it is.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior

Postby rystills » Fri Jun 21, 2019 10:23 pm

Yeah, the PlayerController is working well now. Interestingly, forcing a high contact friction value at all times results in the aforementioned "sliding up walls" behavior, but following your suggestion and simply increasing the frictional value associated with the floor's contactId results in quick, responsive grounded movement without any negative side effects as far as I can tell. Physically, I suppose that makes quite a bit of sense. I will continue to experiment with the PlayerController and see if I can further adapt it to my needs. In the meantime, I believe all of my questions on this topic have been resolved. Thanks again for your assistance!
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby Julio Jerez » Thu Jun 27, 2019 11:20 am

I am making some improvement to the controller.
You say that setting high friction causes the player to climb walls.
That should never happens, I made an extraordinary effort to make a player that is driven by friction.
So a high friction value no matter how strong it was, should never ever cause the player to move if the contact projection over the velocity is smaller that the friction along the tangent.
The controller is not a simple adhock implementation, it is in fact constrained optimization, with the goal to let the capsule move along the direction of least resistance. Therefore the least resistance path can be a steeper slope but never a vertical wall because a vertical wall would be a singular matrix.

So that is not a good sign, not just a bug but a fundament catastrofic problem.

My guess is I am misunderstanding what you mean, if you can can you make a video so that I can see what you mean?
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby rystills » Thu Jun 27, 2019 11:32 pm

Sure thing, this is likely just a miscommunication and not actually an issue. Here's a short clip where ContactFriction returns 0 for steep slopes / walls (contacts whose normal.m_y < 0.9), and 10 for all other contacts:
https://giant.gfycat.com/InnocentTalkat ... shark.webm

and here's a clip where ContactFriction always returns 10 regardless of the normal.m_y value:
https://giant.gfycat.com/MinorMarriedLa ... hrush.webm

As you can see, in the first clip the player stops when he hits a wall, whereas in the second clip hitting a wall causes the player to jump up and down. The code in the first clip is what I'm using (as well as what came with the BasicPlayerController when I downloaded it, more or less) so its not a problem for me either way.

My engine is not open source at the moment, but if you think it would help, I'd be happy to add you to the github repository so that you can see the full codebase and play with it yourself. Just let me know and I'll clean things up a bit and then add you as a collaborator so that you can access it.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby Julio Jerez » Fri Jun 28, 2019 7:53 am

ah I see the problem, so not you were not wrong, I was, that behavior with the high vertical friction should not happens and it's not acceptable to me.
I will fix it.

I see you set a friction value of 10, nothing wrong with that but :shock:

I think what I now see what happen, a friction value of 10 will allows the player to climb an 85 dregrees slope. so any contact normal with the slightest deviation from being horizontal will generate some vertical motion. That's my theory but I will try to recrate it anyway.

I think the solution is to unconditionally or maybe optionl make contact on the wall of the cylinder friction less and only contact on the round patch been tractions contacts.
that seems should like an attractive proposition the only way to know if to implement and try.

I will try some adjustments.

on the GitHub, as much I like, I must decline now, too many people ask me this same request but it takes too much on my time to set build systems.
if it comes the time them yes, but must the time, bugs can be fixed by a demo that link to the newton dll and that do not make the mouse exclusive so that does not hang visual studio when attaching to the exe.

Anyway I almost have the refinement ready, I will commute this weekend.
It will also address few other glitches that cause the player getting stuck on complex corners. Plus the ability to push objects and drive on moving surfaces. All emergine from the simulation so the end app does not have to do anything.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby rystills » Fri Jun 28, 2019 4:11 pm

Excellent, those all sound like helpful fixes :) If I may ask one additional question regarding the PlayerController, how might I go about allowing the player to influence the PlayerController's mid-air movement? SetForwardSpeed and SetLateralSpeed are perfect on the ground, but once the Player leaves the ground by jumping or falling, the player loses all control until the PlayerController lands on the ground once more. I would like to provide the Player with some control over the PlayerController while in midair in order to make jumping more precise.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby Julio Jerez » Fri Jun 28, 2019 5:00 pm

rystills wrote:how might I go about allowing the player to influence the PlayerController's mid-air movement? SetForwardSpeed and SetLateralSpeed are perfect on the ground, but once the Player leaves the ground by jumping or falling, the player loses all control until the PlayerController lands on the ground once more. I would like to provide the Player with some control over the PlayerController while in midair in order to make jumping more precise.


ah that's where it comes the user side game logic.
remember when I said, the client app add its own game logic, the controller only resolve the constrained kinematic impose by the world.
This is not quite 100% true, since for the control to be useful some feedback has to be provided,
I already added one which was the set local frame.
another one would be a function call to check if the play is airborne, I will add that sometime tonight
the you can do something like:
you can do something like that.

Code: Select all
   virtual void ApplyMove (dCustomPlayerController* const controller, dFloat timestep)
   {
      // calculate the gravity contribution to the velocity
      dVector gravity(controller->GetFrame().RotateVector(dVector(DEMO_GRAVITY, 0.0f, 0.0f, 0.0f)));
      dVector totalImpulse(controller->GetImpulse() + gravity.Scale (controller->GetMass() * timestep));
      if (PlayerAirbone()) {
         //totalImpulse + someUserImpulse
      }
      controller->SetImpulse(totalImpulse);
.....


the user impulse could be in any direction or magnitude. it can be a rocket or a simple jump, or summing
if you want for example do a jump, you just add one vertical initial impulse, and that will be a jump.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby rystills » Fri Jun 28, 2019 5:17 pm

That airborne flag sounds like a great quality of life addition! Currently I have a 'canJump' flag which I set to true on each frame where the PlayerController is in contact with a sufficiently gentle normal. My jump logic is quite similar to your recommendation, which is great to see! I'm just having some trouble with moving forward / backward / left / right after jumping. It seems like SetForwardSpeed and SetLateralSpeed don't work while the Player is in the air, so whatever speed the player had when he jumped is locked until he reaches the ground. Perhaps that is simply an issue with my code though. I'll take a closer look tonight, and peek under the hood to see how Newton resolves these methods.
rystills
 
Posts: 17
Joined: Wed Jun 12, 2019 2:01 pm

Re: BasicPlayerController - slippery, strange behavior [Solv

Postby Julio Jerez » Fri Jun 28, 2019 6:13 pm

rystills wrote:It seems like SetForwardSpeed and SetLateralSpeed don't work while the Player is in the air, so whatever speed the player had when he jumped is locked until he reaches the ground.

yes this is correct. That's in tune with the law of motions.
SetForwardSpeed and SetLateralSpeed act by friction, so if the player is on air, the speed along the plane remain constant. It may seem off now but as you use it more you will find that these are the features that make the controller predictable. :mrgreen:
and that behavior come out of the simulation for free. so instead of removing from a set of predetermined features, you can just keep adding.

once the player in on air it needs it own means of propulsion: a rocket, wings, jumps, anything that can be implemented via an impulse. Just way for the function IsAirBorned that will give you precise state logic.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests