R
В общем каждый SDF объект задается кодом своей SDF
Size: a a a
2020 December 29
R
на glsl например
R
Пофигу. На чем-то что можно вставить в шейдер который марширует
R
Для начала сойдет функция на glsl
R
Я ее вставляю в код (шаблон intersection shader-а) и компилирую шейдер
R
GPU трейсит лучик и находит потенциальное пересечение, потому что AABB объекта пересеклос с лучиком. Запускает его intersection shader, там идет маршировка и либо находится пересечение, либо нет.
Все, дальше разницы между SDF и полигонами нет
Все, дальше разницы между SDF и полигонами нет
IL
Ну мы тогда немного возвращаемся к вчерашней теме. Динамическая загрузка шейдеров, и в особенности таких объемных, которые строят модель человека, например, штука не быстрая. И она будет вам разрушать опять же всю конфигурацию пайплайна каждый раз.
R
Конечно. Вот только новые объекты в сцене появляются почти никогда
IL
Тогда будут исключительно статические сцены
R
И я могу заранее при загрузке уровня создать библиотеку из всех шейдеров, какие только могу пригодится на этом уровне
R
А если добавится еще что-то, ну ок, пересоздам библиотеку и пайплайн
IL
Вообще, объемный шейдер для конструирования сложной модели может занимать тысячи строк glsl кода, и он будет загружаться вместе со всем пайплайном секунды, если не десятки секунд.
R
При этом мне не надо останавливать рендеринг. Когда создастся новый пайплайн, тогда и подменю
R
Все равно шейдер на CPU паралельно компилироваться будет
IL
Но более существенный вопрос тут даже не в оптимизации, а, повторюсь, в том, как этот самый шейдер пользователь будет конструировать. Это практически не так просто
IL
Ну, у вас будут сцены без анимаций по сути. Без реал-тайм анимаций
R
Ну тут у меня есть пара идей
R
Почему же без анимации?
IL
Потому что шейдеры долго грузятся
R
Никто не запрещает в шейдере переменные иметь