What's the difference between Update and FixedUpdate? When are they called?

 

- 구글번역

 

http://answers.unity3d.com/questions/10993/whats-the-difference-between-update-and-fixedupdat.html

 

As far as I understand it, the two different update functions work something like this. I'm writing it in the form of pseudocode first, and adding diagrams below, which may or may not make it clearer to understand!

In the (completely fictitious) code below, first the appropriate number of physics steps are executed in order to "catch up" with the current time (and each step, FixedUpdate() is called on each object which implements it). Next, the graphics for the frame are rendered, followed by Update() on each object which implements it.

 

마찬가지로 지금까지 내가 이해, 두 가지 업데이트 기능을 이런 식으로 뭔가를 작동합니다. 내가 먼저 의사의 형태로 작성하고, 또는 이해하는 것이 명확하지 않을 수있는 아래의 다이어그램을 추가 해요!

아래의 (완전 가상의) 코드에서 물리학 단계 먼저 적절한 숫자는 현재 시간 (각 단계 FixedUpdate ()를 구현하는 각 객체에서 호출) "를 잡기"를 순서대로 실행됩니다. 다음 프레임의 그래픽을 구현하는 각 개체에 대해 업데이트 () 다음에 렌더링됩니다.

var physicsTimeSimulated = 0;
var lastUpdateTime = 0;    
 
while (Unity is Running)
{
    while (physicsTimeSimulated < Time.time)
    {
        Engine.ExecutePhysicsStep();
        Engine.FixedUpdate(); // <-- sent to all objects
        physicsTimeSimulated += physicsTimeStep;
    }
 
    deltaTime = Time.time - lastUpdateTime;
    Engine.RenderFrame();
    Engine.Update(); // <-- sent to all objects
    lastUpdateTime = CurrentTime;
 
    // and repeat...
}

It's worth noting that if the game is running at a slow frame rate, there will be numerous physics updates between each visible frame render. Conversely, if the game is running at a very high frame rate, there may be no physics steps at all between some of the frame renders, because the time elapsed since the last rendered frame has not yet exceeded the time period of a single physics step.

If the physics timescale is left at its default value (0.02) this gives us 50 physics updates per second - each physics step simulates the motion that occurs over the period of two-hundredths of a second.

The diagram below shows a period of one-tenth of a second. The dots which break up the line indicate 100th's of a second.

그것은 게임 속도가 느린 프레임 속도로 실행중인 경우, 표시되는 각 프레임 렌더링 사이에 수많은 물리학 업데이트가 될 것이라고 지적 가치가있다.게임은 매우 높은 프레임 속도로 실행중인 경우 최종 렌더링 된 프레임 이후 경과 한 시간이 아직 하나의 물리 단계의 기간을 초과하지 않았기 때문에, 반대로, 프레임의 일부 렌더링과 전혀 물리학 단계가 없을 수 있습니다 .

물리 척도가 디폴트 값 (0.02)에 남아있는 경우이 우리에게 초당 50의 물리 업데이 트를 제공합니다 - 각 물리학 단계는 두 번째의 2 백분의 기간 동안 발생하는 동작을 시뮬레이트합니다.

아래 그림은 10 분의 1 초의 시간을 보여줍니다.선을 분해 점 100의 초를 나타냅니다.

 

(I'm using an "F" to show where the FixedUpdate calls go)

0                                                0.1 seconds
|                                                 |
.____.____.____.____.____.____.____.____.____.____.___ 
F         F         F         F         F         F

Now, if our game were running nice and fast at 100fps, we'd have two frame renders for every physics step - and therefore two calls to our Update() functions, for every call to our FixedUpdate() functions. (Key: "F" for FixedUpdate and "U" for Update)

 

우리의 게임은 100FPS에서 좋은 빠른 실행한다면 지금, 우리는 두 개의 프레임은 모든 물리학 단계 렌더링 거라고 - 우리 업데이트하는 것이 두 번 호출 () 함수, 우리 FixedUpdate () 함수에 대한 모든 호출. (키 : FixedUpdate를위한 "F"및 업데이트를위한 "U")

 

0                                                0.1
|                                                 |
.____.____.____.____.____.____.____.____.____.____.___ 
F         F         F         F         F         F
 U    U    U    U    U    U    U    U    U    U    U

If our game is running slower, say - at 30 frames per second (and therefore 30 calls to all Update() functions per second), it would mean that we actually sometimes have more than one physics step between each frame render. In the case of 30 fps, the result would be that sometimes two physics steps are executed between frames, and sometimes one, which would look something like this, for the first 10th of a second:

 

우리 게임이 느리게 실행되는 경우, 말 - 초당 30 프레임 (따라서 모든 업데이트 () 초당 기능 30 호출)에, 우리가 실제로 가끔 각 프레임 렌더링 사이에 하나 이상의 물리 단계를 의미한다. 초당 30 프레임의 경우, 결과는 두 번째의 첫 10 들면, 다음과 같이 보일 것입니다, 이는 때때로 두 물리학 단계는 프레임 사이에 실행되고, 경우에 따라 하나되는 것 :

 

0                                                0.1
|                                                 |
.____.____.____.____.____.____.____.____.____.____.___ 
F         F         F         F         F         F
 U                U               U                U

So, in most normal circumstances, you'll always get the desired number of physics steps per frame, and interleaved with these will be the visual frame updates, at as fast a rate as possible.

It's for this reason that FixedUpdate should be used when applying forces, torques, or other physics-related functions - because you know it will be executed exactly in sync with the physics engine itself.

Whereas Update() can vary out of step with the physics engine, either faster or slower, depending on how much of a load the graphics are putting on the rendering engine at any given time, which - if used for physics - would give correspondingly variant physical effects!

The exception to this would be that if your scene was putting such a load on the physics engine that it approaches the point where it becomes impossible to execute the required number of physics time steps to keep up to speed with 'real time'. This means that your game has become impossible to simulate in real time - and in this case you need to seriously think about redesigning your game! This can happen if you have large numbers of complex objects (eg, rigidbody mesh colliders) all clumped together so you have lots of many-to-many collisions occuring each step.

Hope this sheds some light on the comings and goings of FixedUpdate and Update!

 

그래서, 대부분의 정상적인 상황에서, 당신은 항상 프레임 당 물리학 단계의 수를 얻을 것이다, 이러한 인터리브는 가능한 한 빨리 속도로에서 시각적 프레임 업데이트됩니다.

그것은 힘, 토크, 또는 다른 물리학 관련 기능을 적용 할 때 FixedUpdate를 사용하는 것을 이런 이유입니다 - 당신이 그것을 물리 엔진 자체 동기화 정확하게 실행됩니다 알고 있기 때문에.

업데이트 ()는 그래픽 주어진 시간에 렌더링 엔진에 넣어 얼마나 많은 부하에 따라 하나를 빠르게 또는 느리게, 물리 엔진 단계에서 달라질 수있는 반면, 어느 - 물리학 사용하는 경우 - 상응하는 변형을 줄 것이다 물리 효과!

이 예외는 장면이 물리 엔진에 같은 하중을 가하고 된 경우 그것은 '실시간'으로 속도를 유지하기 위해 물리 시간 단계의 수를 실행 불가능하게 포인트에 접근하는 것이 될 것입니다. 이 경우에 당신은 심각하게 당신의 게임을 재 설계에 대해 생각해야합니다 -이 게임은 실시간으로 시뮬레이션하는 것이 불가능하게되었음을 의미합니다! 당신은 모든 당신이 각 단계를 발생하는 다 대다 충돌을 많이 갖도록 뭉쳐 복잡한 많은 수의 개체 (예를 들어, rigidbody 메쉬 colliders)가있는 경우이 문제가 발생할 수 있습니다.

이 FixedUpdate 및 업데이트의 출입에 대한 몇 가지 빛을 비춰 희망!