В этом туториале посылается только один луч в сторону источника света. В предыдущем туториале тени можно блюрить
assiduous
> Я работал в Нижегородском офисе.
понятно, я думал про запад :)
assiduous
У вас есть интеграция с Qt? Возможно ли рендериться в qt-шное окно без побочных эффектов?
Есть ли сравнительные тесты по производительности между голым api (например Vulkan) и вашим движком, чтобы понять насколько большой оверхед?
0xc0de
> У вас есть интеграция с Qt? Возможно ли рендериться в qt-шное окно без побочных
> эффектов?
а когда побочные эффекты возникали?
0xc0de
> У вас есть интеграция с Qt? Возможно ли рендериться в qt-шное окно без побочных
> эффектов?
Для Qt примера нет, есть для GLFW. В целом, если библиотека предоставляет доступ к хэндлу окна, то все должно работать без проблем.
> Есть ли сравнительные тесты по производительности между голым api (например Vulkan) и вашим движком, чтобы понять насколько большой оверхед?
Очень сильно зависит от того, как использовать. При оптимальном использовании оверхед будет минимальный (10% или даже меньше).
0xc0de
> Есть ли сравнительные тесты по производительности между голым api (например
> Vulkan) и вашим движком, чтобы понять насколько большой оверхед?
Всякие наниты и люмены рисуют всю сцену за десяток вызовов апи, так какая разница какой оверхэд в обертке над апи? Главное как напишешь алгоритм, тем более из-за валидации в дебаге миллионы дроуколов будут жутко тормозить, а в релизе разрабатывать очень не просто.
Ребят, у вас написано что Godus написан на Вашем движке, а в википедии написано что использован Marmelade SDK. https://ru.wikipedia.org/wiki/Godus
Выглядит очень красиво, оценить пока нет возможности. Не вижу ни одного примера со скелетной анимацией и поиском пути. Правильно ли я понимаю, что у вас чисто графический движок?
Salamandr
> Ребят, у вас написано что Godus написан на Вашем движке, а в википедии написано
> что использован Marmelade SDK. https://ru.wikipedia.org/wiki/Godus
Они перешли на Diligent в этом году.
> Выглядит очень красиво, оценить пока нет возможности. Не вижу ни одного примера со скелетной анимацией и поиском пути. Правильно ли я понимаю, что у вас чисто графический движок?
Преимущественно, да. Скелетная анимация есть в загрзучике/рендерере GLTF
Рассматривали ваш движок в сравнении с Bgfx.
- Полезно больше качественных примеров, в Bgfx хоть они и простые, но шире по разнообразию.
- Непонятно есть ли многопоточность при базовом использовании. В Bgfx всё сразу мультипоточно, свой command buffer. Не нужно думать об этом совсем.
- Наличие C# враппера. PInvoke, не C++/CLR.
Это основные продающие критерии при сравнении.
betauser
> В Bgfx всё сразу мультипоточно, свой command buffer. Не нужно думать об этом совсем.
Я не очень хорошо знаю BGFX, но насколько я понимаю, там вообще ничего не мультипоточно. Во всяком случае, как АПИ с глобальными функциями типа OpenGL может быть многопоточным?
Если, конечно, не считать специальный поток, в котром команды на самом деле исполняются, за многопоточность.
assiduous
Пользователь движка наполняет данные кадра для рисования, вызывая методы API движка. Они сначала складываются в очередь (движковый командный буфер). Потом вызываем "Draw", кадр начинает рисоваться. Рисуется из фонового потока. Мы в это время уже другое делаем в основном.
Т.е. в основном потоке мы только отдаем данные. Это очень небольшая часть времени. Всё другое делается из фонового потока. Это основная фича Bgfx.
betauser
Многопоточность с точки зрения современных API (DirectX12, Vulkan, Metal) - это возможность распараллеливания записи команд по нескольким потокам. В BGFX такой возможности нет и не может быть в принципе. Diligent - это явный низкоуровенвый API, он не создает скрытых потоков, как не делают этого DirectX12 и Vulkan. Если пользователю надо выполнять команды в отдельном фоновом потоке - это просто сделать. По умолчанию этого нет.
Ну не скрытый, фоновый)
Про дополнительные потоки, когда их больше одного, это интересно. Мы как юзеры подготовили данные сцены, чтобы отдать движку. В чем полезность нескольких потоков? Может наглядные примеры
betauser
> подготовили данные сцены, чтобы отдать движку. В чем полезность нескольких
> потоков? Может наглядные примеры
В целом полезность нескольких потоков в том, что они могут быть одновременно выполнены на нескольких ядрах процессора, скоращая общее время. К примеру, запись команд для shadow map может выполняться одновременно с записью команд для генерациии g-буфера. Совеременные движки рассматривают фрейм не как линейную последовательность команд, а как граф, где многие участки могут быть записаны паралелльно.
У нас фрейм граф - как раз одна из следующих задач.
assiduous
Ага, понятно, спасибо, интересно.
Мы как пользователи движка собрали объекты для рендера, сделали группы для каждого каскада теней. Всё подготовили. Получается, что каждую каскаду можно генерировать полностью параллельно? Тогда буст очевиден. Или всё же есть нюансы?
Тема в архиве.