СОДЕРЖАНИЕ

CПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ .............................. 8

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ ................................................................................. 9
ВВЕДЕНИЕ ................................................................................................................ 10
1 ОБЗОР ПРЕДМЕТНОЙ ОБЛАСТИ ..................................................................... 11
1.1 Постановка задачи ........................................................................................... 11
1.2 Обзор существующих решений ...................................................................... 11
1.2.1 Camera Mouse ............................................................................................. 11
1.2.2 Head Mouse ................................................................................................. 11
1.2.3 Продукты компании Tobii ......................................................................... 12
1.2.3.1 Tobii EyeX ................................................................................................ 12
1.2.3.2 Tobii Pro Glasses ...................................................................................... 12
1.2.4 Enable Viacam ............................................................................................. 13
1.3 Почему OpenCV? ............................................................................................. 14
1.4 Модульная система UE 4................................................................................. 14
1.5 Система плагинов в UE 4 ................................................................................ 16
1.5.1 Содержание плагина .................................................................................. 16
1.5.2 Папка плагина ............................................................................................ 17
1.5.3 Код плагина ................................................................................................ 17
1.5.4 Плагины движка ......................................................................................... 19
1.5.5 Плагины проекта ........................................................................................ 20
1.5.6 Файлы дескрипторов плагинов ................................................................ 20
1.6 Обзор основных классов и зависимостей ...................................................... 20
1.6.1 UObject ........................................................................................................ 21
1.6.2 AActor .......................................................................................................... 21
1.6.3 APawn .......................................................................................................... 21
1.6.4 ACharacter ................................................................................................... 21
1.6.3 UActorComponent ....................................................................................... 22
1.6.4 APlayerController ........................................................................................ 22
1.6.5 AHUD .......................................................................................................... 22
1.6.6 UGameInstance ............................................................................................ 22

6
 1.7 Обзор игрового процесса ................................................................................ 23
1.7.1 Автономный режим ................................................................................... 25
1.7.2 Режим редактора ........................................................................................ 25
1.8 Распознавание ключевых точек лица............................................................. 25
1.8.1 Использованные инструменты ................................................................. 25
1.8.2 Вывод формул для распознавания жестов лица ..................................... 26
2 Разработка модуля.................................................................................................. 30
2.1 Файловая структура модуля............................................................................ 30
2.2 Связка UE 4 и OpenCV .................................................................................... 30
2.3 Реализация работы плагина в системе Unreal Engine 4 ............................... 31
2.4 Система валидации жестов ............................................................................. 35
2.5 Описание работы класса считывания и обработки изображения с веб-
камеры ..................................................................................................................... 36
2.6 Реализация пользовательского интерфейса .................................................. 38
2.6.1 Описание элементов пользовательского интерфейса ............................ 39
2.6.2 Взаимодействие пользовательского интерфейса с системой ................ 39
2.7 Реализация симуляции мыши ......................................................................... 40
3. Эксперименты........................................................................................................ 41
3.1 Выборка пороговых значений ........................................................................ 41
3.2 Калибровка........................................................................................................ 43
ЗАКЛЮЧЕНИЕ ......................................................................................................... 45
СПИСОК ЛИТЕРАТУРЫ......................................................................................... 46

7
 CПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ
ИИ – искусственный интеллект
BAR – brows aspect ratio
EAR – eye aspect ration
MAR – mouth aspect ration
PIE - Play In Editor
SIE - Simulate In Editor
UBT – UnrealBuildTool
UE 4 – Unreal Engine 4

8
 ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
Актёры – экземпляры класса AActor
Пешки – экземпляры класса APawn
Персонажи – экземпляры класса ACharacter
Blueprint - система визуального программирования в Unreal Engine
UnrealBuildTool - это настраиваемый инструмент, который управляет процессом
создания исходного кода UE4 в различных конфигурациях сборки

9
 ВВЕДЕНИЕ
В настоящее время не редкостью являются случаи, когда человек не может
управлять своим компьютером посредством стандартных решений вроде
клавиатуры и мыши. На данный момент таким людям приходится пользоваться
самодельными устройствами или находить нетривиальные способы
использования стандартных решений. Моя работа предлагает одно из решений
данной проблемы, которая поможет облегчить управление компьютером во
время игры.

Данное решение предлагает получать входные данные для управления

мышью через веб-камеру, которая в пору пандемии есть практически у каждого.
Решение разработано в виде плагина для проекта с использованием Unreal Engine
4 версии 25.4, что позволит переносить модуль управления в другие проекты с
минимальным количеством действий.

10
 1 ОБЗОР ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Постановка задачи
Реализовать плагин для UE 4, чтобы использовать его в дипломном
проекте. Реализовать систему настройки работы, автокалибровки и валидации
работы плагина.

1.2 Обзор существующих решений

На сегодняшний день существует несколько решений для замены мыши
полностью или частично:

1.2.1 Camera Mouse

Работа данной программы основывается на определении контрольной
области изображения с веб-камеры. Такой областью обычно используется какая-
нибудь яркая метка. Положение курсора нестабильно, курсор часто “дребезжит”
даже при статичном положении лица. Для хорошей работы программы требуется
хорошая камера, а также чтобы лицо пользователя было достаточно хорошо
освещено.

Рисунок 1 - Пример работы Camera Mouse

1.2.2 Head Mouse
Программа, разработанная сотрудниками Университета Лериды
(Испания). Имеются недостатки в точности управления курсором, однако есть
автокалибровка, которая запускается при каждой паузе или после заданного
временного интервала. Можно настроить скорость движения курсора,
11
отзеркалить движения, а также есть возможность идентифицировать команды с
помощью глаз пользователя или губ. В углу экрана отображается картинка с веб-
камеры, по которой можно судить о том, насколько правильно ориентировано
лицо пользователя.

Рисунок 2 - Пример работы Head Mouse

1.2.3 Продукты компании Tobii
1.2.3.1 Tobii EyeX
Tobii EyeX – это трекер, который обеспечивает связь пользователей с
персональным компьютеров. Камеры отслаивают положение глаз человека для
определения положения курсора. Недостатком данного решения является сам
трекер, так как его нужно покупать. Пользователи отмечают крайнюю усталость
глаз после непродолжительного использования, так как для отслеживания глаз
используются камеры с инфракрасной подсветкой. Кроме того, данное
устройство поддерживается далеко не во всех играх и не предусматривает замену
мыши полностью, но уменьшает количество движений мыши.

1.2.3.2 Tobii Pro Glasses

Pro Glasses фиксируются на голове пользователя и вычисляют точку на
мониторе, на которую смотрит пользователь. Это довольно удобно, однако для
точного вычисления голова пользователя должна находиться на определённом
месте перед экраном, а выход за неё приводит к сильному снижению точности
вычисления. Эти очки также не предусматривают полной замены мыши.
12
 1.2.4 Enable Viacam
Enable Viacam (eViacam) — программа, заменяющая использование
компьютерной мыши на управление при помощи движений головы
пользователя, отслеживаемых обычной веб-камерой.

Встроенный мастер настройки Enable Viacam дает возможность подобрать

оптимальную чувствительность движка и сконфигурировать основные функции
под физиологические особенности пользователя. Программа может имитировать
нажатия клавиш на виртуальной клавиатуре. Реализована эмуляция нажатия
клавиш мыши: левой, средней, правой; способы управления: двойное нажатие,
Drag-and-drop. Используемые компоненты OpenCV и wxWidgets.

Рисунок 3 - Пример работы в Enable Viacam

Таблица 1 - Сравнение решений

Есть Детекция Не требуют Полная Не

автокалибровка жестов дополнительного замена вызывает
оборудования мыши сильной
усталости
от работы

13
Camera - - + + +
Mouse
Head + + + + +
Mouse
Tobii + - - - -
EyeX
Tobii + - - - -
Pro
Glasses
Enable + + + + +
Viacam

1.3 Почему OpenCV?

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

1.4 Модульная система UE 4

Модули — это строительные блоки UE 4. Движок реализован в виде
большого набора модулей, и игры предоставляют свои собственные модули для
их дополнения. Каждый модуль инкапсулирует набор функций и может
предоставлять открытый интерфейс и среду компиляции (с макросами, путями
включения и т. Д.). Это означает, что у нас есть возможность поделить наш код
на абстрактные секции и сделать его более многоразовым и структурированным.
Кроме того, при сборке игры есть код, который в игре не используется, а
требуется только для редактора UE 4, в этом нам также помогает модульная
система.

14
 Модули объявляются через файлы C# с расширением .build.cs и хранятся в
папке с исходным кодом вашего модуля. Исходный код C++, принадлежащий
модулю, хранится рядом с файлом .build.cs или в его подкаталогах. Каждый файл
.build.cs объявляет класс, производный от базового класса ModuleRules, и задает
свойства, управляющие тем, как он должен быть построен из его конструктора.
Эти файлы .build.cs (Листинг 1) компилируются с помощью UBT и создаются
для определения общей среды компиляции.

Листинг 1 – Пример содержания файла .build.cs модуля.

using UnrealBuildTool;
using System.Collections.Generic;
public class MyModule : ModuleRules
{
public MyModule(ReadOnlyTargetRules Target) :
base(Target)
{
// Settings go here
}
}
У модуля есть параметр, который определяет куда следует включать
модуль, а куда нет:

1. Runtime,
2. RuntimeNoCommandlet,
3. Developer,
4. Editor,
5. EditorNoCommandlet,
6. Program.
Также у модуля есть параметр LoadingPhase, который определят стадию
загрузки модуля:

1. Default,
2. PostDefault,
3. PreDefault,
4. PostConfigInit,
5. PreLoadingScreen,
6. PostEngineInit.

Любой модуль обязательно имеет 3 файла:

15
 1. заголовочный файл этого модуля <Имя модуля>.h, в нём
располагается интерфейс модуля, объявляются методы старта и конца работы
модуля,
2. исходный файл <Имя модуля>.cpp. В нём, соответственно,
находится определение методов старта и конца работы модуля и совершается
дополнительная работа, например, объявляется новая категория логирования,
3. <Имя модуля>.Build.cs - в этом файле мы подключаем модули,
необходимые для работы нашего модуля.

1.5 Система плагинов в UE 4

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

1.5.1 Содержание плагина

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

Плагины с кодом будут иметь папку Binaries, которая содержит

скомпилированный код для этого плагина, а временные файлы продукта сборки
будут храниться в отдельной папке Intermediate в каталоге плагина.

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

файлы ресурсов, специфичные для этого плагина. Файлы конфигурации плагина
следует размещать в соответствии с тем же соглашением, что и другие файлы
конфигурации:
16
 1. Плагины движка: [PluginName]/Config/Base[PluginName].ini,
2. Плагины игры: [PluginName]/Config/Default[PluginName].ini.

1.5.2 Папка плагина

Чтобы плагины были найдены, они должны быть расположены в одном из
путей поиска плагинов в вашем проекте или в самом движке (Табл. 2).

Таблица 2 - Расположение папки плагина по типу плагина

Тип плагина Необходимое расположение

Engine /[UE4 Root]/Engine/Plugins/[Plugin

Name]/

Game /[Project Root]/Plugins/[Plugin Name]/

Вы также можете организовать плагины в подкаталоги в базовой папке

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

Unreal Engine находит ваш плагин путем поиска файлов. uplugin на диске.
Эти файлы называются дескрипторами плагинов. Это текстовые файлы,
содержащие основную информацию о вашем плагине. Дескрипторы плагинов
обнаруживаются и загружаются автоматически движком, редактором и UBT при
каждом запуске этих программ.

1.5.3 Код плагина

При создании файлов проекта для Visual Studio или Xcode любые
подключаемые модули, имеющие папки с кодом, будут добавлены в файлы
вашего проекта, чтобы упростить переход к их исходному коду. Эти плагины
будут автоматически скомпилированы UBT при компиляции вашего игрового
проекта.

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

По большей части макет исходного файла плагина такой же, как и у любого
другого модуля C++ в движке.

Плагины могут объявлять новые типы (UCLASS, USTRUCT и т. д.),

которые регистрируют новые сущности в системе. В файлах заголовков в
исходном каталоге модуля (или в одном из его подкаталогов). Система сборки
обнаружит эти файлы и при необходимости сгенерирует код для поддержки
новых типов.

UE 4 поддерживает взаимозависимые модули и плагины. Модули проекта

могут зависеть от подключаемых модулей, включив подключаемые модули в его
файле .uproject. Точно так же плагины указывают на зависимость, разрешая
другие плагины в их собственных файлах .uplugin. Однако есть одно важное
ограничение: плагины и модули разбиты на иерархические уровни (Рис. 4) и
могут зависеть только от других подключаемых модулей или модулей того же
или более высокого уровня. Например, хотя модуль проекта может зависеть от
модуля двигателя, модуль двигателя не может зависеть от модуля проекта. Это
связано с тем, что движок (и все его плагины и модули) является более
высокоуровневым, чем любой проект, так как он должен иметь возможность
создавать без проекта.

18
 Рисунок 4 - Иерархия уровней зависимости между проектами и модулями
Стрелки указывают на возможную зависимость. Каждый тип плагина или
модуля может зависеть от других на своем уровне или выше.

1.5.4 Плагины движка

UE 4 имеет несколько встроенных плагинов, включенных в каталог Engine.
Плагины движка похожи на плагины проекта, за исключением того, что они
доступны для всех проектов. Обычно эти плагины создаются программистами
движков и инструментов для обеспечения базовой функциональности, которую
можно использовать в нескольких проектах, сохраняя при этом в одном месте.
Это может позволить пользователю добавлять или переопределять функции
двигателя без изменения кода UE 4.

19
 1.5.5 Плагины проекта
Плагины находятся в подпапке Plugins в каталоге вашего проекта и будут
обнаружены и загружены во время запуска игры или редактора.

Если подключаемый модуль содержит модули с папками с исходным

кодом (и файлы .Build.cs), код подключаемого модуля будет автоматически
добавлен в сгенерированные файлы проекта C++, чтобы вы могли работать над
разработкой подключаемого модуля вместе с вашим проектом. Всякий раз, когда
вы компилируете свой проект, любые плагины с доступным исходным кодом
также будут скомпилированы как зависимость от вашей игры.

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

генератором проекта Visual Studio и не будут отображаться в ваших файлах
проекта C++, но они все равно будут загружаться при запуске движка.

1.5.6 Файлы дескрипторов плагинов

Дескрипторы плагинов - это файлы с расширением <Название
плагина>.uplugin. Первая часть имени файла — это всегда имя вашего
подключаемого модуля. Файлы дескриптора плагина всегда находятся в каталоге
вашего плагина, где движок обнаружит их во время запуска.

Дескрипторы плагинов пишутся в формате файла JSON (JavaScript Object

Notation).

Файл дескриптора представляет собой список переменных в формате JSON

из типа FPluginDescriptor. Есть одно дополнительное поле, FileVersion, которое
является единственным обязательным полем в структуре. FileVersion дает
версию файла дескриптора подключаемого модуля и обычно должна быть
установлена на самую высокую версию, разрешенную движком.

1.6 Обзор основных классов и зависимостей

В этой главе приводится описание наиболее используемых классов
гемплейного фреймворка (Рис. 5) UE 4.

20
 Рисунок 5 - Диаграмма классов UML основных классов гемплейного
фреймворка UE 4

1.6.1 UObject
Базовый класс всех объектов UE4. Он обеспечивает дополнительные
методы для создания и использования объектов, а также виртуальные функции,
которые следует переопределить в дочерних классах.

1.6.2 AActor
AActor — это базовый класс для объекта, который может быть размещен
на уровне. Актёры могут содержать набор компонентов типа ActorComponent,
которые можно использовать для управления перемещением актёров, их
рендерингом и т. д. Другой основной функцией Actor является репликация
свойств и вызовов функций по сети во время игры.

1.6.3 APawn
APawn - это базовый класс всех актеров, которыми могут владеть игроки
или ИИ. Они являются физическими представлениями игроков и существ на
уровне.

1.6.4 ACharacter
Персонажи — это пешки, у которых есть 3д модель, форма коллизии и
встроенная логика движения. Они несут ответственность за всё физическое
взаимодействие между игроком или ИИ и миром, а также реализуют базовые
сетевые модели и модели ввода. Они предназначены для вертикально

21
ориентированного представления игрока, который может ходить, прыгать,
летать и плавать по миру с помощью CharacterMovementComponent.

1.6.3 UActorComponent
ActorComponent - это базовый класс для компонентов, определяющих
многократно используемое поведение, которое может быть добавлено к
различным типам AActor’ов. Компоненты, у которых есть расположение
относительно корня AActor, известны как SceneComponents, а те, которые можно
визуализировать, - PrimitiveComponents.

1.6.4 APlayerController
PlayerController’ы используются игроками-людьми для управления
пешками.

1.6.5 AHUD
Базовый класс дисплея. У него есть холст и холст отладки, на котором
можно рисовать примитивы. Он также содержит список простых хит-боксов,
которые можно использовать для простого обнаружения щелчка по элементам.
Также включен метод рендеринга отладочного текста. Предоставляет несколько
простых методов визуализации текста, текстур, прямоугольников и материалов,
к которым также можно получить доступ из Blueprint.

1.6.6 UGameInstance
Объект-менеджер высокого уровня для экземпляра запущенной игры.
Создается при создании игры и не уничтожается, пока экземпляр игры не будет
закрыт. Запуск в standalone (автономном) режиме, создаст один экземпляр этого
класса. Запуск в PIE (воспроизведение в редакторе) будет генерировать для
каждого экземпляра PIE свой экземпляр UGameInstance.

22
 1.7 Обзор игрового процесса
Здесь показаны два основных пути запуска игрового процесса: путь
редактора и автономный путь. Общий порядок событий - инициализация
движка, создание и инициализация GameInstance, затем загрузка уровня и,
наконец, начало игры. Однако между автономным режимом и режимом
редактора есть различия, как в точном порядке вызова некоторых функций, так
и в том, в каком режиме они вызываются. Таким образом есть два способа
запуска проекта:

1. через редактор,
2. автономно.

Различия в этих двух способах заключаются в наличии самого редактора в

одном из них и процессе самого запуска. Если в случае запуска через редактор,
пользователю нужно запустить проект в редакторе и выбрать каким образом
будет запускаться игра, после чего создаются экземпляры класса UGameInstance
для каждого окна редактора. В автономном режиме UE 4 инициализируется без
дополнительных действий, создаёт один экземпляр класса UGameInstance и
переходит в общий для двух способов поток – подготовке UWorld, созданию
актёров в мире, вызовам методов BeginPlay и т. д. (Рис. 6).

23
Рисунок 6 - Порядок старта игрового процесса
24
 1.7.1 Автономный режим
В автономном режиме, который используется в играх, в которые играют
вне редактора, объекты, необходимые для игры, создаются и инициализируются
сразу же после инициализации движка при запуске. Такие объекты, как
GameInstance, создаются и инициализируются перед запуском движка (в отличие
от создания и инициализации движка), а начальная карта загружается сразу
после вызова функции запуска движка. Официально игровой процесс начинается
с этого момента, когда уровень создает соответствующий игровой режим и
игровое состояние, а затем и других актеров.

1.7.2 Режим редактора

В режиме редактора, который используется в Play In Editor и Simulate In
Editor, используется другой поток. Движок инициализируется и запускается
немедленно, так как это необходимо для запуска редактора, но создание и
инициализация объектов, таких как UGameInstance, откладываются до тех пор,
пока пользователь не нажмет кнопку для запуска сеанса PIE или SIE. Кроме того,
актеры на уровне дублируются, так что внутриигровые изменения не влияют на
уровень в редакторе, и каждый объект, включая объект UGameInstance, имеет
отдельную копию для каждого экземпляра PIE. Путь редактора объединяется с
автономным путем с началом игрового процесса в классе UWorld.

1.8 Распознавание ключевых точек лица

1.8.1 Использованные инструменты
Для детекции лица в OpenCV существует каскадный классификатор для
лиц, однако он выдавал крайне неточные результаты при тестах. Взамен этому
инструменту, в дополнительных модулях OpenCV, которые не входят в
стандартные модули, есть инструмент, который позволяет использовать
обученные глубокие нейронные сети без подключения соответствующих
фреймворков, на которых они были обучены. Для детекции лиц была взята
предобученная в Caffe нейросеть, которая показала высокую точность вместе с
достаточной скоростью работы.

25
 Для детекции ключевых точек лица был использован Facemark API (Рис. 7)
из модуля OpenCV Face. Он имеет три различных реализации обнаружения
ориентиров:

1. FacemarkKazemi: эта реализация основана на статье В. Каземи

и Дж. Салливана “One Millisecond Face Alignment with an Ensemble of
Regression Trees” [1], опубликованной в CVPR 2014. Альтернативную
реализацию этого алгоритма можно найти в DLIB.
2. FacemarkAAM: Эта реализация использует Active Appearance
Model (AAM) и основана на статье под названием “Optimization problems
for fast AAM fitting in-the-wild” [2] Дж. Цимиропулоса и М. Пантика,
опубликованной в ICCV 2013.
3. FacemarkLBF Эта реализация основана на статье С. Рена под
названием “Face alignment at 3000 fps via regressing local binary features” [3]
опубликованной в CVPR 2014.

Плагин использует реализацию FacemarkLBF, на которую доступна

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

Рисунок 7 - Диаграмма наследования для cv::face::Facemark

1.8.2 Вывод формул для распознавания жестов лица

Для определения жестов лица (табл. 3) используются формулы
соотношения:

Соотношение сторон глаза (EAR) вычисляю по формуле (1)

26
 ||𝑝2 − 𝑝6|| + ||𝑝3 − 𝑝5||
𝐸𝐴𝑅 = (1)
2 ∗ ||𝑝1 − 𝑝4||

, где p1-p6 - ключевые точки глаза. [4] (Рис. 8)

Рисунок 8 - График зависимости EAR от положения ключевых точек глаза

По аналогии с соотношением сторон глаза была выведена формула

(2) для соотношения сторон рта (MAR):

(||𝑝2 − 𝑝8|| + ||𝑝3 − 𝑝7|| + ||𝑝4 − 𝑝6||)

𝑀𝐴𝑅 = (2)
(2 ∗ ||𝑝1 − 𝑝5||)

, где p1-p8 - ключевые точки рта. (Рис. 9)

Рисунок 9 - Ключевые точки рта

27
 Формула соотношения положения бровей (3):

(max(||p1 − p2|| + ⋯ + ||p1 − p6||) , (||p1 − p7|| + ⋯ + ||p1 − p11||))

𝐵𝐴𝑅 = (3)
4 ∗ ||𝑝1 − 𝑝12||

, где p1 - p12 - ключевые точки бровей. (Рис. 10)

Рисунок 10 - Ключевые точки, который используются для высчитывания BAR

Таблица 3 - Жесты человеческого лица и их значение для системы

Действие Значение

Активация/деактивация контроля
мышью

(Открытие рта)

28
Продолжение таблицы 3

Левый клик мыши

(Моргание)

Правый клик мыши

X2

(Моргание два раза)

Активация/деактивация режима
прокрутки

(Прищурить глаза)

Активация/деактивация режима
кликов мыши

(Поднятие бровей)

Движения курсора / поворот колеса

мыши

(Движение головой)

29
 2 Разработка модуля
2.1 Файловая структура модуля
Проект состоит из основного геймплейного модуля, который необходим
для запуска проекта и плагина FLDPlugin (Рис. 11). Все методы не связанные
непосредственно с игровой логикой вынесены в статическую библиотеку
FLD_BPL для уменьшения числа зависимостей.

Рисунок 11 - Структура проекта в файловой системе

2.2 Связка Unreal Engine 4 и OpenCV

Связывание OpenCV, как и любой другой сторонней библиотеки, с UE 4
возможно произвести с помощью UnrealBuildTool. Средства UE 4 уже
поддерживают подключение сторонних библиотек и заголовков в проект, однако
для нашего проекта это не подходит, так как подключение заголовков OpenCV
вызывает коллизию пространств имён с системой Unreal Engine. Для обхода этой
проблемы было принято решение о выносе отдельных функций, которые
работают с библиотеками OpenCV, в динамическую библиотеку и производить
явную загрузку динамической библиотеки в Unreal Engine (Рис. 12).

30
 Рисунок 12 - UML-диаграмма вынесенных в dll функций

2.3 Реализация работы плагина в системе Unreal Engine 4

В проекте была создана библиотека Blueprint’ов UFLD_BPL (Рис. 12) в
C++, в которой реализуется явная загрузка динамической библиотеки и
получение указателей на используемые функции. Данное решение (Рис. 13)
позволяет удобно использовать функции из внешней библиотеки как в C++, так
и в системе визуального программирования Blueprint.

31
Рисунок 13 - EPC (Event-driven process chain – диаграмма
32
 Для реализации плагина был создан класс AWebcamReader,
унаследованный от класса AActor, в котором, с помощью методов библиотеки
UFLD_BPL, управлял логикой поведения. Для начала работы системы требуется,
чтобы пользователь самостоятельно выбрал положение своей головы и
активировал режим контроля мыши однократным открытием рта. С этого
момента игрок может управлять движениями мыши отводя нос от центра
выделенной области. Для переключения режимов работы мыши используются
соответствующие жесты (Табл. 3). Для симуляции мыши была создана Blueprint
библиотека UCursor_BPL (Рис. 14), это позволяет избежать излишнего
копирования кода. UCursor_BPL симулирует клики и движения мыши, это
означает, что все настройки пользовательского ввода и событий для мыши в игре
будут работать также, как если бы мы управляли игровым процессом
стандартной мышью. Для гибкой настройки движения курсора по экрану был
создан класс FGameAnalogCursor. Он реализует ускорение скорости по мере
движения, учитывание минимального значения сигнала ввода для движения
мыши. Однако такой класс не доступен для настройки значений по умолчанию в
редакторе Unreal Engine 4, для решения данной проблемы в плагине реализован
класс UCamMouseCursorSettings, который содержит значения по умолчанию,
график ускорения и указатель на экземпляр класса FGameAnalogCursor (Рис. 15).

33
Рисунок 14 - UML-диаграмма классов AWebcamReader, UCursor_BPL,
FGameAnalogCursor

34
 Рисунок 15 - Скриншот настроек UCamMouseCursorSettings в редакторе UE 4

2.4 Система валидации жестов

Для каждого вида жеста (Табл. 3) реализована система валидации.
Определяется временной промежуток для каждого жеста и через определённые
промежутки времени состояние жеста проверяется (Рис. 16). По итогу, если на
выбранном временном промежутке жест был большую часть времени выполнен,
то будет считать, что жест действительно выполнялся. В ином случае,
соответственно, считаем, что жест не выполнялся. Данная система имеет
недостаток в том, что при выборе большого промежутка времени требуется
большой промежуток ожидания, также может возникнуть ситуация, когда
пользователь начал выполнять жест уже после половины выделенного
промежутка и в таком случае придётся выполнять жесть в полтора раза дольше.
Однако, так как система не подразумевает выбор больших промежуток
валидации, то этот недостаток незначителен.

35
 Рисунок 16 - Блок-схема работы алгоритма

2.5 Описание работы класса считывания и обработки изображения с веб-

камеры
В начале игры в событии BeginPlay происходит подготовка данных (Рис.
17) для работы системы, явная компоновка динамической библиотеки, проверка
работоспособности камеры и передача функций изменения текстуры
изображения с веб-камеры и валидации таймеру в качестве функции обратного
вызова. Получаем три потока работы системы (Рис. 18):

36
 1. DoProcessing – метод класса, который обрабатывает
полученные данные после валидации. Реагирует на жесты и работает с
вводом/выводом для симуляции мыши,
2. ValidateFunction – метод, который инициирует просчёт
ключевых точек лица и обрабатывает поступающие данные с веб-камеры
для избегания ложных срабатываний,
3. UpdateTexture – метод, которые берёт изображения с веб-
камеры и обновляет текстуру, после чего она передаётся в материал в
качестве параметра.

Рисунок 17 - Диаграмма последовательности примера взаимодействия системы

и игрока

37
 Рисунок 18 - IDEF3 PFDD. Диаграмма работы класса AWebcamReader
2.6 Реализация пользовательского интерфейса
Blueprint BP_HUD в моём проекте – это стартовая точка для
инициализации пользовательского интерфейса. На момент BeginPlay HUD ищет
экземпляры класса BP_WebcamReader, если находит, то создаёт виджет и

38
передаёт в параметры указатель на BP_WebcamReader, иначе создаёт
BP_WebcamReader самостоятельно и передаёт указатель на него далее.

2.6.1 Описание элементов пользовательского интерфейса

На экране есть 3 структурных элемента пользовательского интерфейса
(Рис. 19), которые можно выделить:

1. Изображение с веб-камеры, на котором выделены ключевые

точки и выбранное поле для управление курсором мыши,
2. Вывод статусов мода нашего инструмента,
3. Количество морганий глаз.

Рисунок 19 - Схематичный рисунок пользовательского интерфейса

2.6.2 Взаимодействие пользовательского интерфейса с системой

Изображение с веб-камеры, представляет собой материал с текстурой
параметром. Во время создания виджета я создаю динамический материал
изображения, это позволяет мне во время игры изменять параметры материала.
39
Для своевременного изменения изображения передаётся указатель на материал
в экземпляр класса BP_WebcamReader. При событии обновления кадра в этом
экземпляре по указателю на материал передаётся новое изображение. Значения
морганий глаз и активных состояний (табл. 2) привязаны к соответствующим
значениям экземпляр класса BP_WebcamReader. Для вывода на экран активных
состояний используется привязка содержания строки к функции, в которой по
ноде FormatText в системе Blueprint создаётся строка в зависимости от
введённых параметров.

Таблица 4 - Состояния системы

Состояние системы Описание

MouseMode Режим контроля курсором мыши.
ClickMode Режим контроля кликами мыши.
ScrollMode Режим контроля колесом мыши.

2.7 Реализация симуляции мыши

Для симуляции мыши реализован класс Blueprint - библиотеки Cursor_BPL
(Рис.6). Он реализует левый и правый клики мыши, движение мыши и
управление колесом. Для искусственной симуляции ввода используются методы
ввода для класса FViewportClient. Как было сказано в главе 2.5, статические
методы для симуляции мыши вызываются из метода DoProcessing класса
AWebcamReader.

40
 3 Эксперименты
3.1 Выборка пороговых значений
Для выбора пороговых значений были построены графики для каждого
значения соотношения сторон, описанные в главе 1.8.2.

Рисунок 20 - График зависимости EAR от времени во время тестирования

Экспериментально выяснилось, что для порогового значения EAR оптимально
значение 0.3.

41
 Рисунок 21 - Зависимость BAR от времени во время тестирования
Экспериментально выяснилось, что для порогового значения BAR оптимально
значение 1.58.

42
 Рисунок 22 - Зависимость MAR от времени во время тестирования
Экспериментально выяснилось, что для порогового значения BAR оптимально
значение 0.5.
3.2 Калибровка
Калибровка пороговых значений соотношений сторон позволила найти
наиболее подходящие значения для лучшей работы модуля. В целом, во время
тестирования с разными людьми результаты по умолчанию показали свою
универсальность, однако для улучшения опыта использования было введено
меню автокалибровки (Рис. 23). Пользователь за отведённое время выполняет
соотвествующий жест, показатели записываются и по ним вычисляется среднее
значение. После чего оно выставляется, как пороговое значение для
соответствующего жеста.

43
Рисунок 23 - Виджет калибровочного режима

44
 ЗАКЛЮЧЕНИЕ
По результатам работы были соблюдены условия для наиболее простого
развертывания плагина в других проектах, а также полностью перенесён
функционал мыши на использование веб-камеры. Были выявлены недостатки,
при определении точек лица, при большом угле поворота головы точки
начинают “дребезжать” или занимать неправильное место. Однако, в целом,
данное решение работоспособно, как показала практика, полноценное
использование подходит лучше всего для игровых жанров, где не требуется
быстрота и точность управления, например, пошаговые стратегии.

45
 СПИСОК ЛИТЕРАТУРЫ
1. Kazemi V., Sullivan J. One millisecond face alignment with an ensemble of
regression trees //Proceedings of the IEEE conference on computer vision and pattern
recognition. – 2014. – С. 1867-1874.

2. Tzimiropoulos G., Pantic M. Optimization problems for fast aam fitting in-the-wild
//Proceedings of the IEEE international conference on computer vision. – 2013. – С.
593-600.

3. Ren S. et al. Face alignment at 3000 fps via regressing local binary features
//Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition.
– 2014. – С. 1685-1692.

4. Soukupova T., Cech J. Eye blink detection using facial landmarks //21st computer
vision winter workshop, Rimske Toplice, Slovenia. – 2016.

5. Shilkrot R., Escrivá D. M. Mastering OpenCV 4: A comprehensive guide to

building computer vision and image processing applications with C++. – Packt
Publishing Ltd, 2018.

46