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

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

Номер версии надо поправить, текущей. Ну и ссылки уже не рабочие, кроме тех что на Гитхаб ведут

Нужно перетащить кнопку за пределы окна, проблема в том что она перемещается только в пределах ее родительского окна.
Первое что приходит в голову это скрыть перетаскиваемый элемент и создать похожий, прикрепленный к курсору. Но такой метод больше похож на костыль.
Есть ли проще варианты?
Требуется для реализации инвентаря, перетаскивания, выбрасывания предметов.

Zarj
Какой UI, какой форк? Может просто перепривязывать элемент к uiroot?

стандартный UI, urho3d 1.7, попробую к uiroot.

вообще перемещать надо не сам предмет, а специально заготовленную иконку. А оригинальный предмет, прятать. И по окончании перемещения непосредственно делать перестановки в инвентаре. Или показывать старый.

Первое что приходит в голову это скрыть перетаскиваемый элемент и создать похожий, прикрепленный к курсору.
значит изначальный вариант будет лучше?

Еще вопрос, как лучше нарисовать 2д сетку в окне с иконками?
Рисовать непосредственно линии через граф. api
или затайлить текстуру.

Спасибо всем за ответы!
SetClipChildren(false) не дает никакого эффекта, видимо это особенность ScrollView.
На данный момент вариант Salamandr более подходящий.

Переношу свои старые наработки в урху, и паралельно учу его, с самим урховским UI знаком 3й день только, так что не совсем понял.
В общем я делаю так:

  SharedPtr<ScrollView> scrl = GetSubsystem<UI>()->GetRoot()->CreateChild<ScrollView>();
  SharedPtr<UIElement> cntnt(scrl->CreateChild<UIElement>());
  scrl->SetContentElement(cntnt);
  
  Button* item = new Button(context_);
  scrl->GetContentElement()->AddChild(item);

SetClipChildren(false) пробовал как для ScrollView так и для ContentElement

Как у тебя вообще этот код скомпилировался? )
Сильно не пинать) Писал в спешке, главное работает)

тухлая это идея все равно
И все же будет полезно. Жаль нет нормальной документации по UI, приходится лезть в код и экспериментировать. Благодарю

Затрудняюсь в выборе рендера, в приоритете PBR, но с графикой у меня мало опыта.

Интересует на сколько готов рендер в rbfx для работы?
Какие отличия в производительности рендеров urho3d и rbfx?
Специфика работы с графическими активами, на сколько больше трудозатраты на создание ассета для PBR пайплайна?

Задача отрисовка больших локаций, для шутера.

Копал ту игру какое то время. В целом работает быстро, картинку выдает приятную.
Но игровым движком это трудно назвать, там никакой архитектуры нет, монолитная смесь c++ в стиле c.
Не помню, но когда копал, там вроде бы была проблема с тенями, если создать большую карту.
Физика самописная, разве что сетевой код будет полезен. Так что пришлось отказаться от него.
Если и брать тот проект за основу то придется все переписывать, а я бы хотел получить как можно меньше задач с графикой.

Урху я переписываю для внедрения ECS и c99 api. Шутерные механики некоторые уже есть. Осталось с рендером определится.

1vanK
> В Урхо/rbfx придется конечно меньше переписывать, просто потому что
> переписывать там нечего в плане шутеров, все придется с нуля самому делать xD
Так и в плане стратегии.  А вообще изначально Урхо для какой игры делали или сразу как универсальный движок?

ёж
> Да, не важно какой движок берете (Unreal, Unity, Urho3D, Torque3D и прочее).
> В любом случае игровую логику и механику прийдется самому пилить.
"... но есть нюанс" (с)
Разные движки будут создавать разные преграды в написании игровой логики, и требовать разный масштаб усилий.

Вот очень простой пример. Допустим, я хочу сделать в Урхе персонажа, который может стоять, а может идти вперед, и я хочу плавный переход между этими двумя анимациями. Например, как в этом сэмпле Урхи.

Казалось бы, просто проигрываем одну или другую анимацию с блендингом, во всех движках это есть. Но если ты посмотришь на пример по ссылке выше, то при блендинге анимаций там монстр немного машет руками. Этого взмаха нет нигде в анимациях, это на самом деле в анимации просачивается Т-поза модели. Это баг в движке анимации Урхи, а в Юнити его нет. Значит, пользователь Юнити потратит меньше времени, чем пользователь Урхи, делая конкретно этот аспект своей игры.

И я так могу пойти сравнивать сотни разных аспектов движков. Где-то Урха будет лучше, где-то Юнити. Но я почему-то думаю, что Юнити чаще.

1vanK
> Урхо он как юнити, в базовой своей версии ничего не может. Вот только для Юнити
> есть миллион модулей в их юнити сторе, а для урхо надо искать по репозиторим
> пользователей и не факт, что найдешь что-то вменяемое
Еще один фактор — что в Юнити можно сделать очень много вещей, не меняя движок. А вот в Урхе движок придется подкручивать регулярно. См. тот же PR с Ribbon Trails в Урху.
И это проблема, потому что если сторонние компоненты из пользовательских реп еще можно накатить легко, то вот изменения движка ты из пользовательских реп хрен накатишь нормально.