3D.ru

Nicloay писал(а):Если реч не идет о мобильных платформах.

с чего Вы взяли, или я нажимаю что-то не то?

делать свой гуй который будет превосходить все существующие аналоги это замашка покруче чем "а сейчас мы запилим ммо"

BenjaminMoore писал(а):

Nicloay писал(а):Если реч не идет о мобильных платформах.

с чего Вы взяли, или я нажимаю что-то не то?

Был не прав, беру слова обратно
http://blogs.unity3d.com/2012/07/05/uni ... ile-games/

Dynamic Fonts on Mobile

In Unity 4 you will be able to use dynamic fonts on mobile devices. You can include any OS fonts without having to include font data in your build. At runtime a font sheet is dynamically created with only the characters that are currently needed. This allows you to keep the build size down. If you do not want to use an OS font you can also embed ttf files (and fall back to OS fonts for missing characters / languages). Using dynamic fonts (embedded or not) saves runtime texture memory in languages where you have many characters, but typically do not use all of them. Additionally, Unity 4 also supports using HTML-like markup when rendering text. This allows for easy insertion of styles in an inline manner.

Both dynamic fonts and HTML like markup are part of the core unity product and are not limited to mobile platforms.

Чето помню, просто ворнинги которые сыпались, из за dynamic font size.

gnoblin писал(а):делать свой гуй который будет превосходить все существующие аналоги это замашка покруче чем "а сейчас мы запилим ммо"

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

Так в 4.6 новую систему GUI обещают. На видео вплоне достойно выглядит.

Картинки симпатишные, но то как все показано, для меня, ставит под вопрос возможность расширения...

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

отвечаю из будущего
да, padding будет.
сетка со снапом уже есть.
события реализованы и их рассылка в трех видах:
дефолтные евенты С#, месседжи юнити и коллбеки, которые вешаются через рефлекшен в инспекторе, такое есть в NGUI и uGUI, не знаю как в дайконе.

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

у нас сохраняется доступ к отрисовке контроллов кодом в ООП стайле + будет прослойка аналогичная дефолтной гуйне: всякие if(XGUI.Button(...)) и так далее, но с гораздо большим функционалом, в отличии от того как это делал дефолтый гуй.
нужно что-то расширить? наследуйтесь да и ваяйте что хотите там.

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

насчет твинов тоже видел вопрос, по сути таких же твинов как в дайконе у нас не будет, но будет настраиваемая анимация для каждого из состояний гуй элемента, где можно проанимировать всё: цвет, позицию, размер, спрайт и так далее
может мы и захреначим какие-то прессеты для такого, но это уже будет ясно в релизе.

ах, да, я совсем забыл добавить, что тут сравнения пошли с Legacy GUI, нам пришлось отказаться от него, в силу некоторых нерешимых задач в его контексте
теперь у нас будет своя хитрая GL начинка

BenjaminMoore писал(а):во-вторых у нас гуй будет полностью доступен из кода, чего в нормальном виде нет в текущих гуях: собрать гуй на НГУИ из кода - очень веселая задача.
у нас сохраняется доступ к отрисовке контроллов кодом в ООП стайле + будет прослойка аналогичная дефолтной гуйне: всякие if(XGUI.Button(...)) и так далее, но с гораздо большим функционалом, в отличии от того как это делал дефолтый гуй.
чтобы было яснее, все текущие гуй-фреймворки завязаны на иерархии и наборе компонентов развешанных на объектах, у нас такого нет.
весь вайсвиг по сути надстройка для тех, кто не любит ничего делать из кода, но хочет, чтобы все было красиво и быстро.

Шикарно, это именно то, чего я жду.

Скоро будет

выкатив мне 100500 элементов GUI в одном скроллере! FPS правда был не очень (4-5 кадров в секунду), но IT'S A LIVE !

На нгуи и дайконе мы и не так извращались, и все работало.

А юГуи почти полная копия нгуи.

Ну и как дела, в ассетсторе уже появились? Я тут начал один проектец, вот и думаю, может ваш опробовать гуй.

Ещё не в сторе. Решили сильно сменить возможности и производительность. Детали чуть позже.

Woolf писал(а):Ну и как дела, в ассетсторе уже появились? Я тут начал один проектец, вот и думаю, может ваш опробовать гуй.

Релиз откладывается и на это есть веские причины: мы во всю переходим на свой рендер гуй контроллов, что до меня не было запланировано.
Если раньше у нас бэкнэндом выступал LegacyGUI, то сейчас мы рисуемся по-своему.

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

Кратко расскажу, почему именно переход на кастомный рендер так важен.
LegacyGUI не умеет рисоваться с кастомными материалами, вообще никак.
Мы не имеем никакого контроля над клипингом гуя, он только в форме Rect, что достаточно печально.
LegacyGUI в 3д? нет, не слышал ( можно конечно рендерить в текстуру, но это такой костыль)
Кастомные контроллы = костыль

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


Все можно настроить как из инспектора, так и кодом.
Если выставить аттрибут [ExecuteInEditorMode], то Вы сможете настроить все гуи контроллы еще и с помощью вайсвига, единственное ограничение это невозможность изменить парента контролла, чтобы избежать коллизий - вы контролируйте иерархию контролов сами кодом.
У нас есть обертка компонентная, чтобы клепать гуй вообще одной рукой с помощью мышки, это обычные монобехи с одним контроллом внутри, вайсвиг собирает гуй с помощью него. Однако подход с отдельным ядром позволяет комбинировать создание гуя кодом и вайсвигом: получается Вы делаете геткомпонент и просто делаете тот же AddControl. Единообразие и гибкость.

Второй главный плюс такого ядра : Возможность рисоваться в Editor'e, для Нео это вообще один из основных плюсов. Не один гуи фреймворк на текущий момент не может этого. Вся динамика и интерактивность так же сохраняется - одно общее ядро.

Свое ядро принесло и еще несколько своих полезностей:
*Динамический атласинг, у нас все текстуры используемые в стилях гуя автоматические кидаются в атласы, если нужно добавить еще какие-то текстуры - без проблем. Мы все склеим. Динамический атласинг так же будет работать в рантайме, например Вы подгрузили пачку иконок для магазина или аватарок, фреймворк сам постепенно приклеит текстуры к атласу, чтобы снизить DC.
Для всего этого у нас свой формат спрайтов, потому что юнитеки к сожалению свои спрайты полностью окопали, а нам нужны меши, а точнее шейпы
*Шейпы - это произвольные формы для контролов, хоть звездочкой, хоть кружочком. Произвольное обрезание гуя любой формы(не только рект в случае LegacyGUI).
*Ох, еще раз скажу про материалы, сколько ими можно сотворить разных эффектов гуя
*Единообразие методов драг'н'дропа, селекта(что используется сейчас во всю в вайсвиге) позволяет спокойно все использовать в рантайм и по-умолчанию у пользователя появляется инструменты для выделения геймобъектов, например удобно для всяких стратегий.
*Никаких долбанных трансформов с их пересчетом матриц при любом вздохе, у нас это не было проблемой и при LegacyGUI, но мы сохраняем это свойство и сейчас.
*Сериализация гуя в свой формат: сохранение настроек окон у пользователя, сразу встроена в фреймворк. Благодаря свою формату, Ваш сeрвер сможет собирать каркас гуя, например для интерактивного магазина, прикреплять изображения и всё это отправлять клиенту, при этом ничего не зная о юнити. Обновление гуя клиента без ребилдинга клиента. Внешний редактор гуя.
*Готовый 3д рендер, гуй сразу 3д, даже если создали его кодом, можно крутить-вертеть как угодно. При этом этом сохраняется удобность, если Вам нужен обычный 2д, никакой дополнительной пляски.
*Комбинирование решений: основное окно редактирования у нас GameView это позволяет добиться пиксельной точности гуя и картинка у нас однозначно будет такая же, что и редакторе. Компоненты поддерживают идеологию юнитеков и всех текущих мейнстрим гуёв. Режим 3Д дает возможность перебраться в пайплайн рендера игры, чтобы сделать взаимодействие гуя с игровыми объектами, получать источники света для материала, повесить коллайдеры.

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

Еще из релизных фич, это трансферы гуя из NGUI -> XGUI, LegacyGUI -> XGUI, Daikon -> XGUI

Как видите, объем работы увеличился, потому стоит немного потерпеть, но оно того стоит.
Если есть желание отпишите мне в ЛС или Неодропу, и мы Вас пригласим на бета-тестирование к концу месяца.

Очень важный вопрос относительно комбинирования вашего гуя и дефолтного. К примеру, снизу текстура от дефолтного, сверху ваши кнопки - реально? У меня есть ваши ранние версии, я уже пробовал, вот к примеру такая задача - верхний скрин масштабируется по размеру экрана, кроме нижней области - там отступ от края экрана всегда 200 пикселей, нижняя панель в 200 пикселей может масштабироваться по ширине, но никогда по высоте, причем, при любых разрешениях. Пытался что-то изобрать xGUI, не получилось, плюнул, сделал тремя строчками нативного гуя ))

Woolf писал(а):Очень важный вопрос относительно комбинирования вашего гуя и дефолтного. К примеру, снизу текстура от дефолтного, сверху ваши кнопки - реально? У меня есть ваши ранние версии, я уже пробовал, вот к примеру такая задача - верхний скрин масштабируется по размеру экрана, кроме нижней области - там отступ от края экрана всегда 200 пикселей, нижняя панель в 200 пикселей может масштабироваться по ширине, но никогда по высоте, причем, при любых разрешениях. Пытался что-то изобрать xGUI, не получилось, плюнул, сделал тремя строчками нативного гуя ))

из этого описания я не понял над каким элементов нужно рисоваться, над нижним баром в 200 пикселей высотой?
если да, то это очень легко сделать и на старом XGUI
делаете контейнер пустой, убираете у него стиль, выставляете LayoutAnchor в LowerCenter, высоту четко задаете в 200 пикселей, ширину в 100%, позиция X 0, Y 0
в него кидаете свои кнопки и они всегда будут над этим ректом

отрисовку OnGUI можно регулировать Execute Order Scripts, мы так же рисуемся через него, потому нужно просто расположить выше или ниже ваш скрипт относительного нашего XGUIOnGUI
единственно с помощью XGUI не получится отрисовать одновременно разные контролы под и над Вашей текстурой
для этого нужно все таки перенести текстуру в XGUI