1vanK
> Я может и рад был бы подкрутить Юнити, вот только Урхо я могу подкрутить, а
> Юнити - нет)
Занеся тонну деняк разрабам, даже Юнити подкрутить можно)
1vanK
> а вот исходников юнити я не встречал.
Они тоже утекали. У меня исходников Юнити нет, и я не читаю их в образовательных целях.
ёж
> я к тому что получив анимацию в коде
> можно делать с ней что угодно
А я к тому, что этот баг существует на уровне AnimatedModel и AnimationController.
Ты то можешь делать что хочешь, но если хочешь пофиксить этот баг, не меняя движка, компоненты анимации тебе придется переписывать самому.
1vanK
> Я правильно понял, что подкрутить то и не дают, а только почитать?
Всякие Эскейп фром Краков вроде подкручивают сам Юнити.
Но это все по индивидуальной договоренности, без ценника.
Похоже мой изначальный вопрос по 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к объектов, редактор Урхи, грустно свистнув, превращается в тыкву. Может там конечно другие факторы тоже есть, но это то что я нашел. Хотя может я это пофиксил в Урхе, и у тебя другое?.. Я не помню, давно было.
1vanK
Там даже ссылки нет на GitHub. Как это поможет Zarj?
ёж
> Посему, в Редакторе Сцены должны задействоватся все возможные оптимизации.
> Фрустум, лоды, окклудеры и прочее (как и в самой игре)
Ты не поверишь, они задействованны.
Исходя из перечисленного - реально нет универсального движка, всё надо подгонять под себя. Отсюда вывод, лучший движок - тот что легче переделывается )
ёж
> Еще есть объединение объектов на дистанции в один.
Я про это тоже уже написал выше.
ёж
> Движок хорош, когда заточен под потребности конкретного проекта (нет ничего
> лишнего)
> А вот механизмы оптимизации Сцены никогда лишними не бывают.
Бывают, можно делать игру и без сцены, это в первую очередь 2д игр касается ))
ёж
> Нет игровой логики и механик - это да, но это не тоже самое что
> универсальность.
Тут вообще не угодить, разные жанры, разные предпочтения разработчиков...
1vanK
> Получается, что единственный значимый фактор - по названию выбирать. Вот рбфкс
> - хрен выговоришь даже ))
Ничо, пубджи выжили — значит и мы сможем.
Но мне "rebel fork" больше нравится.