Тёмная тема
радио
>https://p3dm.ru/files/characters/human/10702-aloy.html
полезный ресурс) столько болванок...
>Другими словами,
>хотите рендерить как это делают распоследние игровые проекты
>от корпоративных игровых студий?
а чо разве волосы на 100к поликов сделать сложно?) Возможно придется повозится, но все-таки это возможно.
Я просто думаю урха "обкакается" 50-сплайнов считать в рилтайме, для опорных на цепочках из риджидбадей
поэтому думаю нужно выбирать двиг который сможет в 50 сплайнов)
>Похоже, что я главный троль в этой ветке :)
да, но никто этого так и не узнает т.к. ты трешь все свои посты)
>А, каков практический (с позиции игростроя) интерес может быть?
нови мойнкруфт, для новой поросли, которые не приемлютъ вида старого - "кубизма" т.к. у них в тренде будет - "слоенность" ?
Там же генератор этого всего через граф, вот что меня радует. Ближе к людям.
>вот что меня радует. Ближе к людям.
такая фигня делается в 3-4 клика, несколько метабалл'ов + ремешер из блоков.
GLoom
> Вы уже видели чего Teknologicus запилил?
похоже на imgui
А как в Урхе клонировать элементы UI?
Я нашёл где в коде у меня тормоза.
Я делаю заготовки UI-блоков или отдельных элементов в xml-ках, потом гружу их. Некоторые интерфейсы имеют дофига блоков, которые надо отдельно расставлять, поэтому все они тематически собирается в свои xml-ки, являясь детьми некого stub-объекта. Потом можно его загрузить и найти нужный элемент по GetChild. Удобно.
Но, как выяснилось, кеш ресурсов какой-то медленный. Одно обращение занимает где-то 0.05 - 0.1 секунды. По идее, можно было бы сделать свой кеш, и часть одноразовых элементов я храню в классе, но их нельзя клонировать :(
И если xml-ка большая, закачиваем её как UI элемент, берём оттуда GetChild по id - всё, он извлекается из своего родителя после вставки в UI игры, и тогда xml-ку надо качать заново. И тут должен был помочь кеш, но он не помог.
StepEver
>Одно обращение занимает где-то 0.05 - 0.1 секунды
на чтении и парсинге xml'ки?
попробуй закешировать все свои UI'шки (XMLFile) на старте приложения по такому же принципу, если это возможно конечно
https://gamedev.ru/community/urho3d/forum/?id=234744
codingmonkey
Я так примерно и делаю, но там тормоза, когда из кеша делаешь LoadXml. Сами UI-шки кешить есть смысл, когда они в одном количестве, а у меня есть, например, слоты, их по 10 штук одинаковых, например, надо, их бы уметь клонировать... придётся, видимо, функцию самому писать :(
PS: вот, к примеру, я делаю драг-н-дроп рабочих. У меня есть UI для драга, раньше я её постоянно выдёргивал из общей UI-колоды, предварительно её загрузив из кеша. И был небольшой лаг. Я UI скинул в класс, один раз загрузил на страте сцены, и лагов не стало. Но вот вставка рабочих в слот требует пересобрать оба слота (слот-откуда и слот-куда, так как в них количество поменялось), и тут приходится несколько раз загружать картинки.
StepEver
>Но вот вставка рабочих в слот требует пересобрать оба слота (слот-откуда и слот-куда, так как в них количество поменялось), и тут приходится несколько раз загружать картинки.
А в ячейках уже есть ImageComponent или чо там у Урхи Sprite? И ты там только картинки меняешь/подгружаешь ?
Хз чему бы там тогда тормозить, я например тоже просто обновляю картинки у элементов UI,
когда из character inventory снарягу одеваю на перса character equipment (из одной области инвентаря в другую)
все картинки/иконки кешированы и сидят в InventoryDataBase (компонент со списком префабов, иконок и описаний всего что только можно...)
обновление во всех слотах делает одна функция, которая вызывается в аккурат после каких либо действий с инвентарем
codingmonkey
> И ты там только картинки меняешь/подгружаешь ?
Не только, в том и проблема. Насколько я понимаю, картинку как раз можно залить несколько раз, с неё на ходу генерится текстура.
codingmonkey
> можно конечно сделать спрятанные сегменты и открывать их если объем сумки меняется.
Да, видимо, придётся оптимизировать эти вещи, честно копаться внутри, а не пересобирать всё.
У меня там проблема только в том, что с рабочими неизвестно число их в слоте. Население планеты выросло - число юнитов в слотах выросло. Опять же, одно окно используется под разные планеты с разным числом народа на них. Можно, конечно, сделать 50 пунктов на слот и думать что "640кб должно хватить каждому" :) но как-то это не рационально. Я думаю, надо будет сделать какое-то среднее решение: те элементы UI, которые или в количестве 1 или не используются интерактивно - складываем в XML и работаем удобно. Остальные (их не должно быть сильно много) - создаём вручную, они не должны быть по природе слишком сложные. В идеале - сделать функцию клонирования UI.
Всем привет, я тут новенький, читаю и наслаждаюсь. Естественно мало что понимаю :)
StepEver
>Можно, конечно, сделать 50 пунктов на слот и думать что "640кб должно хватить каждому" :) но как-то это не рационально.
посмотри как этот момент реализован в аналогичных играх, там тоже на каждого юнита своя UIElement/иконка создается? А если юнитов тысячи?
BBadger
>Всем привет
привет
>читаю и наслаждаюсь.
что прямо занимательное чтиво?
>Естественно мало что понимаю :)
ну тогда, ты попал туда куда нужно... )
codingmonkey
> посмотри как этот момент реализован в аналогичных играх, там тоже на каждого юнита своя UIElement/иконка создается? А если юнитов тысячи?
Не, да, ты прав, и я буду переделывать эти места, но есть те, которые придётся создавать вручную. К счастью, их немного :)
BBadger
Привет
Как клонировать UIElement? :)
Как клонировать UIElement? :)
К сожалению не до конца понял.
BBadger
>Как клонировать UIElement? :)
см. лайфхак, как можно легко и непринужденно клонировать UIElement'ы
У меня была беда с производительностью кода я клонировал префабы для города. Оказалось что создавать модели гораздо быстрее так как не посылается Хренова туча сообщений в систему. По этому я сгенерировал код который клонирует через копирование значений из компонент в новосозданный компонент. Загрузка города ускорилась в разы.
