i have a character controller player and whenever it moves and colliding with colliders that have a 90 deg slope, i get a large FPS drop…
Not colliding:
watch the profiler…
the movement script has something like 500 lines and i thought i have made the problem but then i made a new script for a basic horizontal move and it still did this:
var moveDirection = Vector2.zero;
function Update ()
{
moveDirection.x = Input.GetAxis("Horizontal") * 5;
moveDirection.y -= 9*Time.deltaTime;
GetComponent(CharacterController).Move(moveDirection * Time.deltaTime);
}
That is not suggesting you have the character controller set to be able to climb a 90 angle slope limit, does it?
The characterController is designed to slide along other colliders, so if it is “trapped” it is trying to solve its direction of movement and that is probably making the hit on the cpu.
I have noticed that the characterController is pretty expensive (they even use the term “expensive” on some of the character controller functions that show up in the profiler. - this prompted me to switch my AIs to using rigidbodies and only the players use characterControllers.}
I may be overlooking something, but in the end, I think there will be other things in your game play that will ultimately drop the frame rate to below 100s or 1000s of fps.
oh - I did not word that correctly. What I meant was that it probably is not a good idea to set the slope limit to 90 degrees and then expect the characterController to be able to climb up the wall - that is not what you are trying to do is it?
The rest of my reply relates to what a characterController does when it is colliding and processing to determine which way it can slide. If you have it trapped then it is just doing tons of processing and that is the cause of the slow down.
Do in regards to what?
You show a profiler that says 4000 fps, and then a characterController that is stuck in a hole and now 1000 fps - what is your point?
You did not answer my question - are you expecting it to climb up the wall?
no i dont want it to climb up the wall and never expected it to do so…
it basicly do what i want it to do, makes the player stop and wont let it move to the side the wall is in.
the problem is with thos uneeded calculations…
what do you mean what is my point? even if i have 10000 fps, i dont think a character controller need to cost so much when it is colliding with 90deg wall while moving. the FPS before doesnt matter, this is a basic scene from my game, so when i will add more scripts, monsters etc. it will drop below 100 fps probably so currently the FPS before the problem doesnt matter. what matters is the heavy cost of uneeded calculations in the character controller.
well it is good to clarify that what you initially referred to as “a 90 degree slope” is what we both think of as a “wall” and it is not that you set the character controller’s slope limit to 90 degrees.
The way you are reacting to the processing time of the character controller makes it seem like you may think that if this simple test causes the profiler frame rate to go from 4000 to 1000 then when you have a full game running and it is running at e.g. 60 fps, the character controller is going to make it run at 15fps. Well that is not the case.
In your profiler, the character controller move function is taking a total of about 4.6 milliseconds. That is about 4/1000 of a second. As I wrote earlier, it is not doing “needless” processing - while you are pressing the keys it is calculating collisions as well as calculating a solution for how to steer out of the collision while still colliding, and doing it in a smooth way. If you wrote your own code to do that, as MarkusDavey suggested, I suspect the process time might be a little higher than 4.6ms.
Watching the profiler with nothing going on and then with the character controller is not a good way to assess how optimized it is for what it actually does. You could do the same thing with nothing going in your game and then start doing a physics.raycast loop in your update and go “what the heck why is that taking so much time?”
I also noticed in all three screen shots the profiler shows the Awake function taking 75% of the process time. I do not know why the Awake function is still showing up after run time, or what you might have performed in it, but consider that comparison with the 10% of the controller move time. My profiler usually shows the renderer at the top. I think in the case of your screenshots, the character controller is taking 10% of basically nothing going on.
Zipper made an observation about the status display, which shows the frame rate of the graphics update. There will be many other things that effect the frame rate if you continue developing your game and keep your own code optimized by watching the profiler and not fretting over the character controller. The exception to this is if you plan to have LOTS of characters controlled with character controllers and as I wrote in an earlier reply, that might be something to avoid if you want optimal performance, but for the player character it takes care of a LOT of features for you and does it quite optimally considering what it does.
The real problem is preoptimization. Your trying to optimize a problem that doesn’t exist yet. That’s a waste of time…
You don’t know if it will be a problem or not. You are just speculating at this point.
Drop in 10 more, or however many more you are going to actually use at one time in your game. (A stress test.) If the frame rate is above 60, then don’t sweat it. If the frame rate is too low, THEN optimize.
Your just dealing with ‘how you think it should be’ compared to ‘how it is’. You can’t win thinking like that.
