trofch1k

Ассинхронная загрузка ассетов.

2020-08-10T11:22:51.452Z

Оригинал: https://docs.unrealengine.com/en-US/Programming/Assets/AsyncLoading/index.html

Unreal Engine 4.9

В UE4 появилось несколько новых систем, сильно упрощающих ассинхронную загрузку ассетных данных. Они заменяют большую часть функционала "seekfree" пакетов в UE3. Новые методы работают одинаково, как при разработке так и с подготовленными данными уже на устройстве пользователя. Такми образом, вам не нужно поддерживать две ветви кода. Существуют два основных метода для загрузки и ссылания на данные.

FSofObjectPaths и TSoftObjectPtr

Самый простой способ сослаться на ассет для дизайнера или художника — это создать строгий указатель на UProperty и присвоить ему категорию. В UE4 если у вас есть строгий указатель на UObject, который верно ссылается на ассет, то этот ассет будет загружен вместе с объектом, содержащим этот ассет путём размещения объекта на карте или ссылание на ассет из чего-то наподобие gameinfo. Если вы не будете соблюдать осторожность, то можете загрузить сразу все 100% ваших ассетов во время загрузки вашей игры. Если вы хотите, чтобы дизайнеры могли создавать ссылки на конкретные ассеты, используя тот же интерфейс, что и в случае со строгим указателем, используйте FSofObjectPaths и TSoftObjectPtr.

FSofObjectPaths — это простая структура, содержащая строку с полным именем ассета. Если вы создадите поле этого типа в классе, то оно появится в редакторе, как если бы это было поле типа UObject*. Также, она корректно поддерживает кукинг и редиректы, так что если у вас есть SoftObjectPath, то она гарантировано будет работать на устройстве пользователя. TSoftObjectPath — это практически TWeakObjectPtr, который является враппером FSoftObjectPath и будет шаблоном конкретного класса, чтобы можно было разрешить выбирать в редакторе только конкретные классы. Если ассет на который ссылаются существует в памяти, TSoftObjectPtr.Get() вернёт его. Если нет, то вы можете вызвать TSoftObjectPath(), чтобы найти ассет на который он ссылается, загрузить его, используя метод ниже, а затем снова вызвать TSoftObjectPtr.Get(), чтобы разыменовать его.

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

Реестр ассетов и Библиотеки объектов

Реестр ассетов — это система, которая хранит матаданные об ассетах и позволяет создавать запросы об этих ассетах. Она используется в редакторе для вывода информации в браузере контента, но ещё её можно использовать из геймплейного кода для создания запросов метаданных о незагруженных ассетах. Чтобы метаданные ассета отображались при поиске, нужно дабавить тег AssetRegistrySearchable в свойства. Запросы к реестру ассетов возвращают объекты типа FAssetData, содержащие информацию об объекте и карту с парами формата ключ->значение, содержащими свойства, помеченные как доступные для поиска.

Самый простой способ работы с группами незагруженных ассетов — это использование Object Library. Object Library — это объект, содержащий список загруженных объектов или FAssetData для незагруженных объектов, который наследует от общего класса. Для загрузки библиотеки объектов нужно дать ей путь, по которому она будет искать, что в свою очередь добавит все ассеты по этому пути. Это может быть очень полезно, потому что так можно назначать отдельные части вашей контентной папки для разных видов контента, и ходожники и дизайнеры смогут доавлять ассеты без необходимости редактировать список ассетов. Ниже приведён пример загрузки данных ассетов с диска, используя библиотеку объектов.

if (!ObjectLibrary)
{
        ObjectLibrary = UObjectLibrary::CreateLibrary(BaseClass, false, GIsEditor);
        ObjectLibrary->AddToRoot();
}
ObjectLibrary->LoadAssetDataFromPathy(TEXT("/Game/PathWithAllObjectOfSameType"));
if (bFullyLoad)
{
        ObjectLibrary->LoadAssetsFromAssetData();
}

В этом примере создаётся новая библиотека объектов, связывается с базовым классом и загружает все данные ассетов, найденные по указаннному пути. Затем опционально загружаются сами ассеты. Следует полностью загружать ассеты либо если они лёгкие, либо если вы занимаетесь кукингом и вам нужно убедиться, что все ассеты действительно "кукнулись". Пока вы выполняете запрос реестру ассетов во время кукинга и загружаете возвращённые ассеты, библиотека объектов будет работать с "кукнутыми" данными на устройстве пользователя в точности, как при разработке. С момента, как у вас есть данные ассетов в ObjectLibrary, вы можете создавать запросы и выборочно загружать определённые ассеты. Ниже приведён пример создания запроса.

TArray<FAssetData> AssetDatas;
ObjectLibrary->GetAssetDataList(AssetDatas);

for (int32 i = 0; i < AssetData.Num(); ++i)
{
        FAssetData& AssetData = AssetDatas[i];

        const FString* FoundTypeNameString = AssetData.TagsAndValues.Find(GET_MEMBER_NAME_CHECKED(uaSSEToBJECT, tYPEnAME));

        if (FoundTypeNameString && FoiundTypeNameString->Contains(TEXT("FooType")))
        {
                return AssetData;
        }
}

В этом примере происходит поиск по библиотеке объектов чего либо, где поле TypeName содержит "FooType". Возвращается первый найденный экземпляр. После получения AssetData, можно вызвать ToStringReferece() чтобы конвертировать её в FSoftObjectPath, который можно будет загружать ассинхронно.

StreamableManager и Асинхронная загрузка

Теперь когда у вас есть FSoftObjectPath, который ссылается на ассет на диске, как его можно загрузить асинхронно? Использование FStreamableManager — простейший способ сделать это. Для начала вам нужно будет создать FStreamableManager. Я бы советовал поместить его во что-то на подобие глобального для игры синглтон объекта, например определённого с помощью GameSingletonClassName в DefaultEngine.ini. Затем ему можно передать FSoftObjectPath и начать загрузку. SynchronousLoad произведёт обычную блокирующую загрузку (игра остановиться до завершения загрузки) и вернёт ассет. Этот метод может подойти для легковесных объектов, однако в некоторых случаях может остановить главный поток слишком надолго. В таком случае нужно будет использовать ReqestAsynchLoad, который асинхронно загрузит группу ассетов и вызовет делегата по завершению. Ниже приведён пример.

void UGameCheatManager::GrantItems()
{
        TArray<FSoftObjectpath> ItemsToStream;
        FStreamManager& Streamable = UGameGlobals::Get().StreamManager;
        for (int32 i = 0; i < ItemList.Num(); ++i)
        {
                ItemsToStream.AddUnique(ItemList[i].ToStringReference());
        }
        Streamable.RequestAsynchLoad(ItemsToStream, FStreamableDelegate::CreateUObject(this, &UGameCheatManager::GrantItemsDeffered));
}

void UGameCheatManager::GrantItemsDeffered()
{
        for (int32 i = 0; i < ItemList.Num(); ++i)
        {
                UGameData* ItemData = ItemList[i].Get()
                if (ItemData)
                {
                        MyPc->GrantItems(ItemData);
                }
}

В этом примере ItemList является TArray&lt, который содержит TSoftObjectPath<UGameItem>, который был модифицирован дизайнерами в редакторе. Код итерирует список и конвертирует TSoftObjectPath<UGameItem> в StringReference и ставит их в очередь на загрузку. Когда все эти предметы загружены (или отсутствуют и не могли быть загружены), вызывается переданный ранее делегат. Этот делегат затем итерирует тот же список предметов, разыменовывает их и передаёт игроку. StreamableManager хранит строгие ссылки на любой загруженный им ассет, пока не будет вызван делегат, чтобы вы могли быть уверены, что ни один из объектов, которых вы хотели асинхронно загрузить не будут удалены сборщиком мусора до того как будет вызван делегат. StreamableManager перестаёт хранить ссылки после вызова делегата, так что вам нужно строго ссылаться на объекты где-нибудь в другом месте, чтобы удостовериться, что они остануться под рукой.

Вы можете использовать тот же самый метод для загрузки FAssetData, просто вызовите для них (FAssetData) ToStringReference и поместите их в массив, затем вызовите RequestAsynchLoad вместе с делегатом. Делегат может быть чем угодно, так что вы можете передать информацию о пейлоэде, если это необходимо. Путём комбинирования выше описанных методов вы можете создать систему, позволяющую эффективно загружать любые ассеты в вашу игру. Переписывание геймплейного кода, использующего прямые обращения к памяти под использование асинхронной загрузки займёт время, но в итоге ваша игра будет иметь меньше простоев и будет использовать намного меньше памяти.

Что такое стабилизация отдачи в Call of Duty: Modern Warfare 2019

2020-07-20T20:38:27.579Z

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

Введение

Привет. Как вы наверное поняли из названия речь пойдёт о том, что такое стабилизация отдачи (recoil stabilization в английской версии) в CoD:MW19 и как она работает. Написанное в этой статье идёт в разрез с общепринятым мнением в англоязычном сообществе, будто бы стабилизация влияет на горизонтальную отдачу, хотя на самом деле она влияет на вертикальную отдачу и не только на неё. В начале будет небольшая теоретическая часть и описание методов тестирования, а потом мы перейдём к делу.

Теория

В большинстве современных шутеров используется модель отдачи подразумевающая наличие подброса ствола согласно паттерну отдачи, прописаному гейм-дизайнером, и разлёта пуль. Как вы могли заметить оружие в Modern Warfare ведёт себя немного по-другому, каждый раз, когда вы из него стреляете.

Проще всего это описывается так. Представьте паттерн отдачи (красный на картинке ниже). Точки на этом паттерне (синие), мы назовём эталонными точками попаданий. Оружие бросает от одной точки к следующей. Теперь представьте круг вокруг каждой из точек (зелёный). Размер такого круга будет показывать как сильно может отклониться пуля от своей эталонной точки. Наконец, главная особенность этой модели — это влияние разброса на отдачу оружия. Если пуля решит отклониться влево от своей эталонной точки, то и ствол оружия бросит немного левее эталонной точки. Если пуля уйдёт ниже, тогда вы почувствуйте меньше вертикальной отдачи и наоборот. (фиолетовый - пример одного из паттернов который может получиться). Такая модель используется в Insurgency: Sandstorm, Rainbow Six: Seige, Valorant и даже разработчики Battlefield 5 отказались от модели с "прокликом" оружия в её пользу. В серии Call of Duty — это Modern Warfare 2019, Black Ops 4 и WW2, но на счёт последней я не уверен.

Методы тестирования

Перед тем как я покажу результаты я должен описать методы тестирования, чтобы избежать недопонимания в будущем.

Для тестов я использовал следующие сборки. Три АК в 7.62х39, каждый из которых имеет "бубен" на 75 патронов, демонтированный приклад и ствол длинной 8.1 дюйма. Первй АК был оставлен как есть. Второй получил компенсатор и рукоять наёмника. На третий были установлены дульный тормоз и рукоять угловая рукоятка.

Стоя перед стеной, я выстрелил столько очередей, сколько мог на ней уместить. Затем я сделал скриншот стены и перенёс его в Фотошоп, где отметил первую и пятую пулю в каждой очереди. Затем я совместил пометки для каждой очереди наложив друг их друг на друга, выровняв по первой пуле.

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

Результаты

Ниже вы можете видеть группы каждого из трёх АК.

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

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

Наконец, версия с угловой рукояткой и дульным тормозом имеет вертикальную отдачу равную "control" версии. Хорошо видно, что пули как бы "сжимаются" к определённой точке (синия точка по центру, хорошо видно, что края группы более прозрачные т.к. там меньше пуль наслаивается друг на друга). Я очень сомневаюсь, что такое поведение случайно, ведь мы протестировали аж три сборки и взяли по тридцать образцов для каждой, но такие результаты показала только одна. Таким образом можно сделать вывод, что стабилизация отдачи влияет на фактор случайности в отдаче. Простым языком, стабилизация уменьшает размер зелёных кругов (т.е. разброс) из теоретической части и заставляет пулю "стремиться" к центру своего круга.

Дополнение

Очевидно, что случайность отдачи было бы куда лучшим названием для того, что Infinity Ward нарекли стабилизацией. Тем не менее нам всё ещё интересно, почему уменьшая случайность мы так же уменьшаем вертикальную отдачу.

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

На практике

После прочтения прошлых разделов, может показаться, что стабилизация во всём лучше контроля, но на практике всё немного по-другому. В этот раз я исаользовал два АК в 7.62х39 с треугольным рамочным прикладом. Первый имел компенсатор и рукоять наёмника (слева на картинке), второй — дульный тормоз и угловую рукоятку (справа). Из каждого я выстрели по две очереди по 15 патронов, и результаты оказались неотличимы.

Заключение

Я протестировал лишь один ствол с всего лишь двумя наборами улучшений. Такая небольшая выборка говорит лишь о том, что вложение в стабилизацию при создании сборки не является плохим решением. Однако, мой метод тестирования может вдохновить безумцев в сообществе Call of Duty на проведение более масштабных тестов. Так же мой метод может помочь ютюберам, делающим обзоры оружия, при добавление в игру новых образцов.

Как уже подметил u/CanadianTuero на Редите, метод не совсем правильный. Хоть стрельбы и ведётся всегда перпендикулярно стене, но положение обзор "камеры при скриншоте не перпендикулярен каждой очереди, а потому может возникнуть искажение перспективы в случае с образцами на боковых границах стены, что в конечном итоге приведёт к неточности тестирования. Насколько велика эта неточность мне неизвестно, но я пологаю, что она не настолько большая чтобы невелировать результаты моих тестов.

Спасибо, что дочитали до сюда. Всем добра.

Лабораторная работа #2 Проектирование БД

2020-04-16T19:43:30.184Z

Предметная область

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

Словестное описание

На складе бывают несколько видов тканей. Каждая сущность такой ткани содержит: код, название, площадь в одном рулоне, код фабрики - производителя.

Ткани хранятся на складе: код ткани, количество рулонов на складе.

Каждый вид ткани производит одна или несколько фабрик: код, название, страна.

В каждом виде ткани испытывает потребность закупщики - предприятия из России: код, название, город.

На основании данных со склады и запросов производящих предприятий составляется список запросов на ткань по каждому предприятию: код запроса, код предприятия, код запрашиваемой ткани, количество в рулонах, статус заказа (ожидется поступление на склад импортёра, отправлен, подтверждено получение).