Обновление до Unity 6.0
На этой странице перечислены изменения в Unity 6.0, которые могут повлиять на существующие проекты при обновлении их с версии 2022 LTS до Unity 6.0.
- Конвейеры рендеринга
- Свойства радиуса гауссовского фильтра из LightingSettings теперь являются значениями с плавающей точкой
- Улучшение энергосбережения светочувствительного зонда
- Запеченное глобальное освещение Enlighten больше не доступно
- Android: класс Java UnityPlayer необходимо переименовать в UnityPlayerForActivityOrService
- Android: Java-класс UnityPlayer больше не наследует FrameLayout
- Android: Обновление инструментов сборки
- FetchFirstCompatibleTypeUsingScriptableRenderPipelineExtension заменено на GetDerivedTypesSupportedOnCurrentPipeline
- CustomEditorForRenderPipelineAttribute и VolumeComponentMenuForRenderPipelineAttribute устарели
- Освещение окружающей среды: зонд окружающей среды и зонд отражения skybox больше не выпекаются по умолчанию
- Автоматическое освещение удалено
- Графические форматы , DepthAuto, ShadowAuto и VideoAuto устарели
- Пределы Mipmap больше не влияют на текстуры runtime по умолчанию
- Улучшено создание пользовательских контроллеров с UXML
- Меню Assets/Create и ScriptTemplates были реорганизованы
- UI Toolkit реорганизация и упрощение обработки событий
- Изменение расположения буфера в Metal
- Папка Packages в глобальном кэше пакетов больше не используется
- Переменные среды UPM_CACHE_PATH и UPM_NPM_CACHE_PATH больше не поддерживаются
- Изменились версии инструментов по умолчанию Android
- Версия 7-Zip, включенная в Unity Editor, больше не поддерживает сжатие zstandard
- Object.FindObjectsOfType и Object.FindObjectOfType устарели
- Физика: Изменен способ расчета крутящего момента при использовании ForceMode.VelocityChange или ForceMode.Acceleration
Конвейеры отображения
Это руководство по обновлению описывает, как обновить до Unity 6.0 версии Unity Встроенный Render Pipeline. Для обновления других конвейеров рендеринга, см.:
- Модернизация URP
- Модернизация HDRP
Чтобы обновить другие пакеты, ознакомьтесь с документацией к используемым пакетам.
Свойства радиуса гауссовского фильтра от LightingSettings теперь являются значениями с плавающей точкой
Средство Progressive Lightmapper включает вариант Gaussian среди расширенных Продвинутый уровень параметров фильтрации (Lighting Window > Lightmapping Settings > Filtering > Direct Filter > Gaussian). Элемент управления Радиус для фильтрации Gaussian теперь поддерживает дробный шаг, например 0,5. Ранее он поддерживал только целочисленные шаги (от 1 до 5).
В результате этого изменения эти свойства теперь устарели в C# API:
int LightingSettings.filteringGaussRadiusAOint LightingSettings.filteringGaussRadiusDirectint LightingSettings.filteringGaussRadiusIndirect
Замены с плавающей точкой для устаревших свойств:
float LightingSettings.filteringGaussianRadiusAOfloat LightingSettings.filteringGaussianRadiusDirectfloat LightingSettings.filteringGaussianRadiusIndirect
Можно вызвать одну из устаревших функций членов для округления радиуса гауссовского фильтра до ближайшего целого числа.
Улучшение энергосбережения светочувствительного зонда
Световые зонды теперь такие же яркие, как и карты освещения. Раньше световые зонды Unity были только на 94% яркими, как они должны быть. По этой причине объекты, освещенные световыми зондами, выглядели немного темнее, чем объекты, освещенные картами освещения. Из-за тонкости этого изменения, возможно, что многие пользователи не увидят заметной разницы.
Если вы предпочитаете старый вид, вы можете достичь этого следующим образом:
- Печь световые зонды.
- Используйте C# для получения копии массива LightmapSettings.lightProbes.bakedProbes.
- Для каждого экземпляра SphericalHarmonicsL2 умножайте коэффициент 0 на 16/17.
- Запишете свою копию массива обратно в LightmapSettings.lightProbes.bakedProbes.
«Глобальное освещение» больше не доступно.
Базовый модуль Enlighten Baked Global Illumination больше не доступен.
При обновлении проекта до этой версии, Unity удаляет backend Enlighten baking из раскрывающегося списка выбора lightmapper и заменяет Progressive Lightmapper в каждом Scene, где вы выбрали backend Enlighten baking.
На силиконовых устройствах Apple, Unity заменяет Progressive GPU Lightmapper для Enlighten baking backend. На всех других устройствах, Unity выбирает CPU Progressive Lightmapper.
Enlighten предварительно рассчитанный Realtime Global Illumination все еще доступен и поддерживается до Unity 6.
Android: класс Java UnityPlayer необходимо переименовать в UnityPlayerForActivityOrService
UnityPlayer Класс Java заменён двумя новыми классами-мостами: UnityPlayerForActivityOrService и UnityPlayerForGameActivityОба этих новых класса вытекают из UnityPlayer, но открытые методы, такие как displayChanged и windowFocusChanged переехали из UnityPlayer конкретно к UnityPlayerForActivityOrService.
Если вы расширить деятельность по умолчанию Unity и использовать UnityPlayer класс, вы можете столкнуться с ошибками компиляции. В этом случае переименуйте UnityPlayer до UnityPlayerForActivityOrService.
Android: Java-класс UnityPlayer больше не наследует FrameLayout
UnityPlayer Java-класс больше не наследует FrameLayout. Если вам нужен доступ FrameLayout, позвоните getFrameLayout функции на UnityPlayer экземпляр.
Android: Обновление инструментов сборки
Версии инструментов сборки Android для Gradle и Android Gradle Plugin (AGP) обновлены для обеспечения совместимости с последними инструментами разработки Android. Обновленные версии выглядят следующим образом:
| Инструмент | Предыдущая версия | Обновленная версия |
|---|---|---|
| Градль | 8.13 | 9.1.0 |
| AGP | 8.10.0 | 9.0.0 |
Обзор изменений, внесенных этими обновлениями, см. в разделе Что нового в Unity 6.0.
Unity автоматически применяет это обновление в большинстве проектов. Возможно, потребуется внести изменения вручную, если применяется любое из следующих условий:
- Настраиваемые шаблоны Gradle включены в Настройки проигрывателя > Настройки публикации или ваш проект включает
mainTemplate.gradleилиlauncherTemplate.gradle. - В вашем проекте используются старые сторонние плагины, которые не обновляются для обновлений Gradle и AGP.
Для обеспечения плавного перехода в соответствующих случаях следует принять следующие меры:
Если у вас включен пользовательский шаблон Gradle Custom Gradle Template, проверьте файлы
.gradleна наличие устаревших атрибутов. Unity отображает диалоговое окно при сборке, когда обнаруживаются устаревшие атрибуты, и автоматически переименовывает их для использования более новых версий.Проверьте наличие обновлений у сторонних поставщиков SDK, таких как Advertising и Analytics, чтобы убедиться, что они поддерживают AGP 9.0.0.
Для проектов с настраиваемой логикой в шаблонах
.gradleобязательно ознакомьтесь с устаревшим APIs, перечисленным в официальных примечаниях к выпуску AGP.-
Настройте уникальные пространства имен для любых пользовательских плагинов или библиотек Android в вашем проекте. Установите пространство имен в:
AndroidManifest.xml: пакет=“com.example.library.unique”build.gradle: пространство имен “com.example.library.unique”
FetchFirstCompatibleTypeUsingScriptableRenderPipelineExtension заменено на GetDerivedTypesSupportedOnCurrentPipeline
RenderPipelineEditorUtility.FetchFirstCompatibleTypeUsingScriptableRenderPipelineExtension теперь устарел. Используйте GetDerivedTypesSupportedOnCurrentPipeline вместо него. Сигнатура этого метода также изменилась; теперь он возвращает все производные типы, а не только первый, который он встречает. Это предотвращает несоответствия, потому что Unity не гарантирует порядок типов.
CustomEditorForRenderPipelineAttribute и VolumeComponentMenuForRenderPipelineAttribute устарели
CustomEditorForRenderPipelineAttribute и VolumeComponentMenuForRenderPipelineAttribute теперь устарели. Используйте CustomEditor и VolumeComponentMenu вместо них. Чтобы ограничить выбор конвейера, когда эти атрибуты активны, объедините их с SupportedOnRenderPipelineAttribute и укажите тип RenderPipelineAsset. Если вы хотите активировать атрибут SRP, который работает с Встроенным Render Pipeline, используйте SupportedOnRenderPipelineAttribute без параметров. Это обеспечивает унифицированный рабочий процесс для обоих атрибутов, когда возникает необходимость активировать их на конкретном конвейере.
Освещение окружающей среды: зонд окружающей среды и зонд отражения Skybox больше не выпекаются по умолчанию.
UnityПрогрессивный Lightmapper больше не запекает зонд окружающей среды и зонд отражения skybox по умолчанию, и Перерасчет освещения окружающей среды установка в Освещение окно удалено.
Чтобы не допустить отсутствия освещения в новой созданной сцене, Unity назначает по умолчанию Lighting Data Asset, содержащий освещение, которое соответствует материалу skybox по умолчанию.
Вы должны выбрать Создать освещение в окне Освещение в следующих случаях:
- Чтобы исправить освещение в сцене, где вы полагаетесь на предыдущее автоматическое поведение запекания.
- Чтобы увидеть изменения освещения в новой сцене, если вы измените настройки освещения окружающей среды.
Если вы полагаетесь на предыдущее автоматическое поведение печенья, но используете по умолчанию настройки освещения окружающей среды, Unity обновляет сцену для использования по умолчанию Lighting Data Asset.
Автоматически генерируемое освещение удалено
Настройка Auto Generate в окне Освещение была удалена, и соответствующие APIs теперь устарели.
Чтобы создать выпеченное освещение для сцены, можно выполнить любое из следующих действий:
- Выберите Создать освещение в окне Освещение.
- Используйте
Lightmapping.BakeAPI. - Используйте
Lightmapping.BakeAsyncAPI.
Чтобы проверить карты освещения во время редактирования, теперь вы можете выбрать Scene View Draw Mode и установить Lighting Data на Предварительный просмотр. Это отображает предварительный просмотр запеченного освещения. Предварительные карты освещения не деструктивны, и вы можете использовать их после того, как вы запечили сцену.
Если сцена зависит от автоматически генерируемого освещения, то она больше не имеет заготовленного освещения. Выберите Создать освещение в окне Освещение, чтобы перезаготовить освещение вручную.
Если вы используете скрипт для открытия сцены, теперь вы должны использовать Lightmapping.Bake или Lightmapping.BakeAsync вместо ожидания завершения автоматически генерируемого освещения.
Графические форматы DepthAuto, ShadowAuto и VideoAuto устарели
Следующие графические форматы, которые были ранее устаревшими в 2022.1, теперь устарели и вызывают ошибки компиляции, если вы их используете:
GraphicsFormat.DepthAutoGraphicsFormat.ShadowAutoGraphicsFormat.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после построения.
- Использование конструктора с TextureFormat, с
Эти пользователи могут пожелать обновить свои скрипты, если они используют устаревшие конструкторы.
Чтобы обновить ваши скрипты, используйте конструктор Texture2D с конструктором MipmapLimitDescriptor, чтобы указать, что Текстура времени выполнения должна быть затронута настройками качества.
Это изменение было сделано для согласованности с новой поддержкой ограничения mipmap для Texture2DArrays. Вместо того, чтобы каждая текстура определяла свое собственное поведение ограничения mipmap по умолчанию, мы выбрали согласованность и решили, что текстуры времени выполнения должны явно включать ограничения mipmap. Это поведение включения предпочтительнее, чем отключения, потому что текстуры времени выполнения часто используются более универсальными способами, где неожиданная загрузка меньшего количества mips, чем ожидалось, может быть более вредной, чем неожиданная загрузка большего количества mips.
Расширенное создание пользовательских контроля с UXML
Упрощено создание пользовательских контроллеров с UXML в UI Toolkit. Это изменение делает рабочий процесс быстрее и проще в использовании.
Основным улучшением является введение атрибутов UxmlElement и UxmlAttribute. Эти атрибуты упрощают создание атрибутов и автоматически получают имена атрибутов из имен свойств, устраняя необходимость в классах UxmlTraits и UxmlFactory.
Теперь вы можете создание пользовательских конверторов атрибутов для определенных типов данных, обеспечивая бесперебойное преобразование значений в и из строк атрибутов UXML. Мы также улучшили UxmlObjects, что позволяет определять в визуальных элементах пользовательские невизуальные элементы. Новая система использует Unity сериализации и использует генератор исходных кодов для создания UxmlSerializedData классы для элементов из всех UxmlAttribute определения для каждого класса пользовательского элемента, благодаря чему поддерживаются пользовательские отрисовщики свойств, декораторы и различные атрибуты.
Кроме того, введение переопределений атрибутов позволяет повысить гибкость при работе с унаследованными атрибутами, чтобы переопределяли поведение атрибутов UXML. Эти улучшения обеспечивают более эффективный и удобный опыт создания сложных пользовательских контроля в Unity 6.0 и далее.
Дополнительные примеры и сведения см. в Миграция пользовательского контроля из более ранней версии в Unity 6.
Меню «Ассеты/Создать» и ScriptTemplates были реорганизованы
Меню Assets/Create было реорганизовано и разбито на категории. В рамках этого изменения файлы Unity Built-In ScriptTemplate были переименованы.
Пользователи, добавившие элементы в меню Assets/Create с помощью CreateAssetMenuAttribute, MenuItemAttribute или пользовательского ScriptTemplate, могут пожелать изменить приоритет пункта меню, так как его расположение относительно других элементов теперь отличается.
Пользователи, которые создавали ассеты, выполняя эти пункты меню с EditorApplication.ExecuteMenuItem API, должны проверить новый путь к пункту меню.
Пользователям, которые ранее переопределяли встроенные ScriptTemplate в Unity, необходимо обновить имена своих переопределяющих файлов, чтобы они соответствовали новым именам встроенных шаблонов.
UI Toolkit Реорганизация и упрощение обработки событий
Методы ExecuteDefaultAction и ExecuteDefaultActionAtTarget устарели. Для их замены добавлены следующие методы:
HandleEventTrickleDownHandleEventBubbleUp
Unity выполняет эти новые методы на каждом элементе в пути отправки события сразу после TrickleDown и до BubbleUp обратных вызовов этого элемента. Во время этих методов фаза отправки устанавливается на TrickleDown или BubbleUp соответственно, а currentTarget события совпадает с элементом, выполняющим метод.
Фаза отправки AtTarget и метод PreventDefault устарели. Вызов StopPropagation или StopPropagationImmediately теперь прекращает дальнейшее выполнение HandleEventTrickleDown и HandleEventBubbleUp одновременно с прекращением дальнейшего вызова обратных вызовов TrickleDown и BubbleUp.
В большинстве случаев, если вы не обновляете свой код до новых методов, ваш код не должен существенно менять свое поведение. UI Toolkit по-прежнему вызывает устаревшие методы в том же порядке, что и раньше, или с минимальными изменениями. Однако все стандартные контроллеры в UI Toolkit перешли на использование новых методов, соответственно изменив порядок выполнения их логики. Смешивание вызовов устаревших методов с использованием обновленных контроллеров может привести к некоторой логике, которая не синхронизирована по сравнению с предыдущими версиями Unity.
Чтобы обновить существующий код до новых методов, выполните следующие действия:
- Замените
ExecuteDefaultActionиExecuteDefaultActionAtTargetнаHandleEventBubbleUpиPreventDefaultнаStopPropagation(или удалите вызовPreventDefault, еслиStopPropagationуже был вызван в том же блоке кода). Это покрывает большинство случаев. - Если у вас возникли проблемы из-за вызова старого кода
PreventDefaultво время обратного вызоваBubbleUp, который больше невозможен и не может быть заменен StopPropagation, потому что событие уже достигло своей цели, рассмотрите возможность добавления обратного вызова во время фазыTrickleDownдля вызоваStopPropagation. Этот шаг, как правило, достаточен для решения таких сценариев. - В редких случаях, когда вышеупомянутые изменения не достаточны для сохранения функциональности старого кода, необходим тщательный анализ каждого конкретного случая. Решение может быть не всегда простым в этих контекстах.
Изменения расположения буфера в Metal
Перекрестная компиляция шейдеров Unity с шейдерами Metal изменилась в отношении расположения буферов. Любой буфер, содержащий типы min16float, half или real, теперь имеет другое расположение памяти по сравнению с предыдущими версиями Unity.
Вам нужно действовать только в том случае, если вы нацеливаетесь на Metal и используете APIs, которые записывают необработанные данные непосредственно в буферы, например:
Вам не нужно действовать, если вы используете только CommandBuffer.SetComputeFloatParam или Material.SetFloat.
Более конкретно, HLSL, min16float, half и real inside buffers всегда преобразуются в 32-битный MSL float, тогда как в предыдущих версиях Unity они могли быть преобразованы в 16-битный MSL half, в зависимости от целевой платформы.
Если вы тестировали ваши шейдеры только на платформах Metal, проверьте буферы в сгенерированном коде MSL, чтобы убедиться, что макет соответствует данным буфера, доступным в C#. Вы можете проверить, влияет ли это изменение на ваши шейдеры, добавив #pragma metal_fxc_allow_float16_in_cpu_visible_buffers в ваш код шейдера и посмотреть, исправлены ли какие-либо визуальные артефакты. Если вы заметите разницу, удалите эту прагму и настройте свой шейдер и код C# так, чтобы он работал правильно без прагмы, чтобы улучшить межплатформенную совместимость вашего проекта.
Чтобы использовать в буферах 16-битные числа с плавающей запятой, рассмотрите возможность использования компилятора DXC HLSL и добавления #pragma require Native16Bit в ваш шейдер. Но обратите внимание, что использование DXC в Unity все еще находится на экспериментальной стадии.
Папка Packages в глобальном кэше пакетов больше не используется
Глобальный кеш пакетов содержит несколько вложенных папок. Одна из них, packages, больше не используется Package Manager.
Вам нужно действовать только в том случае, если у вас есть скрипты автоматизации или конвейеры, которые взаимодействуют непосредственно с глобальным кэшем пакетов. packages подпапку, например, если вы используете UPM_CACHE_PATH экологическая переменная. Если да, то вы можете удалить ссылки. Unity не предлагает прямую замену подпапку для packages. Теперь пакеты извлекаются непосредственно в кэш проекта.
Если вы больше не поддерживаете проекты, созданные с помощью Unity 2023.2, вы можете безопасно удалить подкаталог packages из корня глобального кэша пакетов. Эта операция необязательна.
Переменные среды UPM_CACHE_PATH и UPM_NPM_CACHE_PATH больше не поддерживаются
Предыдущие версии Unity Editor поддерживали следующие переменные среды:
UPM_CACHE_PATH, чтобы указать абсолютный путь к расположению, в котором вы хотите, чтобы Package Manager хранил несжатое содержимое тарбаллов пакетов.UPM_NPM_CACHE_PATH, чтобы указать абсолютный путь для кэша данных реестра Package Manager.
Вы должны действовать только в том случае, если у вас есть скрипты автоматизации или конвейеры, которые устанавливают значения пути для UPM_CACHE_PATH или UPM_NPM_CACHE_PATH:
- Замена
UPM_CACHE_PATHневозможна, так как пакеты теперь извлекаются непосредственно в кэш проекта. Однако вы можете использовать переменную окруженияUPM_CACHE_ROOTдля установки корня глобального кэша. Обратите внимание, что корень глобального кэша является родительским каталогом подпапки, ранее связанной сUPM_CACHE_PATH. - Нет замены для
UPM_NPM_CACHE_PATH. Однако, вы можете использоватьUPM_CACHE_ROOTпеременную окружения, которая является родительским каталогом дляUPM_NPM_CACHE_PATH. ИспользуйтеUPM_CACHE_ROOTвместоUPM_NPM_CACHE_PATHи настройте значения в ваших скриптах или конвейерах.
Дополнительные сведения см. в Настройка глобального кэша.
Изменились версии инструментов по умолчанию Android
Unity обновил версии по умолчанию следующих инструментов, используемых Android. Версии по умолчанию NDK, SDK Command Line Tools и SDK Tools остаются без изменений. Обновленные версии выглядят следующим образом:
| Инструмент | Версия |
|---|---|
| Градль | 8.4 |
| Android Плагин Gradle | 8.3.0 |
| SDK Инструменты построения | 34.0.0 |
| SDK Инструменты платформы | 34.0.5 |
| Комплект разработки Java (JDK) | 17 |
Если ваш проект использует пользовательские шаблоны Gradle, рассмотрите воссоздание этих шаблонов, чтобы избежать любых проблем построения с обновленной Android Версия плагина Gradle. Дополнительные сведения см. в Изменение файлов проекта Gradle с файлами шаблона Gradle.
Версия 7-Zip, включенная в Unity Editor, больше не поддерживает сжатие zstandard
Предыдущие версии Unity Editor включали форк 7-Zip, поддерживающий сжатие zstandard:
Версии Windows включали 7-Zip-zstd, форк mcmilk/7-Zip-zstd, который является форком версии 7-Zip 22.01. Этот код уязвим для нескольких известных проблем безопасности, таких как CVE-2023-31102 и CVE-2023-40481.
Версии macOS и Linux включали p7zip-zstd, форк tehmul/p7zip-zstd (заброшен в 2017 году), который является форком p7zip (заброшен в 2016 году), который является форком 7-Zip. Этот код уязвим для нескольких известных проблем безопасности, таких как CVE–2016–7804, CVE–2017–17969, CVE–2018–10115, CVE–2018–10172, CVE–2018–5996, CVE–2023–31102 и CVE–2023–40481.
Unity 6.0 включает в себя обычную версию 23.01 7-Zip для редакторов Windows, macOS и Linux. Однако эта версия 7-Zip не поддерживает zstandard сжатие или декомпрессию для .zip или.7z архивов. Она также не поддерживает дополнительные форматы сжатия и алгоритмы хеширования, добавленные в mcmilk/7-Zip-zstd.
Если у вас есть пакеты, использующие двоичные файлы 7za или 7z.exe, которые работают на архивах с использованием сжатия zstandard, используйте один из следующих вариантов:
- Используйте альтернативный формат сжатия, например, архивы .zip с использованием алгоритма deflate или архивы.7z с использованием LZMA или LZMA2.
- Предоставьте свои собственные двоичные файлы, поддерживающие требуемые форматы архивов и алгоритмы сжатия.
Object.FindObjectsOfType и Object.FindObjectOfType устарели
Object.FindObjectsOfType теперь устарел. Используйте Object.FindObjectsByType вместо него.
Object.FindObjectOfType теперь устарел. Используйте Object.FindFirstObjectByType или Object.FindAnyObjectByType вместо этого.
Эти устаревшие функции автоматически сортировали результаты по экземпляру ID, прежде чем возвращать их вам. Этот процесс занимает много времени, особенно если список объектов большой (например, более 100 объектов).
Новые функции ByType принимают режим сортировки (FindObjectsSortMode) в качестве параметра. Выбор передачи в FindObjectsSortMode.InstanceID ведет себя так же, как и раньше, и возвращает объекты, отсортированные по экземпляру ID. Если вы вместо этого передаете в FindObjectsSortMode.None, список возвращается несортированным, что может быть значительно быстрее. Рекомендуется использовать FindObjectsSortMode.None.
Физика: Изменен способ расчета крутящего момента при использовании ForceMode.VelocityChange или ForceMode.Acceleration
Rigidbody.AddForceAtPosition и Rigidbody.AddExplosionForce теперь применяют другое количество крутящего момента при использовании ForceMode.VelocityChange или ForceMode.Acceleration, чем они делали в Unity 2022 LTS и раньше. Это является результатом исправления математической ошибки, вызванной умножением угловых сил на массу, что было неправильно. Теперь приложенная сила масштабируется по матрице тензора инерции.
Если изменение величины крутящего момента влияет на ваш проект, вы можете воссоздать логику, использованную в Unity 2022 и предыдущих версиях. Обновите методы, чтобы умножить силу на массу тела, а затем переключите ForceMode.Acceleration на ForceMode.Forceи ForceMode.VelocityChange на ForceMode.Impulse. Например:
| До | После |
|---|---|
body.AddForceAtPosition(force, pos, ForceMode.Acceleration) |
body.AddForceAtPosition(force * body.mass, pos, ForceMode.Force) |
body.AddForceAtPosition(force, pos, ForceMode.VelocityChange) |
body.AddForceAtPosition(force * body.mass, pos, ForceMode.Impulse) |
body.AddExplosionForce(force, pos, radius, up, ForceMode.Acceleration) |
body.AddExplosionForce(force * body.mass, pos, radius, up, ForceMode.Force) |
body.AddExplosionForce(force, pos, radius, up, ForceMode.VelocityChange) |
body.AddExplosionForce(force * body.mass, pos, radius, up, ForceMode.Impulse) |