Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 12 Next capture
2021 2022 2023
1 capture
12 Jun 22 - 12 Jun 22
sparklines
Close Help
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
2
Question by Ehren · Feb 19, 2010 at 10:04 PM · physicsfixedupdatetimestep

Making FixedUpdate fixed-timestep-independent

In the online Unity documentation, it's recommended that you multiply by Time.deltaTime in order to make your game's logic framerate-independent. However, the FixedUpdate documentation contains examples such as the following:

function FixedUpdate(){
    rigidbody.AddForce(Vector3.up);
}

This is typically okay since the rate at which FixedUpdate is called is constant. However, it becomes a problem if, after writing all your logic, you suddenly want to change the Fixed Timestep. In the above example, this would change the amount of time the specified force was being applied to the rigidbody (unless I'm misunderstanding how AddForce works).

Is it considered better practice to do something like the following (assuming the above code was written with a Fixed Timestep of 0.02)? Or is changing the Fixed Timestep considered a rare enough occurrence that logic like this is (normally) unnecessary?

var expectedTimestep = 0.02;

function FixedUpdate(){ rigidbody.AddForce(Vector3.up * (expectedTimestep / Time.deltaTime)); }

Comment
Add comment
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

3 Replies

· Add your reply
  • Sort: 
avatar image
4
Best Answer

Answer by jonas-echterhoff · Feb 20, 2010 at 08:58 AM

The physics engine takes the elapsed time into account, so in most cases, it should not matter to you. Typically, forces are applied continuously (such as the engine of a car) - the same force is being applied over a long time.

The only case where it does make a difference is when you want to apply a force in a single frame, as an impulse - for example to manually apply the result of a collision. Then you should indeed take the time into account for consistent behavior at different fixed time step intervals.

Comment
Add comment · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
0

Answer by Aubrey Hesselgren · Sep 20, 2010 at 02:27 PM

Also, use Time.fixedDeltaTime for the time step between consecutive FixedUpdate calls. That is the way to access your current fixed timestep setting in the manager.

Or have I misinterpreted the problem? Something to do with issues of synchronization between update and fixedupdate?

Comment
Add comment · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image
0

Answer by angularsen · Apr 02, 2018 at 03:13 PM

Detailed answer here: http://answers.unity.com/answers/1488426/view.html


TL;DR You do NOT need to multiply by deltaTime to get timestep independent physics.

Comment
Add comment · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this Question

Answers Answers and Comments

1 Person is following this question.

avatar image

Related Questions

"Fast" fixed timestep 1 Answer

How to make code in FixedUpdate() independent from fixed timestep? 1 Answer

Raycast drags behind the transform that generates it 1 Answer

Interpolating positions between FixedUpdate frames? 1 Answer

Physics behaviour changing with framerate - Is FixedUpdate() actually working properly? 3 Answers


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges