Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

To increase fixed timestep, or to not and fight the problems...

Discussion in 'Physics' started by HiddenMonk, Feb 22, 2015.

  1. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    There are some issues with having the fixed timestep at .02... (in regards to having a custom rigidbody character controller), but there is one that I am mainly concerned about, which is the delay.

    There is a delay from your input to when you actually see the rigidbody move, since it must wait for the next fixed update. (yes, I am getting input from update)

    This delay also causes the screen movement to not be smooth. You are basically playing at 50fps. Interpolation can fix it, but that increases the delay from input to movement even more.

    What I ended up doing is creating a custom rigidbody character controller that is similar to the built in character controller and tried to merge the physics with my own scripts. It works alright, but there are issues that I keep needing to figure out and fix. Currently I dont have the 2 mixing together to nicely and some sacrifices would need to be made.

    What it comes down to is... Do I want to keep fighting this, or just bump up the fixed timestep to .01 (doubling the amount of calculations) in order to stop fighting the system and just use it. This custom rigidbody has been a big time sink. I do not really plan on having to much physics going on, which is also why I dont really want to bump the timestep to .01 because it seems like a waste. Its like I just want my character to have the better physics, and other things like rockets or falling objects can have crappy physics, but this doesnt seem possible as far as I know.

    Surely others have had to make a decision like this, and I would like to ask to those experienced as to what they would decided to do. I would still have custom scripts for my character to better help correct the physics mistakes, but I would have to walk around less wires to get what I desire.

    Any help is appreciated, thank you!
     
  2. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Why not use .0167? Then physics will run at 60fps. Most monitors can't display faster than that.

    --Eric
     
    Nanako likes this.
  3. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    That might be fine for the visuals, but people may still be able to feel a delay in the input.

    Right now I have a "ghostRigidbody" that follows my transform and I basically blend the 2 together, However, this isn't really perfect. For example, if I do a dash with my transform, and do my own collision detection, my character would be stuck at an object until the next fixedupdate where my ghostrigidbody can catch up and then move the object in front of me out of my way.

    The next thought would be to move the object out of the way myself with moving its transform and etc etc, but then I would basically be creating a whole custom physics engine and wouldnt even need fixedupdate anymore. Id like to avoid that.
     
    Last edited: Feb 23, 2015
  4. Nanako

    Nanako

    Joined:
    Sep 24, 2014
    Posts:
    1,047
    move your camera in Update for a start, to smooth out the screen
     
  5. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    My camera was in lateUpdate. It is not smooth mainly because I am not lerping its transform or anything, just applying it to my characters transform, and if my character is just a rigidbody moving with addforce with forcemode.velocitychange (in order to try and get snappy movements), the movement is not smooth, making the camera movement not smooth. I would need to interpolate, which only further the delay between the input and visuals.

    I don't think I would be able to use the physics fully, and would have to either continue trying to make my hybrid type model work better, or just ditch the physics and do things myself, which I want to avoid.

    To give an example of an issue I am having atm with my hybrid mode;
    Currently I have a custom collision detect that runs during update, which after finding a collision, it does some calculations to find out where to slide (so that if I hit a wall I dont just get stuck, but actual moving along the wall depending on my angle).
    I also have a "ghostRigidbody" that acts as my Force for when hitting movable objects.
    The problem is, if I do a fast dash into a movable ball, my collision detect will cause me to slide around the sphere before my ghostRigidbody had time to update and actually push the sphere. So now the sphere hardly moved since my ghostRigidbody is told to follow my transform, which has moved around the sphere.

    Now to fix this, maybe what I could do is make each movable object have a tag "IsMovable" and when I collide with it, to get its mass and do my own calculations to decide how much I can move it before my ghostRigidbody takes over. However, this is just yet another wire I need to dangle around to get this hybrid to work.

    If anyone has any tips or past experience on something like this, do let us know =)
     
    Last edited: Feb 23, 2015
  6. MatthewW

    MatthewW

    Joined:
    Nov 30, 2006
    Posts:
    1,356
    What platform are you targeting? How complex is your physical environment?

    I run Aztez at 120HZ, but our physical world is pretty simple. That said, you can probably get away with increasing physics frequency in most PC/Console games as long as you're careful about how you're modeling everything...
     
  7. HiddenMonk

    HiddenMonk

    Joined:
    Dec 19, 2014
    Posts:
    987
    Targeting desktop platforms (windows, linux, mac)