Рендреринг кадров происходит быстрее, чем частота обновления на мониторе. Но видеокарта сообщает, что кадр отрисовался не сразу, а только после выполнения внутренних процедур.
Со стороны кажется, что рендер не поспевает и происходит адаптация под проседания fps.
Если модель имеет внутренний таймер не кратный 10 тикам то будут рывки. Например модель считается быстрее каждые 9 тиков, то каждый 9 кадр будет в два раза быстрее.
Поэтому важно синхронизировать два таймера. Но корректных данных о тиках внешнего таймера нет.
Нет. Будет как в статье. Физика есть на любой момент данных, кадры выдаются на экран равномерно. Но картинка на них дергается, так как значение физики будет браться на неправильный момент.
Но ведь как раз в определени времена одного кадра и появляется ошибка. Авторы статьи пытаются сделать шаг симуляции рваный времени 1 кадр, но если видеокарта иногда неправильно отдаёт время, то как определять шаг симуляции?
Две сотни FPS это обсчёт физики каждые 5 мс. В таком случае видеокарта считающая кадры по 16 мс
0 16 32 48 64 80
Получит следующие значения физики
0 15 30 45 60 80
Кадры выводятся равномерно, но вот разница по физике у них
15 15 15 15 20
Каждый пятый кадр будет на треть быстрее. Получим неравномерный видеоряд.
К тому же такие значения можно получить только на мощных компах на которых и так можно поставить фиксированный 60 FPS.
Учитывая уже упоминаемое gpu-bound, никто не мешает выполнять симуляцию значительно чаще
Мешает ограниченность CPU. Даже сейчас игры встречаются игры упирающиеся в CPU и не выдающие стабильные 60 fps именно из-за ограничений в процессоре. Для отсутствия же артефактов надо считать в разы больше.
Решение с плавующим таймером позволяет в разы снизить требования к cpu пользователя.
Чем же они отличаются? В статье показано несколько кадров которые выводиться с одинаковой частотой, но не правильными значениями физики. Ровно тоже самое будет в случае не совпадения тиков физики и графики
Был FPS 60 тик физики 16 мс и рендер 16мс. В какой то момент FPS скакнул вниз до 50. Если отследить и изменить тик физики до 20 то рендер и физика опять будут синхронны и дальше картинка будет плавной.
Нет. В этом случае всего один кадр запоздает на 4 мс, а для всех последующих физика и рендер будет синхронным до следующего скачка FPS. В случае с фиксированным таймером скачки кадров будут каждый 5 кадр.
Проблема в том, что этот отдельный таймер надо настраивать на тот же период, что и период забора кадров. Иначе как вы писали ниже будет постоянно повторяющаяся ситуация с неравномерностью видеоряда.
Если FPS меняется не сильно (например с 60 упало до 50) то скачек будет с 16 мс до 20 мс всего 4 мс. После одного фрейма cpu пересчитает длину тиков физики и все придёт в норму.
Видеокарта не запрашивает кадр. Это cpu говорит ей вот начало нового кадра, физика обсчитана на такое то время.
Чтобы знать на какое время считать следующий тик физики он спрашивает видеокарту сколько она рендерит кадр — драйвер отвечает 24 мс, но при этом успевает обсчитывать каждые 16 мс кадр.
В случае подкручивание физики кадры будут идти через равные промежутки тиков физики. При включённой g-sync/freesync каждые 20мс будет выдаваться плавный кадр без всяких дёрганий
На указанной машине машине все летает и быстро обсчитывается, поэтому при указании что время тика физики = 16 мс, все работает плавно.
Но разработчики также учитывают что машина пользователя может быть слабее и время рендринга может быть 20 мс. В таком случае надо поменять тик физики, иначе как вы выше написали будет неравномерно дрыгающая картинка. Для этого они спрашивают у видеокарты когда она закончила считать и вот тут возникают проблемы иногда видеокарта на этот вопрос отвечает полную чушь, несоответствующую действительности. А дальше начинаются визуальные лаги при том что все успевает обсчитаться.
Никто не будет считать физику 300 раз в секунду, это слишком нагружает CPU. Все считают физику по одному разу на каждый кадр без промежуточных состояний.
В случае расчётов по физики фиксированным тикам не совпадающим с частой забора будет слудующее. Допустим физику считают каждые 16 мс. А выводят каждые 17 мс.
Время физики 0 16 32 48 64… 224 240 256
Время графики 0 17 34 51… 238 255 272
Видно что чем больше времени пройдёт тем больше рассинхронизация и для синхронизации придётся в один кадр запихнуть два тика физики.
Главный вопрос что есть «текущее» состояние мира? Время прихода команды на начало рендринга кадра плавает от кадра к кадру. Например для первого кадра это было в 8 мс, для второго в 2 мс, а для третьего в 12 мс. Видеокарта успевает обсчитывать все и выдать кадр стабильно каждые 16 мс, даже если команда на начало немного запоздало, но при таком подходе картинка получается дёрганной.
Если FPS просел с 60 кадров на 59 то при адаптивном шаге под время рендринга кадра картинка останется практически плавной, а вот если оставить время тика физики постоянным то постепенно накопиться разница по времени между кадром и физикой, что приведёт к дерганности картинки.
Так в этом и проблема, что видеокарта говорит рендеринг кадра занял 24 мс, давай физику на следующие 24 мс. А на самом деле рендеринг кадра занял меньше 16 мс. Сейчас нет физической возможности правильно узнать время на которое надо посчитать физику для отображения.
Со стороны кажется, что рендер не поспевает и происходит адаптация под проседания fps.
Поэтому важно синхронизировать два таймера. Но корректных данных о тиках внешнего таймера нет.
На мощных компах метод с подкручиванием тормозит только потому что комп прикидывается, что не успевает рендерить.
0 16 32 48 64 80
Получит следующие значения физики
0 15 30 45 60 80
Кадры выводятся равномерно, но вот разница по физике у них
15 15 15 15 20
Каждый пятый кадр будет на треть быстрее. Получим неравномерный видеоряд.
К тому же такие значения можно получить только на мощных компах на которых и так можно поставить фиксированный 60 FPS.
Мешает ограниченность CPU. Даже сейчас игры встречаются игры упирающиеся в CPU и не выдающие стабильные 60 fps именно из-за ограничений в процессоре. Для отсутствия же артефактов надо считать в разы больше.
Решение с плавующим таймером позволяет в разы снизить требования к cpu пользователя.
Да и fps прыгает только при значительной смене объектов рендера, например при смене локации в рамках же одной сцены он более-менее постоянен
Чтобы знать на какое время считать следующий тик физики он спрашивает видеокарту сколько она рендерит кадр — драйвер отвечает 24 мс, но при этом успевает обсчитывать каждые 16 мс кадр.
Но разработчики также учитывают что машина пользователя может быть слабее и время рендринга может быть 20 мс. В таком случае надо поменять тик физики, иначе как вы выше написали будет неравномерно дрыгающая картинка. Для этого они спрашивают у видеокарты когда она закончила считать и вот тут возникают проблемы иногда видеокарта на этот вопрос отвечает полную чушь, несоответствующую действительности. А дальше начинаются визуальные лаги при том что все успевает обсчитаться.
В случае расчётов по физики фиксированным тикам не совпадающим с частой забора будет слудующее. Допустим физику считают каждые 16 мс. А выводят каждые 17 мс.
Время физики 0 16 32 48 64… 224 240 256
Время графики 0 17 34 51… 238 255 272
Видно что чем больше времени пройдёт тем больше рассинхронизация и для синхронизации придётся в один кадр запихнуть два тика физики.
Главный вопрос что есть «текущее» состояние мира? Время прихода команды на начало рендринга кадра плавает от кадра к кадру. Например для первого кадра это было в 8 мс, для второго в 2 мс, а для третьего в 12 мс. Видеокарта успевает обсчитывать все и выдать кадр стабильно каждые 16 мс, даже если команда на начало немного запоздало, но при таком подходе картинка получается дёрганной.
Так в этом и проблема, что видеокарта говорит рендеринг кадра занял 24 мс, давай физику на следующие 24 мс. А на самом деле рендеринг кадра занял меньше 16 мс. Сейчас нет физической возможности правильно узнать время на которое надо посчитать физику для отображения.