Fixed update unity что это
Fixed update unity что это
Во многих туториалах говорят, что Фикс используется для физики, при этом встречал даже в официальных туториалах, что используют обычный Апдейт. Так в каких конкретно случаях надо использовать Фикс? Чем черевато, если вместо него использовать Апдейт? Можно ли использовать обе функции в одном скрипте?
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Откуда такая информация?
Re: Update и FixedUpdate
Откуда такая информация?
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Лучше не делать, но всё-таки будет работать? Просто не понятен эффект, чем это чревато?
Re: Update и FixedUpdate
Re: Update и FixedUpdate
Я так понял, что если очень низкий фпс и игра считай что в режиме недопаузы, FixedUpdate будет стабильно тикать по часам компьютера. И т.к. физика в юнити в каком-то смысле отделена от общей среды, то если посылать сигналы с Update(), они будут как управление марсоходом, который в данный момент катится с горы где-то на Марсе. Т.е. все ваши действия будут неадекватны по отношению к физике.
И наоборот, если вы логику кинете в FixedUpdate, это при ведёт к линейности вызовов при разной нагрузке на определённые фреймы, что вызовет скачкообразные микролаги.
Re: Update и FixedUpdate
Во многих туториалах говорят, что Фикс используется для физики, при этом встречал даже в официальных туториалах, что используют обычный Апдейт. Так в каких конкретно случаях надо использовать Фикс? Чем черевато, если вместо него использовать Апдейт? Можно ли использовать обе функции в одном скрипте?
У меня на fixedDeltaTime акселерометр никак не реагировал. Ставишь TimeScale = 0.5 например, или на 0, вся сцена неподвижна, а объект привязанный к акселерометру работает в полную силу.
А на обычном deltatime все ОК.
Так что смотрите внимательней с этим.
MonoBehaviour.FixedUpdate()
Success!
Thank you for helping us improve the quality of Unity Documentation. Although we cannot accept all submissions, we do read each suggested change from our users and will make updates where applicable.
Submission failed
For some reason your suggested change could not be submitted. Please try again in a few minutes. And thank you for taking the time to help us improve the quality of Unity Documentation.
Description
Frame-rate independent MonoBehaviour.FixedUpdate message for physics calculations.
MonoBehaviour.FixedUpdate has the frequency of the physics system; it is called every fixed frame-rate frame. Compute Physics system calculations after FixedUpdate. 0.02 seconds (50 calls per second) is the default time between calls. Use Time.fixedDeltaTime to access this value. Alter it by setting it to your preferred value within a script, or, navigate to Edit > Settings > Time > Fixed Timestep and set it there. The FixedUpdate frequency is more or less than Update. If the application runs at 25 frames per second (fps), Unity calls it approximately twice per frame, Alternatively, 100 fps causes approximately two rendering frames with one FixedUpdate. Control the required frame rate and Fixed Timestep rate from Time settings. Use Application.targetFrameRate to set the frame rate.
Use FixedUpdate when using Rigidbody. Set a force to a Rigidbody and it applies each fixed frame. FixedUpdate occurs at a measured time step that typically does not coincide with MonoBehaviour.Update.
In the following example, the number of Update calls is compared against the number of FixedUpdate calls. FixedUpdate executes 50 times per second. (The game code runs around 200 fps on a test machine.)
Is something described here not working as you expect it to? It might be a Known Issue. Please check with the Issue Tracker at issuetracker.unity3d.com.
Copyright ©2021 Unity Technologies. Publication Date: 2021-11-26.
Разница между методом обновления и FixedUpdate в Unity?
Я следую там руководству по разработке игр для Lynda Unity 2D, инструктор использует Update метод, у игрока есть компонент RigidBody2D и Box collider, он использует Update метод для перевода игрока, но когда я делаю то же Update самое, игрок не двигается, а когда я делаю это FixedUpdate все работает. Он дает уроки по Unity 4.3, а я беру курс по Unity 4.6.
Я собирался написать это как комментарий, но это оказалось довольно длинным, поэтому я превратил это в ответ.
Текущие ответы в основном правильные, но несколько упомянутых вещей вводят в заблуждение / неправильно.
Например, вы не хотите опрашивать входные данные FixedUpdate (не из-за производительности, а потому, что вызовы просто не будут работать правильно). ИИ падает в одну лодку.
(* Time.deltaTime и Time.fixedDeltaTime имеют одинаковое значение при вызове в FixedUpdate [Unity может определить, произошел ли текущий вызов и Time.deltaTime во время FixedUpdate возврата Time.fixedDeltaTime ))
Это не влияет на физику из-за характера остальной части порядка выполнения и движка, но почти все, что вы вставляете в FixedUpdate будет затронуто добавите, и это вызовет проблемы.
Например, если вы поместите обработку AI внутри FixedUpdate нет никаких оснований предполагать, что ИИ не будет пропускать обновления для нескольких кадров подряд. Кроме того, каждый раз, когда `FixedUpdate отстает, ваш ИИ будет обновляться несколько раз в одном кадре до того, как будут обрабатываться такие вещи, как физика и ввод / движение игрока, что, по крайней мере, является пустой тратой обработки, но также весьма вероятно, что вызовет сложный процесс. чтобы отследить ошибки и неустойчивое поведение.
И небольшая заметка о Time.deltaTime когда и как его использовать:
В общем, вы хотите, чтобы ваше движение было в секунду. Таким образом, независимо от скорости компьютера, ваша физика / движение будет вести себя одинаково, и у вас не будет странных ошибок, появляющихся на медленных устройствах.
В чём отличие FixedUpdate и Update? Когда они вызываются?
1 ответ 1
Быстрое описание: Update вызывается каждый кадр, а FixedUpdate с фиксированной частотой независимо от FPS. При этом частоту можно изменить в настройках Unity.
FixedUpdate вызывается с фиксированной частотой независимо от FPS. При этом частоту можно изменить в настройках Unity. Вызывается фиксировано независимо от того, как часто изображение обновляется. Обычно используют для выполнения задач, связанных с игровым процессом (например, обновление физики).
Я сначала напишу псевдокод и добавлю диаграммы ниже, которые, возможно, помогут понять что к чему.
В приведенном ниже (полностью вымышленном) коде сначала выполняется соответствующее количество физических шагов, чтобы «догнать» текущее время (и на каждом шаге вызывается FixedUpdate() для каждого объекта, который его реализует). Затем отрисовывается графика для кадра, за которым уже следует Update() для каждого объекта, который ее реализует.
Если игра работает с низкой частотой кадров, между каждым видимым рендером кадра будет множество обновлений физики. И наоборот, если игра работает с очень высокой частотой кадров, между рендерингом некоторых кадров может вообще не быть шагов физики, потому что время, прошедшее с момента последнего рендеринга кадра, еще не превысило период времени одного физического шага.
У Юнити можно настроить количество обновлений физики в секунду. По-умолчанию это «0,02», т.е. это примерно 50 обновлений физики в секунду (каждый шаг физики имитирует движение, которое происходит в течение двух сотых секунды).
Итак, для начала простая диаграмма, где показан период в одну десятую секунды. Точки, разделяющие линию, обозначают сотые доли секунды. А «F», чтобы показать, равные деления вызова метода FixedUpdate
Теперь, если бы наша игра работала хорошо и быстро со скоростью 100 кадров в секунду, у нас было бы два рендера кадра для каждого шага физики и, следовательно, два вызова наших функций Update для каждого вызова наших функций FixedUpdate
Если наша игра работает медленнее, скажем, со скоростью 30 кадров в секунду (и, следовательно, 30 вызовов всех функций Update в секунду), это будет означать, что на самом деле у нас иногда бывает более одного физического шага между рендерингом каждого кадра. В случае 30 кадров в секунду результатом будет то, что иногда между кадрами выполняются два физических шага, а иногда один, который будет выглядеть примерно так, в течение первых 10 долей секунды:
Таким образом, в большинстве обычных обстоятельств вы всегда будете получать желаемое и постоянное количество физических шагов в кадре, и вместе с ними будут чередоваться обновления визуального кадра с максимально возможной скоростью.
По этой причине FixedUpdate следует использовать когда используются силы (Force) к объекту, крутящих моментов или других функций, связанных с физикой, потому что вы знаете, что он будет выполняться точно синхронно с самим физическим движком.
В то время как Update может отличаться от физического движка, быстрее или медленнее, в зависимости от того, какую нагрузку графика накладывает на движок рендеринга на текущий момент времени (что при использовании данного метода для физики дало бы не постоянную и не корректную работу)
Исключением было бы то, что если бы ваша сцена оказывала такую нагрузку на физический движок, что она приближалась бы к точке, когда становится невозможным выполнить необходимое количество физических шагов по времени, чтобы идти в ногу с «реальным временем». Это означает, что вашу игру стало невозможно моделировать в реальном времени, и в этом случае вам нужно серьезно подумать о переработке вашей игры! Это может произойти, если у вас есть большое количество сложных объектов (например, коллайдеров сетки твердого тела), которые сгруппированы вместе, поэтому на каждом шаге возникает множество столкновений «многие ко многим».
Движение с коллизией через Update и FixedUpdate, что такое «телепортация» в контексте физического движка в Unity?
Что подразумевают, когда говорят «телепортация» в контексте передвижения физического объекта?
2 ответа 2
Как работает любой физический движок (в геймдеве)
Дискретизация
Как мы видим, версия с fps = 10 хоть и похожа на наш синус, но есть явные “промахи». Или, другими словами, чем меньше шаг дискретизации, тем более точный получается результат на выходе.
А что там все-таки с физикой?
Возьмем простейший пример:
Двигающийся объект и стена-коллайдер перед ним, пока что в настройках ничего не трогаем и пытаемся двигать наш объект кодом, который написан во всех туториалах по Unity:
А теперь попробуем все то же самое сделать через Update и Transform.Translate :
А если это препятствие убрать, что вполне легальная операция, ну мало ли у нас персонаж уперся в дверь, а она открылась. Правда нашему кубику резко поплохело:
С передвижением через FixedUpdate объект не дергается и не отлетает в рандомные стороны.
Почему так происходит?
3 раза меньше, поэтому и кажется, что объекты внутри и куб дергается.
Что делать с большими скоростями?
Цель: задать большую скорость объекту. Получается что-то такое:
Для таких ситуаций существует целый набор разных CCD (Continuous Collision Detection) алгоритмов:
Они разные и нужны для разных ситуаций, какие-то быстрые, какие-то медленные, тема интересная, но вопрос не об этом, так остановимся на самом “простом” Continuous режиме. После переключения наш объект остановится из-за преграды, вот в принципе и все, это просто работает. Логика там простая: вместо проверки на каждом вызове FixedUpdate физический движок до перемещения объекта под влиянием каких-то сил проверяет специальными алгоритмами (в этом и заключается их различие), не сталкивается ли объект с чем-то во время движения в этом кадре.
Почему нельзя перемещать физические объекты в Update?
Потому что логический и физический движки – это два разных потока. Unity самостоятельно ими управляет, но это не значит, что их нельзя сломать.
С точки зрения физического движка неподвижный элемент сменил свою позицию – это и есть телепортация. А поскольку физический движок ничего не знает о движении объект – просчитывать коллизии с помощью CCD он не будет.
А как же алгоритмы CCD?
Может показаться, что перенос Transform кода в FixedUpdate может как-то решить проблему, но нет, это будет все та же телепортация, только с другой частотой.
Горькая, но все же пилюля
Так почему же это решение не самое оптимальное?
Чаще считается физика – больше нагрузка на ЦП. Обычно такое решение не самое оптимальное, но “обычно” =/= “всегда”, так что и такое применяют.