Обновление до Unity 4.0

Активное состояние GameObject

В Unity 4.0 изменен способ обработки активного состояния игровых объектов. GameObjectОсновной объект в сценах Unity, который может представлять персонажей, реквизит, декорации, камеры, путевые точки и многое другое. Функциональность GameObject определяется прикрепленными к нему компонентами. Подробнее
См. в Словарь, активное состояние теперь наследуется дочерними игровыми объектами, так что любой GameObject, который неактивен, также приведет к неактивности его дочерних элементов. Мы считаем, что новое поведение имеет больше смысла, чем старое, и всегда должно было быть таким. Кроме того, грядущая новая система графического интерфейса сильно зависит от нового поведения 4.0 и была бы невозможна без него. К сожалению, это может потребовать некоторой работы по исправлению существующих проектов для работы с новым поведением Unity 4.0, и вот изменение:

Старое поведение:

Активность GameObject определяется его свойством .active.
Это можно запросить и установить, проверив свойство .active.
Активное состояние игрового объекта не влияло на активное состояние дочерних игровых объектов. Если вы хотите активировать или деактивировать GameObject и все его дочерние элементы, вам необходимо вызвать GameObject.SetActiveRecursively.
При использовании SetActiveRecursively для GameObject предыдущее активное состояние любого дочернего GameObject будет потеряно. Когда вы деактивируете, а затем активируете GameObject и все его дочерние элементы с помощью SetActiveRecursively, любой дочерний элемент, который был неактивен до вызова SetActiveRecursively, становился активным, и вам приходилось вручную следите за активным состоянием дочерних элементов, если хотите вернуть его в прежнее состояние.
Сборные элементы не могли содержать какое-либо активное состояние и всегда были активны после сборноготипа ресурса, позволяющего хранить игровой объект. в комплекте с компонентами и свойствами. Префаб действует как шаблон, из которого вы можете создавать новые экземпляры объектов на сцене. Подробнее
См. в экземпляре Словарь.

Новое поведение:

Является ли GameObject активным или нет, определяется его собственным свойством .activeSelf и свойствами всех его родителей. GameObject активен, если его собственное свойство .activeSelf и свойство всех его родителей равно true. Если какое-либо из них равно false, GameObject неактивен.
Это можно запросить с помощью свойства .activeInHierarchy.
Состояние .activeSelf GameObject можно изменить, вызвав GameObject.SetActive. При вызове SetActive (false) для ранее активного GameObject деактивируется GameObject и все его дочерние элементы. При вызове SetActive (true) для ранее неактивного игрового объекта это активирует игровой объект, если все его родители активны. Дочерние элементы будут активированы, когда активны все их родители (т. е. когда для всех их родителей параметр .activeSelf установлен в true).
Это означает, что SetActiveRecursively больше не нужен, поскольку активное состояние наследуется от родителей. Это также означает, что при деактивации и активации части иерархии вызовом SetActive предыдущее активное состояние любого дочернего игрового объекта будет сохранено.
Сборные элементы могут содержать активное состояние, которое сохраняется при создании сборных экземпляров.

Пример:

У вас есть три игровых объекта, A, B и C, так что B и C являются дочерними элементами A.

Deactivate C by calling C.SetActive(false).
Now, A.activeInHierarchy == true, B.activeInHierarchy == true and C.activeInHierarchy == false.
Likewise, A.activeSelf == true, B.activeSelf == true and C.activeSelf == false.
Now we deactivate the parent A by calling A.SetActive(false).
Now, A.activeInHierarchy == false, B.activeInHierarchy == false and C.activeInHierarchy == false.
Likewise, A.activeSelf == false, B.activeSelf == true and C.activeSelf == false.
Now we activate the parent A again by calling A.SetActive(true).
Now, we are back to A.activeInHierarchy == true, B.activeInHierarchy == true and C.activeInHierarchy == false.
Likewise, A.activeSelf == true, B.activeSelf == true and C.activeSelf == false.

Новое активное состояние в редакторе

Чтобы визуализировать эти изменения, в редакторе Unity 4.0 любой GameObject, который неактивен (либо потому, что его собственному свойству .activeSelf присвоено значение false, либо одному из его родителей), будет выделен серым цветом в иерархии и будет иметь серый значок в инспектореокне Unity, которое отображает информация о текущем выбранном игровом объекте, активе или настройках проекта, позволяющая просматривать и редактировать значения. Дополнительная информация
См. в Словарь. Собственное свойство GameObject .activeSelf отражается его активным флажком, который можно переключать независимо от родительского состояния (но он активирует GameObject только в том случае, если активны все родительские объекты).

Как это повлияет на существующие проекты:

Чтобы вы знали, какие места в вашем коде могут повлиять на вас, свойство GameObject.active и функция GameObject.SetActiveRecursively() объявлены устаревшими.
Однако они по-прежнему функционируют. Чтение значения GameObject.active эквивалентно чтению GameObject.activeInHierarchy, а установка GameObject.active эквивалентна вызову GameObject. Установитьактив(). Вызов GameObject.SetActiveRecursively() эквивалентен вызову GameObject.SetActive() для GameObject и всех его дочерних элементов.
Сцены выхода из версии 3.5 импортируются путем установки свойства selfActive любого игрового объекта в сцене Сцена содержит окружение и меню вашей игры. Думайте о каждом уникальном файле сцены как об уникальном уровне. В каждой сцене вы размещаете свое окружение, препятствия и декорации, по сути проектируя и создавая свою игру по частям. Подробнее
Посмотрите в Словарь его предыдущее активное свойство.
В результате любой проект, импортированный из предыдущих версий Unity, должен по-прежнему работать должным образом (хотя и с предупреждениями компилятора), если он не зависит от наличия активных дочерних элементов неактивных объектов GameObject (что больше невозможно в Unity). 4.0).
Если ваш проект предполагает наличие активных дочерних элементов неактивных игровых объектов, вам необходимо изменить свою логику на модель, которая работает в Unity 4.0.

Изменения в конвейере обработки объектов

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

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

Пример потери ссылок, поскольку они еще не являются постоянными

Рассмотрите этот небольшой пример:

public class ModelPostprocessor : AssetPostprocessor
{
    public void OnPostprocessModel(GameObject go)
    {
        PrefabUtility.CreatePrefab("Prefabs/" + go.name, go);
    }
}

В Unity 3.5 это создаст префаб со всеми правильными ссылками на меши и т. д., поскольку все меши уже были бы постоянными, но поскольку в Unity 4.0 это не так, тот же постпроцессор создаст префаб. префаб, где все ссылки на меши исчезли, просто потому, что Unity 4.0 еще не знает, как разрешить ссылки на объекты в префабе исходной модели. Чтобы правильно скопировать префаб модели в префаб, вы должны использовать OnPostProcessAllAssets, чтобы просмотреть все импортированные активы, найти префаб модели и создать новые префабы, как указано выше.

Пример ссылок на ранее импортированные активы, которые удаляются

Второй пример немного сложнее, но на самом деле это вариант использования, который мы видели в версии 3.5, но который сломался в версии 4.0. Вот простой ScriptableObject со ссылками на meshосновной графический примитив Unity. Меши составляют большую часть ваших 3D-миров. Unity поддерживает триангулированные или четырехугольные полигональные сетки. Поверхности Nurbs, Nurms, Subdiv должны быть преобразованы в полигоны. Подробнее
См. в Словарь.

public class Referencer : ScriptableObject
{
    public Mesh myMesh; 
}

Мы используем этот ScriptableObject для создания актива со ссылками на сетку внутри модели, затем в нашем постпроцессоре мы берем эту ссылку и даем ей другое имя, конечным результатом является то, что когда мы повторно импортировали модель, имя меша будет определяться постпроцессором.

public class Postprocess : AssetPostprocessor
{
    public void OnPostprocessModel(GameObject go)
    {
        Referencer myRef = (Referencer)AssetDatabase.LoadAssetAtPath("Assets/MyRef.asset", typeof(Referencer));
        myRef.myMesh.name = "AwesomeMesh";
    }
}

Это отлично работало в Unity 3.5, но в Unity 4.0 уже импортированная модель будет полностью заменена, поэтому изменение имени сетки из предыдущего импорта не будет иметь никакого эффекта. Решение здесь состоит в том, чтобы найти меш другими способами и изменить его имя. Самое важное отметить, что в Unity 4.0 вы должны ТОЛЬКО изменять данные входные данные для постпроцессора и не полагаться на ранее импортированную версию того же ресурса.

Опция чтения/записи сетки

В Unity 4.0 добавлена опция «Чтение/запись включена» в настройках импорта модели. Когда этот параметр отключен, он экономит память, поскольку Unity может выгрузить копию данных меша в игре.

Однако, если вы масштабируете или создаете экземпляры сеток во время выполнения с неравномерным масштабом, вам может потребоваться включить «Чтение/запись включена» в их настройках импорта. Причина в том, что неравномерное масштабирование требует хранения данных сетки в памяти. Обычно мы обнаруживаем это во время сборки, но когда сетки масштабируются или создаются во время выполнения, вам нужно установить это вручную. В противном случае они могут неправильно отображаться в игровых сборках.

Оптимизация сетки

Model Importer в Unity 4.0 стал лучше оптимизировать сетку. Флажок «Оптимизация сетки» в средстве импорта моделей в Unity 4.0 теперь включен по умолчанию и будет изменять порядок вершин в вашей сетке для достижения оптимальной производительности. У вас может быть некоторая постобработкапроцесс, который улучшает визуальные эффекты продукта путем применения фильтров и эффектов до того, как изображение появится на экране. Вы можете использовать эффекты постобработки для имитации физических свойств камеры и пленки, например Bloom и Depth of Field. Дополнительная информация постобработка, постобработка, постобработка
Посмотреть в Словарь код или эффекты в вашем проекте, которые зависят от вершины порядок ваших мешей, и они могут быть нарушены этим изменением. В этом случае отключите «Оптимизацию сетки» в импортере сетки. В частности, если вы используете компонент SkinnedCloth, оптимизация сетки приведет к изменению отображения весов вершин. Поэтому, если вы используете SkinnedCloth в проекте, импортированном из версии 3.5, вам нужно отключить «Оптимизацию сетки» для затронутых сеток или перенастроить веса вершин, чтобы они соответствовали новому порядку вершин.

Мобильный ввод

Благодаря Unity 4.0 ввод с мобильных датчиков стал лучше согласовываться между платформами, что означает, что вы можете писать меньше кода при обработке типичного ввода на мобильных платформах. Теперь ускорение и гироскоп будут следовать ориентации экрана одинаково как в iOSмобильной операционной системе Apple. Подробнее
См. в Словарь и на платформах Android. Чтобы воспользоваться этим изменением, вы должны реорганизовать свой код ввода и удалить код, специфичный для платформы и ориентации экрана, при обработке ускорения и ввода гироскопа. Вы по-прежнему можете получить старое поведение на iOS, установив для параметра Input.compensateSensors значение false.

Вы можете отблагодарить автора, за перевод документации на русский язык. ₽ Спасибо