Unity 6.3
0 онлайн 106 гостей 3 в системе
Вход
← Обновление Unity Шаг 8 из 11

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

На этой странице перечислены изменения в Unity 2023.2, которые могут повлиять на существующие проекты при обновлении их с версии 2023.1 до версии 2023.2.

Контуры страницы

Освещение окружающей среды: зонд окружающей среды и зонд отражения Skybox больше не выпекаются по умолчанию.

UnityПрогрессивный Lightmapper больше не запекает зонд окружающей среды и зонд отражения skybox по умолчанию, и Перерасчет освещения окружающей среды установка в Освещение окно удалено.

Чтобы не допустить отсутствия освещения в новой созданной сцене, Unity назначает по умолчанию Lighting Data Asset, содержащий освещение, которое соответствует материалу skybox по умолчанию.

Вы должны выбрать Создать освещение в окне Освещение в следующих случаях:

  • Чтобы исправить освещение в сцене, где вы полагаетесь на предыдущее автоматическое поведение запекания.
  • Чтобы увидеть изменения освещения в новой сцене, если вы измените настройки освещения окружающей среды.

Если вы полагаетесь на предыдущее автоматическое поведение печенья, но используете по умолчанию настройки освещения окружающей среды, Unity обновляет сцену для использования по умолчанию Lighting Data Asset.

Автоматически генерируемое освещение удалено

Настройка Auto Generate в окне Освещение была удалена, и соответствующие APIs теперь устарели.

Чтобы создать выпеченное освещение для сцены, можно выполнить любое из следующих действий:

  • Выберите Создать освещение в окне Освещение.
  • Используйте Lightmapping.Bake API.
  • Используйте Lightmapping.BakeAsync API.

Чтобы проверить карты освещения во время редактирования, теперь вы можете выбрать Scene View Draw Mode и установить Lighting Data на Предварительный просмотр. Это отображает предварительный просмотр запеченного освещения. Предварительные карты освещения не деструктивны, и вы можете использовать их после того, как вы запечили сцену.

Если сцена зависит от автоматически генерируемого освещения, то она больше не имеет заготовленного освещения. Выберите Создать освещение в окне Освещение, чтобы перезаготовить освещение вручную.

Если вы используете скрипт для открытия сцены, теперь вы должны использовать Lightmapping.Bake или Lightmapping.BakeAsync вместо ожидания завершения автоматически генерируемого освещения.

Графические форматы DepthAuto, ShadowAuto и VideoAuto устарели

Следующие графические форматы, которые были ранее устаревшими в 2022.1, теперь устарели и вызывают ошибки компиляции, если вы их используете:

  • GraphicsFormat.DepthAuto
  • GraphicsFormat.ShadowAuto
  • GraphicsFormat.VideoAuto

GraphicsFormatUtility.GetGraphicsFormat API больше не возвращает устаревшие форматы. Вместо этого он выполняет следующее:

  • Переводит RenderTextureFormat.Depth в GraphicsFormat.None вместо GraphicsFormat.DepthAuto. GraphicsFormat.None указывает на отображение только глубины.
  • Преобразует RenderTextureFormat.Shadowmap в GraphicsFormat.None вместо GraphicsFormat.ShadowAuto. Если вы создаете текстуру рендеринга в формате GraphicsFormat.None, вы должны установить RenderTextureDescriptor.shadowSamplingMode на ShadowSamplingMode.CompareDepths, чтобы включить выборку с сопоставлением глубины.

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

Например, в следующем фрагменте GraphicsFormatUtility.IsDepthFormat возвращает false вместо true:

RenderTextureDescriptor desc = new RenderTextureDescriptor(256, 256, RenderTextureFormat.Depth, 32);
bool isDepthOnly = GraphicsFormatUtility.IsDepthFormat(desc.graphicsFormat);

Чтобы проверить, является ли RenderTexture или RenderTextureDescriptor только глубинным, используйте одно из следующих действий:

  • if (renderTexture.graphicsFormat == GraphicsFormat.None && renderTexture.depthStencilFormat != GraphicsFormat.None)
  • if (renderTexture.format == RenderTextureFormat.Depth || renderTexture.format == RenderTextureFormat.Shadowmap)

Пределы Mipmap больше не влияют на текстуры по умолчанию

Созданные во время выполнения текстуры 2D больше не будут ограничены по умолчанию загрузкой mipmap. Раньше ограничения mipmap нужно было отключать явно через конструктор Texture2D (посредством предоставления логического параметра ignoreMipmapLimit, когда конструктор вызван с TextureFormat, или IgnoreMipmapLimit TextureCreationFlag, когда он вызван с GraphicsFormat), или переключая tex.ignoreMipmapLimit построенной текстуры. Это поведение изменилось: ограничения mipmap теперь включены для созданных во время выполнения текстур 2D.

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

  • Пользователи, которые неосознанно ожидают, что текстуры runtime будут следовать настройкам качества.
  • Пользователи, которые намеренно хотели, чтобы текстуры выполнения следовали настройкам качества и достигли этого, используя любой конструктор Texture2D по умолчанию.

Это изменение не затрагивает пользователей в следующих случаях:

  • Пользователи, которые явно хотели, чтобы текстуры времени выполнения оставались в полном разрешении.
  • Пользователи, которые намеренно хотели текстуры runtime следовать настройкам качества и достигли этого, сделав следующее явно:
    • Использование конструктора с TextureFormat, с false для ignoreMipmapLimit,
    • Установка tex.ignoreMipmapLimit на false после построения.

Эти пользователи могут пожелать обновить свои скрипты, если они используют устаревшие конструкторы.

Чтобы обновить ваши скрипты, используйте конструктор Texture2D с конструктором MipmapLimitDescriptor, чтобы указать, что Текстура времени выполнения должна быть затронута настройками качества.

Это изменение было сделано для согласованности с новой поддержкой ограничения mipmap для Texture2DArrays. Вместо того, чтобы каждая текстура определяла свое собственное поведение ограничения mipmap по умолчанию, мы выбрали согласованность и решили, что текстуры времени выполнения должны явно включать ограничения mipmap. Это поведение включения предпочтительнее, чем отключения, потому что текстуры времени выполнения часто используются более универсальными способами, где неожиданная загрузка меньшего количества mips, чем ожидалось, может быть более вредной, чем неожиданная загрузка большего количества mips.

Расширенное создание пользовательских контроля с UXML

Упрощено создание пользовательских контроллеров с UXML в UI Toolkit, чтобы ускорить рабочий процесс и сделать его более интуитивным.

Основным улучшением является введение атрибутов UxmlElement и UxmlAttribute. Эти атрибуты упрощают создание атрибутов и автоматически получают имена атрибутов из имен свойств, устраняя необходимость в классах UxmlTraits и UxmlFactory.

Теперь можно создавать собственные конвертеры атрибутов для конкретных типов данных, обеспечивая точное преобразование значений в строки атрибутов UXML и обратно. Мы также улучшили UxmlObject: внутри визуальных элементов теперь можно объявлять собственные невизуальные элементы. Новая система опирается на сериализацию Unity и с помощью генератора исходного кода создаёт классы UxmlSerializedData по всем объявлениям UxmlAttribute для каждого класса пользовательского элемента, благодаря чему поддерживаются пользовательские отрисовщики свойств, декораторы и различные атрибуты.

Внедрение «переопределений атрибутов» позволяет настраивать поведение атрибутов UXML и обеспечивает гибкость при работе с унаследованными атрибутами. Эти улучшения обеспечивают более эффективный и удобный опыт создания сложных элементов UI в Unity 2023.2 и далее.

Например, следующий пример кода представляет собой пользовательский контроллер, созданный с помощью UxmlFactory и UxmlTraits:

public class HealthBar : VisualElement
{
   private const float k_LowValue = 0;
   private const float k_HighValue = 100;

   // Declare as usable with Uxml
   public new class UxmlFactory : UxmlFactory<HealthBar, UxmlTraits> { }
   // Define attributes (and connect with class properties) for Uxml 
   public new class UxmlTraits : BindableElement.UxmlTraits
   {
       UxmlColorAttributeDescription m_Color = new UxmlColorAttributeDescription { name = "color", defaultValue = Color.white };
       UxmlFloatAttributeDescription m_Value = new UxmlFloatAttributeDescription { name = "value", defaultValue = k_HighValue };

       public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
       {
           base.Init(ve, bag, cc);
           var bar = ve as HealthBar;
           bar.color = m_Color.GetValueFromBag(bag, cc);
           bar.value = m_Value.GetValueFromBag(bag, cc);
       }
   }

   public Color color { get; set; }

   [Range(k_LowValue, k_HighValue)]
   public float value { get; set; }
}

Следующий пример кода делает то же самое, что и предыдущий, но использует новую систему UxmlElement и UxmlAttributes:

[UxmlElement]
public class HealthBar2 : VisualElement
{
   private const float k_LowValue = 0;
   private const float k_HighValue = 100;

   [UxmlAttribute]
   public Color color { get; set; } = Color.white;

   [UxmlAttribute]
   [Range(k_LowValue, k_HighValue)]
   public float value { get; set; } = k_HighValue;
}

Дополнительные примеры и информацию см. в документации по Unity UI Toolkit, а также в подробном блог-посте осенью.

Меню «Ассеты/Создать» и ScriptTemplates были реорганизованы

Меню Assets/Create было реорганизовано и разбито на категории. В рамках этого изменения файлы Unity Built-In ScriptTemplate были переименованы.

Пользователи, добавившие элементы в меню Assets/Create с помощью либо tribute CreateAssetMenuAttribute``, MenuItemAt, либо Custom ScriptTemplate, могут пожелать изменить приоритет пункта меню, так как его расположение относительно других элементов теперь отличается.

Пользователи, которые создавали ассеты, выполняя эти пункты меню с EditorApplication.ExecuteMenuItem API, должны проверить новый путь к пункту меню.

Пользователям, которые ранее переопределяли встроенные ScriptTemplate в Unity, необходимо обновить имена своих переопределяющих файлов, чтобы они соответствовали новым именам встроенных шаблонов.

UI Toolkit Реорганизация и упрощение обработки событий

Методы ExecuteDefaultAction и ExecuteDefaultActionAtTarget устарели. Для их замены добавлены следующие методы:

  • HandleEventTrickleDown
  • HandleEventBubbleUp

Unity выполняет эти новые методы на каждом элементе в пути отправки события сразу после TrickleDown и до BubbleUp обратных вызовов этого элемента. Во время этих методов фаза отправки устанавливается на TrickleDown или BubbleUp соответственно, и событие `currentTarget`` совпадает с элементом, выполняющим метод.

Фаза отправки AtTarget и метод PreventDefault были устарены. Вызов StopPropagation или StopPropagationImmediately теперь прекращает дальнейшее выполнение HandleEventTrickleDown и HandleEventBubbleUp одновременно с прекращением дальнейшего вызова обратных вызовов TrickleDown и `BubbleUp``.

В большинстве случаев, если вы не обновляете свой код на новые методы, ваш код не должен значительно менять свое поведение. UI Tookkit по-прежнему вызывает устаревшие методы в том же порядке, что и раньше, или с минимальными изменениями. Однако все стандартные контроллеры в UI Toolkit перешли на использование новых методов, соответственно изменив порядок выполнения их логики. Смешивание вызовов устаревших методов с использованием обновленных контроллеров может привести к некоторой логике, которая не синхронизирована по сравнению с предыдущими версиями Unity.

Чтобы обновить существующий код до новых методов, выполните следующие действия:

  • Замените ExecuteDefaultAction и ExecuteDefaultActionAtTarget на HandleEventBubbleUp и PreventDefault на StopPropagation (или удалите вызов PreventDefault, если StopPropagation уже был вызван в том же блоке кода. Это покрывает большинство случаев).
  • Если у вас возникли проблемы из-за вызова старого кода PreventDefault во время обратного вызова BubbleUp, который больше невозможен и не может быть заменен StopPropagation, потому что событие уже достигло своей цели, рассмотрите возможность добавления обратного вызова во время фазы TrickleDown для вызова StopPropagation. Этот шаг, как правило, достаточен для решения таких сценариев.
  • В редких случаях, когда вышеупомянутые изменения не достаточны для сохранения функциональности старого кода, необходим тщательный анализ каждого конкретного случая. Решение может быть не всегда простым в этих контекстах.

Дополнительные ресурсы

← Предыдущий шагОбновление до Unity 6.0