Тёмная тема
Судя по всему предлагают купить компанию с движком и всеми работниками) А то у них трудности щас)
1vanK
> Я правильно понял, что подкрутить то и не дают, а только почитать?
Всякие Эскейп фром Краков вроде подкручивают сам Юнити.
Но это все по индивидуальной договоренности, без ценника.
Eugene
> Всякие Эскейп фром Краков вроде подкручивают сам Юнити.
> Но это все по индивидуальной договоренности, без ценника.
Один хрен тормозит))
Похоже мой изначальный вопрос по rbfx затерялся)
Затрудняюсь в выборе рендера, в приоритете PBR, но с графикой у меня мало опыта.
Интересует на сколько готов рендер в rbfx для работы?
Какие отличия в производительности рендеров urho3d и rbfx?
Специфика работы с графическими активами, на сколько больше трудозатраты на создание ассета для PBR пайплайна?
Задача отрисовка больших локаций, для шутера.
Zarj
В рендере rbfx багов давно небыло, значит стабилен. Была пара wtf моментов из за Alphamask например, но в целом ок.
Другой вопрос что тебе нужно. Если нужен, например, terrain, то это беда что там что тут.
Для FPS нужно рисовать оружие в руках так, чтоб оно не проваливалось в геометрию уровня. Из коробки этого нет ни там ни там.
Ну и т.п. Надо много писать самостоятельно, как уже говорили.
Субъективно - рендер rbfx может быть медленнее (надо как нибудь замерить пока совместимость ещё есть) но с ним удобнее работать (один язык шейдеров, какие то эффекты есть из коробки). Можешь просто взять sample-project, подсунуть нужную тебе сцену и замерить что будет. В sample-project уже есть управление и контроллер персонажа, так что сможешь сразу оценить подходит тебе или нет.
Zarj
> Интересует на сколько готов рендер в rbfx для работы?
Ну, ты можешь пользоваться рендером rbfx, и он не упадет, и нарисует тебе адекватную картинку, одинаковую на всех платформах. Некоторые вещи еще не закончены, но больших ломающих изменений не предвидится.
> Специфика работы с графическими активами, на сколько больше трудозатраты на создание ассета для PBR пайплайна?
PBR в Урхе значительно сырее, чем в rbfx. В rbfx полноценно поддерживается стандарт PBR материалов в metallic workflow, в Урхе PBR на уровне кое-как работающего прототипа, без полноценной интеграции с движком.
Если быть совсем честным, то PBR в Урхе можно настроить так, чтобы он выглядел приемлемо — я видел одного человека, которому это удалось. Для этого просто нужно намного больше ручной работы, усилий и времени.
И да, единственный способ грузить PBR ассеты в Урху — плагин для конвертации ассетов юнити в урху от Глеба. Сейчас Урха этим плагином больше не поддерживается (заархивирована), так что поддержка этого плагина будет тоже на тебе.
Я могу с чистой совестью посоветовать Урху кому-то, кому достаточно unlit и Lambertian материалов. Я не могу посоветовать Урху кому-то, кто хочет PBR.
> Какие отличия в производительности рендеров urho3d и rbfx?
rbfx медленнее. Насколько — сложно сказать, потому что нет нормального сравнения на реалистичной игровой сцене. Сравнения на искусственных сценах не очень полезны.
Например, Huge Object Count пример медленнее примерно в два раза на дефолтных настройках (в режиме индивидуальных StaticModel). Но это — синтетический пример того, как не надо делать игровые сцены. Какой-нибудь чистый OpenGL будет на такой сцене наверное раз в десять быстрее, чем Урха)
Как пример могу сказать что я переносил лес из unity в urho3d. Просто как есть модели деревьев объектами, без травы. Редактор urho3d просто помирал от такого количества объектов, редактор rbfx как то ворочался. Я не знаю это из за action script против c++ или из за чего. В любом случае стоит продумать как разбивать открытое пространство чтобы редактировать можно было и в целом менеджить. Я думал для одного из своих проектов сделать менежмент кусков карты с генерацией лодов на горизонте через symplygon, но мне тогда не хватало префабов.
GLoom
> Я не знаю это из за action script против c++ или из за чего.
А, это смешно, на самом деле, я с этим разбирался.
UI редактора в rbfx — immediate mode, объекты в глубине иерархии сцены ничего в UI не жрут, пока не открыты.
UI редактора Урхи — stateful, и имеет квадратичную сложность инициализации, пропорционально общему количеству объектов в сцене.
Поэтому когда у тебя в сцене за 10-20к объектов, редактор Урхи, грустно свистнув, превращается в тыкву. Может там конечно другие факторы тоже есть, но это то что я нашел. Хотя может я это пофиксил в Урхе, и у тебя другое?.. Я не помню, давно было.
GLoom
> Для FPS нужно рисовать оружие в руках так, чтоб оно не проваливалось в
> геометрию уровня. Из коробки этого нет ни там ни там.
Из коробки нет, потому что вещь специфичная, но есть не из коробки
1vanK
Там даже ссылки нет на GitHub. Как это поможет Zarj?
Там в видео измененный шейдер LitSOlid, я выделил строчки которые добавлены
Вот тему нашел кстати https://urho3d-forum-archive.github.io/t/depthhack-for-weapon-rendering/2202/
ёж
> Тема-темой, но ты код давай выкладывай с решением.
Ну в теме код шейдера выложен
ёж
> Посему, в Редакторе Сцены должны задействоватся все возможные оптимизации.
> Фрустум, лоды, окклудеры и прочее (как и в самой игре)
Ты не поверишь, они задействованны.
Я помню в редакторе открывал тяжелую сцену, были лаги, причем не просадка фпс, а какие-то периодические фризы. Оказалось, что просто шейдеры opengl компилировались, когда объекты в поле зрения камеры первый раз попадали