- FlyOfFly
- Постоялец
FlyOfFly
> Вот представим у тебя 100карт
> ...И вот ты бегаешь по 155555уровням и в каждом меняешь размеры кнопок
LoadScene.Additive
UI может быть отдельной (основной сценой), а непосредственно карты другой
Более того, это помогает с точки зрения управлениями ресурсов. (выгружать ассеты после выгрузки сцены с картой)
Это так же помогает в работе в команде, когда люди не наступают себе на ноги редактируя одну сцену на всех.
PS: если UI и уровень не разделяют туториалы на ютубчике, то это их проблемы, так ведь? :)
Адаптив имеет проблему в виде того, что надо ещё связывать сцены уи с сценами уровнями и не забывать обновлять связь. Ну как я и написал, ты можешь взять проект оставшийся после другого человека, где в каждом уровне будет уи.
FlyOfFly
> Адаптив имеет проблему в виде того, что надо ещё связывать сцены уи с сценами
> уровнями и не забывать обновлять связь. Ну как я и написал, ты можешь взять
> проект оставшийся после другого человека, где в каждом уровне будет уи.
а в чём проблема связывать сцену УИ и сцену уровня?
- если знаем входную точку, то её нужно сдвинуть в камеру. (ну или камеру в точку старта). Эти же проблемы решаются при интеграции какой-нить spine анимации от разных аниматоров. Они же могут умудрится или центр не там поставить, или масштаб не тот. Но это вполне себе обыденная рутина по стандартизации ассетов.
Уровень = ассет. Не иначе. (к нему тоже должны применяться какие-то стандарты и требования)
- если на сцене уровня есть камеры (а они там скорее всего есть), их нужно отключить. Но это не великая непосильная сложность
Допустим, ты подбираешь проект с индивидуальным УЙом в каждой сцене. Ты пишешь свой единый сцено-УЙ, и используешь Additive для дозагрузки сцен-уровней.
Во врема загрузки сцены-уровня, кроме того что отключаешь камеры, ты можешь поодключать уй, который прописан в сцене (если он там есть).
Вполне себе легко решаемая задача.
skalogryz
Причём тут камера? Если интерфейс с ней не связан
FlyOfFly
> Причём тут камера? Если интерфейс с ней не связан
камера при том, что это "глобальный объект", коих не должно быть активных сразу несколько штук. (Аудио сорц, такой же)
если на твоей сцене есть UI, и на загружаемой сцене есть UI, то ты хочешь какой-то из UI-ев отключить. (аналогично камере, или аудио сорцу)
skalogryz
>
> камера при том, что это "глобальный объект", коих не должно быть активных сразу
> несколько штук. (Аудио сорц, такой же)
Что ты черт возьми несешь? камер может быть несколько. допустим для вывода разной информации на экране и именно поэтому в камере есть настройка depth и rect.
И ты перепутал AudioSource и AudioListener. Аудиосорц может быть несколько. а вот слышатель один
skalogryz
>
> если на твоей сцене есть UI, и на загружаемой сцене есть UI, то ты хочешь
> какой-то из UI-ев отключить. (аналогично камере, или аудио сорцу)
-Что ты черт возьми несешь? Одно из распростроненных практик в юнити это создавать несколько UI для оптимизации его. Причем не от васянов. а от самих разрабов движка
https://unity.com/ru/how-to/unity-ui-optimization-tips
FlyOfFly
> В юнити даже с префабами надо будет бегать по всем сценами и все настраивать это.
FlyOfFly
> Одно из распростроненных практик в юнити это создавать несколько UI для оптимизации его.
так чего ты жалуешься, если это распространнённая практика для оптимизаций?! :)
upd
FlyOfFly
> https://unity.com/ru/how-to/unity-ui-optimization-tips
...и в статье ничего не сказано о том, что это круто копипастить один и тот же UI для разных уровней
FlyOfFly
> И ты перепутал AudioSource и AudioListener. Аудиосорц может быть несколько. а вот слышатель один
легко мог перепутать.
и может быть имел в виду не камеру, а какой-нить InputController.
но суть аналогии не меняется.
если при загрузке additive сцены, на это дополительной сцене что-то нужно отключить, то это нужно отключить.
Ваш кэп (с)
И это "что-то" могут быть, как встроенные компоненты юнити, так и любые дополнительные надстройки. В виде того же UI-а.
Mephistopheles
>Все может быть конечно, но слабо верится что можно забраться так высоко и там удержатся будучи балваном.
Не смотрел видосы про дедушку, который на работе с призраками здоровается? Этот мир такой, что местами именно они окружающими и ценятся. Над болванами потешаются, а умников не любят, потому первые у многих вызывают более приятные эмоции.
skalogryz
>
> так чего ты жалуешься, если это распространнённая практика для оптимизаций?! :)
>
> upd
> FlyOfFly
> > https://unity.com/ru/how-to/unity-ui-optimization-tips
> ...и в статье ничего не сказано о том, что это круто копипастить один и тот же
> UI для разных уровней
так и я не об этом ) Я именно об
skalogryz
> если на твоей сцене есть UI, и на загружаемой сцене есть UI, то ты хочешь
> > какой-то из UI-ев отключить. (аналогично камере, или аудио сорцу)
FlyOfFly
> так и я не об этом ) Я именно об
давай ещё раз.
при загрузке доп сцены, что тебе мешает поотключать её старый UI неугодный UIUX-дизайнеру?!
я бы согласился с тем что Unity это гамно, потому что возможности поотключать это старый UI нет вообще.
Ну т.е. сцена грузится и всё! и никакого контроля в рантайме над происходящим.
Но unity даёт тотальный контроль над всем происходящим. Над всем сценами. И почему бы этим не пользоваться.
А ещё можно прям в редакторе скрипт на шарпе наваять, который пробежится по всем сценам (подцепленным проектом) и тупо поудаляет этот UI с этих сцен (минус нужные сцены). И это хорошее свойство движка в целом.
FlyOfFly
> И вот ты бегаешь по 155555уровням и в каждом меняешь размеры кнопок
Это не проблема юнити, когда что то делаешь ты решаешь хочешь закладывать туда гибкость и переиспользование или по быстрому "захаркодить". В юнити ничего не мешает делать "правильно", это просто занимает больше времени чем просто прибить к игровому уровню.
Mephistopheles
>
> Это не проблема юнити, когда что то делаешь ты решаешь хочешь закладывать туда
> гибкость и переиспользование или по быстрому "захаркодить". В юнити ничего не
> мешает делать "правильно", это просто занимает больше времени чем просто
> прибить к игровому уровню.
Ничего не мешает сделать свой движок. Тем более если правильно в юнити это использовать юнити только для вывода графики и физики, даже monobehaivor не одобрителен
FlyOfFly
> Ничего не мешает сделать свой движок. Тем более если правильно в юнити это
> использовать юнити только для вывода графики и физики, даже monobehaivor не одобрителен
главный вопрос зачем? Оно работает приемлемо. Перфекционизм главный враг разработки.
Основная "оптимизация" на юнити это убрать из апдейта тяжеловесные операции и не плодить миллионы отдельных актеров.
Если хочется переписать юнити - то ты в 99% случаев не компетентен. Либо не знаешь как пользоватся этим инструментом либо выбрал движок не под свою задачу.
Это как взять напильник и заточить шлиц(или как оно называется) на нем чтобы шурупы крутить.
Ты потратишь уйму времени и оно вообще не факт что будет работать лучше чем стоковое решение.
Mephistopheles
>
> Ты потратишь уйму времени и оно вообще не факт что будет работать лучше чем
> стоковое решение.
Тогда уж тем более лучше другие движки. где стандартных решений для стандартных задач больше
FlyOfFly
> Тогда уж тем более лучше другие движки
Гипотетически, может ситуация повториться в других движках?