Войти
ПрограммированиеФорумОбщее

Скелетная анимация, эффективный рендеринг

Страницы: 1 2 Следующая »
#0
(Правка: 4 окт. 2021, 2:40) 17:13, 3 окт. 2021

Привет.

1. Есть набор моделек, хотим их максимально эффективно отрендерить. Ок, заполняем буфер с инстанс-данными для всех инстансов, отправляем на GPU, там происходит куллинг и подготовка indirect-буфера, рендерим все кучей за один draw call.

2. Теперь добавляем скелетную анимацию. Ок, рассчитываем трансформы всех костей для всех кадров анимации, заливаем в буфер, общий для всех, дальше все как в п.1, но дополнительно в инстанс-данные добавляется текущее время анимации для инстанса и еще интерполируем трансформы между кадрами при рендеринге.

3. Теперь добавляем возможность рулить костями произвольно (например ragdoll). И вот тут сталкиваемся с тем, что для каждого инстанса будет уникальный набор трансформов костей. Вся эта стройная схема с indirect и GPU-куллингом уже не подходит. Приходится каждый кадр складывать трансформы костей каждого инстанса в буфер и отправлять его на GPU. Куллинг, соответственно, только на CPU, что печально.
А раз так, то и в случае со скелеткой нет смысла считать/хранить все кадры, а просто на CPU посчитать трансформы костей текущего кадра анимации и залить их все так же в буфер.

Сейчас сделано как в п.3 для общего случая - и ragdoll и анимации имеют общий code path с обновлением буферов на каждый кадр.
Как нынче модно делать такие штуки? Не Vulkan, если что - старый добрый GL.


#1
11:26, 11 янв. 2022

Ну класть в буфер трансформы костей для каждого инстанса на каждый кадр, как это отменяет gpu culling и indirect? Что бы не обновлять трансформы костей невидимых инстансов, их можно откулить по фрустуму на цпу, их же не так много

#2
(Правка: 13:32) 13:27, 11 янв. 2022

San
> 2. Теперь добавляем скелетную анимацию. Ок, рассчитываем трансформы всех костей
> для всех кадров анимации, заливаем в буфер, общий для всех, дальше все как в
> п.1, но дополнительно в инстанс-данные добавляется текущее время анимации для
> инстанса и еще интерполируем трансформы между кадрами при рендеринге.
"все кадры анимации" типично могут занимать сотни гигабайт на риг, а для случаев физики и инверсной кинематики они вообще заранее неизвестны. поэтому трансформы костей типично интерполируют на CPU, там же, где стейтмашина анимаций и миксер анимаций сидят, а уже готовые массив готовых трансформов костей для каждого инстанса отправляется на GPU каждый кадр.

> Куллинг, соответственно, только на CPU, что печально.
сколько у тебя объектов? сотню баундинг боксов откаллить — это вообще нисколько. причём CPU в любом случае должен иметь информацию о куллинге, чтобы, например, не обновлять невидимые объекты (для которых это допустимо).

если прямо приспичило culling именно на gpu делать, то можно информацию о видимых объектах считать на GPU и отправлять обратно на CPU на _следующем кадре_. то есть видимость объектов будет отставать на один кадр, но обычно на это пофиг.

#3
13:35, 11 янв. 2022

San
> Как нынче модно делать такие штуки? Не Vulkan, если что - старый добрый GL.

то есть сейчас у тебя есть простой вариант?

#4
15:41, 11 янв. 2022

Ох, я уже и забыл про эту тему. И проект уже не открывал несколько месяцев )


innuendo
> то есть сейчас у тебя есть простой вариант?
Ага, то, что в п.3 описано. Работает, проблем никаких. Просто было интересно узнать про альтернативные современные подходы к этому вопросу, а то я, скорее всего, отстал от жизни.

CatsCanFly
> как это отменяет gpu culling и indirect?
Получается так, что нужно всегда иметь данные для всех инстансов, что не особо эффективно.

Suslik
> для случаев физики и инверсной кинематики они вообще заранее неизвестны
Именно так, поэтому и сделал по-старинке.
Так-то проблем нет, тему запилил для общего развития - разузнать как сейчас с этим дела обстоят.

> информацию о видимых объектах считать на GPU и отправлять обратно на CPU на _следующем кадре_
Тоже про это думал, да.

#5
(Правка: 21:53) 21:52, 11 янв. 2022

San
> 2. Теперь добавляем скелетную анимацию. Ок, рассчитываем трансформы всех костей
> для всех кадров анимации, заливаем в буфер, общий для всех, дальше все как в
> п.1, но дополнительно в инстанс-данные добавляется текущее время анимации для
> инстанса и еще интерполируем трансформы между кадрами при рендеринге.
Чтобы анимация была корректной - нельзя сразу считать абсолютный трансформ, и интерполировать кадры с абсолютным траснформом. Нужно интерполировать 2 кейфрейма с локальным трансформом, получать текущий трансформ с локальными трансформациями, и только после этого считать абсолютный трансформ для каждой кости.

#6
22:21, 11 янв. 2022

San
> Ок, заполняем буфер с инстанс-данными для всех инстансов, отправляем на GPU
Вообще есть соменения в надобности GPU Culling, если анимация на CPU считается. Считай иерархию костей и все оcтальное на GPU тогда может GPU Culling будет давать прирост, особенно для сотен объектов.

#7
(Правка: 23:03) 23:02, 11 янв. 2022

Andrey
Дык он так и делает для запеченной анимации. (см. пункт 2). А что делать с регдолами? Их не запечешь, приходится гонять с ЦПУ.

#8
23:16, 11 янв. 2022

А разве не отдают всё на откуп PhysX и прочим? Еще же инверсная кинематика есть, коллизии ударов всякие и прочее.

#9
2:47, 13 янв. 2022

HolyDel
> Дык он так и делает для запеченной анимации. (см. пункт 2)
что-то не увидел этого. заливает он каждый кадр. а хотелось бы ничего не лить, а считать все на GPU и кулить там. Но не так это просто.

#10
10:35, 13 янв. 2022

San
> Ага, то, что в п.3 описано. Работает, проблем никаких. Просто было интересно
> узнать про альтернативные современные подходы к этому вопросу, а то я, скорее
> всего, отстал от жизни.

можно добавить transform feedback для теней

#11
13:34, 13 янв. 2022

innuendo
Делал через TF запекание заскинненого меша. Получилось медленнее, чем при наивном подходе + память жрется.
Проще всего (и быстрее), как ни странно, делать все манипуляции с костями на цпу.

#12
14:06, 13 янв. 2022

San
> Получилось медленнее, чем при наивном подходе + память жрется.
т.е. чтение текстур проседает?

#13
14:35, 13 янв. 2022

Andrey
Насколько я помню, возникал stall при обращении к обновленному VB (в который рендерился меш).
Ко всему прочему обращение к VB было не через кадр. Ну и на каждый инстанс приходилось выделять отдельный VB.
Больше инстансов - больше тормозов, увы.

#14
15:19, 13 янв. 2022

San
> Делал через TF запекание заскинненого меша. Получилось медленнее, чем при
> наивном подходе + память жрется.

покажи как ты делал

Страницы: 1 2 Следующая »
ПрограммированиеФорумОбщее