Я новичок в изучении компьютерной анимации (для игр). Пока что единственный метод, с которым я столкнулся, это рисование каждого кадра, каждого обновления кадра. Таким образом, в начале каждого кадра весь кадр стирается, а затем перерисовывается то, что нужно для этого кадра.

У меня вопрос, является ли этот метод единственным, который используется для создания анимации и игр. Кажется, это немного неэффективно. Я также не совсем понимаю, как этот метод будет работать для 3D- игр. Может ли кто-нибудь объяснить это более подробно?

Очень старые игры использовали технику, при которой перерисовывались только те части кадра, которые изменились в этом кадре. Что я могу вспомнить, игра «Маленькое большое приключение» использует эту технику (1994). Но вы можете видеть, что в игре большую часть времени установлена ​​статическая камера. только когда вы выходите из видимой области, сцена перерисовывается. Если вы играете в игру, вы также заметите небольшую задержку на этом кадре. На современных графических процессорах с современными игровыми движками все изменилось. Все перерисовывается на каждом кадре. В зависимости от техники рендеринга, вещи могут быть отрисованы несколько раз. Вычислительная мощность графического процессора просто невероятно высока, если вы используете его правильно. Но повторное использование происходит. Например, движок может решить обновить карту теней только каждый 5-й кадр. Или освещение не обновляется, если нет изменений в источниках света.

Нет.

По крайней мере, если вы включите старые игры 70-х годов, которые использовали векторные изображения.

Например, широко известная игра Asteroids, которая изначально была разработана для векторных дисплеев, которые представляют собой принципиально иной способ рендеринга графики на экран.

Векторные мониторы также использовались в некоторых аркадных играх конца 1970-х - середины 1980-х годов, таких как Asteroids, Tempest и Star Wars. Atarius использовал термин Quadrascan для описания технологии, используемой в игровых автоматах.

https://en.wikipedia.org/wiki/Vector_monitor

Современная графика на 100% сделана для растеризации, которая по определению записывает содержимое графического буфера на дисплей каждый кадр.

На самом низком уровне графический процессор на вашей машине действительно вычислит каждый кадр с нуля и отправит его на ваш экран. Однако вы будете подвержены этому только в том случае, если вы сами управляете этими низкоуровневыми вещами [1]. Однако любой графический (и с этим, игровой) движок будет обрабатывать эти вещи за вас, и вы можете свободно выражать сцену. с точки зрения многих объектов, которые вы могли бы изменить между кадрами, но будет постоянным.

... как этот метод будет работать для 3D-игр ...

Элементы в трехмерном пространстве являются постоянными, графический движок, опять же, пересчитает изображение на экране для любых изменений, которые произошли (движение камеры и т. Д.)

[1] ... например, если вы пишете свой собственный движок [2] с чем-то вроде OpenGL. Даже в этом случае вы, вероятно, будете хранить постоянные вещи между кадрами.

[2] Что не подходит для вашего текущего уровня квалификации.

Краткий ответ: Нет.

Длинная история:

Когда я изучал программирование игр в школе, нас учили делать следующее:

Решите, какую частоту кадров нам нужно в игре (например, 30).

Напишите некоторый код, который добавляет 1 к счетчику для каждого интервала (33 мсек для 30 кадров в секунду). Этот код работает одновременно с игровым циклом.

Тогда игровой цикл, который выполняет вычисления для игры (обновление состояния игры), уменьшит один и тот же счетчик на 1 для каждого кадра. Но графические расчеты и рисование на экране будут выполняться только в том случае, если счетчик равен нулю.

В результате графическая частота кадров будет меняться в зависимости от того, насколько хорошо процессор обрабатывает вычисления в игре. Когда в игре происходит не так уж много, вычисления просты, и частота кадров графики будет выше, чем фактическое обновление игрового состояния (в основном это бесполезная трата времени, поскольку мы выводим одно и то же игровое состояние более одного раза на экране).

Но затем многое происходит в игре, процессору предстоит проделать больше работы, и обновления состояния игры будут иметь приоритет перед рисованием на экране.

Большую часть времени игра будет продолжать обновляться с намеченной скоростью, но будет выглядеть «запаздывающей», поскольку вы не увидите каждое обновление на экране. Это может быть предпочтительным для замедления всей игры, потому что вы заставляете его рисовать каждое обновление на экране.

Все это было сделано с C ++ и без игрового движка, ни видеокарты. Все работало на одном ядре. Мы использовали несколько библиотек для 2D-графики.

Прежде чем можно сказать, «рисуют» ли видеоигры каждый кадр, сначала необходимо определить, что означает «рисовать». Конечно, существует множество видеоигр, которые не все рисуют каждый кадр, собирая растровое изображение с нуля; на самом деле, многие игровые платформы никогда не собирают полные растровые изображения вообще .

Существует несколько подходов видеоигр к генерации дисплея. В очень небольшом числе ЦПУ включает и выключает электронный луч или для каждого пикселя, или, для игр с векторным сканированием, задает координату XY каждой наносимой точки. Большинство игр, которые делают это, делают это в основном для того, чтобы продемонстрировать, что процессор достаточно быстрый. Чаще всего в играх используется аппаратное обеспечение, которое при отсутствии нагрузки на ЦП неоднократно выводило бы на дисплей некоторую комбинацию пикселей или векторов. Этот шаблон может быть получен путем последовательного считывания данных из области памяти и интерпретации каждого бита или группы битов как цвет пикселя (это называется отображением битовой карты). В некоторых случаях оборудование может считывать байт памяти для каждого 8x8, 16x16, или область другого размера дисплея, а затем используйте этот байт для выбора диапазона памяти для считывания данных пикселей (это часто называют отображением карты символов). Некоторые аппаратные платформы могут накладывать несколько растровых дисплеев на настраиваемые позиции. Они называются спрайтами.

Некоторые платформы не позволяют изменять шаблон отображения во время его отправки на экран, но вместо этого требуют, чтобы все обновления происходили после того, как луч закончил рисовать один кадр, но до того, как он начал рисовать следующий. На таких платформах все, что должно появиться в кадре, должно быть загружено в аппаратное обеспечение дисплея до начала этого кадра, и на дисплее будет отображаться шаблон, который можно настроить одновременно. Если бы процессор остановился во время показа кадра, этот же кадр продолжал бы отображаться бесконечно. Другие платформы позволяют изменять или реконфигурировать шаблон во время его отрисовки на экране. Это позволяет показать экран, который намного сложнее, чем видеосхема могла бы справиться сама по себе.

Большинство игр для персональных компьютеров используют аппаратное обеспечение, настроенное для рисования одного растрового экрана, а затем для рисования на этом экране всего, что должно отличаться от того, что уже есть. Иногда может быть проще рисовать вещи, не обращая внимания на то, действительно ли это необходимо в конкретном случае, но если код может легко определить, что нет причин для изменения части экрана, производительность можно улучшить, пропустив эту часть. Современные платформы часто бывают достаточно быстрыми, чтобы они могли рисовать весь экран много раз в течение кадра, но исторически это было не так. Например, самый быстрый код для записи всех пикселей на экране высокого разрешения компьютера Apple II займет более двух кадров, а самый быстрый код для копирования всех пикселей на компьютере Apple II ». Экран с высоким разрешением из другого буфера займет в два раза больше. Чтобы добиться хорошей производительности, игры должны обновлять только те вещи, которые действительно менялись, и это то, что обычно делали хорошие игры.

Короче говоря, я бы сказал, что нарисованы не все рамки, а только те, которые необходимы для представления вашей истории или темы игры или игрового процесса. Плюс время, которое вы хотели бы совершить в определенных случаях, имело бы значение.