2021.3.34 2022.3.17 2023.2.5 2023.3.0

[artk]

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

Как бы NGUI "программно" и управляется. Это обычные GameObject'ы и объекты. При желании можно сделать тот же самый стандартный Gui.
NGUI - это обычные плашки, плюс некоторые дополнительные удобства. Как плашки могут не нравиться?

[Woolf]

Это обычные GameObject'ы и объекты.

Вот о чем я и говорю. Вместо ОДНОГО объекта с гуем плодится хренова туча левых сущностей, что весьма затрудняет работу с ним. Кроме того, это плашки - отсюда беда с разрешениями и отсюда же тянущиеся и мутные текстуры. В общем - для казуалок с двумя кнопками, нгуй может и неплох, для серьезных вещей - уродлив и неудобен.

[artk]

Вот о чем я и говорю. Вместо ОДНОГО объекта с гуем плодится хренова туча левых сущностей, что весьма затрудняет работу с ним. Кроме того, это плашки - отсюда беда с разрешениями и отсюда же тянущиеся и мутные текстуры. В общем - для казуалок с двумя кнопками, нгуй может и неплох, для серьезных вещей - уродлив и неудобен.

Мутных текстур нету - пиксель перфект работает нормально. А для тянущихся спрайтов есть бордеры и r-спрайты. Абсолютно так же работает и обычный гуи.
Проблема с разрешениями - можно делать "резиновую" верстку, но придется разрабатывать самому. Про левых сущностей - ну да, когда в OnGui создаются каждый такт новые объекты - это нормально?
Про серьезные вещи как раз наоборот. Я использую гую только в прототипах. Я не представляю где можно найти дизайнера который сможет сделать дизайн UI для стандартной гуи. И как можно сделать что-нибудь нестандартное, кроме кнопок в нем. Как можно наследовать какой-нибудь класс или изменить? И как сделать анимацию для элементов и под-элементов? Как сделать 3D интерфейс, или встроенный в игру интерфейс? Как сделать "заскриптованный" интерфейс?
Интерфейс и HUD для игр - всегда уникальный и сложный, по сравнению с приложениями. Тут нативным гуи не обойтись.
Проблема в NGUI: трудно сделать сложную анимацию, нет инструментов для дизайнера, плохая архитектура, нету готовой "резиновой" верстки.
Сейчас смотрю на scaleForm, в нем все это реализовано. Кто-нибудь уже работал с ним?

[BornFoRdeatH]

Да черт бы меня побрал, резина не резина, текстуры не текстуры, какого хрена весь гуй в стопитцот обьектах, неужели было так сложно сделать один го, а в нем инфа о обьектах на сцене, чтобы получил раз на него ссылку и работаешь, а тут чтобы с каждым елементом работать нужно его получить, чтобы кнопку написать надо на нее скрипт навесить, дурдом.

[Neyl]

Тоже бесит гуй, размазанный по десяткам геймобжектов и скриптов. Вот здорово что в меканим в 4.3 дадут возможность избавится от глубокой иерархии отдельных геймобжектов для каждой кости и объединить весь скелет в компактный U3DMesh. Так теперь получается что даже в простом гуе будет больше объектов чем в сложной модели персонажа.

[seaman]

избавится от глубокой иерархии отдельных геймобжектов для каждой кости и объединить весь скелет в компактный U3DMesh

Вы уверены, что от иерархии именно избавляются? По моему ее просто скрывают. Никуда она не девается. Да и не может деться - анимации перестанут работать.
Тем более, что доступ к отдельным костям - благо, когда нужно прицепить, например меч к руке. Так что Вы тут не правы.

[Neyl]

Вы уверены, что от иерархии именно избавляются? По моему ее просто скрывают. Никуда она не девается. Да и не может деться - анимации перестанут работать.

Насколько я понял , избавляются именно от иерархии геймобжектов с трансформами. Да, иерархия костей конечно никуда не девается, но она представляется в некоем внутреннем оптимизированном формате. Можно сказать что её скрывают. Но в той же презентации говорится что у такого подхода множество преимуществ - это удобно для рабочего процесса (поскольку уменьшает "видимую иерархию" и позволяет проще работать с аттачментами) и это "incredibly good for performance"

[Woolf]

Вы уверены, что от иерархии именно избавляются? По моему ее просто скрывают. Никуда она не девается. Да и не может деться - анимации перестанут работать.

Насколько я понял , избавляются именно от иерархии геймобжектов с трансформами. Да, иерархия костей конечно никуда не девается, но она представляется в некоем внутреннем оптимизированном формате. Можно сказать что её скрывают. Но в той же презентации говорится что у такого подхода множество преимуществ - это удобно для рабочего процесса (поскольку уменьшает "видимую иерархию" и позволяет проще работать с аттачментами) и это "incredibly good for performance"

Кроме того - прощай ручное масштабирование и изменение костей? Или в legacy останется иерархия? У меня вот удочки гнутся именно как набор трансформов.

[gnoblin]

можно включать те кости, что тебе нужны - подозреваю всё ок )

[broken]

Касаемо версии 4.2.1, у всех полет нормальный и все на него перешли? Больше интересуюсь для функционала под веб чем для мобил.

[Sef]

4.2 мне вообще работу на несколько недель затормозил из-за глюков. С 4.2.1 уже работаю.

[DbIMok]

http://blogs.unity3d.com/2013/10/11/uni ... r-support/

[Johnson]

еслиб не беда с дроколами и запуском OnGUI по несколько раз за фрейм...

А в чем там беда? Просто нужно представлять как работает GL - одна текстура - один дк. Одна строка - один дк.
Все окна в одном дк не вывети - они ж перекрывают друг друга в произвольном порядке и имеют дочерей (хоть бы и кнопки).

Была у меня мысль генерировать текстуру перед отрисовкой и уложиться в 1 дк, но эту мысль я быстро выжег из головы как нерациональную. Генерировать 30-200 огромных текстур в секунду - не лучшая идея.
И, кстати, интересует - nGUI разве укладывается в меньшее количество дк при той же сложности гуя?

[gnoblin]

еслиб не беда с дроколами и запуском OnGUI по несколько раз за фрейм...

А в чем там беда? Просто нужно представлять как работает GL - одна текстура - один дк. Одна строка - один дк.
Все окна в одном дк не вывети - они ж перекрывают друг друга в произвольном порядке и имеют дочерей (хоть бы и кнопки).

Была у меня мысль генерировать текстуру перед отрисовкой и уложиться в 1 дк, но эту мысль я быстро выжег из головы как нерациональную. Генерировать 30-200 огромных текстур в секунду - не лучшая идея.
И, кстати, интересует - nGUI разве укладывается в меньшее количество дк при той же сложности гуя?

да, NGUI при той же сложности гуя отрисует тебе всё в пару дк т.к. юзаются атласы и бачинг.

[Woolf]

еслиб не беда с дроколами и запуском OnGUI по несколько раз за фрейм...

А в чем там беда? Просто нужно представлять как работает GL - одна текстура - один дк. Одна строка - один дк.
Все окна в одном дк не вывети - они ж перекрывают друг друга в произвольном порядке и имеют дочерей (хоть бы и кнопки).

Была у меня мысль генерировать текстуру перед отрисовкой и уложиться в 1 дк, но эту мысль я быстро выжег из головы как нерациональную. Генерировать 30-200 огромных текстур в секунду - не лучшая идея.
И, кстати, интересует - nGUI разве укладывается в меньшее количество дк при той же сложности гуя?

да, NGUI при той же сложности гуя отрисует тебе всё в пару дк т.к. юзаются атласы и бачинг.

нгуй теоретически не может достигнуть той же сложности гуя, поскольку рисует плашками (более того - GameObject-ами), вместо прямого рендера на экран, что уже ущербно. Далее - что 1 дк, что 100 дк - в отношении нативного юнитевского гуя не имеет ровно никакого значения, поскольку весь гуй рисуется ТОЛЬКО тогда, когда происходят изменения гуя. В остальное время все красиво как вы говорите "батчится", на самом деле - это единый (почти единый) VBO объект, который выводится за 1дк. И еще раз повторюсь - не нужно бояться ДК. Они на производительность практически не влияют. Количество полигонов в кадре и тяжелые шейдеры - значительно сильнее просаживают фпс, чем дк. И к мобилам это тоже относится. Моя ущербная читалка ритмикс (она даже не планшет, просто читалка на андроиде!) жрет 1000 дк и не морщится. Кстати, терейн она тоже замечтельно жрет. Так что уж говорить про более современные устройства.