Urho3D - Вопросы-ответы (комментарии) (2 стр)

1vanK
> Я может и рад был бы подкрутить Юнити, вот только Урхо я могу подкрутить, а
> Юнити - нет)
Занеся тонну деняк разрабам, даже Юнити подкрутить можно)

1vanK
> а вот исходников юнити я не встречал.
Они тоже утекали. У меня исходников Юнити нет, и я не читаю их в образовательных целях.

ёж
> я к тому что получив анимацию в коде
> можно делать с ней что угодно
А я к тому, что этот баг существует на уровне AnimatedModel и AnimationController.
Ты то можешь делать что хочешь, но если хочешь пофиксить этот баг, не меняя движка, компоненты анимации тебе придется переписывать самому.

1vanK
> Я правильно понял, что подкрутить то и не дают, а только почитать?
Всякие Эскейп фром Краков вроде подкручивают сам Юнити.
Но это все по индивидуальной договоренности, без ценника.

Похоже мой изначальный вопрос по rbfx затерялся)

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
> Получается, что единственный значимый фактор - по названию выбирать. Вот рбфкс
> - хрен выговоришь даже ))
Ничо, пубджи выжили — значит и мы сможем.