Преобразование пользовательского интерфейса: проектирование интерфейса будущего (3 из 5)

Различия между реальным и виртуальным миром исчезают, когда технология Intel® RealSense™ применяется в интерактивном обучении

Автор: Джон Тиррел

Сенсорное управление и управление жестами, распознавание изображений и дополненная реальность — все эти технологии используются в множестве образовательных приложений и игр, они объединяют виртуальный мир с реальным совершенно невероятным образом. Доступные и совершенные технологии, такие как Intel® RealSense™, развивают эти изменения, и с каждой новой возможностью устройств границы между реальным миром и виртуальным миром становятся все более размытыми. В результате можно создать мир для игр и обучения, где разница между реальным и виртуальным будет несущественной.

Компании 3D4Medical, PlayTalesи Scholasticвходят в число первых разработчиков, внедряющих технологию IntelRealSenseв области развлекательного обучения и образования. Эти компании работали в сотрудничестве с Intelв ходе освоения новых технологий и решения связанных с ними проблем. Приложения и продукты этих компаний открывают новую страницу интерактивных решений для детей и взрослых.

Интерактивные медицинские решения

Интерактивное обучение охватывает гораздо более обширную область, чем интерактивные приложения для детей. Ирландская компания 3D4Medicalсоздает межплатформенные приложения для анатомии, здравоохранения и фитнеса, а также медицинские справочники. Четвертая версия программы Essential Anatomy* компании 3D4Medical (см. рис. 1) в настоящее время лидирует по продажам среди медицинских приложений для Windows*, Android* и iOS*.

 

Рисунок 1. Снимок экрана приложения EssentialAnatomy

Разработчики изучают возможности применения технологии IntelRealSenseтаким образом, чтобы соответствовать строгим требованиям, предъявляемым к приложениям в медицинской области. Сергей Буштырков, менеджер по разработке программного обеспечения в компании 3D4Medical, предложил использовать Intel® RealSense™ SDKс подключаемым модулем Unity, чтобы проще было достичь нужных результатов при моделировании конечностей в виртуальном пространстве.

«Камера Intel® RealSense™ 3Dи IntelRealSenseSDKпредоставляют информацию, но для создания высококачественного коммерческого приложения нужно больше, чем просто данные, — поясняет Сергей. — Нам был нужен трехмерный движок для создания привлекательного изображения, поэтому мы используем Unityдля создания среды и управления руками».

Еще один уровень важности в медицинском приложении — точность, с которой распознаются отдельные конечности и суставы. Группа разработчиков под руководством Буштрыкова в настоящее время работает над анатомически точным распознаванием рук, превосходящим потребности большинства приложений с управлением жестами. «Камера снимает некоторое количество точек на руках и оцифровывает их, — говорит Буштырков. — Этот поток данных представляет собой набор координат и углов поворота для каждой из 22 отслеживаемых точек руки» (см. рис. 2).

Рисунок 2. Точки руки, отслеживаемые камерой IntelRealSense 3D

Преобразование необработанных данных в точную модель виртуальной руки — сложный процесс, причем дополнительные усилия требуются для высокого уровня детализации, необходимой для медицинского приложения. «Мы развиваем технологию, создавая очень качественные модели человеческих рук, адаптируя их к информации, которую мы получаем с камеры IntelRealSense 3D, приводя их в движение и координируя их.

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

Компания 3D4Medicalвыбрала технологию IntelRealSenseв качестве основы для своей долгосрочной работы и стремится всегда быть на переднем крае новых технологий. «С точки зрения компаний, работающих в нашей области, мы находимся на переднем крае технологий во многих областях, — подчеркивает Найл Джонстон, вице-президент компании 3D4Medicalпо развитию бизнеса. — Мы работаем с этой технологией с самых первых этапов разработки, и это прекрасная возможность как следует изучить ее потенциал».

В гостях у сказки

Испанская компания PlayTalesначала продавать интерактивные книги в магазине AppleAppStoreв начале 2012 года и быстро стала лидером рынка в этой области. Компания разрабатывает продукты на основе глобальных франшиз, таких как «Гарфилд», «Улица Сезам» и TheLittlePrince, а также на базе собственной интеллектуальной собственности, например, My NewBaby*. Виртуальный магазин PlayTales, в котором представлено свыше 200 наименований на семи языках, быстро превратился в желанный источник интерактивных сказок для родителей и детей во всем мире.

Разработчики планируют интегрировать технологию IntelRealSenseв новую интерактивную книгу Wizard of Oz*и в учебное научное приложение ProfessorGarfield* (рис. 3). «Когда мы узнали о новой технологии Intel, мы немедленно стали размышлять над тем, что мы сможем предлагать покупателям с точки зрения интерфейса, трехмерной графики и взаимодействия», — говорит Энрике Тапиас, директор компании PlayTales.

Рисунок 3. Ребенок рукой управляет бабочками в приложении ProfessorGarfield

Технология IntelRealSenseеще не была выпущена, когда компании PlayTalesпредставилась возможность, выходящая за рамки обычной реализации новой технологии в своих продуктах. Речь идет о сотрудничестве обеих компаний. «Пока мы работали над приложением, корпорация Intelодновременно разрабатывала IntelRealSenseSDK. Нам пришлось приспосабливаться к этому, — говорит Пабло Бенитес, директор компании PlayTales. — Очень хорошо, что мы можем первыми тестировать новые возможности, мы наблюдаем развитие и приложения, и SDK, и в результате получаем великолепные возможности, улучшающие взаимодействие с нашей программой. Нам очень понравился режим распознавания контура, поскольку он отслеживает силуэт ближайшего к камере объекта. Этот режим мы используем, чтобы перенести руки пользователя в наш трехмерный мир в играх, где мы отображаем представление руки. Благодаря этому пользователи могут, к примеру, «собирать воду», сложив руки ковшиком, или выбирать направление полета бабочек, указывая пальцами».

Изменение в поведении

Работа с технологией IntelRealSenseприносит компании PlayTalesощутимые преимущества. «Мы осваиваем технологию, которая будет широко использоваться на рынке в ближайшие годы. Это важно для нас, — говорит Тапиас. — Кроме того, мы исследуем возможности интерфейса с точки зрения детей. Мы тестируем удобство пользовательского интерфейса и получаем помощь со стороны фокус-групп Intelдля тестирования нашего содержимого и реализации технологии IntelRealSense».  «При тестировании приложений Wizard of Oz и ProfessorGarfield, мы обнаружили, что у детей возникают затруднения с пониманием принципа глубины при взаимодействии с новыми трехмерными мирами, — добавляет Бенитес. — Кроме того, они часто уходили из поля зрения камеры. Поэтому мы применили пошаговые инструкции, учебные материалы и оповещения, чтобы пояснить детям, куда они могут двигаться и как это следует делать».

Компания PlayTalesиспользует эту информацию для разработки нынешних и будущих продуктов по мере изменения ожиданий покупателей. «Поведение детей изменяется очень быстро, причем благодаря предлагаемым им технологиям и устройствам, — говорит Тапиас. — Мне кажется, что у детей больше вариантов использовать IntelRealSense. Это уже не просто обучение или чтение, это взаимодействие с содержимым, например, управление движением бабочек в проекте ProfessorGarfield».

Тапиас и его команда понимают огромный потенциал, раскрываемый технологией IntelRealSense, но уверены, что реализацию этой технологии необходимо тщательно контролировать, дорабатывать до возможного совершенства и до полного соответствия контексту использования, будь то обучение или развлечения. Для Тапиаса прогноз на будущее выглядит весьма оптимистично: «Технология IntelRealSense— одна из самых важных для нас в течение следующего года, причем не только для стационарных компьютеров и ноутбуков, но и для устройств, которыми пользуются дети, то есть для планшетов и смартфонов».

Фантастика Scholastic

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

Многие бренды этой компании стали привычными в среде детских материалов в США и в других странах, например, бренды CliffordtheBigRedDog*и MagicSchoolBus*. Технология IntelRealSenseиспользуется в серии I Spy*этой компании: этот бренд был запущен в 1992 году для детских книг, а сейчас это интерактивная игровая среда.

Рисунок 4. Снимок экрана приложения I SpyPirateShip

ISpyPirateShip* (рис. 4) — новинка в семействе брендов, предназначенная для переносных моноблоков AIOи трансформеров. «В приложении используется множество возможностей IntelRealSense, в том числе жесты, распознавание сжатого кулака и раскрытой ладони, отслеживание точке на лице, — говорит Контруччи. — В игре вы увидите полный спектр новых возможностей».

Дети и камеры

Одна из задач в игре I SpyPirateShipзаключается в том, чтобы смотреть в телескоп, установленный на марсовой площадке корабля, и находить объекты, скрытые среди звезд (рис. 5). При реализации технологии IntelRealSenseдля отслеживания движения головы пользователей, осматривающих небо, разработчики столкнулись с интересными проблемами.

Рисунок 5. Вид из телескопа, приложение I SpyPirateShip

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

Когда пользователь находит какой-либо объект, он сообщает это программе тем, что просто останавливается на найденном объекте: эта, казалось бы, простая модель взаимодействия очень хорошо воспринимается аудиторией. «Для детей это совершенно волшебные ощущения, им кажется, что они действительно находятся на кораблей, и могут физически воздействовать на окружающий мир», — говорит Контруччи.

Для Контруччи наибольшим потенциалом обладает способность приложения определять, когда лицо пользователя останавливается в определенном положении. «У такого подхода много других сценариев применения, — продолжает она. — Например, если ребенок рассматривает электронную книгу и останавливается на картинке со львом, программа может отреагировать на это, сказать, как называется это животное и дать его описание. Таким образом, дети получают справку на лету».

Социальное обучение

Орнит Гросс, руководитель продукции Intelв области игр и образования, дает совершенно однозначный ответ на вопрос о том, полезна ли интерактивность для учебного процесса. «Если сделать учебный материал увлекательным, живым и веселым, это поможет его лучше запомнить. Это, безусловно, помогает в обучении.

Когда мы начали осваивать эту область, мы узнали, что для успешного изучения требуется сочетание широкого набора факторов, — говорит Орнит. — Один из них — это взаимодействие, будь то с учителем, с другом или с приложением. Интерактивность делает процесс получения знаний более глубоким».

Технология IntelRealSenseявляется настоящим произведением искусства с точки зрения интерактивности, но этим все не ограничивается. «Второй фактор — социальный. Вы не просто учитесь, а учитесь в составе группы, — поясняет Орнит. — Это направление заслуживает дальнейшей разработки, мы будем этим заниматься в новом поколении наших решений. Здесь все дело в том, что работает модель взаимодействия одного со многими, а не одного с одним, если мы учимся вместе с моим другом».

Полный вперед!

Технология IntelRealSenseподтверждает свои преимущества для групп разработчиков, решивших внедрить ее: она фундаментально изменяет подход к взаимодействию пользователей с компьютерами и мобильными устройствами. Искренний интерес разработчиков к новой технологии стал заслуженной наградой для Орнита и его команды. «Меня удивило, что разработчики, поняв, что IntelRealSenseSDKдает и высокоуровневые, и низкоуровневые данные, начали сами писать код для взаимодействия, используя все APISDK. Например, SDKотслеживает на лице 78 реперных точек и распознает разные мимические черты, например, открытие или закрытие глаза, открытый рот и так далее. Эти возможности были объединены, чтобы SDKмог распознать, когда пользователь начинает корчить рожи. Еще один пример — распознавание жестов руки. IntelRealSenseSDKотслеживает 22 точки суставов руки и жест сведения пальцев. Разработчик объединил эти API, доступные в SDK, и получил совершенно уникальный жест складывания пальцев, который разработали специально для главного персонажа в игре».

Как известно, технология — это только начало. Гораздо важнее содержимое. Контруччи подводит краткий итог мотивации Scholasticв отношении освоения возможностей технологии IntelRealSense: «Многие считают, что управление жестами получит крайне широкое распространение не только потому, что ребенок хочет взаимодействовать с компьютером именно так, а потому, что это естественное действие. Когда мы выпустили I SpyPirateShipдля тестирования этого естественного взаимодействия с участием детей, для них это были совершенно новые ощущения. И это было очень интересно».

Ресурсы 

Изучить технологию Intel RealSense, узнать о бета-версии Intel RealSense SDK для Windows и заказать набор разработчика можно здесь.

В будущем камера Intel RealSense 3D будет встраиваться в ноутбуки, моноблоки и планшеты. Посмотрите, как компания  faceshiftиспользует эту камеру для управления аватарами на 16 планшетах для создания «виртуальных селфи».

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

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

Узнайте, как технология Intel RealSense стирает границы между личным общением и общением на расстоянии. Прочтите статью  здесь.

Intel и Intel RealSense являются товарными знаками корпорации Intel в США и в других странах.

Дополнительные сведения об оптимизации компиляторов см. в нашем уведомлении об оптимизации.

Преобразование пользовательского интерфейса. Проектирование интерфейса будущего (4 из 5).

Уход из плоскости. Трехмерная съемка и демонстрация

Download PDF

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

Но появившиеся недавно новые технологии меняют эту картину. Достаточно незначительных усилий, чтобы покупатели могли на планшетах видеть, как они будут выглядеть в разных моделях виртуальных очков. Аналогичные приложения для Android* и iOS* позволяют покупателям просматривать и взаимодействоватьс виртуальной мебелью, одеждой, тканями, игрушками и т. д. В большинстве случаев трехмерные образцы товаров, используемые в этих приложениях, ограничиваются заранее подготовленным содержимым, которое было создано профессионалами.

Но камеры Intel® RealSense™ 3D будут способны уже скоро сделать возможности трехмерного сканирования, печати и демонстрации доступными для широкого круга пользователей. Используя отслеживание рук и пальцев, голосовые команды, распознавание лица и функции дополненной реальности, обеспечиваемые технологией Intel® RealSense™, пользователи смогут естественным образом взаимодействовать с реальными и виртуальными объектами и печатать их трехмерные модели. Возможны самые разные сценарии использования — от профессионального (продажи, медицина, дизайн, образование) до развлекательного (игры, создание фильмов, социальное общение).

Компании 3D Systems, Autodesk и DotProduct первыми осваивают новые возможности, располагая обширным опытом создания и печати трехмерного содержимого. Они внедряют технологию Intel RealSense для того, чтобы сделать возможности трехмерной съемки и отображения доступными для широкой аудитории.

Трехмерное изображение и печать

Компания 3D Systems, которую основал Чак Халл, изобретатель трехмерной печати, с 1986 года обслуживает заказчиков в таких отраслях, как автомобильная промышленность, аэрокосмическая промышленность, промышленное проектирование и медицина. В настоящее время компания занимается популяризацией трехмерной печати.   «Камера Intel RealSense 3D — естественный выбор, — говорит Пинь Фу (Ping Fu), директор компании 3D Systems. — Два года назад большинство трехмерных сканеров стоило от 10 000 до 50 000 долларов США. С помощью камер Intel RealSense 3D пользователи получат доступ к трехмерным сканерам, встроенным в их ПК, трансформеры, моноблоки, ультрабуки и планшеты».

Компания 3D Systems разрабатывает два настольных приложения, которые будут использовать технологию Intel RealSense на ПК: 3DMe* и SENSE*. Оба эти приложения созданы с помощью Intel® RealSense™ SDK 2014.

Приложение 3DMe дает возможность любому пользователю дать свое собственное лицо любимому игровому персонажу, например баскетболисту из НБА, Боргу из «Звездного пути», сноубордисту, принцессе и так далее (рис. 1). После съемки персонаж можно напечатать на трехмерном принтере, анимировать или показать друзьям по социальным сетям.

Рисунок 1. Лицо пользователя сканируется в персонаж с помощью приложения 3DMe*

SENSE — это программа для сканирования объектов. «Можно отсканировать вашу голову, все тело или какие-либо объекты, например вашу любимую игрушку, а затем напечатать их трехмерную модель или экспортировать, — поясняет Пинь Фу. — Естественным примером использования служат игры. Разработчики и конструкторы могут применять эту возможность для создания эталонных моделей с высокой степенью детализации для сложных конструкций, обычные пользователи могут сканировать свои любимые вещи, делиться ими с друзьями и печатать на трехмерных принтерах».

Сценарии использования трехмерной печати индивидуальных отсканированных объектов весьма разнообразны. «Производители кукол хотят создавать лица кукол индивидуально, такими же, как лица девочек, — говорит Пинь Фу. — Спортсмены по заслугам оценят шлемы, которые идеально подойдут под индивидуальную форму головы. Пользователи могут сканировать свои кисти и руки, чтобы с легкостью получать отливки, устраняющие неудобства и туннельный синдром».

Приложения 3DMe и SENSE производят съемку объектов (рис. 2) в виде редактируемых трехмерных моделей вместе с картой текстур и информацией о цвете. Пользователи 3DMe будут переадресованы на cubify.com для печати человекоподобных моделей; пользователи SENSE смогут печатать свои модели на персональных трехмерных принтерах семейства CUBE* компании 3D Systems или смогут отправлять модели в облако и распечатывать в компаниях, предоставляющих услуги трехмерной печати. Персональный принтер CUBE поддерживает печать ограниченным набором материалов, тогда как мощные профессиональные и промышленные трехмерные принтеры могут печатать «...металлом, керамикой, акрилом, пластиком и даже съедобным шоколадом и сахарной глазурью» (Пинь Фу).

Рисунок 2. Сканирование объектов с помощью программы SENSE*

Приложение SENSE поддерживает экспорт моделей в форматы OBJ, DXE, PLY, а также в другие форматы, принятые в САПР-системах. «Пользователи систем автоматизированного проектирования (САПР) предпочитают работать с параметризованными моделями, чтобы при изменении геометрии эти изменения также распространялись на поверхности, текстуры и т. д., — продолжает Пинь Фу. — Программа SENSE совместима с программным пакетом Geomagic Solution компании 3D Systems, который предоставляет самый быстрый способ преобразования отсканированных данных в параметрические модели для систем САПР».

По словам Пинь Фу, технология Intel RealSense способна работать с общей погрешностью в пределах 1 мм: «Этого вполне достаточно для многих персональных продуктов — индивидуально подбираемых оправ очков, обуви или медицинских устройств, таких как шины для срастания сломанных костей. Для промышленного проектирования трехмерные отсканированные модели будут перенесены в среду САПР для повышения детализации и более точной доработки эталонного проекта».

Пинь Фу начала работать в области трехмерного сканирования в 1996 году, когда она стала руководителем и одним из основателей компании Geomagic, ведущей в мире компании по созданию программного обеспечения для трехмерного сканирования. Эта компания в 2013 году была приобретена компанией 3D. Пинь Фу всегда стремилась сделать трехмерное сканирование доступным для широкого круга потребителей и работала над соединением возможностей трехмерного сканирования и трехмерной печати. В корпорации Intel она нашла единомышленников. «Наше сотрудничество с Intel было взаимовыгодным и полезным, — говорит она. — Мы много работаем вместе. Технология Intel RealSense обеспечивает интуитивное взаимодействие с компьютером, а камеры Intel RealSense 3D получают необработанные данные. Наша программа получает это облако точек и преобразует его в полноцветную текстурную модель, пригодную для дальнейшего использования. Мы формируем возможности, позволяющие сделать работу с компьютером без помощи контроллеров в трехмерных приложениях доступной, удобной и интересной».

Пинь Фу подчеркивает важность опыта Intel в области интеграции оборудования с оптимизированным программным обеспечением: «Над Intel RealSense SDK работает великолепная команда. Они отлично знают, как поддерживать сообщество разработчиков». Обе компании помогали друг другу в работе. Инженеры 3D Systems использовали Intel RealSense SDK для создания своих приложений, управления камерой и распознавания лиц. «Нам также очень помогла тесная работа с сотрудниками команды User Experience корпорации Intel при создании интуитивного, удобного в использовании приложения».

Компания 3D Systems также внесла свой вклад в разработку Intel RealSense SDK, предоставив функции обработки отсканированных данных. Эти функции дадут другим разработчикам возможность преобразования облака точек в модели. «При трехмерном сканировании одна из основных проблем заключается в том, что необработанные данные зачастую содержат много помех, — заявляет Пинь Фу. — Мы предусмотрели очень развитые функции очистки, в том числе и возможность заполнения отверстий на основе кривизны поверхностей. За счет этого достигается весьма естественный вид без необходимости заново сканировать предметы». Специалисты 3D Systems также предоставили возможность снижения детализации предметов при сохранении их общей формы. Такую функцию разработчики игр используют для получения объектов с пониженным количеством полигонов для ускоренного рендеринга на лету. Наиболее уникальный алгоритм — процесс сканирования с точным соответствием отображения (WYSIWYG). За счет этого сканирование существенно упрощается для потребителей и для автоматических систем моделирования.

Каковы основные выводы компании 3D Systems, полученные в процессе разработки? «Правильно реализовать трехмерное сканирование — непростая задача, — говорит Пинь Фу. — Чтобы новая технология получила распространение, крайне важно удобство пользователей. Благодаря помощи Intel мы получили огромный объем информации о настройке производительности, тестировании с участием пользователей и получении отзывов на рынке. Работая с корпорацией Intel, мы получили доступ к другим независимым разработчикам программ, производителям компьютеров и розничным компаниям. Эти связи превратились во взаимовыгодные партнерские отношения».

Трехмерный просмотр для улучшения двухмерных изображений

Компания Autodesk, всемирный лидер в области программного обеспечения для трехмерного проектирования, инженерных задач и развлечений, использует нашу технологию для получения трехмерных данных изображений с тем, чтобы пользователи могли придавать объем двухмерным фотографиям. «Технология Intel RealSense идеально подходит для нашего приложения Pixlr*, предназначенного для редактирования изображений, — говорит Гарет Пеннингтон (Gareth Pennington), старший менеджер по программному обеспечению в компании Autodesk. — Нас особенно интересует сегментация фона и возможность добавить еще одно измерение в двухмерные изображения».

При сегментации фонаиспользуются данные глубины для выделения, то есть сегментации, объектов, находящихся на переднем и на заднем планах, чтобы затем можно было извлечь, заменить или дополнить различные аспекты изображения в реальном времени (рис. 3). Алгоритмы сегментации в Intel RealSense SDK ищут данные определенного цвета и глубины, определяют, что следует отобразить и извлечь, затем выдают результаты в формате видео высокой четкости со скоростью 60 кадров в секунду.

Рисунок 3. Сегментация фона с помощью приложения Pixlr*

«Мы предусматриваем довольно интересные сценарии использования, например мы даем пользователям возможность снимать только свою голову и автоматически удалять фон, чтобы голову можно было преобразовать в графический штамп для переноса на другие изображения, — говорит Пеннингтон. — Также можно создавать индивидуальные смайлики и другие значки для использования в электронных письмах и сообщениях. Например, если вы на корабле, то вы можете себя сфотографировать и применить зеленый фильтр, который будет применяться только к вашему лицу, но не ко всему тому, что находится вокруг вас, чтобы указать, какая это неприятная штука — морская болезнь».

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

Приложение Pixlr в настоящее время доступно и в виде веб-приложения, и в качестве традиционного приложения для Windows*, Mac OS, iOS и Android. Версия с поддержкой технологии Intel RealSense будет приложением для Windows. Рассуждая о перспективах, Пеннингтон заявил: «Интересно размышлять о том, что мы могли бы сделать со всеми прочими возможностями технологии Intel RealSense: отслеживанием движений, распознаванием лица, можно поработать с измерением предметов и с изменением фокуса... Все это очень интересно. В Intel RealSense SDK для нас осталось еще много функций, которые следовало бы изучить. Потенциал Intel RealSense, безусловно, раскроется со временем, когда эта технология станет доступной для широкого круга потребителей. Это будет просто здорово».

Трехмерное изображение на планшетах

С момента своего основания в 2012 годукомпания DotProduct обслуживала профессиональный рынок и первых потребителей услуг трехмерного сканирования: компании нефтегазовой отрасли и энергетики, инженерно-проектные компании, а также организации, занимающиеся криминалистикой и историческими документами. «Эти отрасли используют трехмерные изображения, — поясняет Брайан Ахерн (Brian Ahern), директор компании DotProduct. — Они применяют трехмерные изображения в проектировании и эксплуатации, в обслуживании и модернизации оборудования, во всей своей работе».

Признав, что компактные трехмерные датчики стали доступной альтернативой промышленным сканерам, компания DotProduct разработала решение на базе планшета Android, способное создавать точные трехмерные модели объектов. Эта система поступила в продажу по цене 5000 долларов США. Теперь компания работает с корпорацией Intel над разработкой еще более дешевого планшетного решения на базе Intel RealSense.

«Мы чрезвычайно увлечены технологией Intel RealSense, — говорит Ахерн. — Когда камеры Intel RealSense 3D будут встраиваться в планшеты, доступные в широкой продаже, рынок будет расти в геометрической прогрессии». Брайан считает, что DotProduct становится компанией, ориентированной на программное обеспечение, и будет лицензировать свои технологии производителям устройств, интегрирующих технологию Intel RealSense в свою продукцию.

Как и компании 3D Systems и Autodesk, DotProduct также стремится сделать свои решения более доступными и удобными для потребителей, чтобы привлечь более широкую аудиторию. «В бета-версии 2.0 полностью переделан пользовательский интерфейс. Функции навигации, просмотра и рендеринга полностью интуитивны [рис. 4]».

Рисунок 4. Переделанный пользовательский интерфейс DotProduct.

Брайан считает, что в первую очередь новый продукт будет популярен среди продвинутых потребителей, наиболее важными будут функции съемки трехмерных изображений и обмена ими: «Одно из наших конкурентных преимуществ — проприетарный алгоритм сжатия изображений без потерь, благодаря которому можно отправлять по электронной почте трехмерные облака точек, не расходуя огромные объемы памяти на создание моделей». С помощью бесплатного приложения для просмотра пользователи смогут отправлять друг другу, к примеру, модель гостиной в своем доме, открывать ее на планшете, который преобразует облако точек в модель для просмотра с любых ракурсов и для измерения.

Основная технология компании DotProduct основывается на платформе Android, но «…не зависит от нее. Android — это оболочка, а наш код написан на C++. Сейчас мы переносим его на Windows», — говорит Ахерн. После выпуска продукта в 2015 году он будет работать на обеих платформах. Кенн Уокер (Kenn Walker), менеджер по продукту Intel RealSense, добавляет: «Если говорить о приложениях, использующих Intel RealSense, некоторые из них работают на высоком уровне SDK. Приложение DotProduct, напротив, работает ближе к «железу», взаимодействуя с данными в необработанном виде».

Какая вычислительная мощность требуется для обработки всех этих данных? «Чем больше всего (ЦП, ГП, ОЗУ), тем лучше, — говорит Ахерн. — Чем выше мощность, тем лучше результаты».

Сценарии использования самые разнообразные — от игр до продаж, обучения, развлечений и т. д. «В некоторых компаниях, работающих в области дизайна, сотрудникам приходится вручную измерять размеры объектов, комнат и помещений. Это трудоемкий и длительный процесс. Возможность просто навести планшет на какой-либо предмет (рис. 5) или комнату, перенося при этом планшет вокруг, под предметами и над ними, чтобы потом нажать кнопку «Готово» и получить готовую модель, произведет настоящую революцию».

Рисунок 5. Сканирование с помощью планшета

Говоря об основных выводах из процесса разработки, Брайан заявил: «Мы поняли, что даже инженеры порой недооценивают скорость развития потребительских технологий. Мы знали, что рано или поздно появятся мобильные устройства со встроенными трехмерными технологиями, но это произошло быстрее, чем мы предполагали».

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

Ресурсы

Изучить технологию Intel RealSense, узнать о бета-версии Intel RealSense SDK для Windows и заказать набор разработчика можно здесь.

Ваш проект готов к демонстрации? Станьте участником программы Intel® Software Innovator.Эта программа поддерживает разработчиков передовых проектов, дает возможность выступить с рассказом о своем проекте и устроить демонстрацию.

Приступите к работе в центре ресурсов для разработчиков.

Прочтите часть 1,часть 2и часть 3этой серии «Преобразование пользовательского интерфейса: проектирование интерфейса будущего».

Intel, эмблема Intel и RealSense являются товарными знаками корпорации Intel в США и в других странах.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

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

© Корпорация Intel, 2015. Все права защищены.

Download Source Code ZIPfile

Процедурный рендеринг разреженного пространства (SPVR) — это методика рендеринга пространственных эффектов в реальном времени. Мы очень рады, что в будущей книге «GPU Pro 6» будет глава, посвященная SPVR. В этом документе приводятся некоторые дополнительные сведения

SPVRс высокой эффективностью отрисовывает большой объем, разделяя его на маленькие кусочки и обрабатывая только используемые кусочки. Мы называем эти кусочки «метавокселями». Воксель — это наименьшая часть объема. Метавоксель — это трехмерный массив вокселей. А весь объем в целом — это трехмерный массив метавокселей. В примере есть константы времени компиляции для определения этих чисел. В настоящее время он настроен на объем, равный 1024³ вокселям, в виде 32³ метавокселей, каждый из которых состоит из 32³ вокселей.

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

В примере также эффективно используется память. Примитивы объема можно считать сжатым описанием содержания объема. Алгоритм эффективно распаковывает их на лету, последовательно переходя к наполнению и к отслеживанию лучей метавокселей. Такое переключение может выполняться для каждого метавокселя. Но переключение между заполнением и отслеживанием лучей связано с расходом ресурсов (например, смена шейдеров), поэтому алгоритм поддерживает заполнение списка метавокселей перед переходом к отслеживанию лучей для них. Он выделяет относительно небольшой массив метавокселей и повторно использует их при необходимости для обработки всего объема. Обратите внимание, что во многих типичных случаях используется только малая часть всего объема.

Рисунок 1. Частицы, воксели, метавоксели и различные системы координат

На рис. 1 показаны все составные части: воксели, метавоксели, частица примитива объема, источник света, камера и мир. У каждой составной части есть эталонная точка, которая определяется положением P, направленным вверх вектором U и направленным вправо вектором R. Система трехмерна, но на рис. 1 используется упрощенное двухмерное представление.

• Воксель — наименьшая часть объема. Для каждого вокселя задается цвет и плотность.
• Метавоксель — это трехмерный массив вокселей. Каждый метавоксель хранится в виде трехмерной текстуры (например, трехмерной текстуры 32³DXGI_FORMAT_R16G16B16A16_FLOAT).
• Объем — общий объем, состоящий из нескольких метавокселей. На рис. 1 показан упрощенный объем из метавокселей 2х2.
• Частица — сферический примитив объема с радиальным сдвигом. Обратите внимание, что это трехмерная частица, а не двухмерная плоскость.
• Камера — та самая камера, которая используется для рендеринга всей остальной сцены из точки наблюдения.

Описание алгоритма

// Рендеринг карты теней для каждой модели сцены, видимой из представления освещения

// Рендеринг предварительного Z-прохода для каждой модели сцены, видимой с точки зрения наблюдателя

// Применение частиц для каждой частицы: для каждого покрываемого частицами метавокселя путем присоединения частиц к списку частиц метавокселя

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

// Отрисовка сцены в обратный буфер для каждой модели сцены с точки зрения наблюдателя

// Совмещение цели рендеринга с точки зрения наблюдателя с рендерингом полноэкранного спрайта обратного буфера с использованием цели отрисовки как текстуры

Обратите внимание, что в этом примере поддерживается заполнение нескольких метавокселей перед отслеживанием лучей. Заполняется «кэш» метавокселей, затем проводится отслеживание лучей, и процедура повторяется вплоть до обработки всех метавокселей. Также поддерживается заполнение метавокселей только в каждом n^-номкадре или только однократное заполнение. Если в реальном приложении нужна статическая или медленно изменяющаяся объемная сцена, то приложение будет работать намного быстрее, если оно не будет обновлять все метавоксели в каждом кадре.

Заполнение объема

В примере метавоксели заполняются покрывающими их частицами. «Покрывающими» означает, что границы частиц пересекаются с границами метавокселя. Пустые метавоксели не обрабатываются. Приложение сохраняет цвет и плотность в каждом вокселе метавокселя (цвет в формате RGB, плотность в виде значения альфа-канала). Эта работа выполняется в пиксельном шейдере. Приложение записывает данные в трехмерную текстуру в виде неупорядоченного представления доступа (UAV) RWTexture3D. Образец приложения отображает двухмерный квадрат, состоящий из двух треугольников, такого размера, чтобы он совпадал с метавокселем (т. е. 32x32 пикселя для метавокселя 32x32x32). Пиксельный шейдер проходит каждый воксель в соответствующем столбце вокселей, вычисляет плотность и цвет каждого вокселя на основе частиц, покрывающих метавоксель.

В примере определяется, находится ли каждый воксель внутри каждой частицы. На двухмерной схеме показана упрощенная частица. (На схеме показана двухмерная окружность с радиальным сдвигом. В трехмерной системе используются сферы с радиальным сдвигом.) На рис. 1 показан радиус окружения частицы r_P и ее радиус смещения r_PD. Частица покрывает воксель, если расстояние между центром частицы P_P и центром вокселя P_V меньше расстояния сдвига r_PD. Например, воксель в P_VIнаходится внутри частицы, а воксель в P_VO — снаружи.

Внутри = |P_V– P_P| < r_PD

Скалярное произведение вычисляет квадрат длины вектора без затраты лишних ресурсов. Это позволяет избежать ресурсоемкой операции извлечения квадратного корня sqrt(), поскольку можно сравнивать не длины, а квадраты значений длины.

Внутри = (P_V– P_P) ∙ (P_V– P_P) < r_PD²

Цвет и плотность зависят от положения вокселя внутри частицы и от расстояния до поверхности частицы r_PDвдоль линии, проходящей от центра частицы через центр вокселя.

C = цвет (P_V– P_P, r_PD)
D = плотность (P_V– P_P, r_PD)

Интересны различные функции плотности. Вот некоторые возможные варианты.

• Двоичная — если воксель находится внутри частицы, то цвет = C и плотность = D (где C и D — константы). В противном случае цвет = черный, плотность = 0.
• Градиент — цвет изменяется от C1 до C2, а плотность изменяется от D1 до D2 по мере изменения расстояния из положения вокселя от центра частицы до поверхности частицы.
• Подстановка по текстуре — цвет может быть сохранен в одномерной, двухмерной или трехмерной текстуре, он подстанавливается в зависимости от расстояния (X, Y, Z).

В образце реализованы два примера: 1) постоянный цвет, оттенок которого определяется значением смещения, 2) градиент от ярко-желтого до черного на основе радиуса и возраста частицы.

Существует не менее трех интересных способов указания положения в метавокселе.

1. Нормализованный
   • Число с плавающей запятой
   • Начало координат — в центре метавокселя
   • Диапазон от -1,0 до 1,0
2. Координаты текстуры
   • Число с плавающей запятой (преобразуется в число с фиксированной запятой алгоритмом получения)
   • Начало координат — в верхнем левом углу двухмерного изображения (верхний левый задний угол трехмерного изображения).
   • Диапазон от 0,0 до 1,0
   • Центр вокселя находится на половине metavoxelDimensions (т. е. 0,0 — угол вокселя, а 0,5 — центр).
3. Индекс вокселя
   • Целое число
   • Начало координат — в верхнем левом углу двухмерного изображения (верхний левый задний угол трехмерного изображения).
   • Диапазон от 0 до metavoxelDimensions — 1
   • Z — направление света, а X и Y — плоскости, перпендикулярные направлению света.

Положение вокселя в пространстве метавокселя определяется положением метавокселя P_M и индексами вокселя (X, Y). Индексы вокселя дискретны, их значение составляет от 0 до N-1 на протяжении метавокселя. На рис. 1 показана упрощенная сетка 2х2 метавокселей размером 8х8 вокселей с P_VIв метавокселе (1, 0) в позиции вокселя (2, 6).

Освещение

После вычисления цвета и плотности каждого вокселя в метавокселе вычисляется освещенность вокселей. В образце используется простая модель освещения. Пиксельный шейдер последовательно обходит столбец вокселей, умножая цвет вокселя на текущее значение света. Затем значение света корректируется с учетом плотности вокселя. Существует как минимум два способа корректировки освещения. Вреннинге и Зафар¹используют степень e^{-плотность}. Мы используем 1/(1+плотность). В обоих случаях результат изменяется от 1 на нулевом расстоянии до 0 на бесконечности. Результаты выглядят схоже, но деление может быть быстрее, чем exp().

L_n+1 = L_n/(1+плотность_n)

Обратите внимание, что этот цикл распространяет свет по единственному метавокселю. В коде свет распространяется от одного метавокселя к другому с помощью текстуры распространения света. Код записывает последнее значение распространения света в текстуру. Следующий метавоксель считывает свое начальное значение распространения света из этой текстуры. Размер этой двухмерной текстуры задается для всего объема. Это дает два преимущества: можно параллельно обрабатывать несколько метавокселей; итоговое содержимое можно использовать в качестве карты света для отбрасывания теней от объема на остальную сцену.

Тени

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

Шейдер проводит выборку карты теней один раз на метавоксель (на столбец вокселей). Шейдер определяет индекс (т. е. строку в столбце), в котором первый воксель попадает в тень. Воксели, находящиеся перед shadowIndex, не в тени. Воксели, находящиеся в позиции shadowIndexили после нее, находятся в тени.

Рисунок 2.Взаимосвязь между значениями Z теней и индексами

Значение shadowIndexсоставляет от 0 до METAVOXEL_WIDTHпо мере изменения значения тени от верхней части метавокселя к его нижней части. Центр локального пространства метавокселя находится в точке с координатами (0, 0, 0), пространство занимает область от -1,0 до 1,0. Поэтому верхний край имеет координаты (0, 0, -1),
а нижний край — (0, 0, 1). Преобразование в пространство света/теней:

Top    = (LightWorldViewProjection._m23 - LightWorldViewProjection._m22)
Bottom = (LightWorldViewProjection._m23 + LightWorldViewProjection._m22)

Что дает следующий код шейдера в FillVolumePixelShader.fx:

float shadowZ      = _Shadow.Sample(ShadowSampler, lightUv.xy).r;
float startShadowZ = LightWorldViewProjection._m23 - LightWorldViewProjection._m22;
float endShadowZ   = LightWorldViewProjection._m23 + LightWorldViewProjection._m22;
uint  shadowIndex  = METAVOXEL_WIDTH*(shadowZ-startShadowZ)/(endShadowZ-startShadowZ);

Обратите внимание, что метавоксели являются кубами, поэтому ширина METAVOXEL_WIDTHтакже является высотой и глубиной.

Текстура распространения света

В дополнение к вычислению цвета и плотности каждого вокселя FillVolumePixelShader.fx записывает итоговое значение распространенного света в текстуру распространения света. В образце кода эта текстура называется $PropagateLighting. Это двухмерная текстура, покрывающая весь объем. Например, образец, настроенный как объем 1024³ (32³ метавокселя по 32³ вокселя в каждом), будет иметь текстуру распространения света 1024x1024 (32*32=1024). Отметим два момента: эта текстура включает место для границы каждого метавокселя толщиной в один воксель; значение, сохраненное в текстуре, является последним значением до тени.

Каждый метавоксель имеет границу толщиной в один воксель, чтобы работала фильтрация текстур (при выборке в ходе отслеживания лучей из точки наблюдения). Объем отбрасывает тени на остальную сцену путем проецирования текстуры распространения света на эту сцену. При простой проекции появились бы визуальные артефакты в местах, где значения текстуры удваиваются для поддержки границы толщиной в один воксель. Артефактов удается избежать путем настройки координат текстуры с учетом этой границы. Вот этот код (из DefaultShader.fx):

float  oneVoxelBorderAdjust = ((float)(METAVOXEL_WIDTH-2)/(float)METAVOXEL_WIDTH);
float2 uvVol       = input.VolumeUv.xy * 0.5f + 0.5f;
float2 uvMetavoxel = uvVol * WIDTH_IN_METAVOXELS;
int2   uvInt       = int2(uvMetavoxel);
float2 uvOffset    = uvMetavoxel - (float2)uvInt - 0.5f;
float2 lightPropagationUv = ((float2)uvInt + 0.5f + uvOffset * oneVoxelBorderAdjust )
                          * (1.0f/(float)WIDTH_IN_METAVOXELS);

Текстура распространения света сохраняет значение света в последнем вокселе, который не находится в тени. Если процесс распространения света встречает поверхность затенения, то распространение света обнуляется (свет не распространяется дальше объекта, отбрасывающего тень). Сохранение последнего значения освещения дает возможность использовать текстуру в качестве карты освещенности. Проецирование этого последнего значения освещения на сцену означает, что поверхность отбрасывания теней получает ожидаемое значение освещения. Поверхности, находящиеся в тени, не используют эту текстуру.

Отслеживание лучей

Рисунок 3.Отслеживание лучей из точки наблюдения

В образце производится отслеживание лучей метавокселя с помощью пиксельного шейдера (EyeViewRayMarch.fx), выборка берется из трехмерной текстуры в виде представления ресурсов шейдера (SRV). Отслеживается каждый луч от дальнего края до ближнего по отношению к точке наблюдения. Отфильтрованные выборки отбираются из соответствующей трехмерной текстуры метавокселя. Каждый отобранный цвет добавляется в итоговый цвет, а каждая отобранная плотность затеняет итоговый цвет и добавляется в итоговый альфа-канал.

blend       = 1/(1+density)
colorresult = colorresult * blend + color * (1-blend)
alpharesult = alpharesult * blend

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

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

На рис. 3 видно, как выборки оказываются в разных метавокселях. Серые элементы находятся вне метавокселей. Красные, зеленые и синие элементы оказываются в разных метавокселях.

Тестирование глубины

Шейдер отслеживания лучей учитывает буфер глубины, обрезая лучи в соответствии с буфером глубины. Для повышения эффективности отслеживание лучей начинается с первого шага луча, проходящего проверку глубины.

Рисунок 4. Взаимосвязь между глубиной и индексомs

Взаимосвязь между значениями глубины и индексами отслеживания лучей показана на рис. 4. Код прочитывает значение Z из Z-буфера и вычисляет соответствующее значение глубины (т. е. расстояние от наблюдателя). Величина индексов изменяется пропорционально от 0 до totalRaymarchCount в соответствии с изменением глубины от zMin до zMax. Из этого кода получаем (из EyeViewRayMarch.fx):

float depthBuffer  = DepthBuffer.Sample( SAMPLER0, screenPosUV ).r;
float div          = Near/(Near-Far);
float depth        = (Far*div)/(div-depthBuffer);
uint  indexAtDepth = uint(totalRaymarchCount * (depth-zMax)/(zMin-zMax));

Здесь zMin и zMax — значения глубины с точки зрения отслеживания лучей. Значения zMax и zMin соответствуют самой дальней точке от наблюдателя и самой ближней к нему точке.

Сортировка.

При рендеринге метавокселей поддерживаются два порядка сортировки: один для света, другой для наблюдателя. Распространение света начинается в метавокселях, ближайших к источнику света, затем переходит к более дальним метавокселям. Метавоксели полупрозрачны, поэтому для получения правильного результата необходима сортировка с точки зрения наблюдателя. С точки зрения наблюдателя существует два способа сортировки: от заднего плана к переднему с «верхним» альфа-смешением и от переднего плана к заднему с «нижним» альфа-смешением.

Рисунок 5. Порядок сортировки метавокселей

На рис. 5 показано простое расположение трех метавокселей, камеры и источника света. Для распространения света требуется порядок 1, 2, 3; мы должны распространить свет через метавоксель 1, чтобы узнать, сколько света дойдет до метавокселя 2. Затем нужно провести свет через метавоксель 2, чтобы выяснить, сколько света достигнет метавокселя 3.

Также нужно сортировать метавоксели из точки зрения глаза. При рендеринге от переднего плана к заднему мы сначала отрисовали бы метавоксель 2. Синяя и фиолетовая линии показывают, почему расстояние до метавокселей 1 и 3 больше, чем до метавокселя 2. Нам нужно распространить свет через метавоксели 1 и 2 перед рендерингом метавокселя 3. В наихудшем случае требуется распространять свет через весь столбец перед рендерингом любого из его элементов. При рендеринге в порядке от заднего плана к переднему мы сможем отрисовать каждый метавоксель сразу же после распространения в нем света.

В образце сочетается сортировка от переднего плана к заднему и от заднего к переднему, чтобы поддерживать возможность рендеринга метавокселей сразу же после распространения света. Метавоксели над перпендикуляром (зеленая линия) отрисовываются от заднего плана к переднему с «верхним» смешением, а метавоксели под перпендикуляром — от переднего плана к заднему с «нижним» смешением. Такая процедура упорядочения всегда выдает правильные результаты, не требуя огромного объема памяти для размещения всего столбца метавокселей. Обратите внимание, что, если приложение способно выделить достаточно памяти, этот алгоритм всегда может сортировать от переднего плана к заднему с «нижним» смешением.

Альфа-смешение

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

«Верхнее» смешение: Цвет_{назначение} = Цвет_{назначение} * Альфа_{источник} + Цвет_{источник}

«Нижнее» смешение: Цвет_{назначение} = Цвет_{источник} * Альфа_{назначение} + Цвет_{назначение}

При этом альфа-смешение в обоих случаях работает одинаково: альфа-значение назначения увеличивается на альфа-значение пиксельного шейдера.

Альфа_{назначение} = Альфа_{назначение *} Альфа_{источник}

Ниже приведены состояния рендеринга для «верхнего» и «нижнего» смешения.

Состояния рендеринга «верхнего» смешения (из EyeViewRayMarchOver.rs)

SrcBlend          = D3D11_BLEND_ONE
DestBlend         = D3D11_BLEND_SRC_ALPHA
BlendOp           = D3D11_BLEND_OP_ADD
SrcBlendAlpha     = D3D11_BLEND_ZERO
DestBlendAlpha    = D3D11_BLEND_SRC_ALPHA
BlendOpAlpha      = D3D11_BLEND_OP_ADD

Состояния рендеринга «нижнего» смешения (из EyeViewRayMarchUnder.rs)

SrcBlend          = D3D11_BLEND_DEST_ALPHA
DestBlend         = D3D11_BLEND_ONE
BlendOp           = D3D11_BLEND_OP_ADD
SrcBlendAlpha     = D3D11_BLEND_ZERO
DestBlendAlpha    = D3D11_BLEND_SRC_ALPHA
BlendOpAlpha      = D3D11_BLEND_OP_ADD

Совмещение

Результатом отслеживания лучей из точки наблюдения является текстура с заранее умноженным значением альфа-канала. Мы отображаем полноэкранный спрайт с альфа-смешением для составления изображения с обратным буфером.

Цвет_{назначение} = Цвет_{назначение} * Альфа_{источник} + Цвет_{источник}

Состояния рендеринга:

SrcBlend  = D3D11_BLEND_ONE

DestBlend = D3D11_BLEND_SRC_ALPHA

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

Известные проблемы

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

Заключение

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

Разное

Некоторые слайды SPVR из презентации на конференции SIGGRAPH 2014:

https://software.intel.com/sites/default/files/managed/64/3b/VolumeRendering.25.pdf

См. пример в действии на Youtube*:

http://www.youtube.com/watch?v=50GEvbOGUks
http://www.youtube.com/watch?v=cEHY9nVD23o
http://www.youtube.com/watch?v=5yKBukDhH80
http://www.youtube.com/watch?v=SKSPZFM2G60

Дополнительные сведения об оптимизации для платформ Intel:

Whitepaper: Compute Architecture of Intel Processor Graphics Gen 8
IDF Presentation: Compute Architecture of Intel Processor Graphics Gen 8
Whitepaper: Compute Architecture of Intel Processor Graphics Gen 7.5
Intel Processor Graphics Public Developer Guides & Architecture Docs (Multiple Generations)

Благодарности

Благодарю за участие: Марка Фоконно-Дюфрена, Томера Барона, Джона Кеннеди, Джефферсона Монтгомера, Рэндалла Раувендала, Майка Берроуса, Фила Тэйлора, Аарона Кодэй, Егора Юсова, Филипа Стругара, Раджу Бала и Квернита Фремке.

Справочные материалы

1. M. Wrenninge и N. B. Zafar, SIGGRAPH 2010 и 2011 Production Volume Rendering, заметки к курсу: http://magnuswrenninge.com/content/pubs/ProductionVolumeRenderingFundamentals2011.pdf

2. M. Ikits, J. Kniss, A. Lefohn и C. Hansen, Volume Rendering Techniques (технологии объемной отрисовки), GPU Gems, http://http.developer.nvidia.com/GPUGems/gpugems_ch39.html

Дополнительные сведения об оптимизации компиляторов см. в нашем уведомлении об оптимизации.

Аннотация

igzip — высокопроизводительная библиотека для выполнения сжатия gzip или DEFLATE. Она была изначально описана в статье Высокопроизводительное сжатие DEFLATE для процессоров с архитектурой Intel. В этой статье описывается связанный выпуск исходного кода, содержащий необязательные (во время сборки) оптимизации для повышения степени сжатия геномных наборов данных в форматах BAM и SAM. igzip работает примерно в 4 раза быстрее, чем Zlib при настройке на максимальную скорость, и с примерно такой же степенью сжатия для геномных данных. Мы считаем, что igzip можно схожим образом оптимизировать для других областей применения, где наборы данных отличаются от обычных текстовых данных.

Обзор

Можно собрать две основные версии igzip: igzip0c и igzip1c. Первая работает быстрее, а вторая — чуть медленнее, но с более высокой степенью сжатия. Обе эти версии значительно быстрее, чем стандартные gzip -1 или Zlib -1, но отличаются чуть меньшей степенью сжатия. В этих реализациях используется набор инструкций SSE 4.2. Они предназначены для процессоров Intel, поддерживающих этот набор инструкций.

В [1] мы описали степень сжатия и производительность igzip при работе над данными общего назначения. После этого мы расширили реализацию для эффективной обработки геномных данных. В вычислительном процессе, используемом при определении геномной последовательности, серьезным ограничением производительности является сжатие данных. Существуют сценарии использования с долгосрочным хранением, когда требуется очень высокая степень сжатия, особенно если учесть значительные размеры наборов геномных данных. Тем не менее на различных этапах определения геномной последовательности существуют операции, в которых требуется очень быстрое сжатие с умеренной степенью сжатия. В этом исследовании мы сосредоточились на двух основных форматах данных, используемых для определения геномной последовательности; это форматы SAM и BAM.

Анализ этих форматов показал, что содержимое данных весьма специфично, встречается только в геномных данных и значительно отличается от обычных данных (например, от наборов данных в коллекции Университета Калгари). Мы выявили следующие основные свойства геномных данных: очень малая длина совпадений при обработке LZ77 (~90 % совпадений длиной менее 8 байт), очень малые смещения (у ~90 % совпадений сдвиг менее 1024 байт) и очень разнообразное распределение литералов (например, в формате SAM значительное количество символов A, T, G, C из обработанных строк последовательностей). Мы изменили таблицы Хаффмана в igzip таким образом, чтобы учесть эти особенности, и добились примерно такой же степени сжатия, как у Zlib-1, но в 4 раза быстрее.

Интерфейс программирования

API

struct LZ_Stream2 {
    UINT8 *next_in;   // Next input byte
    UINT32 avail_in;  // number of bytes available at next_in
    UINT32 total_in;  // total number of bytes read so far

    UINT8 *next_out;  // Next output byte
    UINT32 avail_out; // number of bytes available at next_out
    UINT32 total_out; // total number of bytes written so far
    UINT32 end_of_stream; // non-zero if this is the last input buffer

    LZ_State2 internal_state;
  };

  void init_stream(LZ_Stream2 *stream);
  void fast_lz(LZ_Stream2 *stream);

Основной принцип состоит в том, что next_in указывает на входной буфер, а avail_in указывает длину этого буфера. Аналогичным образом next_out указывает на пустой выходной буфер, avail_out указывает размер этого буфера.

Поля total_in и total_out начинаются с 0 и обновляются функцией fast_lz(). Они соответствуют общему количеству прочтенных или записанных байт на текущий момент на случай, если такая информация нужна вызывающему приложению.

Функция init_stream() статически инициализирует структуру данных потока, и в частности внутреннее состояние.

Вызов fast_lz() возьмет данные из входного буфера (обновив next_in и avail_in) и запишет сжатый поток в выходной буфер (обновив next_out и avail_out). Функция возвращается, когда либо avail_in, либо avail_out выдаст нуль (т. е. когда закончатся входные данные либо когда заполнится выходной буфер).

После передачи последнего входного буфера следует задать флаг end_of_stream. При этом процедура обработает битовый поток до конца входного буфера, если в выходном буфере достаточно места.

Простой пример

LZ_Stream2 stream;
    UINT8 inbuf[LEN_IN], outbuf[LEN_OUT];

    init_stream(&stream);
    stream.end_of_stream = 0;

    do {
        stream.avail_in = (UINT32) fread(inbuf, 1, LEN_IN, in);
        stream.end_of_stream = feof(in);
        stream.next_in = inbuf;

        do {
            stream.avail_out = LEN_OUT;
            stream.next_out = outbuf;

            fast_lz(&stream);

            fwrite(outbuf, 1, LEN_OUT - stream.avail_out, out);
        } while (stream.avail_out == 0);

        assert(stream.avail_in == 0);
    } while (! stream.end_of_stream);

Операция Zlib FLUSH_SYNC в данный момент не поддерживается.

Версии исходного кода

Параметры в файле options.inc определяют, какая версия будет собрана. Это определяет количество символов в синтаксисе YASM. Сценарий Perl преобразует этот файл в options.h для использования в коде C. Редактировать файл options.h вручную не следует. (Если Perl недоступен, можно вручную отредактировать options.h, но затем убедиться, что параметры в файлах options.h и options.inc совпадают.)

Как уже было сказано выше, две основные версии — это 0c и 1c. Версия выбирается путем редактирования файла options.inc, где может быть одна из следующих строк.

   %define MAJOR_VERSION IGZIP0C

или

   %define MAJOR_VERSION IGZIP1C

(В этом выпуске версии IGZIP0 и IGZIP1 не поддерживаются.)

В любой из этих версий можно выбрать одну из трех таблиц Хаффмана. Таблица по умолчанию предназначена для использования с большинством файлов. Существуют две другие таблицы, оптимизированные для использования с геномными приложениями, в частности для файлов в формате SAM и BAM. Чтобы выбрать одну из этих таблиц, раскомментируйте соответствующие строки (удалив начальную точку с запятой).

  ;%define GENOME_SAM
  ;%define GENOME_BAM

Если обе строки закомментированы (как показано выше), используются таблицы по умолчанию. Не следует раскомментировать обе эти строки одновременно.

По умолчанию igzip создает файл в формате GZIP (RFC 1952). Если строка

  ;%define ONLY_DEFLATE

раскомментирована, то будут сформированы выходные данные формата DEFLATE, т. е. без заголовков GZIP.

Рисунок 1: Поддерживаемые (протестированные) версии в этом выпуске

Код можно собрать в Linux или Windows. Существует Makefile для Linux. Код сочетает C и ассемблер. Для сборки ассемблерного кода следует использовать ассемблер YASM. Путь к YASM в Makefile можно изменить в соответствии с местом установки YASM в среде пользователя.

Собрать код можно (под управлением Linux) в виде статической библиотеки, например make lib0c или make lib1c, или в виде общего объекта, например make slib0c или make slib1c.

Результаты

Этот выпуск igzip поддерживает не только две основные версии (igzip0c и igzip1c), но и дополнительную оптимизацию для геномных наборов данных, в частности для файлов BAM и SAM. Эти файлы довольно сильно отличаются от обычных файлов, а распространенность статистических данных по каждому типу этих файлов означает, что можно оптимизировать таблицы Хаффмана для этой статистики и добиться более высокой степени сжатия.

Для иллюстрации три тестовых файла были сжаты при разных конфигурациях. Одним из тестовых файлов был progl из коллекции Университета Калгари (так называемого корпуса Калгари). Он соответствует обычному файлу. Два других файла — произвольные примеры геномных файлов форматов BAM и SAM. В каждом тесте была вычислена степень сжатия как частное от деления размера сжатого файла на размер несжатого файла (чем меньше, тем лучше). Для краткости показана только степень сжатия для «предпочитаемой» версии igzip (т. е. при запуске igzip0c-bam для файла BAM). Как и ожидалось, предпочитаемая версия обеспечивает более высокую степень сжатия, чем другие версии (например, при запуске igzip0c для файла SAM вместо igzip0c-sam). Кроме того, для упрощения мы показываем производительность igzip только для предпочитаемых типов данных. Производительность не слишком различается из‑за разных таблиц Хаффмана в igzip, она больше зависит от входного типа данных.

Примечание.Тесты и оценки производительности проводятся на определенных компьютерных системах и компонентах и соответствуют приблизительной производительности продуктов Intel в этих тестах. Любые отличия в оборудовании системы и в программном обеспечении или конфигурации могут повлиять на фактическую производительность. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности. Дополнительные сведения о тестах производительности и о производительности продуктов Intel см. по адресу http://www.intel.com/performance/resources/benchmark_limitations.htm

Результаты производительности, приведенные в этом разделе, были получены при измерении на процессоре Intel® Core™ i7 4770 (Haswell). Тесты проводились при отключенной технологии Intel^® Turbo Boost Technology и представляют производительность без использования технологии гиперпоточности Intel^® (Intel^® HT) на одном ядре. Мы предлагаем результаты для данных в памяти, исключая файловый ввод-вывод.

Мы скомпилировали реализации Zlib с помощью компилятора GCC с параметрами оптимизации aggressive. В качестве эталона для сравнения мы использовали Zlib версии 1.2.8.

Временные показатели измерялись с помощью функции rdtsc(), которая возвращает счетчик штампа времени процессора (TSC). TSC — это количество тактовых циклов после последнего сброса. TSC_initial — значение TSC, записанное перед вызовом функции. После завершения работы функции rdtsc() вызывается снова, чтобы записать новый счетчик циклов TSC_final. Фактическое количество циклов для вызванной процедуры вычисляется с помощью выражения:

кол-во циклов = (TSC_final-TSC_initial).

Для каждого файла проведено значительное количество таких измерений с последующим усреднением их результатов.

Рисунок 2. Разница в скорости и в степени сжатия igzip0c* по сравнению с gzip/Zlib -1

Производительность сжатия (циклов на байт) и степень сжатия

В таблице показаны степень сжатия и производительность для «предпочитаемой» версии igzip для соответствующего типа файлов. Видно, что, в частности, для тестовых файлов BAM и SAM, степень сжатия igzip очень близка с zlib -1. Для файлов в формате SAM степень сжатия и скорость оказались такими же, как для некоторых обычных файлов из набора данных Университета Калгари, тогда как для формата BAM и степень сжатия, и скорость ниже, чем для SAM (это касается и igzip, и Zlib). В формате BAM значительная часть данных полей уже упакована в двоичном формате, из-за чего сжатие при помощи алгоритмов LZ77 незначительно. В результатах видно, что по скорости igzip примерно в 4 раза быстрее Zlib (при настройке на максимальную скорость в обоих случаях).

Заключение

igzip — библиотека для высокоскоростного сжатия по алгоритму DEFLATE/gzip. Возможны ее различные конфигурации с разным соотношением степени сжатия и скорости. Кроме того, существуют дополнительные возможности оптимизации для геномных файлов BAM и SAM. При оптимизации степень сжатия близка к gzip -1, но скорость существенно выше. Изучив форматы SAM и BAM, мы считаем, что можно анализировать различные наборы данных из других приложений, которые могут довольно сильно отличаться от стандартных текстовых данных, и разрабатывать индивидуально подобранные реализации igzip со схожими результатами.

Авторы

Джим Гилфорд (Jim Guilford), Винод Гопад (Vinodh Gopal), Шон Галли (Sean Gulley) и Важди Фегали (Wajdi Feghali)

Благодарности

Пауло Нарваэс (Paolo Narvaez), Мишали Наик (Mishali Naik) и Гил Уолрич (Gil Wolrich), спасибо за участие!

Справочные материалы

[1] Высокопроизводительное сжатие Deflate: http://www.intel.com/content/www/ru/ru/
intelligent-systems/wireless-infrastructure/ia-deflate-compression-paper.html.

Дополнительные сведения об оптимизации компиляторов см. в нашем уведомлении об оптимизации.

By Edward J. Correia

Введение

Для разработчика Мэтта Пильца, уроженца Висконсина, тройка явно является счастливым числом. Пильц — основатель компании LinkedPIXEL, , и благодаря своим творческим способностям и упорному труду он одержал победу подряд на трех конкурсах разработчиковпроводимых корпорацией Intel. Недавно его приложение для рисования Scribblifyс 10-точечным сенсорным управлениеми графическим пользовательским интерфейсом на базе Google Chrome* получило главный приз на конкурсе Intel® App Innovation Contest 2013При разработке приложения использовались ресурсы с портала Intel® Developer Zone. Весной 2013 года Пильц выиграл конкурс Intel® Perceptual Computing Challenge, представив приложение Magic Doodle Pad,для рисования с управлением с помощью жестов руки. В 2012 году он выпустил игру Ballastic, оптимизированную для ультрабуков.

Как и в прошлых конкурсных работах, замысел приложения Scribblify (рис. 1) родился задолго до начала конкурса, но приложение Scribblify получило путевку в жизнь именно на мобильных устройствах. Будучи одним из 200 участников конкурса, получивших компьютер-моноблок Lenovo Horizon*от спонсора, корпорации Lenovo, Пильц с радостью принял идею переделать свое приложение для полноразмерного экрана. «Когда я узнал про моноблок Lenovo Horizon с огромным 27-дюймовым сенсорным экраном высокой четкости с разрешением 1920х1080, я понял, как здорово будет создать версию этого приложения для большого полотна, чтобы можно было рисовать прямо на праздничном столе или на других больших поверхностях, — говорит он. — Вот куда меня привела концепция программы». Для этого Пильцу пришлось изменить программу таким образом, чтобы она хорошо работала на экране вшестеро большем, чем раньше, и принимала сенсорный ввод с 10 точек касания вместо одной.

Рисунок 1.Scribblify позволяет пользователям создавать любые наброски и рисунки, от каракулей до настоящего искусства

Происхождение Scribblify

Пильц начал заниматься разработкой мобильных приложений в 2010 году, когда он приобрел свое первое мобильное устройство — Apple iPod touch*. Компания LinkedPIXEL выпустила раннюю версию Scribblify в следующем году. «Сначала интерфейс был предназначен для разрешения 480x320. Все было очень маленьким и компактным, чтобы поддерживать крайне ограниченные на тот момент аппаратные ресурсы», — вспоминает он.Приложение Scribblify для iOS* поступило в магазин App Store в январе 2011 года. «Его стали устанавливать, причем с каждым месяцем все больше», — говорит Пильц. Поэтому примерно год назад он выпустил версию для Google Android* .

Пильц описывает Scribblify как программу для непрофессионального рисования и набросков с некоторыми особыми возможностями. «Моя программа отличается от остальных кистями и цветовыми эффектами», — говорит он. Кисти (см. рис. 2), которые он создал сам, включают текстуры, отсутствующие в большинстве подобных приложений для рисования. «Мне нравится думать, что большинство их уникально», — говорит он, но тут же добавляет, что Scribblify не следует считать конкурентом мощных приложений для профессиональной работы над иллюстрациями. «Научиться работать с предназначенным для iPad эквивалентом такого приложения, как Photoshop, очень непросто, — заявляет Пильц. — С другой стороны, есть очень простые приложения для рисования, в которых только одна обычная круглая кисть и совсем немного разных параметров. А на промежуточном уровне, для которого я и задумал Scribblify, не было ничего подобного. Это приложение для пользователей любого возраста, и не нужно обучаться работе с ним: его достаточно просто запустить и можно сразу использовать».

Рисунок 2.В приложении Scribblify поддерживается 62 оригинальных кисти

Проблемы

Первое затруднение возникло, когда пришлось выбрать технологию для создания версии Scribblify для Microsoft Windows*. Сначала Пильц использовал пакет App Game Kit* (AGK) компании TGC, с помощью которого он ранее сделал игру Ballastic. «Мне удалось создать грубый прототип, но его функциональность была крайне ограничена по сравнению с тем, чего я хотел добиться в этом приложении», — говорит Мэтт. Для участия в конкурсе приложения должны быть разработаны для многопользовательского интерфейса Lenovo Aura* и не должны опираться на крупные фрагменты используемой операционной системы. Из правил следовало, что разработчики не должны были использовать никакие встроенные диалоговые окна Windows. «Было бы очень просто использовать в моем приложении стандартные диалоговые окна открытия и выбора файлов или их сохранения при взаимодействии с файловой системой, например, — говорит Пильц. — Но при этом исчезла бы нестандартность, к которой мы стремились на конкурсе Intel: сделать каждое приложение уникальным».

Для решения проблемы Пильц использовал Node.js*, — это серверная платформа JavaScript* на основе событий для создания сетевых служб для V8 — обработчика JavaScript в составе браузера Chrome. По словам Райана Даля, создателя Nodeэта платформа обеспечивает неблокирующий ввод-вывод с помощью цикла событий, а благодаря встроенному пулу событий поддерживает асинхронный файловый ввод-вывод.

«Основное назначение Node.js — разработка веб-приложений и использование их на настольных компьютерах вне зависимости от операционной системы, — говорит Пильц. — Нет необходимости даже в установке Windows. Базой всего приложения является Node.js». С помощью этой платформы и библиотеки под названием Node-Webkit, Пильц реализовал сохранение и загрузку файлов изображений с помощью интерфейса и галереи, которые он создал сам с помощью стандартных веб-технологий. Приложение работает на платформе Chromium* Embedded Framework (CEF), которая предоставляет мощные средства отображения HTML и JavaScript, такие же, как в браузере Chrome.

Как в Scribblify сохраняются и удаляются изображения
При первой загрузке приложения Scribblify общедоступная папка «Мои документы» пользователя открывается через Node.js.

// Initialize Node.js file system
var fs = require('fs');

// Get User's Documents Folder (Win 7+)
var galleryPath = process.env['USERPROFILE'] + "\Documents\Scribblify\";
galleryPath = galleryPath.replace(/\/g, "/"); // Use forward slashes

// See if folder exists, otherwise create it
if(!fs.existsSync(galleryPath))
{
    fs.mkdir(galleryPath);
}

Когда пользователь запрашивает сохранение файла, полотно HTML5 преобразуется в данные изображения.

var saveImg = canvas.toDataURL();

A unique filename is generated based on timestamp, and Node.js saves the image data to the system.
// Write image data buffer to file
var data = saveImg.replace(/^data:image/w+;base64,/, "");
var buf = new Buffer(data, 'base64');
var fName = galleryPath + destFilename;
fs.writeFile(fName, buf, function(err) {
    if(err)
    {
        console.log(err);
    }
});

Если пользователь хочет удалить изображение из галереи, в Node.js это делается очень просто.

fs.unlinkSync(galleryPath + targetImg);

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

var fileList = fs.readdirSync(currentPath);
var result = [];
for (var i in fileList) {
    var currentFileFull = currentPath + '/' + fileList[i];
    var currentFile = fileList[i];
    var fileExt = currentFile.split(".").pop().toUpperCase();
    var stats = fs.statSync(currentFileFull);
    if (stats.isFile() && fileExt == "PNG") {
       result.push(currentFile);
    }
    else if (stats.isDirectory()) {
         // Directory instead...
    }
}

После создания списка пути к изображениям сохраняются в массиве, их можно загрузить с помощью стандартных технологий HTML и JavaScript. Такой подход используется и для отображения галереи, и для импорта определенных изображений обратно на полотно.

Пильцу удалось создать прототип части функций приложения с помощью уже привычных технологий, включая встроенный в HTML5 элемент полотна для пользовательского интерфейса и Node.js для внутренней обработки, но некоторые из новых возможностей приложения оказалось не так просто реализовать. «Я попытался сделать то, что не так часто реализуется в виде веб-приложения: я хотел создать полное творческое приложение для рисования с кистями со сложными текстурами вместо фигур, которые образуются процедурами», — говорит он.

Сначала программа работала хорошо, но потом в ней обнаружилась проблема. «При использовании нескольких точек касания или при слишком быстром рисовании приложения зависало на несколько секунд из-за недостаточной производительности элемента полотна, а затем продолжало работу», — заявляет автор. Поиск решения привел разработчика к Cocos2d-x, это межплатформенная среда с открытым исходным кодом, доступная по лицензии Массачусетского технологического института (МТИ). Недавно в ее ветвь JavaScript была добавлена поддержка WebGL.

С помощью Cocos2d-Javascript удалось намного удобнее перенести код на WebGL, где производительность была намного выше, учитывая хорошую поддержку видеокарты, которой был оборудован моноблок. «Теперь Cocos2d-Javascript отрисовывает изображения на экране с помощью WebGL, кадровая скорость при этом достигает 60 кадров в секунду. Теперь пользоваться программой стало удобно и интересно», — говорит Пильц. В Scribblify используется стандартный HTML для элементов интерфейса и взаимодействия с пользователями. Пильц описывает решение как гибрид стандартного HTML и JavaScript вместе с другими обработчиками, включая Node.js для внутренней обработки и Cocos2d-Javascript для упрощенной отрисовки WebGL.

Для решения общих вопросов Пильц использовал бесплатный сайт Stack Overflow, на котором профессиональные разработчики и программисты-любители обмениваются ответами на вопросы. «Несколько раз бывало, что я изучал определенные задачи или сталкивался с разными затруднениями, — говорит разработчик. — В таких случаях самый быстрый и удобный способ найти решение — это посмотреть, что рекомендуют другие». Для справки по Cocos2d-xи Node.js, Пильц активно использовал API этих продуктов, и, разумеется, он использовал CodeProject* не только для этого проекта, но и для других своих работ. «Я обращаюсь туда всякий раз, когда мне нужна более подробная информация по определенным вопросам программирования, — говорит Пильц. — Там очень полезные форумы обсуждений, связанные с этим конкурсом, и всегда можно очень быстро получить ответ на вопрос».

Пильц также обнаружил ошибку в обработке касаний в Chromium с набором драйверов Lenovo Horizon: после некоторых касаний не срабатывает высвобождение, особенно при быстром использовании. Для решения этой проблемы он создал небольшую «систему сдержек и противовесов», которая выдает предупреждение, если по ошибке записано избыточное количество касаний. Изображение пользователя будет автоматически сохранено в галерее, после чего пользователю будет предложено перезапустить приложение. Затем предоставляются советы по устранению таких проблем в будущем. «Если пользователь коснется экрана, к примеру, всей ладонью, то программа покажет оповещение с предупреждением, что так делать не следует, нужно касаться экрана кончиками пальцев. Помимо этого, программа предложит перезапустить ее, — сказал он. — Я сообщил об этом, отправив формальное сообщение об ошибкеразработчикам Chromium в ходе конкурса.»

var canvas = document.getElementById('canvas');
canvas.addEventListener('touchstart', touchStartFunction, false);
canvas.addEventListener('touchend', touchEndFunction, false);
canvas.addEventListener('touchcancel', touchCancelFunction, false);
canvas.addEventListener('touchmove', touchMoveFunction, false);
canvas.addEventListener('touchleave', touchLeaveFunction, false);

Платформа Chromium* Embedded Framework (на основе которой построен браузер Google Chrome*) уже долгое время поддерживает сенсорное управление, а внедрять ее очень просто. Можно фиксировать различные формы касаний с помощью простых обработчиков событий, таких как touchstart, touchend, touchcancel, touchmoveи touchleave.

Из-за ограничений конкурса по времени, а также из-за технических ограничений платформы, с которой работал Пильц, от реализации некоторых функций в Scribblify пришлось отказаться. «Важная функция, которую мне очень хотелось добавить — это полноценная система отмены всех действий и их повтора, но для меня это - «терра инкогнита», мне не удалось разобраться, как реализовать эту функциональность без снижения скорости работы всей системы», — заявляет Пильц. Поэтому на данный момент есть ластик и кнопка для очистки всего полотна. Разработчик также собирается добавить еще несколько режимов рисования и новые кисти.

Отладка

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

«Для меня наиболее удобным оказалось то, что средства Chrome для разработчиков включают полнофункциональный отладчик JavaScript. Это дало мне возможность создавать точки остановки и пошагово проходить по коду, отслеживая определенные переменные и свойства, особенно при возникновении проблем», — говорит разработчик. При этом Пильцу удалось проанализировать специфичные элементы модели DOM и обновлять стили на лету, чтобы быстрее достичь нужного результата. Пильц также обнаружил полезные ресурсы для разработчиков, предоставленные корпорацией Lenovo на сайте lenovodev.com, в частности, требования по интеграции для приложений Horizon (требуется регистрация).

Многопользовательский режим

Scribblify для моноблока поддерживает 10 одновременных точек касания. Это означает, что одновременно рисовать изображение на полотне могут 10 пользователей. Учитывая временные рамки конкурса, Пильц уделял основное внимание удобству, с которым можно было интегрировать возможности мультисенсорного управления. «Когда я принял окончательное решение разрабатывать веб-приложение с помощью HTML5 и соответствующих технологий, я знал, что сложности обработки мультисенсорного ввода можно обойти, если используемая веб-платформа уже будет поддерживать мультисенсорный ввод», — говорит он.

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

Дополнительные статьи

• Моноблоки: возможности разработчиков
• Руководство разработчика по графике для процессоров Intel® (для процессоров Intel® Core™ 4-го поколения
• Разработка увлекательных приложений для нового поколения компьютеров-моноблоков

Новые возможности

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

Пильц также гордится пользовательским интерфейсом, который ему удалось создать практически с нуля всего за 6 недель. «Рисовать всеми десятью пальцами одновременно с помощью 10-точечного мультисенсорного ввода, или когда один пользователь сидит с одной стороны от экрана, а другой — с другой стороны, и они оба одновременно рисуют — по-моему, это совершенно новый подход», — заявляет автор. Пильц признает, что в некоторых возможных случаях он использовал уже готовые решения. «Я использовал кое-какие библиотеки, например, для расширенного выбора цветов, — говорит он. — Некоторые библиотеки с лицензией МТИ ускоряют этот процесс, так что мне не пришлось изобретать велосипед».

В Scribblify также поддерживается новый способ выбора и смешения цветов. «Можно добавить много разных цветовых эффектов, поэтому вы не просто выбираете какой-то базовый цвет, — говорит Пильц. — Можно смешать два цвета вместе или использовать цвета плазмы или даже добавить то, что я называю цветовой переменной, где по мере рисования чередуются темные и светлые оттенки, чтобы картинка получилась более естественной».

Недавно Пильц приступил к работе над переделкой Scribblify в приложении для Windows 8, чтобы можно было распространять его через Магазин Windows, в том числе и с помощью специализированного «отдела» Магазина Windows 8 для Lenovo. Для выполнения требований самым простым способом будущая версия Scribblify будет работать на базе Internet Explorer* 11 вместо Chromium и будет использовать новые способы обработки ввода-вывода файлов, поскольку Node.js не поддерживается. Выпуск версии Scribblify для Магазина Windows ожидается в апреле или мае 2014 года.

О конкурсе

В конкурсе Intel App Innovation Contest 2013 разработчикам приложений с порталов Code Project, Habrahabr, ThinkDigitи CSDN, tбыло предложено предоставить идеи приложений для планшетов под управлением Windows и ПК-моноблоков для финансов, здравоохранения, розничной торговли, образования, игр и развлечения. Авторам лучших идей выдавали системы разработки — 200 планшетов и 300 ПК-моноблоков спонсора конкурса, корпорации Lenovo, и предоставляли 6 недель, чтобы воплотить идею в демонстрационную версию приложения. Победившие в конкурсе приложения перечислены здесь,на сайте Intel® Developer Zone.

500 идей было использовано для создания 276 демонстрационных приложений, из которых было отобрано по 5 лучших в 6 категориях. Таким образом, всего в конкурсе 30 приложений-победителей. Приложения оценивались по следующим критериям: насколько хорошо каждое приложение демонстрирует возможности платформы, насколько хорошо оно удовлетворяет потребности данного сегмента рынка, и насколько успешно оно отвечает нуждам предполагаемых конечных пользователей. Разумеется, приложения-победители должны выглядеть достаточно профессионально и использовать хорошую графику, работать быстро и без ошибок и в нужных случаях использовать датчики и сенсорное управление.

В этой статье рассматриваются все операции масштабирования в Intel Media SDK. Масштабирование — одна из самых распространенных операций при обработке видео. Приложение может задать нужную область для каждого видео с помощью конвейера обработки видео (VPP). Используя Intel Media SDK VPP, можно выполнять различные операции масштабирования. Здесь мы описываем две наиболее часто используемые операции и их результаты.

1. Обрезка
2. Изменение размера

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

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

int GetFreeSurfaceIndex(mfxFrameSurface1** pSurfacesPool, mfxU16 nPoolSize)
{
    if (pSurfacesPool)
        for (mfxU16 i = 0; i < nPoolSize; i++)
            if (0 == pSurfacesPool[i]->Data.Locked)
                return i;
    return MFX_ERR_NOT_FOUND;
}

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

mfxStatus LoadRawFrame(mfxFrameSurface1* pSurface, FILE* fSource)
{
    w = pInfo->Width;
	    h = pInfo->Height;
    pitch = pData->Pitch;
	    ptr = pData->Y;
    //read luminance plane
    for (i = 0; i < h; i++) {
        nBytesRead = (mfxU32) fread(ptr + i * pitch, 1, w, fSource);
        if (w != nBytesRead)
            return MFX_ERR_MORE_DATA;
    }
    mfxU8 buf[2048];        // maximum supported chroma width for nv12
    w /= 2;
    h /= 2;
    	ptr = pData->UV;

    // load U
    sts = ReadPlaneData(w, h, buf, ptr, pitch, 0, fSource);
    if (MFX_ERR_NONE != sts)
        return sts;
    // load V
    ReadPlaneData(w, h, buf, ptr, pitch, 1, fSource);
    if (MFX_ERR_NONE != sts)
        return sts;
}

Операция записи на выходную поверхность — после операции RunFrameVPPSync, асинхронно обрабатывающей кадр. Операция синхронизации вызывается для получения всех выходных данных для их обратной записи в необработанный кадр.

mfxStatus WriteRawFrame(mfxFrameSurface1* pSurface, FILE* fSink)
{
    mfxFrameInfo* pInfo = &pSurface->Info;
    mfxFrameData* pData = &pSurface->Data;
    mfxU32 i, j, h, w;
    mfxStatus sts = MFX_ERR_NONE;

	    for (i = 0; i < pInfo->Height; i++)
		    sts =
    WriteSection(pData->Y, 1, pInfo->Width, pInfo, pData, i, 0,
		    fSink);

			    h = pInfo->Height / 2;
			    w = pInfo->Width;

    for (i = 0; i < h; i++)
        for (j = 0; j < w; j += 2)
            sts =
                WriteSection(pData->UV, 2, 1, pInfo, pData, i, j,
                             fSink);
    for (i = 0; i < h; i++)
        for (j = 1; j < w; j += 2)
            sts =
                WriteSection(pData->UV, 2, 1, pInfo, pData, i, j,
                             fSink);
    return sts;
}

Мы будем использовать sample_vpp из учебного руководства на странице Media Solution Portal Входной файл foreman.yuv можно получить здесь. Загруженный файл будет в формате Y4M, его нужно будет преобразовать в формат YV12 с помощью ffmpeg.

ffmpeg -i input.y4m output.yuv

Для операций масштабирования используются шесть параметров VPP.

• CropX, CropY, CropW, CropHопределяют расположение входного и выходного кадров, которое требуется задать явным образом для получения результата.
• Параметры Widthи Heightследует задать явным образом и для входного, и для выходного кадра. При этом значения высоты и ширины должны быть кратны 16 для кадровых изображений и кратны 32 для полей. 

Обрезка- это одна из самых распространенных операций по обработке видео, она часто используется для определения рабочей области (ROI). С ее помощью также можно изменить соотношение сторон видео. Наиболее распространенные изменения: 16:9->4:3 и 4:3->16:9. При изменении соотношения сторон к изображению добавляются черные полосы либо сверху и снизу, либо справа и слева. Ниже приведена таблица входных параметров для обрезки, изменения соотношения сторон с добавлением черных полос сверху и снизу, справа и слева в sample_vpp.

Вот какие результаты вы получите при использовании этих параметров. 

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

Вот какие результаты вы получите при использовании этих параметров.

Более подробные сведения о параметрах и функциях вы найдете в руководстве пользователя, которое находится в папке документов установленной копии MSDK или доступноздесь.

Download Source

Введение

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

В этой статье мы увидим, как использовать библиотеки JavaScript с открытым исходным кодом вместе с Intel XDK для разработки межплатформенных приложений.

Базовые сведения

На сегодняшний день на рынке доступно множество библиотек JavaScript с открытым исходным кодом, многие из которых обеспечивают DOM-манипуляции, помогают создавать пользовательские интерфейсы и т. д. Такие библиотеки обычно работают в любых браузерах. Несоответствия между браузерами обычно обрабатываются внутри таких библиотек.

До недавнего времени JavaScript считался языком разработки веб-приложений. В последнее время модель его использования изменилась: в сочетании с HTML5 он позволяет создавать не только веб-приложения, но и гибридные приложения. Теперь JavaScript является основным языком разработки приложений для Магазина Windows*.

Intel® XDK — инструмент для создания межплатформенных приложений с помощью HTML5 и JavaScript. Применяя единый инструмент, можно разрабатывать, тестировать и развертывать гибридные приложения и веб-приложения HTML5 и JavaScript. Опубликовать пакет приложения можно в Android*, iOS*, Amazon Appstore, Windows Store и т. д.

Принцип «межплатформенности» и означает однократное написание кода и развертывание на любых платформах. Написать приложение можно с помощью платформо-нейтральных языков HTML5 и JavaScript. Intel XDK поможет упаковать этот код для запуска на разных платформах, таких как Android, iOS, Windows 8, Tizen* и пр. Код, написанный на HTML и JavaScript, можно просматривать не только в браузере, но и с помощью WebView. Каждая платформа располагает элементом управления WebView, который может быть использован вашим приложением для отображения страниц HTML. Intel XDK использует WebView для отображения вашего кода на всех поддерживаемых платформах. Этот контейнер Intel XDK располагает доступом к собственным возможностям платформы, которые затем предоставляются приложению через JavaScript.

Разработчики приложений для Магазина Windows иногда сталкиваются с некоторыми затруднениями при использовании открытого исходного кода JavaScript, главным образом из-за ограничений, связанных с безопасностью в Windows. Например, в приложениях для Windows Store запрещена динамическая загрузка ресурсов JavaScript или манипуляция DOM во время выполнения (хотя и существует способ обойти эту проблему). Тем не менее, поскольку приложения разрабатываются в Intel XDK для запуска в контейнере, эти ограничения не действуют.

Принимая во внимание все вышеизложенное, мы создали образец приложения с помощью AngularJS — одной из самых популярных библиотек JS с открытым исходным кодом.

Ограничение в Intel XDK

Здесь есть один подвох, о котором следует помнить. Для создания пользовательского интерфейса конструктор приложений App Designer в Intel XDK использует DOM. Если вы выберете библиотеку JS, которая конфликтует с классами CSS конструктора приложений Intel XDK, то не сможете использовать этот удобный конструктор для создания приложения. В таких случаях можно создать пустой проект, выбрав Start with blank project. В этом случае вы сможете использовать все функции Intel XDK, кроме конструктора приложений.

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

Пример приложения для регистрации учеников

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

Создание приложения реестра учеников

Шаг 1.Создайте новое приложение и выберите Start with App Designer. Введите имя проекта и щелкните Create.

Шаг 2.Выберите фреймворк для приложения. Я в этом примере выбрал просто App Framework.

Теперь переходим к созданию страницы приложения.

Для нашего приложения и для списка учеников нам нужны следующие поля.

Поля:

1. Имя
2. Фамилия
3. Пол
4. Возраст
5. Секция
6. Кнопка «Добавить»

Для этого проекта выберите окно просмотра tablet.

Теперь добавим listviewдля отображения добавленных учеников. Поскольку нужно наполнять список динамически, мы сохраним один элемент списка (для получения формата) и удалим все остальные.

Теперь перейдите в режим кода.

Шаг 3.Нужно загрузить последнюю версию файла angular.js по адресу https://angularjs.org/.

Создайте новую папку JSвнутри папки www и скопируйте в нее файл angular.js, загруженный с веб-сайта angularjs.org. Добавьте ссылку на этот файл в файле index.html.

Теперь angular.jsготов к использованию.

Шаг 4.Создайте класс контроллера. Angular.jsиспользует класс контроллера для обработки пользовательских событий и для манипуляций с данными. Будем использовать встроенный тег script (вы можете создать собственный файл JS и добавить в него этот код).

<script type="text/javascript">
            function StudentManager($scope)
            {
                //An JSON array to hold the student list.
                $scope.students = [];

                //addStudent will add the new student to the list.
                $scope.addStudent = function() {
                $scope.students.push({firstName:$scope.firstName,
                                      lastName:$scope.lastName,
                                      age:$scope.age,
                                      gender:$scope.gender,
                                      section:$scope.section});
                $scope.firstName = '';
                $scope.lastName = '';
                $scope.age = 0;
                $scope.gender = '';
                $scope.section = '';
              };
            }</script>

При этом будет создан новый класс контроллера для вашей страницы.

Шаг 5.Изменяем содержимое HTML.

Шаг 5.1. Теперь запускаем страницу с помощью ng-app. Указываем этот атрибут в теге <body id="afui" ng-app>.

Внимание! Иногда система может удалять этот атрибут при переключении между режимом конструктора и режимом кода. Проверьте этот атрибут и снова добавьте его, если он удален.L control. We will attach this controller to the root level div element.

Шаг 5.2. Свяжите контроллер с элементом управления HTML. Мы привязываем этот контроллер к элементу div корневого уровня.

<div class="uwrap" id="content" ng-controller="StudentManager">

Шаг 5.3. Теперь нужно начать присоединять модели ng-modelк полям ввода. Сначала нужно создать поля для ввода имени, фамилии, возрастаи секции.

<div class="table-thing with-label widget uib_w_2 d-margins" data-uib="app_framework/input" data-ver="1"><label class="narrow-control label-inline">First Name</label><input class="wide-control" type="text" ng-model="firstName"></div>

Аналогичным образом добавим ng-modelи для других полей. Назовем их, соответственно, lastName, age, genderи section.

Шаг 5.4.Найдите тег привязки кнопки «Добавить» и свяжите обработчик событий addStudentс событием ng-click.

<a class="button widget uib_w_10 d-margins green" data-uib="app_framework/button" ng-click="addStudent()" data-ver="1">Add</a>

Шаг 6. Нужно показать список учеников в listview.

Найдите составленный нами ранее список одиночных элементов. Замените <li>на следующее:

<li class="widget uib_w_8" data-uib="app_framework/listitem" data-ver="1" ng-repeat="student in students"><a>Name: {{student.firstName}} {{student.lastName}} <br />Age: {{student.age}}<br /> Gender: {{student.gender}} <br />Section: {{student.section}}</a></li>

Вот и все. Осталось протестировать код на имитаторе и исправить все оставшиеся ошибки.

Шаг 7. После исправления ошибок код готов к развертыванию. Выберите нужный магазин приложений и соберите пакет, предоставив необходимые метаданные.

На следующем снимке экрана показано действующее приложение в Магазине Windows.

Вот как оно выглядит на планшете iPad*.

Заключение

Intel XDK — удобный инструмент для разработки, тестирования и упаковки приложений HTML5 и JavaScript. Библиотеки JavaScript с открытым исходным кодом упрощают разработку; это высококачественные межплатформенные, совместимые с браузерами библиотеки. Intel XDK поддерживает большинство библиотек JavaScript с открытым исходным кодом, если использовать параметр Start with blank project. В этом случае можно использовать все функции Intel XDK, кроме App Designer. Можно также импортировать вашу существующую базу кода.

App Designer — без сомнений, очень удобный компонент. Но если вы хотите его использовать, то необходимо выбирать такие библиотеки, которые не образуют конфликты с работой App Designer. В нашем примере библиотека KnockoutJS не работает с App Designer, поэтому ее нельзя использовать.

Об авторе

Рагавендра Урал (Raghavendra Ural) — эксперт Intel в таких областях, как датчики в Windows 8, HTML5, Intel XDK и компьютерные системы с управлением без помощи контроллеров. Его рабочий опыт в области ИТ насчитывает 14 лет, все это время он занимался различными веб-технологиями и корпоративными решениями. В настоящий момент он занимается популяризацией и внедрением Windows 8, HTML5, других средств Intel и пакетов SDK. Рагавендра увлекается распространением знаний, изучением технических проблем и их решением. Он занимает должность разработчика-евангелиста в подразделении Developer Relationships корпорации Intel.

Intel и эмблема Intel являются товарными знаками корпорации Intel в США и в других странах.

© Intel Corporation, 2014. Все права защищены.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Download Sketch Code Sample

Аннотация

В этом образце кода демонстрируется использование Intel® RealSense™ SDK для Windows* для создания простого приложения для виртуального рисования под названием Sketch. В этом классическом приложении для Windows, разработанном на C#/WPF, демонстрируется ряд возможностей отслеживания положения руки и распознавания жестов в Intel RealSense SDK:

• получение трехмерных (абсолютных) координат суставов кисти руки;
• избирательное получение данных о жестах;
• получение информации о состоянии (обнаружение руки, калибровка, состоянии границ).

(Примечание. Для реализации полной функциональности этого приложения требуется направленная на пользователя трехмерная камера.)

Посмотрите короткое видео о Sketch тут. 

Введение в приложение Sketch

Sketch — простое приложение для рисования, позволяющее пользователю имитировать рисование на полотне, передвигая руку и применяя жесты. На рис. 1 показан пользовательский интерфейс приложения Sketch (разработанного в WPF/XAML).

Рисунок 1. Пользовательский интерфейс приложения Sketch

Для взаимодействия с виртуальным полотном применяются три жеста (они показаны на экране вместе с соответствующими действиями).

• Сведение пальцев («Рисование») — указатель превращается в перо и рисует линию на полотне. Положение указателя на полотне определяется координатами X и Y кончика среднего пальца пользователя. Толщина рисуемой линии определяется положением кончика среднего пальца пользователя по оси Z (если отодвинуть палец от камеры, линия становится тоньше, как при уменьшении нажима на перо или карандаш).

• Разведение пальцев («Движение») — отключение пера, указатель превращается в пустую окружность. «Движение» позволяет перемещать перо по полотну, не рисуя линии. Оно также позволяет выбирать цвета на расположенной справа палитре: достаточно навести указатель на нужный цвет.

• Махание («Очистка») — удаление всех нарисованных линий и очистка полотна, чтобы на нем можно было рисовать заново.

Подробные сведения

Приложение Sketch имитирует рисование на полотне, когда пользователь делает жест «two_fingers_pinch_open» (сведение двух пальцев). Этот жест был выбран, поскольку он близок к положению, которое примет кисть руки, когда пользователь будет держать карандаш или перо. Этот жест показан на рис. 2.

Рисунок 2. Жест рисования

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

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

Ознакомьтесь

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

О технологии Intel^® RealSense™

Чтобы приступить к работе и узнать больше о Intel RealSense SDK для Windows, перейдите по адресу https://software.intel.com/ru-ru/realsense/intel-realsense-sdk-for-windows.

Об авторе

Брайан Браун — инженер по разработке программных приложений в подразделении Developer Relations корпорации Intel. Его профессиональный опыт охватывает создание программного обеспечения и электроники, а также проектирование систем. Среди интересующих его направлений — применение технологий естественного взаимодействия и интерфейсов между компьютером и мозгом. Он активно участвует в нескольких программах разработки различных передовых технологиях в этих областях.

Download Blockhead Code Sample

Аннотация

В этом образце кода демонстрируется использование Intel® RealSense™ SDK для Windows* в классическом приложении на C#/WPF. Образец приложения под названием BlockHeadиспользует три интересных функции Intel RealSense SDK:

• получает и отображает цветное изображение с камеры RGB;
• получает оценочные данные о расположении лица и положении головы;
• получает и анализирует данные о выражении лица.

(Примечание. Для реализации полной функциональности этого приложения требуется направленная на пользователя трехмерная камера.)

Посмотрите короткое видео о BlockHeadтут. 

Введение в приложение Blockhead

Как показано на рис. 1, приложение отображает поток цветовых данных в элементе управления WPF Image и в реальном времени накладывает мультипликационное изображение на лицо пользователя. 

Рисунок 1.Наложение мультипликационного изображения на лицо пользователя

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

• Изображение масштабируется в соответствии с лицом пользователя (уменьшается, когда пользователь отодвигает голову от камеры, и увеличивается, когда пользователь приближает голову к камере) на основе информации о прямоугольной зоне лица.
• Изображение наклоняется влево и вправо в зависимости от положения головы пользователя (поворот вокруг продольной оси).
• Содержимое изображения изменяется на основе получения и анализа данных о выражении лица пользователя (см. рис. 2).

Рисунок 2.Распознавание улыбки, высунутого языка, воздушного поцелуя и открытого рта в реальном времени

Подробные сведения

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

Различные преобразования (например, ScaleTransform, RotateTransform) применяются к объекту изображения для изменения его положения в соответствии с данными Intel RealSense SDK о положении головы. Эти данные включают расположение лица, расположение головы и данные распознавания выражения лица.

SDK может фиксировать около 20 различных выражений лица, которые затем можно анализировать в приложении. В этом приложении основное внимание уделяется выражениям лица с различными очертаниями рта: EXPRESSION_KISS, EXPRESSION_MOUTH_OPEN, EXPRESSION_SMILE и EXPRESSION_TONGUE_OUT. При этом можно без труда расширить возможности приложения, чтобы также использовать информацию о положении головы, глаз и бровей для определения выражения лица.

Ознакомьтесь

Чтобы узнать больше об этом приложении, просмотреть код и развить его, добавив более интересные возможности, опирающиеся на Intel RealSense SDK, загрузите этот пакет здесь.

О технологии Intel^® RealSense™

Чтобы приступить к работе и узнать больше о Intel RealSense SDK для Windows, перейдите по адресу https://software.intel.com/ru-ru/realsense/intel-realsense-sdk-for-windows.

Об авторе

Брайан Браун — инженер по разработке программных приложений в подразделении Developer Relations корпорации Intel. Его профессиональный опыт охватывает создание программного обеспечения и электроники, а также проектирование систем. Среди интересующих его направлений — применение технологий естественного взаимодействия и интерфейсов между компьютером и мозгом. Он активно участвует в нескольких программах разработки различных передовых технологиях в этих областях.

Аннотация

Корпорация Intel представляет первый из процессоров пятого поколения (Broadwell), выпуская три модели семейства Intel^® Core™ M. Эта статья, предназначенная для разработчиков, описывает этот 64-разрядный многоядерный процессор с архитектурой «система на кристалле» и описывает реализованные в нем технологии Intel^®, включая Intel^® HD Graphics 5300.

Основные характеристики процессоров Intel Core M

Семейство процессоров Intel^® Core™ M отличается более высокой производительностью при более компактных размерах, сниженных требованиях к электропитанию и охлаждению (что отлично подходит для тонких устройств без вентиляторов), а также более длительной работе от аккумуляторов. Процессоры поддерживают следующие технологии:

• Intel HD5300 Graphics и Intel® Wireless Display 5.0;
• Intel Wireless-AC 7265 и поддержка беспроводной стыковки (в 2015 г.) с помощью WiGig;
• технология Intel® Smart Sound;
• технология Intel® Platform Protection и другие средства безопасности.

Уменьшение размера + повышение производительности = снижение требований к электропитанию и охлаждению

Intel Core M — первые процессоры, которые будут изготавливаться на основе 14-микронной технологии. Размер кремниевого кристалла удалось сократить более чем на 30 %, хотя количество транзисторов увеличилось более чем на 300 миллионов.  Процессоры Intel Core M отличаются сниженной потребляемой мощностью и выделяют меньше тепла. У трех моделей этого семейства, выпуск которых начался в IV квартале 2014 года, тепловая мощность составляет всего 4,5 Вт. Это означает, что для охлаждения этих процессоров не нужен вентилятор. Эти процессоры позволят добиться высокой производительности в самых тонких устройствах (толщиной менее 9 мм), включая планшеты и трансформеры.

Рисунок 1. Сравнение процессоров Intel Core M с пониженным потреблением электроэнергии

На графике слева на рис. 1 показано снижение тепловой мощности с 18 Вт в 2010 году до 4,5 Вт в процессоре Intel Core M. Это четырехкратное снижение за 4 года и снижение на 60 % по сравнению с 2013 годом. Справа на рис. 1 показано сравнение размеров процессора Intel® Core™ 4-го поколения с новым процессором Intel Core M. За счет уменьшения площади процессора примерно на 50 % удалось уменьшить место, занимаемое процессором на плате, примерно на 25 %.

Процессоры Intel Core M по своим габаритным размерам меньше  процессоров Intel Core 4-го поколения.   При этом двумя ядрам Intel Core M предоставляется кэш объемом 4 МБ. За счет технологии гиперпоточности гипертрединга Intel® поддерживается одновременное выполнение четырех потоков. Благодаря технологии Intel® Turbo Boost 2.0 частота ядер может повышаться с 0,8 ГГц до 2 ГГц, а у процессоров Intel Core M 5Y70 — с 1,1 ГГц до 2,6 ГГц.

 

В едином кристалле с 1,3 млрд транзисторов реализованы ЦП, ГП, контроллер памяти, звуковой контроллер и сетевые интерфейсы, поэтому не следует ожидать снижения производительности. Более того, сравнение с процессором предыдущего поколения Intel^® Core™ i5-4320Y показало значительный прирост производительности.

Технология электропитания

Повсюду в этом документе упоминаются многочисленные технологии Intel, предназначенные для снижения электропитания. Технология Intel® Turbo Boost 2.0 включает модуль отслеживания электропитания, вычисляющий мощность ядер ЦП и ГП, а также модуль управления электропитанием, направляющий электроэнергию туда, где она нужна.  Расширенная технология Intel SpeedStep®с поддержкой C-состояний C0, 1, 1E, 3 и 6—10 обеспечивает наименьшее потребление электропитания в состоянии бездействия. Если требуется увеличить вычислительную мощность, процессор повышает напряжение для быстрого переключения. При включенном гипертрединге это переключение происходит на уровне потоков. Обработка прерываний оптимизирована с точки зрения  электропитания за счет применения X2 APIC и PAIR (маршрутизация прерываний с учетом электропитания): состояние ядер проверяется, чтобы избежать пробуждения ядер, находящихся в состоянии глубокого сна.

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

Прочие компоненты

На одном кристалле Intel Core M расположен также узел контроллера платформы PCH с интеллектуальным управлением электропитанием, поддерживающий PCIe NAND, PCIe 2.0 (12 каналов x1,x2 или x4) и два дополнительных порта USB 2.0.

Интегрированный контроллер памяти поддерживает технологии Intel^® Fast Memory Access и Intel^®
Flex-Memory Access. Экономия электроэнергии обеспечивается с помощью таких решений, как условное самообновление, динамическое понижение напряжения и отключение неиспользуемой системной памяти посредством четырех отключаемых модулей. Поддерживается оперативная память DDR3L или LPDDR3 частотой 1600 МГц или 1333 МГц, разделенная на 2 канала.

Intel^® HD Graphics 5300

Новый компонент семейства Intel HD Graphics, графический процессор Intel HD Graphics 5300, работает с начальной базовой частотой 100 МГц, которая динамически повышается до 800 МГц (850 МГц в модели 5Y70).  Отметим поддержку технологий Intel^® Quick Sync Video (кодирование и пост-обработка мультимедиа и приложений с интенсивной нагрузкой на графическую подсистему), Intel^® In Tru™ 3D, Intel^® Clear Video HD, а также Intel^® Flexible Display Interface (Intel^® FDI). ГП Intel HD Graphics 5300 поддерживает подключение трех экранов (интерфейсы eDP/DP/HDMI).  В HD Graphics 5300 используется процессор GT2 этого семейства (189 млн транзисторов), в нем содержится 24 шейдерных модуля, 4 модуля наложения текстур и 1 модуль вывода отрисованного изображения. Поддерживаются DirectX* 11.1 и более поздних версий,  OpenGL* 4.2, OpenCL^TM 2.0, Shader Model 5.0. Графический процессор способен выдавать изображение с разрешением вплоть до UltraHD (3840 x 2160) по интерфейсу HDMI при 24 Гц.

Тестирование показало, что преобразование видео высокой четкости с помощью Cyberlink*MediaEsspresso* выполнялось на 80 %
быстрее, чем на процессоре Core i5                предыдущего поколения, а скорость в играх     (3DMark* IceStorm Unlimited v 1.2.) увеличилась
на 40 %. При этом система с процессором Intel
Core M проработала от аккумулятора на 1,7 ч дольше (при локальном воспроизведении видео и аккумуляторе 35 Вт-ч).

(Все тесты проведены на эталонных платформах Intel с 4 ГБ двухканальной памяти LPDDR3-1600 (2 модуля по 2 ГБ) с твердотельным накопителем Intel объемом 160 ГБ с операционной системой Windows 8.1. В системе с процессором Core M использовался BIOS версии 80.1, в системе с процессором Core i5-4302Y (предыдущего поколения) — BIOS версии WTM137. В обеих системах использовался драйвер Intel^® HD Graphics версии 15.36.3650, а тепловая мощность составляла 4,5 Вт. Другие параметры: системная политика управления электропитанием: сбалансированная, адаптер беспроводной сети: включен, емкостью аккумулятора: 35 Вт-ч).

Дополнительное время работы от аккумулятора обеспечивается следующими возможностями Intel HD Graphics 5300.

• Технология Intel^® Display Power Savings (Intel DPST) 6.0, снижающая уровень подсветки при одновременном увеличении контрастности и яркости.
• Технология Intel^®  Automatic Display Brightness, использующая датчик на передней панели устройства для регулировки яркости экрана в соответствии с уровнем освещения.
• Технология Intel^® SDRRS (Seamless Display Refresh Rate), снижающая частоту обновления экрана при низком уровне заряда аккумулятора.
• Технология Intel^® Rapid Memory Power Management  (Intel^® RMPM), обеспечивающая автоматическое обновление памяти из состояний с пониженным потреблением электроэнергии
• С-состояние модуля отрисовки графики (RC6), снижающее напряжение шины питания при отсутствии нагрузки.
• Технология Intel^® Smart 2D Display (Intel^® S2DDT), уменьшающая количество операций чтения из памяти для обновления отображения (работает только в одноконвейерном режиме, непригодна для использования с трехмерными приложениями).
• Технология Intel^® Graphics Dynamic Frequency, динамически увеличивающая частоту и напряжение ГП при необходимости.

Беспроводной адаптер Intel^® Wireless-AC7265  2-го поколения

В семействе процессоров Intel Core M также реализованы более скоростные адаптеры WLAN (производительность повышена на 15—100 %)при сниженных на 70 % габаритах за счет использования типоразмера M.2 1216. По сравнению с двухдиапазонным адаптером Intel® Wireless-A7260, у AC7265 значительно повышена надежность каналов, расширено покрытие, поддерживается больше одновременно подключенных устройств и есть возможность потоковой передачи видео с разрешением 1080p. При этом новый беспроводной адаптер расходует на 50 % меньше электроэнергии в состоянии бездействия (4 мВт) и на 30 % при работе (8 мВт при просмотре веб-страниц).

Примечание. Корпорация Intel планирует внедрить возможность беспроводной стыковки с помощью WiGig в семейство Intel Core M в 2015 году.

Intel^®WirelessDisplay 5

Новое поколение технологии Intel^® Wireless Display (Intel^® WiDi) поддерживает разрешение 1920 x 1080p при 60 кадрах в секунду, ускоренное подключение (не более 6 секунд) и сниженные задержки в играх (не более 65 мс). 

Поддерживаемые технологии

• HDCP 2.2
• Адаптивное масштабирование и кадровая скорость
• UoIP: многоточечный сенсорный экран и управление жестами
• Встроенный диспетчер Intel® Update Manager для удобного обновления драйверов
• Поддержка всех полноэкранных игровых форматов DX9/DX11 с определением игрового режима
• В комплект входит программное обеспечение Intel WiDi Remote для управления несколькими окнами при одновременном выводе изображения на два экрана
• Дополнительные функции Intel Pro WiDi, предназначенные для использования в конференц-залах
• DCM (режим раздельных каналов)
• Экран конфиденциальности
• Изоляция WPAN
• Управляемость

См. также «Создание Intel WiDi приложений для ультрабуков^TM».

Технология Intel® Smart Sound

В узел контроллера платформы РСН интегрирован новый, более мощный цифровой сигнальный процессор I2S. Технология Intel Smart Sound (Intel^® SST) снижает потребление электроэнергии за счет разгрузки ЦП системы: сигнальный процессор берет на себя задачи по обработке звука и поддерживает декодирование MP3/AAC, пост-обработку Waves* и DTS*, а также пробуждение по голосовой команде.  Для Intel SST необходимо использовать кодек I2S.

Безопасность, включая технологию Intel^® Platform Protection

Системы с процессорами Intel Core M оснащаются расширенными возможностями безопасности, включая следующие.

• Технология виртуализации Intel^® (Intel^® VT-d и Intel^® VT-x с EPT ) — оптимизация использования памяти виртуальными машинами, поддержка гарантий качества обслуживания
• Инструкции Intel^® AES-NI (Intel^® Advanced Encryption Standards — New Instructions) — 6 инструкций Intel^® SSE для высокопроизводительного шифрования
• Intel^® Secure Key — динамический генератор случайных чисел
• PCLMULQDQ (половинное умножение) — часто используется в шифровании
• Защита ОС
• Отключение бита выполнения (ND)
• SMEP (защита выполнения в режиме супервизора) и SMAP (защита доступа в режиме супервизора)
• Защита устройств Intel^®с Boot Guard
• Intel^® Active Management Technology v10

Процессоры Intel Core M 5Y70 также поддерживают технологии Intel vPro™, Intel^® Trusted Execution (Intel^® TXT) и Windows* Instant Go* (ранее Connected Standby)

Рекомендации для разработчиков

Рассмотрите возможность применения следующих компонентов и вызовов при разработке приложений для процессоров семейства Intel Core M.

• При использовании технологии Intel SpeedStep используйте инструкцию MWAIT и подчиненные состояния для большинства переключений между режимами электропитания, но для состояний C1/C1E используйте инструкцию HLT. Дополнительные сведения о C-состояниях ядер см. в «Семейство процессоров Intel Core M, справочник, том 1».
   
• Расширения Intel® Transactional Sychronization Extensions — New Instructions (Intel® TSX-NI) предоставляют возможность точной настройки блокировок, программируя только грубые блокировки. См. справочник по программированию расширений набора инструкций архитектуры Intel®..
   
• Новая инструкция в наборе Intel® AVX2, AVX2 instruction, синтезированное умножение и сложение значений с плавающей запятой (FMA), полезна при распознавании лиц и в других задачах с интенсивной вычислительной нагрузкой.

• Применяйте оптимизацию приложений сенсорного управления. См. статьи «Руководство по сенсорному управлению для разработчиков: ультрабуки и планшеты», «Разработка с использованием API классического интерфейса»,  «Обработка сенсорного ввода в приложениях для Windows* 8».

• • Оптимизация приложений для датчиков, включая GPS, компас, гироскоп, акселерометр и датчик освещения. Применяйте технологию Intel® RealSense™ и интерфейсы API датчиков для Windows 8.1 (см. «  Руководство по разработке для датчиков на ультрабуках и планшетах под управлением Windows* 8» и «Обнаружение датчиков ультрабуков в Windows* 8»

Прочая документация Intel и полезные инструменты

• Intel® RealSense™ 2014 SDK
• Руководство для разработчиков по Intel® Graphics
• Intel® Media SDK
• Intel® Graphics Performance Analyzers (Intel® GPA) (Intel® GPA)
• Intel® Advanced Vector Extensions (Intel® AVX)(Intel® AVX)
• Руководства разработчиков программного обеспечения по архитектурам Intel® 64 и IA-32
• Список средств для разработки программного обеспечения
• Дополнительные сведения о процессорах Intel Core M

Об авторе

Коллин Калбертсон (Colleen Culbertson) работает в должности инженера по разработке приложений для платформ в отделе Developer Relations Division. Он является автором ряда статей и регулярных публикаций в блоге на портале Intel® Developer Zone.

Тесты и оценки производительности проводятся на определенных компьютерных системах и компонентах и соответствуют приблизительной производительности продуктов Intel в этих тестах. Любые отличия в оборудовании системы и в программном обеспечении или конфигурации могут повлиять на фактическую производительность. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности. Дополнительные сведения о тестах производительности и о производительности продуктов Intel см. на сайте Ограничения тестов производительности Intel.

Примечания

ИНФОРМАЦИЯ В ДАННОМ ДОКУМЕНТЕ ПРИВЕДЕНА ТОЛЬКО В ОТНОШЕНИИ ПРОДУКТОВ INTEL. ДАННЫЙ ДОКУМЕНТ НЕ ПРЕДОСТАВЛЯЕТ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ ЛИЦЕНЗИИ, ЛИШЕНИЯ ПРАВА ВОЗРАЖЕНИЯ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ. КРОМЕ СЛУЧАЕВ, УКАЗАННЫХ В УСЛОВИЯХ И ПРАВИЛАХ ПРОДАЖИ ТАКИХ ПРОДУКТОВ, INTEL НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ОТКАЗЫВАЕТСЯ ОТ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ В ОТНОШЕНИИ ПРОДАЖИ И/ИЛИ ИСПОЛЬЗОВАНИЯ СВОИХ ПРОДУКТОВ, ВКЛЮЧАЯ ОТВЕТСТВЕННОСТЬ ИЛИ ГАРАНТИИ ОТНОСИТЕЛЬНО ИХ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ОБЕСПЕЧЕНИЯ ПРИБЫЛИ ИЛИ НАРУШЕНИЯ КАКИХ-ЛИБО ПАТЕНТОВ, АВТОРСКИХ ПРАВ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

КРОМЕ СЛУЧАЕВ, СОГЛАСОВАННЫХ INTEL В ПИСЬМЕННОЙ ФОРМЕ, ПРОДУКТЫ INTEL НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИТУАЦИЯХ, КОГДА ИХ НЕИСПРАВНОСТЬ МОЖЕТ ПРИВЕСТИ К ТРАВМАМ ИЛИ ЛЕТАЛЬНОМУ ИСХОДУ.

Корпорация Intel оставляет за собой право вносить изменения в технические характеристики и описания своих продуктов без предварительного уведомления. Проектировщики не должны полагаться на отсутствующие характеристики, а также характеристики с пометками «зарезервировано» или «не определено». Эти характеристики резервируются Intel для будущего использования, поэтому отсутствие конфликтов совместимости для них не гарантируется. Информация в данном документе может быть изменена без предварительного уведомления. Не используйте эту информацию в окончательном варианте дизайна.

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

Перед размещением заказа получите последние версии спецификаций в региональном офисе продаж Intel или у местного дистрибьютора.

Копии документов с порядковым номером, ссылки на которые содержатся в этом документе, а также другую литературу Intel можно получить, позвонив по телефону 1-800-548-4725 либо на сайте:http://www.intel.com/design/literature.htm

Программное обеспечение и нагрузки, использованные в тестах производительности, могли быть оптимизированы для достижения высокой производительности на микропроцессорах Intel. Тесты производительности, такие как SYSmark* и MobileMark*, проводятся на определенных компьютерных системах, компонентах, программах, операциях и функциях. Любые изменения любого из этих элементов могут привести к изменению результатов. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности, в том числе к тестам производительности определенного продукта в сочетании с другими продуктами.

Intel, эмблема Intel, Intel Core, Intel SpeedStep, InTru, Intel RealSense и Ultrabook являются товарными знаками корпорации Intel в США и в других странах.

© Intel Corporation, 2014. Все права защищены.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

OpenCL и эмблема OpenCL являются товарными знаками Apple Inc и используются с разрешения Khronos.

Общие сведения о Direct3D* 12
By: Michael Coppock

Загрузить PDF

Аннотация
Microsoft Direct3D* 12 — важный шаг в развитии технологий игр на ПК. В новой версии разработчики получают более мощные средства контроля над своими играми, могут эффективнее использовать ресурсы ЦП.

Содержание

Введение. 3

1.0. Хорошо забытое старое. 3

1.1. Ближе к железу. 4

2.0. Объект состояния конвейера. 5

3.0.Привязка ресурсов. 9

3.1. Опасности, связанные с ресурсами. 10

3.2. Управление резидентностью ресурсов. 11

3.3. Зеркальное копирование состояния. 11

4.0. Кучи и таблицы.. 12

4.1. Привязка избыточных ресурсов. 12

4.2. Дескрипторы.. 13

4.3. Кучи. 13

4.4. Таблицы.. 14

4.5. Эффективность и работа без привязки. 15

4.6. Обзор контекста отрисовки. 15

5.0. Наборы.. 17

5.1. Избыточные команды отрисовки. 17

5.2. Что такое наборы?. 18

5.3. Эффективность кода. 19

6.0. Списки команд. 21

6.1. Параллельное создание команд. 21

6.2. Списки и очередь. 22

6.3. Поток очереди команд. 23

7.0.Динамические кучи. 24

8.0. Параллельная работа ЦП.. 25

Ссылки и полезные материалы.. 29

Уведомления и примечания. 29

Ссылки и полезные материалы

Уведомления и примечания

Введение

На конференции GDC 2014 корпорация Microsoft объявила важную новость для всего рынка игр для ПК в 2015 году — выпуск новой версии Direct3D, а именно версии 12. В D3D 12 создатели вернулись к низкоуровневому программированию: оно дает разработчикам игр более полный контроль и много новых интересных возможностей. Группа разработки D3D 12 старается снизить издержки при задействовании ЦП и повысить масштабиру­е­мость, чтобы полнее нагружать ядра ЦП. Цель состоит в повышении эффективности и  производительности консольных API, чтобы игры могли эффективнее использовать ресурсы ЦП/ГП. В мире игр для ПК большую часть работы, а то и всю работу часто выполняет один-единственный поток ЦП. Другие потоки заняты только операционной системой и другими системными задачами. Существует совсем немного действительно многопоточных игр для ПК. Microsoft стремится изменить эту ситуацию в наборе D3D 12, который является надстройкой над функциональностью рендеринга D3D 11. Это означает, что на всех современных ГП можно запускать D3D 12, поскольку при этом будут эффективнее задействованы современные многоядерные ЦП и ГП. Для использования всех преимуществ D3D 12 не нужно покупать новый графический процессор. Действительно, у игр на ПК с процессором Intel® очень яркое будущее.

1.0 Хорошо забытое старое

Низкоуровневое программирование широко применяется в отрасли консолей, поскольку характеристики и устройство каждой модели консолей неизменны. Разработчики игр могут подолгу отлаживать свои игры, чтобы выжать всю возможную производительность из Xbox One* или PlayStation* 4. С другой стороны, ПК по своей природе — это гибкая платформа с бесчисленным множеством разновидностей и вариаций. При планировании разработки новой игры для ПК требуется учитывать очень много факторов. Высокоуровневые API, такие как OpenGL* и Direct3D*, помогают упростить разработку. Эти API выполняют всю «черную работу», поэтому разработчики могут сосредоточиться собственно на играх. Проблема же заключается в том, что и API, и (в несколько меньшей степени) драйверы достигли уже такого уровня сложности, что они могут увеличить объем потребляемых ресурсов при рендеринге кадров, что приводит к снижению произво­дительности. Именно здесь на сцену выходит низкоуровневое программирование.

Первая эпоха низкоуровневого программирования на ПК окончилась вместе с прекращением использования MS-DOS*. На смену пришли API разных поставщиков. После 3Dglide* компании 3DFX* появились такие API, как Direct3D. ПК проиграли в производительности, получив взамен столь необходимую гибкость и удобство. Рынок оборудования стал крайне сложным, с огромным множеством доступных аппаратных решений. Время разработки увеличилось, поскольку разработчики, естественно, стремились к тому, чтобы в их игры могли бы играть все пользователи. При этом перемены произошли не только на стороне программ, но и в оборудовании: эффективность ЦП с точки зрения потребления электроэнергии стала важнее, чем их производительность. Теперь вместо того, чтобы гнаться за увеличением тактовой частоты, больше внимания уделяется использованию нескольких ядер и потоков ЦП, параллельному рендерингу на современных ГП. Настала пора применить в области игр для ПК некоторые методики, используемые в консольных играх. Пора эффективнее, полнее использовать все доступные ядра и потоки. Словом, пора перейти в XXI век в мире игр для ПК.

1.1 Ближе к железу

Чтобы приблизить игры к «железу», нужно снизить сложность и размер API и драйвера. Между оборудованием и самой игрой должно быть меньше промежуточных уровней. Сейчас API и драйвер тратят слишком много времени на преобразование команд и вызовов. Некоторые или даже многие эти процедуры будут снова отданы разработчикам игр. За счет снижения издержек в D3D 12 повысится производительность, а за счет уменьшения количества промежуточных уровней обработки между игрой и оборудованием ГП игры будут быстрее работать и лучше выглядеть. Разумеется, у медали есть и обратная сторона: некоторые разработчики могут не желать заниматься областями, которые ранее были под контролем API, например программировать управление памятью ГП. Пожалуй, в этой области слово за разработчиками игровых движков, но, впрочем, только время расставит все на свои места. Поскольку выпуск D3D 12 состоится еще не скоро, имеется предостаточно времени для размышлений на эту тему. Итак, как же будут выполнены все эти заманчивые обещания? Главным образом с помощью новых возможностей. Это объекты состояния конвейера, списки команд, наборы и кучи.

2.0 Объект состояния конвейера

Прежде чем рассказывать об объекте состояния конвейера (PSO), сначала рассмотрим контекст рендеринга D3D 11, а потом перейдем к изменениям в D3D 12. На рис. 1 показан контекст рендеринга D3D 11 в том виде, в котором его представил Макс Мак-Маллен (Max McMullen), руководитель по разработке D3D, на конференции BUILD 2014 в апреле 2014 года.

Контекст отрисовки: Direct3D 11

Рисунок 1. Контекст отрисовки D3D 11 [Воспроизводится с разрешения корпорации Майкрософт.]

Крупные толстые стрелки указывают отдельные состояния конвейера. В соответствии с потребностями игры каждое такое состояние можно получить или задать. Прочие состояния в нижней части - фиксированные состояния функций, такие как поле зрения или прямоугольник обрезки. Другие важные компоненты этой схемы будут пояснены в дальнейших разделах данной статьи. При обсуждении PSO нас интересует только левая часть схемы. В D3D 11 удалось снизить издержки ЦП по сравнению с D3D 9 благодаря малым объектам состояния, но по-прежнему требовалась дополнительная работа драйвера, который должен был брать эти малые объекты состояния и сочетать их с кодом ГП во время рендеринга. Назовем эту проблему издержками аппаратного несоответствия. Теперь посмотрим еще на одну схему с конференции BUILD 2014, показанную на рис. 2.

Direct3D 11 — издержки состояния конвейера

Малые объекты состояния à издержки аппаратного несоответствия

Рисунок 2. В конвейере D3D 11 с малыми объектами состояния часто возникают издержки аппаратного несоответствия

На левой стороне показан конвейер в стиле D3D 9: здесь показано, что использует приложение для выполнения своей работы. Оборудование, показанное на правой стороне схемы на рис. 2, необходимо программировать. Состояние 1 представляет код шейдера. Состояние 2 — это сочетание растеризатора и потока управления, связывающего растеризатор с шейдерами. Состояние 3 — связь между смешением и пиксельным шейдером. Шейдер вертексов D3D влияет на аппаратные состояния 1 и 2, растеризатор — на состояние 2, пиксельный шейдер — на состояния с 1 по 3 и так далее. Драйверы в большинстве случаев не отправляют вызовы одновременно с приложением. Они предпочитают записывать вызовы и дожидаться выполнения работы, чтобы можно было определить, что на самом деле нужно приложению. Это означает дополнительные издержки для ЦП, поскольку старые и устаревшие данные помечаются как «непригодные». Поток управления драйвера проверяет состояние каждого объекта во время рендеринга и программирует оборудование так, чтобы соответствовать заданному игрой состоянию. При этой дополнительной работе возможно исчерпание ресурсов и возникновение затруднений. В идеале, как только игра задает состояние конвейера, драйвер тут же «знает», что нужно игре, и сразу программирует оборудование. На рис. 3 показан конвейер D3D 12, который делает именно это с помощью так называемого объекта состояния конвейера (PSO).

Direct3D 12 — оптимизациясостояния конвейера

Группировка конвейера в один объект

Копирование из PSO в аппаратное состояние

Рисунок 3. Оптимизация состояния конвейера в D3D 12 упорядочивает процесс.

На рис. 3 показан упорядоченный процесс с уменьшенными издержками. Один PSO с информа­цией о состоянии для каждого шейдера может за одну копию задать все аппаратные состояния. Вспомните, что некоторые состояния были помечены как «прочие» в контексте рендеринга D3D 11. Разработчики D3D 12 осознали важность уменьшения размера PSO и предоставления игре возможности смены цели рендеринга, не затрагивая скомпилированный PSO. Такие вещи, как поле зрения и прямоугольник обрезки, остались отдельными, они программируются вне остального конвейера (рис. 4).

Контекст рендеринга:
объект состояния конвейера (PSO)

Рисунок 4. Слева показан новый PSO D3D 12 с увеличенным состоянием для повышения эффективности

Вместо того чтобы задавать и прочитывать каждое состояние по отдельности, мы получили единую точку, тем самым полностью избавившись от издержек аппаратного несоответствия. Приложение задает PSO нужным образом, а драйвер получает команды API и преобразует их в код ГП без дополнительных издержек, связанных с управлением потоком. Такой подход (более близкий к «железу») означает, что для обработки команд рендеринга требуется меньше циклов, производительность возрастает.

3.0 Привязка ресурсов

Перед рассмотрением изменений в привязке ресурсов вспомним, какая модель привязки ресурсов использовалась в D3D 11. На рис. 5 снова показана схема контекста рендеринга: слева — объект состояния конвейера D3D 12, а справа — модель привязки ресурсов D3D 11.

Контекст отрисовки:
объект состояния конвейера (PSO)

Рисунок 5. Слева — объект состояния конвейера D3D 12, справа — модель привязки ресурсов D3D 11.

На рис. 5 принудительные точки привязки находятся справа от каждого шейдера. Принудительная модель привязки означает, что у каждого этапа в конвейере есть определенные ресурсы, на которые можно сослаться. Эти точки привязки ссылаются на ресурсы в памяти ГП. Это могут быть текстуры, цели рендеринга, неупорядоченные представления доступа (UAV) и так далее. Привязки ресурсов используются уже давно, они появились даже раньше, чем D3D. Цель в том, чтобы «за кадром» обработать множество свойств и помочь игре в эффективной отправке команд рендеринга. При этом системе необходимо выполнить анализ множества привязок в трех основных областях. В следующем разделе рассматриваются эти области и их оптимизация в D3D 12.

3.1 Опасности, связанные с ресурсами

Опасности обычно связаны с переходами, например с перемещением от цели рендеринга к текстуре. Игра может отрисовать кадр, который должен стать картой среды для сцены. Игра завершает рендеринг карты среды и теперь хочет использовать ее в качестве текстуры. В ходе этого процесса и среда выполнения, и драйвер отслеживают все ресурсы, привязанные как цели рендеринга или как текстуры. Если среда выполнения или драйвер видят какой-либо ресурс, привязанный одновременно и как цель рендеринга, и как текстура, они отменяют более старую по времени привязку и сохраняют более новую. За счет этого игра может переключаться нужным образом, а набор программного обеспечения управляет этим переключением «за кадром». Драйвер также должен очистить конвейер ГП, чтобы можно было использовать цель рендеринга в качестве текстуры. В противном случае пиксели будут прочитаны до того, как они будут удалены из ЦП, и полученный результат будет несогласованным. Собственно говоря, опасность — это все, для чего требуется дополнительная работа ГП с целью получения согласованных данных.

Как и в других усовершенствованиях в D3D 12, решение здесь состоит в том, чтобы предоставить игре больше возможностей управления. Почему API и драйвер должны выполнять всю работу и отслеживание, когда это всего лишь один момент в обработке кадра? Для переключения от одного ресурса к другому требуется около 1/60 секунды. Можно снизить издержки, передав управление игре, тогда дополнительное время будет израсходовано только один раз, когда игра осуществляет переключение ресурсов (рис. 6).

D3D12_RESOURCE_BARRIER_DESC Desc;
Desc.Type = D3D12_RESOURCE_BARRIER_TYPE_TRANSITION;
Desc.Transition.pResource   = pRTTexture;
Desc.Transition.Subresource = D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES;
Desc.Transition.StateBefore = D3D12_RESOURCE_USAGE_RENDER_TARGET;
Desc.Transition.StateAfter  = D3D12_RESOURCE_USAGE_PIXEL_SHADER_RESOURCE;
pContext->ResourceBarrier( 1, &Desc );

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

3.2 Управление резидентностью ресурсов

D3D 11 (и более старые версии) работают так, как если бы все вызовы были в очереди. Игра считает, что API немедленно выполняет вызов. Но на самом деле это не так. ГП поддерживает очередь команд, в которой все команды откладываются и выполняются позднее. При этом обеспечивается распараллеливание вычислений и более эффективное задействование ГП и ЦП, но требуется отслеживание ссылок и их учет. На учет и отслеживание расходуется достаточно много ресурсов ЦП.

Чтобы решить эту проблему, игра получает явное управление жизненным циклом ресурсов. В D3D 12 больше не скрывается очередь ГП. Для отслеживания выполнения на ГП добавлен API Fence. Игра может в заданный момент (например, один раз за кадр) проверить, какие ресурсы больше не нужны, и затем высвободить занимаемую ими память. Больше не требуется отслеживать ресурсы в течение всего рендеринга кадра с помощью дополнительной логики, чтобы высвобождать ресурсы и память.

3.3 Зеркальное копирование состояния

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

4.0 Кучи и таблицы

Осталось рассмотреть еще одно важное изменение привязки ресурсов. В конце раздела 4 будет показан весь контекст рендеринга D3D 12. Новый контекст рендеринга D3D 12 — первый шаг на пути к повышению эффективности использования ЦП в API.

4.1 Привязка избыточных ресурсов

Проведя анализ нескольких игр, разработчики D3D заметили, что обычно в играх в множестве кадров используется одна и та же последовательность команд. Не только команды, но и привязки остаются точно такими же из кадра в кадр. ЦП создает последовательность привязок (скажем, 12) для рисования объекта в кадре. Зачастую ЦП приходится создавать эти же 12 привязок еще раз для следующего кадра. Почему же не поместить эти привязки в кэш? Разработчикам игр можно предоставить команду, указывающую на кэш, чтобы можно было многократно использовать одинаковые привязки.

Вразделе 3 мы обсудили очереди. Когда осуществляется вызов, игра исходит из того, что API немедленно выполняет этот вызов. Но на самом деле это не так. Команды помещаются в очередь, все содержимое которой откладывается и выполняется позднее в ГП. Поэтому если изменить одну из этих 12 привязок, о которых мы говорили ранее, то драйвер скопирует все 12 привязок в новое место, изменит копию, затем даст графическому процессору команду начать использовать скопированные привязки. Обычно у большинства из этих 12 привязок значения бывают статическими, а обновление требуется лишь для нескольких динамических значений. Когда игре нужно внести частичные изменения в эти привязки, она копирует все 12 штук, из-за чего наблюдается чрезмерный расход ресурсов ЦП при незначительных изменениях.

4.2 Дескрипторы

Что такое дескриптор? Коротко говоря, это фрагмент данных, определяющий параметры ресурсов. По сути, это то, из чего состоит объект представления D3D 11. Управление жизненным циклом на уровне операционной системы отсутствует. Это просто данные в памяти ГП. Здесь содержится информация о типе и формате, счетчик MIP для текстур и указатель на пиксельные данные. Дескрипторы находятся в центре новой модели привязки ресурсов.

Дескриптор

Рисунок 7. Дескриптор D3D 12 — небольшой фрагмент данных, определяющий параметр ресурса

4.3 Кучи

Когда представление задано в D3D 11, оно копирует дескриптор в текущее расположение в памяти ГП, откуда прочитываются дескрипторы. Если задать новое представление в этом же расположении, в D3D 11 дескрипторы будут скопированы в новое расположение в памяти, а ГП в следующем вызове команды рендеринга получит указание читать дескрипторы из этого нового расположения. В D3D 12 игра или приложение получают явное управление созданием дескрипторов, их копированием и пр.

Кучи дескрипторов

Рисунок 8. Куча дескрипторов является массивом дескрипторов

Кучи (рис. 8) являются просто очень большим массивом дескрипторов. Можно повторно использовать дескрипторы из предыдущих вызовов рендеринга и кадров. Можно создавать новые при необходимости. Вся разметка находится под управлением игры, поэтому при управлении кучей почти не возникают издержки. Размер кучи зависит от архитектуры ГП. В устаревших маломощных ГП размер может быть ограничен 65 тысячами, а в более мощных ГП ограничение будет определяться объемом памяти. В менее мощных ГП возможно превышение размера кучи. В D3D 12 поддерживается несколько куч и переключение от одной кучи дескрипторов к другой. Тем не менее при переключении между кучами в некоторых ГП происходит сброс данных, поэтому использованием этой функции лучше не злоупотреблять.

Итак, как сопоставить код шейдеров с определенными дескрипторами или наборами дескрипторов? Ответ – с помощью таблиц.

4.4 Таблицы

Таблицы содержат индекс начала и размер в куче. Они являются точками контекста, но не объектами API. При необходимости у каждого этапа шейдера может быть одна или несколько таблиц. Например, шейдер вертекса для вызова рендеринга может содержать таблицу, указывающую на дескрипторы со смещением с 20 по 32 в куче. Когда начнется работа над следующим вызовом рендеринга, смещение может измениться на 32—40.

Таблицы дескрипторов

Рисунок 9. Таблицы дескрипторов содержат индекс начала и размер в куче дескрипторов

Используя существующее оборудование, D3D 12 может обрабатывать несколько таблиц на каждое состояние шейдера в PSO. Можно поддерживать одну таблицу лишь с теми данными, которые часто изменяются между вызовами, а вторую таблицу — со статическими данными, неизменными для нескольких вызовов и для нескольких кадров. Это позволит избежать копирования дескрипторов из одного вызова в следующий. Тем не менее у старых ГП действует ограничение в одну таблицу на каждый этап шейдера. Поддержка нескольких таблиц возможна в современном и в перспективном оборудовании.

4.5 Эффективность и работа без привязки

Кучи дескрипторов и таблицы применяются в D3D для рендеринга без привязки, причем с возможностью задействования всех аппаратных ресурсов ПК. В D3D 12 поддерживаются любые устройства — от маломощных «систем на кристалле» до высокопроизводительных дискретных графических адаптеров. Благодаря такому универсальному подходу разработчики игр получают разнообразные возможности управления привязками. Кроме того, новая модель включает множественные обновления частоты. Поддерживаются кэшированные таблицы статических привязок с возможностью многократного использования и динамические таблицы для данных, изменяющихся в каждом вызове рендеринга. Таким образом, необходимость копировать все привязки для каждого нового вызова рендерингаотпадает.

4.6 Обзор контекста отрисовки

На рис. 10 показан контекст рендеринга с изменениями D3D 12, которые мы уже успели обсудить. Также показан новый объект состояния конвейера и упразднение вызовов Get, но сохранились явные точки привязки D3D 11.

Контекст отрисовки

Рисунок 10. Контекст отрисовки D3D 12 с изменениями, о которых мы уже успели поговорить.

Давайте удалим последние остатки контекста рендеринга D3D 11 и добавим таблицы дескрипторов и кучи. Теперь у нас появились таблицы для каждого этапа шейдера (или несколько таблиц, как показано для пиксельного шейдера).

Контекст отрисовки: Direct3D 12

Рисунок 11. Полный контекст рендеринга D3D 12

Тонко настраиваемые объекты состояния упразднены, их заменил объект состояния конвейера. Удалено отслеживание опасностей и зеркальное копирование состояния. Принудительные точки привязки заменены на управляемые приложением или игрой объекты памяти. ЦП используется более эффективно, издержки снижены, упразднены поток управления и логика и в API, и в драйвере.

5.0 Наборы

Мы завершили рассмотрение нового контекста рендеринга в D3D 12 и увидели, каким образом D3D 12 передает управление игре, приближая ее к «железу». Но этим возможности D3D 12 по повышению эффективности API не ограничиваются. В API по-прежнему существуют издержки, влияющие на производительность, и существуют дополнительные способы повысить эффективность использования ЦП. Как насчет последовательностей команд? Сколько существует повторяющихся последовательностей и как сделать их более эффективными?

5.1 Избыточные команды рендеринга

При изучении команд рендеринга в каждом кадре разработчики D3D в Microsoft обнаружили, что при переходе от одного кадра к другому происходит добавление или удаление только 5—10 % последовательностей команд. Остальные последовательности команд используются во множестве кадров. Итак, ЦП в течение 90—95 % времени своей работы повторяет одни и те же последовательности команд!

Как здесь повысить эффективность? И почему в D3D это не было сделано до сих пор? На конференции BUILD 2014 Макс Мак-Маллен сказал: «Очень сложно создать универсальный и надежный способ записывать команды. Такой способ, чтобы он работал всегда одинаково для разных ГП, с разными драйверами и при этом работал бы быстро». Игре требуется, чтобы все записанные последовательности команд выполнялись так же быстро, как отдельные команды. Что изменилось? D3D. Благодаря новым объектам состояния конвейера, кучам дескрипторов и таблицам состояние, необходимое для записи и воспроизведения команд, значительно упростилось.

5.2 Что такое наборы?

Наборы — это небольшие списки команд, которые один раз записываются, после чего их можно многократно использовать без каких-либо ограничений в одном кадре или в нескольких кадрах. Наборы можно создавать в любом потоке и использовать сколько угодно раз. Наборы не привязываются к состоянию объектов PSO. Это означает, объекты PSO могут обновлять таблицу дескрипторов, а при запуске набора для разных привязок игра будет получать разные результаты. Как и в случае с формулами в электронных таблицах Excel*, математика всегда одинаковая, а результат зависит от исходных данных. Существуют определенные ограничения, чтобы гарантировать эффективную реализацию наборов драйвером. Одно из таких ограничений состоит в том, что никакая команда не может сменить цель рендеринга. Но остается еще множество команд, которые можно записать и воспроизводить.

Наборы

Рисунок 12. Наборы — это часто повторяемые команды, записанные и воспроизводящиеся по мере необходимости

Слева на рис. 12 — пример контекста рендеринга, последовательность команд, созданных в ЦП и переданных на ГП для выполнения. Справа — два пакета, содержащих записанную последовательность команд для многократного использования в разных потоках. По мере выполнения команд ГП достигает команды на выполнение набора. После этого воспроизводится записанный набор. По завершении ГП возвращается к последовательности команд, продолжает и находит следующую команду выполнения набора. После этого прочитывается и воспроизводится второй набор, после чего выполнение продолжается.

5.3 Эффективность кода

Мы рассмотрели управление потоком в ГП. Теперь посмотрим, каким образом наборы упрощают код.

Пример кода без наборов

Перед нами страница настройки, задающая состояние конвейера и таблицы дескрипторов. Затем идут два вызова рендеринга объектов. В обоих случаях используется одинаковая последова­тельность команд, различаются только константы. Это типичный код D3D 11.

// Настройка
pContext->SetPipelineState(pPSO);
pContext->SetRenderTargetViewTable(0, 1, FALSE, 0);
pContext->SetVertexBufferTable(0, 1);
pContext->IASetPrimitiveTopology(D3D_PRIMITIVE_TOPOLOGY_TRIANGLELIST);

// Рисунок 1
pContext->SetConstantBufferViewTable(D3D12_SHADER_STAGE_PIXEL, 0, 1);
pContext->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 0, 1);
pContext->DrawInstanced(6, 1, 0, 0);
pContext->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 1, 1);
pContext->DrawInstanced(6, 1, 6, 0);

// Рисунок 2
pContext->SetConstantBufferViewTable(D3D12_SHADER_STAGE_PIXEL, 1, 1);
pContext->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 0, 1);
pContext->DrawInstanced(6, 1, 0, 0);
pContext->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 1, 1);
pContext->DrawInstanced(6, 1, 6, 0);

Пример кода с наборами

Теперь рассмотрим эту же последовательность команд с пакетами в D3D 12. Первый вызов, показанный ниже, создает набор. Это может быть сделано в любом потоке. На следующем этапе создается последовательность команд. Это такие же команды, как и в предыдущем примере

// Создание набора
pDevice->CreateCommandList(D3D12_COMMAND_LIST_TYPE_BUNDLE, pBundleAllocator, pPSO, pDescriptorHeap, &pBundle);

// Запись команд
pBundle->IASetPrimitiveTopology(D3D_PRIMITIVE_TOPOLOGY_TRIANGLELIST);
pBundle->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 0, 1);
pBundle->DrawInstanced(6, 1, 0, 0);
pBundle->SetShaderResourceViewTable(D3D12_SHADER_STAGE_PIXEL, 1, 1);
pBundle->DrawInstanced(6, 1, 6, 0);
pBundle->Close();

В примерах кода на рис. 17 и 18 достигается такой же результат, как в коде без наборов на рис. 14—16. Хорошо видно, что наборы позволяют существенно сократить количество вызовов, необходимое для выполнения одной и той же задачи. ГП при этом выполняет точно такие же команды и получает такой же результат, но гораздо эффективнее.

6.0 Списки команд

Вы уже знаете, каким образом в D3D 12 повышается эффективность использования ЦП и предоставляются более широкие возможности разработчикам с помощью наборов, объектов состояния конвейера, куч дескрипторов и таблиц. Модель объектов состояния конвейера и дескрипторов поддерживает наборы, которые, в свою очередь, используются для широко распространенных и часто повторяющихся команд. Такой упрощенный и «приближенный к железу» подход снижает издержки и позволяет эффективнее использовать ЦП. Ранее мы упомянули, что в играх для ПК большую часть работы, а то и всю работу выполняет только один поток, а остальные потоки занимаются другими системными задачами и процессами ОС. Добиться эффективного использования нескольких ядер или потоков игрой для ПК не так просто. Зачастую для реализации многопоточности в игре требуются существенные затраты ресурсов и труда. Разработчики D3D собираются изменить это положение дел в D3D 12.

6.1 Параллельное создание команд

Как уже неоднократно упоминалось выше, отложенное выполнение команд — это модель, при которой создается ощущение, что каждая команда выполняется немедленно, но на самом деле команды помещаются в очередь и выполняются позднее. Эта функция сохраняется в D3D 12, но теперь она является прозрачной для игры. Не существует немедленного контекста, поскольку все откладывается. Потоки могут создавать команды параллельно для формирования списков команд, которые подаются в объект API, который называется очередью команд. ГП не будет выполнять команды, пока они не будут отправлены с помощью очереди команд. Очередь — это порядок следования команд, которые указываются в списке. Чем отличаются списки команд от наборов? Списки команд создаются и оптимизируются, поэтому несколько потоков могут одновременно создавать команды. Списки команд используются однократно, а затем удаляются из памяти; на месте удаленного списка команд записывается новый список. Наборы предназначены для многократного выполнения часто используемых команд рендеринга в одном или в нескольких кадрах.

В D3D 11 была сделала попытка распараллелить обработку команд; эта функция называлась отложенным контекстом. Но из-за издержек цели по повышению производительности тогда не были достигнуты. Подробный анализ показал множество мест с избыточной последовательной обработкой, что привело к неэффективному распределению нагрузки по ядрам ЦП. Часть издержек с последовательной обработкой была устранена в D3D 12 с помощью средств повышения эффективности использования ЦП, описанных в разделах 2—5.

6.2 Списки и очередь

Представьте, что два потока создают список команд рендеринга. Одна последовательность должна быть выполнена перед другой. При наличии опасностей один поток использует ресурс в качестве текстуры, а другой поток использует этот же ресурс в качестве цели рендеринга. Драйвер должен проанализировать использование ресурсов во время рендеринга и устранить опасности, обеспечив согласованность данных. Отслеживание опасностей — одна из областей с последовательными издержками в D3D 11. В D3D 12 за отслеживание опасностей отвечает игра, а не драйвер.

D3D 11 поддерживается несколько отложенных контекстов, но при их использовании возникает сопутствующая нагрузка. Драйвер отслеживает состояние для каждого ресурса. Поэтому, как только начата запись команд для отложенного контекста, драйвер должен выделять память для отслеживания состояния каждогоиспользуемого ресурса. Память занята, пока идет создание отложенного контекста. По завершении драйвер должен удалить из памяти все объекты отслеживания. Из-за этого возникают ненужные издержки. Игра объявляет максимальное количество списков команд, которые можно создать параллельно на уровне API. После этого драйвер упорядочивает и заранее выделяет все объекты отслеживания в одном согласованном объекте памяти.

В D3D 11 распространены динамические буферы (буфер контекста, вертексов и т. д.), но «за кадром» остается множество экземпляров удаленных буферов отслеживания памяти. Например, параллельно могут быть созданы два списка команд, и вызвана функция MapDiscard. После отправки списка драйвер должен вмешаться во второй список команд, чтобы исправить информацию об удаленном буфере. Как и в приведенном выше примере с отслеживанием опасностей, здесь возникают значительные издержки. В D3D 12 управление переименованием передано игре, динамического буфера больше нет. Игра получила полное управление. Она создает собственные распределители и может делить буфер на части по мере необходимости. Поэтому команды могут указывать на явным образом заданные точки в памяти.

Как мы говорили вразделе 3.1,среда выполнения и драйвер отслеживают жизненный цикл ресурсов в D3D 11. Для этого требуется подсчет и отслеживание ресурсов, все операции должны быть сделаны во время отправки. В D3D 12 игра управляет жизненным циклом ресурсов и обработкой опасностей, благодаря чему устраняются издержки последовательной обработки и повышается эффективность использования ЦП. Параллельное создание команд работает эффективнее в D3D 12 с учетом оптимизации в четырех описанных областях, что расширяет возможности распараллеливания нагрузки на ЦП. Кроме того, разработчики D3D создают новую модель драйверов WDDM 2.0 и планируют реализовать дополнительные меры по оптимизации, чтобы снизить нагрузку при отправке списков команд.

6.3 Поток очереди команд

Очередь команд

Рисунок 19. Очередь команд с двумя параллельно создаваемыми списками команд и двумя наборами повторяющихся команд

На рис. 19 показана схема набора израздела 5.2,но с многопоточностью. Очередь команд, показанная слева, представляет собой последовательность событий, отправленных на ГП. Списки команд находятся посередине, а справа — два набора, записанные перед началом сценария. Начиная со списков команд, создаваемых параллельно для разных фрагментов сцены, завершается запись списка команд 1, этот список отправляется в очередь команд, и ГП начинает его выполнять. Параллельно запускается процедура управления потоком очереди команд, а список команд 2 записывается в потоке 2. Пока ГП выполняет список команд 1, поток 2 завершает создание списка команд 2 и отправляет его в очередь команд. Когда очередь команд завершает выполнение списка команд 1, она последовательно переходит к списку команд 2. Очередь команд — это последовательность, в которой ГП должен выполнять команды. Хотя список команд 2 был создан и отправлен в ГП до того, как ГП завершил выполнение списка команд 1, список команд 2 будет выполнен только после завершения выполнения списка команд 1. В D3D 12 поддерживается более эффективное распараллеливание для всего процесса.

7.0 Динамические кучи

Как мы уже говорили выше, игра управляет переименованием ресурсов для распараллеливания создания команд. Кроме того, в D3D 12 упрощено переименование ресурсов. В D3D 11 буферы были разделены по типам: были буферы вертексов, констант и индексов. Разработчики игр запросили возможность использовать зарезервированную память так, как им заблагорассудится. И команда D3D выполнила эту просьбу. В D3D 12 разделение буферов по типам отсутствует. Буфер — это просто объем памяти, выделяемый игрой по мере необходимости в размере, необходимом для кадра (или нескольких кадров). Можно даже использовать распределитель кучи с делением по мере необходимости, что повышает эффективность процессов. В D3D 12 также применяется стандартное выравнивание. ГП сможет прочесть данные, если в игре используется стандартное выравнивание. Чем выше уровень стандартизации, тем проще создавать содержимое, работающее с разными моделями ЦП, ГП и другого оборудования. Распределение памяти также является постоянным, поэтому ЦП всегда знает нужный адрес. При этом также повышается эффективность параллельного использования ЦП: поток может направить ЦП на нужный адрес в памяти, после чего ЦП определяет, какие данные нужны для кадра.

Распределение и перераспределение

Рисунок 20. Распределение и перераспределение буферов

В верхней части рис. 20 показана модель D3D 11 с типизацией буферов. В нижней части показана новая модель D3D 12, где игра управляет кучей. Вместо выделения отдельной части памяти для буфера каждого типа используется единый постоянный фрагмент памяти. Размер буфера также настраивается игрой на основе потребностей рендеринга текущего кадра или даже нескольких последующих кадров.

8.0 Параллельная работа ЦП

Пора собрать все воедино и продемонстрировать, каким образом новые возможности D3D 12 позволяют создать действительно многопоточную игру для ПК. В D3D 12 поддерживается параллельное выполнение нескольких задач. Списки команд и наборы предоставляют возможность параллельного создания и выполнения команд. Наборы позволяют записывать команды и многократно запускать их в одном или в нескольких кадрах. Списки команд могут быть созданы в нескольких потоках и переданы в очередь команд для выполнения графическим процессором. И наконец, буферы с постоянным распределением параллельно создают динамические данные. Параллельная работа поддерживается и в D3D 12, и в WDDM 2.0. В D3D 12 устранены ограничения прежних версий D3D, разработчики могут распараллеливать свои игры или движки любым целесообразным способом.

Профилирование в D3D11

Рисунок 21. Типичная параллельная обработка в D3D 11. Поток 0 выполняет почти всю работу, остальные потоки используются незначительно

На схеме на рис. 21 показана типичная игровая нагрузка в D3D 11. Логика приложения, среда выполнения D3D, DXGKernel, KMD и текущая работа задействуют ЦП с четырьмя потоками. Поток 0 выполняет большую часть работы. Потоки 1—3 практически не используются: в них попадают только логика приложения и среда выполнения D3D 11, создающая команды рендеринга. Драйвер пользовательского режима вообще не создает команд для этих потоков в силу особенностей устройства D3D 11.

Профилирование в D3D12

Рисунок 22. Здесь показана такая же нагрузка, как на рис. 21, но в D3D 12. Нагрузка равномерно распределяется по всем 4 потокам, а с учетом других мер по повышению эффективности в D3D 12 скорость выполнения нагрузки значительно увеличена

Теперь рассмотрим такую же нагрузку в D3D 12 (рис. 22). Логика приложения, среда выполнения D3D, DXGKernel, KMD и текущая работа также задействуют ЦП с четырьмя потоками. Но здесь работа равномерно распределяется по всем потокам за счет оптимизации в D3D 12. Поскольку команды создаются параллельно, выполняемая среда D3D также работает параллельно. Издержки ядра значительно снижены за счет оптимизации ядра в WDDM 2.0. UMD работает во всех потоках, а не только в потоке 0, что означает настоящее распараллеливание создания команд. И наконец, наборы заменяют логику избыточного изменения состояния в D3D 11 и ускоряют работу логики приложения.

Показатели D3D11 и D3D12

Рисунок 23. Сравнение параллельной обработки в D3D 11 и D3D 12

На рис. 23 показано сравнение обеих версий. Поскольку уровень фактической параллельности достаточно высок, мы видим относительно равное использование ЦП потоком 0 и потоками 1—3. Потоки 1—3 выполняют больше работы, поэтому в столбце «Только графика» видно увеличение. Кроме того, благодаря снижению нагрузки в потоке 0 и новым мерам по повышению эффективности среды выполнения и драйвера общую нагрузку на ЦП удалось снизить примерно на 50 %. Если рассмотреть столбец «Приложение плюс графика», здесь также распределение нагрузки между потоками стало более равномерным, а использование ЦП снизилось примерно на 32 %.

9.0 Заключение

В D3D 12 повышена эффективность использования ЦП за счет более крупных объектов состояния конвейера. Вместо того чтобы задавать и прочитывать каждое состояние по отдельности, разработчики получили единую точку приложения сил, тем самым полностью избавившись от издержек аппаратного несоответствия. Приложение задает PSO, а драйвер получает команды API и преобразует их в код ГП. Новая модель привязки ресурсов не имеет издержек, вызванных логикой управления потоком, которая теперь не нужна.

За счет использования куч, таблиц и наборов D3D 12 обеспечивает более эффективное использование ЦП и более высокую масштабируемость. Вместо явных точек привязки используются управляемые приложением или игрой объекты памяти. Часто используемые команды можно записывать и многократно воспроизводить в одном кадре или в нескольких кадрах с помощью наборов. Списки команд и очередь команд позволяют параллельно создавать списки команд в нескольких потоках ЦП. Практически вся работа равномерно распределяется по всем потокам ЦП, что позволяет раскрыть весь потенциал и всю мощь процессоров Intel® Core™ 4-го и 5-го поколений.

Direct3D 12 — значительный шаг в развитии технологий игр на ПК. Разработчики игр смогут работать «ближе к железу» за счет более компактного API и драйвера с меньшим количеством промежуточных уровней. За счет этого повышается эффективность и производительность. С помощью сотрудничества группа разработки D3D создала новый API и модель драйверов, предоставляющую разработчикам более широкие возможности управления, что позволяет создавать игры в полном соответствии с замыслом, с великолепной графикой и отличной производительностью.

Ссылки и полезные материалы

• Предварительный обзор API Direct3D* 12
• Блог Microsoft DirectX* 12
• Процессоры Intel® Core™ M
• Процессоры Intel® Core™ 4-го поколения
• Процессоры Intel® Atom™
• Intel® Processor Graphics — руководство для разработчиков

Ссылки на материалы Intel

Корпоративный бренд: http://intelbrandcenter.tagworldwide.com/frames.cfm

Наименования продуктов Intel®: http://www.intel.com/products/processor number/

Уведомления и примечания

См. http://legal.intel.com/Marketing/notices+and+disclaimers.htm

Об авторе

Майкл Коппок (Michael Coppock) работает в корпорации Intel с 1994 года, он специализируется на производительности графики и игр для ПК. Он помогает компаниям, разрабатывающим игры, наиболее эффективно задействовать все возможности ГП и ЦП Intel. Занимаясь и программным обеспечением, и оборудованием, Майкл работал со множеством продуктов Intel, начиная с процессора 486DX4 Overdrive.

Примечания

ИНФОРМАЦИЯ В ДАННОМ ДОКУМЕНТЕ ПРИВЕДЕНА ТОЛЬКО В ОТНОШЕНИИ ПРОДУКТОВ INTEL. ДАННЫЙ ДОКУМЕНТ НЕ ПРЕДОСТАВЛЯЕТ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ ЛИЦЕНЗИИ, ЛИШЕНИЯ ПРАВА ВОЗРАЖЕНИЯ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ. КРОМЕ СЛУЧАЕВ, УКАЗАННЫХ В УСЛОВИЯХ И ПРАВИЛАХ ПРОДАЖИ ТАКИХ ПРОДУКТОВ, INTEL НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ОТКАЗЫВАЕТСЯ ОТ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ В ОТНОШЕНИИ ПРОДАЖИ И/ИЛИ ИСПОЛЬЗОВАНИЯ СВОИХ ПРОДУКТОВ, ВКЛЮЧАЯ ОТВЕТСТВЕННОСТЬ ИЛИ ГАРАНТИИ ОТНОСИТЕЛЬНО ИХ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ОБЕСПЕЧЕНИЯ ПРИБЫЛИ ИЛИ НАРУШЕНИЯ КАКИХ-ЛИБО ПАТЕНТОВ, АВТОРСКИХ ПРАВ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

КРОМЕ СЛУЧАЕВ, СОГЛАСОВАННЫХ INTEL В ПИСЬМЕННОЙ ФОРМЕ, ПРОДУКТЫ INTEL НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИТУАЦИЯХ, КОГДА ИХ НЕИСПРАВНОСТЬ МОЖЕТ ПРИВЕСТИ К ТРАВМАМ ИЛИ ЛЕТАЛЬНОМУ ИСХОДУ.

Корпорация Intel оставляет за собой право вносить изменения в технические характеристики и описания своих продуктов без предварительного уведомления. Проектировщики не должны полагаться на отсутствующие характеристики, а также характеристики с пометками «Зарезервировано» или «Не определено». Эти характеристики резервируются Intel для будущего использования, поэтому отсутствие конфликтов совместимости для них не гарантируется. Информация в данном документе может быть изменена без предварительного уведомления. Не используйте эту информацию в окончательном варианте дизайна.

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

Перед размещением заказа получите последние версии спецификаций в региональном офисе продаж Intel или у местного дистрибьютора.

Копии документов с порядковым номером, ссылки на которые содержатся в этом документе, а также другую литературу Intel можно получить, позвонив по телефону 1-800-548-47-25 либо на сайте http://www.intel.com/design/literature.htm.

Intel, эмблема Intel, Intel Atom и Intel Core являются товарными знаками корпорации Intel в США и в других странах.

* Другие наименования и торговые марки могут быть собственностью третьих лиц.

Intel, эмблема Intel, Intel Atom и Intel Core являются товарными знаками корпорации Intel в США и в других странах.

* Другие наименования и торговые марки могут быть собственностью третьих лиц.

© Корпорация Intel, 2014. Все права защищены.

Уведомление об оптимизации

ПРИМЕЧАНИЕ.В зависимости от содержимого могут потребоваться дополнительные уведомления и примечания. Как правило, они находятся в следующих местах, и их необходимо добавить в раздел «Уведомления» соответствующих документов.

Общие уведомления:уведомления, размещаемые во всех материалах, распространяемых и выпускаемых корпорацией Intel.

Уведомления в отношении производительности и ее измерения:уведомления для материалов, используемых корпорацией Intel для измерения производительности или для заявлений о производительности.

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

Технические примечания:примечания к материалам Intel, когда описываются преимущества или возможности технологий и программ.

Примечание для технических уведомлений: если все описываемые продукты (например, ACER ULV) обладают определенной функцией или поддерживают определенную технологию, то можно удалить заявление о требованиях в уведомлении. При наличии нескольких технических уведомлений можно объединить все заявления «фактическая производительность может различаться» в одно общее.

Загрузите PDF[PDF 488KB]

By: Tim Duncan and Weijia Wang

Введение

В этой статье описываются некоторые новые возможности Corel Painter* 2015. Изначально разработчики Corel обратились в Intel за помощью в повышении производительности, но в конечном итоге специалистам Corel и Intel удалось добиться гораздо большего. Помимо повышения производительности, в Corel Painter 2015 добавлена поддержка трансформеров с изменением интерфейса, что дает возможность делать наброски в сенсорном режиме.

Рисунок 1. Картина на полотне, созданная традиционным способом
Автор — Эрин Дункан, используется с разрешения

Painter и пользователи

Истоки Corel Painter можно проследить до продукта Fractal Painter, который был выпущен компанией Fractal Design в 1990 году. С самого начала эта программа была ориентирована на естественное взаимодействие художника с бумагой и чернилами. Решение получило развитие и превратилось в современное цифровое художественное приложение, которым пользуются как профессиональные художники, так и любители. Согласно статье в журнале PC World за август 2014 года, «Painter можно сравнить с бесконечным ящиком с инструментами художника.
В самой сердцевине этого приложения — многочисленные разнообразные кисти, очень точно имитирующие настоящие материалы». Художники ценят эту программу за ее мощные и широкие возможности цифрового рисования, превосходящие возможности традиционных средств живописи. Corel Painter используется художниками, иллюстраторами, дизайнерами игр, художниками-мультипликаторами, художниками рисованного окружения в кино, графическими дизайнерами, профессиональными фотографами, авторами комиксов, промышленными дизайнерами и т. п.

Рисунок 2. Создайте свое собственное перо

Важность нажима

Технологии живописи на традиционных материалах (холсте, бумаге и т. д) в целом не изменялись с появления первых наскальных рисунков на стенах пещер.   На рис. 1 показан пример картины, написанной традиционным способом.

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

Рисунок 3. Пример графического планшета/дигитайзера

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

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

Рисунок 4. Легкоеи более сильное нажатие с помощью цифрового пера на трансформере

Corel и Intel

Инженеры Corel объединили свои усилия с инженерами Intel (Вейдзя Ванг и Ким Сёнг-Ву) для повышения производительности Corel Painter на многоядерных ПК. Вейдзя сама занимается живописью и активно использует Corel Painter, поэтому для нее эта задача была совершенно естественной. Благодаря ее бесценному опыту и энтузиазму удалось не только оптимизировать производительность продукта, но и улучшить пользовательский интерфейс, особенно в плане поддержки трансформеров с процессорами Intel®. Ким Сёнг-Ву также внес немалый вклад в повышение производительности и разработку пользовательского интерфейса.

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

В начале работы над повышением производительности инженеры создали профиль производительности, который показал использование в Corel Painter избыточного количества системных вызовов. Эти проблемы удалось исправить, улучшив реализацию многопоточных вычислений в приложении. Корпорация Intel предоставила разработчикам Corel экспериментальное тестовое приложение, в котором была добавлена поддержка поточных расширений Intel® SIMD (обработка нескольких наборов данных одной инструкцией), что позволило повысить производительность и одновременно снизить потребление электроэнергии. Опираясь на эту доработку Intel, разработчики Corel провели векторизацию 6 функций, используемых в более чем 200 входящих в приложение кистях (рис. 2). Это повлекло существенное повышение производительности по сравнению с исходным решением без векторизации. Полученные результаты и общая атмосфера профессионального доверия, сформированная при работе над повышением производительности, дала инженерам возможность в дальнейшем поработать над улучшением пользовательского интерфейса, чтобы улучшить поддержку режимов работы трансформеров.

Инструменты и проблемы

В Corel использовали Microsoft Typeperf, средство командной строки, встроенное в Windows*, для сбора профилей производительности (см. рис. 5), которые показали избыток системных вызовов. Но одного этого анализа было недостаточно для выявления причин этой проблемы.

Рисунок 5.   Microsoft Typerperf.exe

Инженеры создали новую тестовую систему с помощью программных средств Intel® VTune™ Amplifier XE (рис. 6) и Intel® Parallel Studio XE.

Рисунок 6.   Экран Intel® VTune™ Amplifier XE

Эта новая система дала возможность измерить правильность работы кистей и повышение производительности в различных сценариях, например в крупных документах с выделенными фрагментами. Она также помогла найти оптимальные параметры по умолчанию для всех задач, связанных с производительностью, что позволило повысить эффективность многопоточных вычислений. Анализ также показал, что можно значительно улучшить программу, использовав расширения Intel® SIMD в дополнение к многопоточности. Теоретически поточные расширения Intel Streaming SIMD могут повысить производительность операций такого типа в 4 раза. Через несколько месяцев работы по векторизации обработчиков кистей вместе с Intel при тестировании были получены следующие результаты: по сравнению с решением без поддержки SIMD скорость работы возросла в среднем в 1,8 раза. Для разных кистей, в зависимости от реализации ветвления в алгоритмах, прирост производительности составил от 1,1 раза до 4 раз. В сочетании с многопоточностью на устройствах с двухъядерными процессорами удалось добиться более чем шестикратного ускорения.

Рассматривая возможность поддержки трансформеров, инженеры Corel задумывались над полной переработкой пользовательского интерфейса для режима планшета. К счастью, такая переделка не потребовалась. При работе над повышением производительности инженеры Intel получили доступ к некоторому исходному коду Painter и выяснили, что в архитектуру пользовательского интерфейса Corel Painter можно было просто «добавить» поддержку планшетного режима вместо того, чтобы «создавать» новую версию Painter для планшетов. В результате сотрудничества была создана единая версия, которая прекрасно работает на ПК с Windows, планшетах и трансформерах (рис. 7).

Рисунок 7. Режим ноутбука и режим планшета

Разработчики Intel выяснили, что пользовательский интерфейс поддерживал возможности настройки и позволял пользователям создавать новые «палитры» — своего рода панели-контейнеры, в которых могут находиться любые команды, кисти, кнопки и значки. Например, можно добавить ваши любимые кисти, команды, такие как «Отмена» или «Повтор», или кнопку-переключатель, чтобы отображать или скрывать слои или панели, такие как панель настройки кистей, и т. д. Пользовательский интерфейс создан на основе XML, поэтому его можно настраивать. Инженеры Intel рекомендовали использовать простое переключение между двумя такими настраиваемыми палитрами, каждая из которых по умолчанию предназначалась для каждого режима: для режима планшета и режима ноутбука. Это переключение выполняется либо вручную, путем выбора режима в приложении, либо автоматически, путем обнаружения перехода из одного режима в другой с помощью событий Windows GetSystemMetrics и WM_SETTINGCHANGE на трансформере.

Рисунок 8. Пример кода: переключение пользовательского интерфейса из режима ноутбука в режим планшета из статьи Кима Сёнг-Ву «Обнаружение режимов планшета и ноутбука, а также ориентации экрана на трансформерах»

Было известно, что художникам требуется отдельный дигитайзер, чтобы применять перо, чувствительное к нажиму. Поэтому инженеры Intel предложили разработчикам Corel добавить поддержку API пера реального времени Майкрософт, доступного для всех встроенных перьев в Windows 8.

Приступив к доработке пользовательского интерфейса, специалисты Corel привлекли команду дизайнеров интерфейса, приложившую немалые усилия для проектирования интерфейса Painter для планшетного режима и для режима ноутбука. Эта команда привлекла множество художников и провела анализ их работы с программой. Стивен Болт, дизайнер пользовательских интерфейсов Corel, рассказывает о результате: «Впервые, когда нам удалось протестировать систему с пером реального времени и с аппаратным переключением между режимами трансформера, было очень здорово: в этот момент мы почувствовали, что весь код, оборудование и программы работают как единое целое, причем работают именно так, как это удобно пользователям».

Рисунок 9. Набор инструментов художника за три тысячи долларов:
ноутбук и дигитайзер (слева), планшет Microsoft Surface Pro за одну тысячу долларов (справа)

Эффективное использование сенсорного управления в Painter

Новая версия Corel Painter поддерживает функцию пера реального времени (RTS) в Windows. RTS‑совместимые устройства включают трансформеры под управлением Windows 8 и более поздних версий. Трансформеры вместе с RTS предоставляют художнику возможности, сравнимые с возможностями графического планшета, но значительно дешевле. Художники, располагающие компьютерами с поддержкой RTS, могут использовать следующий процесс для включения этих возможностей в Corel Painter.

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

Для настройки устройства, совместимого с RTS (Windows) и мультисенсорного ввода в Windows сделайте следующее.

1)    Выберите Edit  -> Preferences -> Tablet.

Рисунок 10. Диалоговое окно настроек планшета

2)    В разделе Tablet Options настройте параметры следующим образом:

а)     выберите RTS-compatible devices (Real-Time Stylus);

б)    установите флажок Enable Multi-touch;

в)     выберите Windows Multi-touch.

Рисунок 11. Рекомендуемые настройки для трансформеров в режиме планшета

3)    Нажмите кнопку ОК.

4)    Перезапустите Corel Painter.

Заключение

В Corel Painter 2015 множество новых и интересных возможностей, помимо описанных здесь. В дополнение к повышенной производительности новые функции для планшетов делают Corel Painter доступным для всех, а не только для профессионалов. Corel Painter 2015 в сочетании с трансформерами на основе процессоров Intel и дигитайзерами дает возможность художникам самого разного уровня мастерства делать наброски и пользоваться сенсорным управлением.

Ссылки и полезные материалы

• Веб-сайт Corel Painter: http://www.painterartist.com/us/product/paint-program/
• Учебные видеоролики Corel Painter: http://www.youtube.com/user/PainterTutorials
• Руководство по началу работы с Corel Painter 2015 (PDF): http://corl.co/1 whMmoM
• Руководство пользователя Corel Painter 2015 (PDF): http://corl.co/1tZzNQJ
• Corel Painter в Twitter (@CorelPainter): http://twitter.com/corelpainter
• Corel Painter в Facebook (corelpainter): https://www.facebook.com/corelpainter
• Обнаружение режимов планшета и ноутбука, а также ориентации экрана на трансформерах: http://intel.ly/10WUYc9
• Сенсорное управление и поддержка трансформеров в ваших любимых играх, Эрик Нимайер: http://intel.ly/1qD5nAi
• Создание приложений с поддержкой трансформеров, Стивен Роджерс: http://intel.ly/1xg2NYk
• Сенсорный ввод и ввод с помощью пера в Windows* 8, Мегана Рао: http://intel.ly/1B4C9nO
• Основы работы с Corel Painter 5 в Youtube* — поддержка трансформеров: http://youtu.be/hwCn7AQKpPM
• История Corel — http://www.corel.com/content/pdf/corporate/History_of_Corel.pdf
• Справочник по RealTimeStylus: http://msdn.microsoft.com/ru-ru/library/windows/desktop/ms701683(v=vs.85).aspx
• Обзор Corel Painter 2015 в журнале PC World Review от 13 августа 2014 г.: http://www.pcworld.com/article/2464183/corel-painter-2015-review-digital-art-studio-betters-its-best-features.html
• Intel® VTune™ Amplifier 2015 http://software.intel.com/ru-ru/intel-vtune-amplifier-xe
• Intel® Parallel Studio XE 2015 http://software.intel.com/ru-ru/intel-parallel-studio-xe

Об авторе

Тим Дункан — один из наших инженеров. Друзья называют его «мистер Гаджет». В настоящее время он помогает разработчикам применять в их продуктах новые технологии Intel. Тим обладает многолетним опытом работы в отрасли и знаком со многими ее сторонами: от производства микросхем до интеграции целых систем. Найдите его на сайте Intel® Developer Zone: Tim Duncan (Intel), в Twitter: @IntelTim, в Facebook: facebook.com/tim.duncanintel.

DownloadDeveloping_Racing_Thrills.pdf

Введение

Опираясь на возможности управления жестами, доступные в  Intel® RealSense™ SDK,компания PlayBuff Studiosразработала последнюю версию игры Death Drive: Racing Thrill * для устройств, поддерживающих технологию Intel® RealSense™. Разработчики PlayBuff обратили внимание, что в совсем в немногих гоночных играх у игрока была возможность одновременно управлять автомобилем и стрелять; в большинстве таких игр использовались традиционные средства управления. Разработчики решили создать игру с более современной и интуитивной атмосферой за счет использования управления жестами и голосом в сочетании с возможностью стрельбы во время езды.

Тарун Кумар (Tarun Kumar), директор компании PlayBuff, и его команда были уверены в том, что управлять с помощью жестов будет удобно и весело и такой подход улучшит общие ощущения от игры. Работая с Intel RealSense SDK для Microsoft Windows *, разработчики PlayBuff встроили управление жестами и голосом в основу игрового процесса. Получилась игра с уникальным интуитивным сочетанием езды и стрельбы.

В процессе разработки удалось изучить различные подходы и процессы анализа, необходимые для успешной реализации управления жестами и голосом в игре, в отличие от игр с традиционным управлением. Разработчики изучили различные варианты управления жестами и голосом, получили немало информации об оптимизации производительности с помощью Intel RealSense SDK и разработали концепцию влияния технологии на развитие компьютеров в будущем.

Решения и проблемы

Данные Intel® RealSense™ SDK

Программисты PlayBuff обнаружили, что Intel RealSense SDK предоставляет разработчикам огромный объем информации, которую можно использовать множеством разных способов. Немало времени на раннем этапе разработки было потрачено на изучение различных вариантов интерфейса и на определение того, какие данные были необходимыми и важными для достижения целей разработки. Команда решила использовать три возможности SDK в игре Death Drive: Racing Thrill: распознавание жестов, отслеживание рук и распознавание голоса в режиме командного управления.

Отслеживание руки и жестов

Интерфейс игры вообще не использует касаний, только возможности отслеживания рук и жестов в Intel RealSense SDK. На устройстве, поддерживающем Intel RealSense, можно пройти всю игру от начала до конца, используя только управление жестами. Отслеживание рук используется для определение положения определенных частей руки и идентификации различия между сжатым кулаком и открытой ладонью. С помощью жестов распознаются различные движения рук, включая боковые движения и быстрое встряхивание.

В следующем фрагменте кода показана реализация отслеживания жестов в игре.

// Get a hand instance here (or inside the AcquireFrame/ReleaseFrame loop) for querying features
          // pp is PXCMSensemanager instance
		PXCMHandModule hand=pp.QueryHand();
		if (hand!=null) {
			// Get Hand Tracking Processed Data
			PXCMHandDatahand_data = hand.CreateOutput();
			hand_data.Update();

			PXCMHandData.IHandmainHand;
			// retrieve the hand data
			pxcmStatus sts=hand_data.QueryHandData(PXCMHandData.AccessOrderType.ACCESS_ORDER_NEAR_TO_FAR,0,out mainHand);
if (sts>=pxcmStatus.PXCM_STATUS_NO_ERROR)
			{
				if(startTimer<4)
					startTimer +=  Time.realtimeSinceStartup-startRTime;

				Openness = mainHand.QueryOpenness();
				handDetected = true;
 // openness is zero when hand detected in starting, so use startTimer for some delay
				if(Openness < 20 &&startTimer>3)
					fist = true;
				else
					fist = false;

PXCMHandData.JointDatajointdata;

// get world coordinates of detected hand..

pxcmStatus xy1 = mainHand.QueryTrackedJoint(PXCMHandData.JointType.JOINT_CENTER,out jointdata);
PXCMPoint3DF32 xy2 =  jointdata.positionWorld;
PointOfCamera = new Vector3(-xy2.x,xy2.y,xy2.z);
// Normalise vector and make screen centre point to origin of world coordinates
				PointOfCamera = new Vector3(Mathf.Clamp(PointOfCamera.x/0.20f,-1,1),Mathf.Clamp(-PointOfCamera.y/0.12f,-1,1),0);
				PointOfCamera = new Vector3(PointOfCamera.x/2 +0.5f,PointOfCamera.y/2 +0.5f,0);
			}
			// clean up
				hand_data.Dispose();
			}else
startTimer = 0;
// Swipe code using hand tracking
// _velocities is vector3 Queue for storing coordinates of hand tracking
timer +=  Time.realtimeSinceStartup-startRTime;
original = new Vector3(-xy2.x,xy2.y,xy2.z);
				if(!FirstTime&& timer>2)
				{
					StartingPoint =original ;
					FirstTime = true;
					swipeVector = Vector2.zero;
					_velocities.Clear();
				}
				else if(timer>3)
				{
if(_velocities.Count>2)// check for three frames, we need at least three frames to get directions
			{
					_velocities.Dequeue();
			_velocities.Enqueue(original - StartingPoint);
			StartingPoint =original ;
			Vector3 total = Vector3.zero;
			varenuma = _velocities.GetEnumerator();
			while(enuma.MoveNext())
			{
			total += enuma.Current;
			}


//check direction vector coordinates for different gestures.
//MOVEMENT_THRESHOLD is minimum value for swipe detection.
		If(total.x> MOVEMENT_THRESHOLD)// for swipe right
		{
		FirstTime = false;
		timer =0;
		}
else if(total.x< -MOVEMENT_THRESHOLD)// swipe left
			{
			FirstTime = false;
			timer =0;
			}
else if(total.y> MOVEMENT_THRESHOLD)// swipe down
			{FirstTime = false;
			timer =0;}
else if(total.y< -MOVEMENT_THRESHOLD)// swipe up
			{FirstTime = false;
			timer =0;
			}else if(total.z> MOVEMENT_THRESHOLD)//  move hand away from camera
			{FirstTime = false;
			timer =0	;}

else if(total.z< -MOVEMENT_THRESHOLD)// move hand towards camera
			{
			FirstTime = false;timer =0;
			}
			}
else
			{
			_velocities.Enqueue (original - StartingPoint);
			StartingPoint = original;
			}
			}

Повороты с помощью жестов

Важной частью процесса разработки стала реализация управления поворотом автомобиля с помощью жестов. Для управления поворотом рулевого колеса автомобиля игра распознает жесты сжатия кулака левой и правой руки для поворота в соответствующую сторону (см. рис. 1). Если после этого разжать кулак, рулевое колесо автоматически вернется в нейтральное положение. Чтобы затормозить или ехать задним ходом, игрок должен сжать кулаки на обеих руках.

Рисунок 1. Жесты, используемые для поворота автомобиля в игре.

В PlayBuff последовательно применили несколько различных подходов, прежде чем удалось добиться успешной реализации управления поворотом с помощью жестов. Сначала использовали моделирование настоящего рулевого колеса, которое было изображено на экране. Игрок управлял им двумя руками. Но на практике в этом случае возникло две проблемы. Во-первых, требовалось, чтобы обе руки всегда были перед экраном. При этом имитировалось относительно «реалистичное» положение рук на рулевом колесе, но руки мешали игроку, загораживая экран — это серьезный недостаток, который разработчики не учли на этапе проектирования.

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

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

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

Что удалось узнать о жестах

В PlayBuff обнаружили, что управление при помощи жестов дает совершенно другие ощущения игрокам. Поскольку управление жестами — относительно новая технология и ее реализация может значительно различаться в разных приложениях и играх, для управления автомобилем в игре потребовалось обучение.

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

Рисунок 2. Управление с помощью жестов поясняется игроку в ходе игрового процесса.

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

Рисунок 3. График учебных инструкций в игре

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

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

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

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

Распознавание голоса

В начале проекта Кумар сомневался в возможностях Intel RealSense SDK в отношении распознавания речи, но вскоре убедился, что в командном режиме все работает очень хорошо. Подсчитав время, необходимое игроку для выполнения каждой команды в меню, он обнаружил, что применение голосовых команд SDK было не только приемлемым, но и более удобным: голосовые команды занимали менее 2 секунд, тогда как выполнение этих же команд с помощью жестов занимало 3—4 секунды. Это продемонстрировало эффективность голосового управления: на каждой команде можно было сэкономить 2—3 секунды, и управлять с помощью голоса было быстрее, чем переходить в меню и запускать игру.

Распознавание голоса используется главным образом в меню игры. Например, игрок может выбрать задание, просто произнеся вслух «задание 3» или «задание 4». С помощью голоса также можно выбрать модель автомобиля и изменить его цвет (см. рис. 4.), произнеся вслух цвет, например, «желтый» или «черный». Если игроку нужно выбрать определенный уровень или задачу на определенном этапе игры, можно использовать соответствующие голосовые команды, например «первая задача» или «вторая задача». Голосовые команды также применимы в игровом процессе для ведения огня из их оружия в качестве альтернативы жесту рукопожатия.

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

Производительность

Наибольшие сложности при разработке были связаны с применяемой в гоночной игре физической моделью, образовывавшей высокую нагрузку на ЦП. Для моделирования физики автомобиля требуется немало ресурсов ЦП, поэтому при разработки много времени было потрачено для сопряжения физики автомобиля с управлением жестами и для оптимизации использования ЦП. Качество графики очень важно в любой игре, и сначала в Death Drive: Racing Thrill было значительно больше графических деталей, в том числе присутствовали эффекты погоды и тумана, реализованные с помощью частиц. В игре сохранилось вычисление теней в реальном времени, но после реализации бета-версии Intel RealSense SDK для интеграции управления жестами с физикой автомобиля оказалось, что производительности ЦП недостаточно: кадровая скорость снижалась ниже необходимой, равной 30 кадрам в секунду. Такой результат был получен на целевой платформе, соответствующей минимальным требованиям к системе: процессор Intel® Core™ i5-4250 частотой 1,3 ГГц, 4 ГБ ОЗУ и видеоадаптер Intel® HD Graphics 5000.

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

Выбор режима ввода

Разработчики PlayBuff считают, что у игроков должна быть возможность выбрать режим ввода в игре. Пользователю не требуется непременно использовать мышь и клавиатуру или сенсорное управление для прохождения игры, но у пользователя есть такая возможность. Например, для стрельбы пользователь может использовать не только жест рукопожатия и голосовые команды, но и клавишу F на клавиатуре.

Тестирование

Тестирование велось на всех этапах процесса разработки с самого начала проекта. В начале работы для упрощения внутреннего тестирования разработчики PlayBuff и команда контроля качества Intel обсудили создание тестовых сценариев специально для Intel RealSense SDK. Дальнейшее тестирование в PlayBuff с привлечением пользователей помогло существенно улучшить пользовательский интерфейс, а в процессе разработки команда сотрудничала с тестовой группой, состоящей из игроков с различными навыками в области гоночных игр и игр со стрельбой.

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

Среди других важных фактов, полученных в ходе тестирования, была проблема частого избыточного поворота (в результате была реализована система адаптации руля), а также тот факт, что работать с меню с помощью голосовых команд оказалось намного быстрее. Тестирование также помогло при отладке встроенного в игру учебного режима. Обучение запускается в зависимости от потребностей пользователей; инструкции отображаются тогда, когда в игре требуются соответствующие действия. Разработчики провели всеобъемлющее тестирование для вычисления среднего времени отклика для задач, чтобы правильно скоординировать время работы различных инструкций.

Заключение

Кумар считает, что для создания и реализации приложения с технологией Intel RealSense, в отличие от традиционного ввода, требуется другой ход мышления. Для выбора правильного подхода на стадии замысла проекта важно внимательно ознакомиться с подробными правилами разработки, предоставляемые корпорацией Intel в составе Intel RealSense SDK.

Разработчикам следует учитывать особенности и преимущества Intel RealSense SDK, рассматривать потенциальные сценарии использования, где интерфейс с управлением жестами может оказаться наиболее удобным. Приложение может быть игровым, развлекательно-образовательным или даже связанным со здравоохранением — в любом случае настоящее преимущество Intel RealSense SDK состоит в создании новых возможностей для пользователей, а не в простой замене традиционных методов ввода на жесты в существующих приложениях. При правильном подходе к технологии, свободном мышлении и грамотном проектировании успех, по мнению Кумара, просто гарантирован.

Для Кумара и его команды в PlayBuff наибольшим преимуществом этого проекта стала сама возможность изучить новую технологию. Сначала разработчики располагали лишь теоретическими знаниями о неконтактных интерфейсах, но теперь они намного лучше понимают все преимущества и затруднения, связанные с технологией Intel RealSense. Благодаря опыту они могут подходить к проектированию будущих игр с точки зрения управления жестами, голосового управления и итогового удобства для пользователей.

Возможные  области применения технологии Intel® RealSense™

При работе с Intel RealSense SDK возникло четкое понимание значительного потенциала этой технологии. Существует немало сценариев использования, в которых технология Intel RealSense может предоставить пользователям новые удобные возможности. Например, в здравоохранении интерфейсы с управлением жестами дадут возможность врачам и пациентам взаимодействовать с меньшей вероятностью распространения инфекции при обходах и при обновлении информации о ходе лечения в больницах.

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

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

По мнению Кумара, основным фактором для воплощения в реальность всех таких приложений, является повышение дальности действия камеры Intel® RealSense™ 3D с текущего расстояния в 1,3 м до такого расстояния, чтобы в кадр камеры попадало все тело человека. При этом камера должна сохранять точность при отдалении объекта съемки от камеры. При таких усовершенствованиях можно будет разрабатывать и другие игровые приложения, такие как теннис и гольф, где камера будет безошибочно измерять силу, направление и точность размаха и удара. Кроме того, успех в области казуальных игр зависит от формирования пользовательской базы с помощью технологий, доступных в широко используемых ноутбуках и мобильных устройствах.

Еще одна область, в которой технология Intel RealSense представляется перспективной — распознавание лиц. Эта технология пока еще не освоена, но у нее огромный потенциал. При этом распознавание жестов, голоса и лица вряд ли полностью вытеснит традиционные интерфейсы, но дополнит их и сделает более удобными в определенных сценариях использования. В целом технология Intel RealSense обладает широким потенциальном для использования в различных областях, она дает новые преимущества пользователем и открывает новые возможности для разработчиков.

О разработчике

Компания PlayBuff Studios, находящаяся в индийском городе Чандигарх, была основана в 2010 году с целью разработки игр мирового уровня. Компания начала с разработки двухмерных игр, предназначенных для магазина Nokia Store, и в первом же году своей работы вошла в тройку лучших компаний Индии. На настоящий момент игры компании PlayBuff были загружены из магазина Nokia Store свыше 65 миллионов раз. По количеству загрузок компания входит в число лучших 25 разработчиков.

Параллельно компания начала работу над играми в трех жанрах, которым в ближайшие 2–3 года планируется уделить больше внимания: гонки, многопользовательские шутеры с видом от третьего лица и мобильные социальные игры. Шутер этой компании под названием Battle It Out * был недавно выпущен и опубликован в магазине Apple App Store, а многопользовательская социальная игра Bands of Woods * находится на этапе активной разработки.

На данный момент компания PlayBuff выпустила два наименования на основе Racing Thrill. Игра Death Drive: Racing Thrill была впервые выпущена в апреле 2014 года в виде приложения для устройств с iOS *, а затем ее выбрали специалисты Майкрософт для переноса на платформы Windows * 8 и Windows Phone *.

Затем игра Death Drive: Racing Thrill была переделана для поддержки интуитивного управления жестами и стала одной из победительниц на первом этапе конкурса Intel^®Perceptual Computing Challenge 2013. После этой победы Кумар и его разработчики потратили 5 месяцев на работу с Intel RealSense SDK, чтобы добавить полное управление жестами и голосом в преддверии общедоступного выпуска версии с поддержкой Intel RealSense SDK.

Предложенная компанией PlayBuff концепция решения для электронных медицинских карт с управлением жестами была отобрана как одна из лучших десяти идей на творческом этапе глобального конкурса Intel® RealSense™ App Challenge 2014,на который были поданы сотни заявок со всего мира. Компания PlayBuff перешла на этап разработки этого конкурса и теперь работает над прототипом решения электронных медицинских карт с управлением голосом и жестами. Такая система позволит врачам получать доступ к медицинским картам пациентов, ни к чему не прикасаясь, и тем самым снизить риск распространения инфекции контактным путем.

Игра Death Drive: Racing Thrill скоро будет выпущена для устройств под управлением Windows 8 со встроенной камерой Intel RealSense 3D. Пакет Intel RealSense SDK можно загрузитьздесь.

Для получения дополнительных сведений о компании PlayBuff Studios и ее играх, в том числе Death Drive: Racing Thrill, посетите сайт этой компании.

Полезные ресурсы

Документация

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

Документацию к Intel RealSense SDK можно загрузитьздесь.

Поддержка Intel

Кумар положительно отзывается от поддержки, полученной им лично и всей командой PlayBuff от Intel в процессе интеграции Intel RealSense SDK, особо указывая на прозрачность работы и быстроту реагирования службы поддержки. На обращения в службу поддержки и по вопросам, связанным с оборудованием, и по техническим вопросам, таким как трудности с хранением откалиброванных данных и отражения, ответ всегда давался в течение одного-двух дней.

Технология Intel RealSense

Intel Developer Zone для RealSense

Intel RealSense SDK

Intel® RealSense™ Developer Kit

Учебные материалы по технологии Intel RealSense

Intel, эмблема Intel и Intel Core являются товарными знаками корпорации Intel в США и в других странах.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

© Корпорация Intel, 2015 г. Все права защищены.

Download paper as PDF

Введение

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

Дополнительные сведения о реализации сшивания панорам, а также о новом подходе, когда для снятия полной круговой панорамы используются две камеры, см. в моей предыдущей публикации: http://software.intel.com/ru-ru/articles/dual-camera-360-panorama-application. В этом документе приводится краткое сравнение двух популярных библиотек, а затем следует подробное описание создания приложения, способного быстро сшивать изображения в панораму.

OpenCV* и PanoTools*

Я протестировал две самых популярных библиотеки с открытым исходным кодом: OpenCV и PanoTools. Я начал с PanoTools — это достаточно развитая библиотека для сшивания, доступная для Windows*, Mac OS* и Linux*. В ней поддерживается множество расширенных возможностей, обеспечивается стабильное качество. Вторая рассмотренная библиотека — OpenCV. OpenCV — это очень крупный проект, содержащий несколько библиотек по обработке изображений, с обширной базой пользователей. Он выпускается для Windows, Mac OS, Linux, Android* и iOS*. Обе библиотеки включают образцы приложений для сшивания. Приложение в составе PanoTools выполнило работу за 1 минуту 44 секунды. Приложение в составе OpenCV — за 2 минуты 16 секунд. Хотя скорость у PanoTools выше, мы решили использовать OpenCV в качестве отправной точки, учитывая значительную пользовательскую базу этой библиотеки и ее доступность на мобильных платформах.

Описание первоначального приложения и сценария тестирования

Мы будем использовать образец приложения OpenCV cpp-example-stitching_detailed в качестве отправной точки. Приложение запускает конвейер сшивания, который включает несколько раздельных этапов. Вот краткое назначение этих этапов.

1. Импорт изображений.
2. Поиск элементов.
3. Попарное сравнение.
4. Деформация изображений.
5. Составление.
6. Смешение.

Для тестирования мы использовали планшет с четырехъядерной «системой на кристалле» Intel® Atom™ Z3770 с 2 ГБ оперативной памяти под управлением Windows 8.1. Нагрузка состояла в сшивании 16 изображений с разрешением 1280 х 720.. 

Многопоточный поиск элементов с помощью OpenMP*

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

Первый этап, который мы распараллеливаем, — поиск элементов. Сначала добавляем директиву компилятора OpenMP над циклом for:

#pragma omp parallel for
for (int i = 0; i < num_images; ++i)

Теперь цикл будет выполняться в несколько потоков. Но в цикле мы задаем значения переменных fullj'mg и img. Из‑за этого возникнет конкуренция между потоками, и это повлияет на результат. Самый простой способ решить эту проблему — преобразовать переменные в векторы. Берем следующие объявления переменных:

Mat full_img, img;

и заменяем их на:

vector<Mat> full_img(num_images);
vector<Mat> img(num_images);

Теперь в цикле мы изменим каждое вхождение каждой переменной на ее новое имя.

full_img becomes full_img[i]
img becomes img[i]

Содержимое, загруженное в full_img и img, используется позже в приложении, поэтому для ускорения не будем высвобождать память. Удалите эти строки:

full_img.release();
img.release();

Затем можно удалить эту строку из этапа составления:

full_img = imread(img_names[img_idx]);

На full_img мы снова ссылаемся при масштабировании в цикле составления. Снова изменяем имена переменных:

full_img становится full_img[img_idx]

img становится img[img_idx]

Итак, первый цикл распараллелен. Теперь нужно распараллелить цикл деформации. Сначала добавляем директиву компилятора, чтобы сделать цикл параллельным:

#pragma omp parallel for
for (int i = 0; i < num_images; ++i)

Это все, что необходимо, чтобы цикл стал параллельным, но можно еще немного оптимизировать этот раздел. Существует второй цикл for сразу после первого. Мы можем перенести работу из него в первый цикл, чтобы сократить количество запускаемых потоков. Переместите эту строку в первый цикл for:

images_warped[i].convertTo(images_warped_f[i], CV_32F);

Также нужно перенести определение переменной images_warped_f выше первого цикла:

vector<Mat> images_warped_f(num_images);

Теперь можно распараллелить цикл составления. Добавляем директиву компилятора перед циклом for:

#pragma omp parallel for
for (int img_idx = 0; img_idx < num_images; ++img_idx)

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

Оптимизация алгоритма попарного сравнения

Попарное сравнение элементов реализовано так, что каждое изображение сравнивается с каждым другим изображением, из-за чего объем работы возрастает по формуле O(n^{^}2). В этом нет необходимости, поскольку нам известен порядок, в котором следуют изображения. Надо переписать алгоритм так, чтобы каждое изображение сравнивалось только с соседними по порядку изображениями.

Для этого изменяем вот этот блок:

vector<MatchesInfo> pairwise_matches;
BestOf2NearestMatcher matcher(try_gpu, match_conf);
matcher(features, pairwise_matches);
matcher.collectGarbage();

на это:

vector<MatchesInfo> pairwise_matches;
BestOf2NearestMatcher matcher(try_gpu, match_conf);
Mat matchMask(features.size(),features.size(),CV_8U,Scalar(0));
for (int i = 0; i < num_images -1; ++i)
{
    matchMask.at<char>(i,i+1) =1;
}
matcher(features, pairwise_matches,matchMask);
matcher.collectGarbage();

Теперь время обработки уменьшилось до 1 минуты 54 секунд, то есть мы выиграли 14 секунд. Обратите внимание, что изображения необходимо импортировать в последовательном порядке.

Оптимизация параметров

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

Мы изменили параметры по умолчанию:

double work_megapix = 0.6;
double seam_megapix = 0.1;
float conf_thresh = 1.f;
string warp_type = "spherical";
int expos_comp_type = ExposureCompensator::GAIN_BLOCKS;
string seam_find_type = "gc_color";

на это:

double work_megapix = 0.08;
double seam_megapix = 0.08;
float conf_thresh = 0.5f;
string warp_type = "cylindrical";
int expos_comp_type = ExposureCompensator::GAIN;
string seam_find_type = "dp_colorgrad";

После изменения этих параметров обработка нагрузки заняла 22 секунды, что на 1 минуту 40 секунд быстрее. Такое ускорение обусловлено главным образом изменением значений параметров work_megapix и seam_megapix. Обработка существенно ускорилась, поскольку теперь мы выполняем сравнение и сшивание для очень маленьких изображений. При этом уменьшается количество отличительных элементов, которые можно найти и сравнить, но за счет усовершенствованного алгоритма сравнения мы можем слегка пожертвовать точностью.

Удаление ненужной работы

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

if (!is_compose_scale_set)
{…
}

if (blender.empty())
{
    …
}

Обратите внимание, что в коде деформации есть одна строка, где нужно заменить full_img[img_idx] на full_img[0]. За счет этого изменения мы можем ускорить обработку на 2 секунды: теперь она занимает 20 секунд.

Перемещение поиска элементов

Мы сделали еще одно изменение, но его реализация зависит от того, как именно работает приложение сшивания. В нашем случае приложение снимает изображения, а затем сшивает их сразу после съемки всех изображений. Если в вашем приложении такая же ситуация, можно перенести ту часть конвейера, которая отвечает за поиск элементов, на этап съемки изображений. Для этого нужно запускать алгоритм поиска элементов сразу же после съемки первого изображения и сохранять данные до того момента, когда они понадобятся. В наших экспериментах это обусловило ускорение сшивания примерно на 20 %, то есть в данном случае время сшивания сокращается до 16 секунд.

Логирование

Изначально логирование не включено, но отметим, что при его включении несколько снижается производительность. Мы обнаружили, что, если включить логирование, время сшивания возрастает примерно на 10 %. Поэтому в итоговой версии приложения важно отключить логирование.

Заключение

Учитывая популярность приложений для панорамной съемки на мобильных платформах, важно располагать решением с открытым исходным кодом, способным быстро сшивать изображения в панораму. Ускорив сшивание изображений, мы сделали приложение более удобным для конечных пользователей. Благодаря всем этим изменениям нам удалось сократить общее время сшивания с 2 минут 18 секунд до 16 секунд, то есть ускорить обработку приблизительно в 8,5 раза. Подробная информация приведена в этой таблице.

Программное обеспечение и нагрузки, использованные в тестах производительности, могли быть оптимизированы для достижения высокой производительности только на микропроцессорах Intel. Тесты производительности, такие как SYSmark* и MobileMark*, проводятся на определенных компьютерных системах, компонентах, программах, операциях и функциях. Любые изменения любого из этих элементов могут привести к изменению результатов. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности, в том числе к тестам производительности определенного продукта в сочетании с другими продуктами.

Конфигурации: четырехъядерная «система на кристалле» Intel® Atom™ Z3770 с 2 ГБ оперативной памяти под управлением Windows 8.1. Дополнительные сведения см. на сайте http://www.intel.com/performance

Примечания

ИНФОРМАЦИЯ В ДАННОМ ДОКУМЕНТЕ ПРИВЕДЕНА ТОЛЬКО В ОТНОШЕНИИ ПРОДУКТОВ INTEL. ДАННЫЙ ДОКУМЕНТ НЕ ПРЕДОСТАВЛЯЕТ ЯВНОЙ ИЛИ ПОДРАЗУМЕВАЕМОЙ ЛИЦЕНЗИИ, ЛИШЕНИЯ ПРАВА ВОЗРАЖЕНИЯ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ. КРОМЕ СЛУЧАЕВ, УКАЗАННЫХ В УСЛОВИЯХ И ПРАВИЛАХ ПРОДАЖИ ТАКИХ ПРОДУКТОВ, INTEL НЕ НЕСЕТ НИКАКОЙ ОТВЕТСТВЕННОСТИ И ОТКАЗЫВАЕТСЯ ОТ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ В ОТНОШЕНИИ ПРОДАЖИ И/ИЛИ ИСПОЛЬЗОВАНИЯ СВОИХ ПРОДУКТОВ, ВКЛЮЧАЯ ОТВЕТСТВЕННОСТЬ ИЛИ ГАРАНТИИ ОТНОСИТЕЛЬНО ИХ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ, ОБЕСПЕЧЕНИЯ ПРИБЫЛИ ИЛИ НАРУШЕНИЯ КАКИХ-ЛИБО ПАТЕНТОВ, АВТОРСКИХ ПРАВ ИЛИ ИНЫХ ПРАВ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

КРОМЕ СЛУЧАЕВ, СОГЛАСОВАННЫХ INTEL В ПИСЬМЕННОЙ ФОРМЕ, ПРОДУКТЫ INTEL НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СИТУАЦИЯХ, КОГДА ИХ НЕИСПРАВНОСТЬ МОЖЕТ ПРИВЕСТИ К ТРАВМАМ ИЛИ ЛЕТАЛЬНОМУ ИСХОДУ.

Корпорация Intel оставляет за собой право вносить изменения в технические характеристики и описания своих продуктов без предварительного уведомления. Проектировщики не должны полагаться на отсутствующие характеристики, а также характеристики с пометками «зарезервировано» или «не определено». Эти характеристики резервируются Intel для будущего использования, поэтому отсутствие конфликтов совместимости для них не гарантируется. Информация в данном документе может быть изменена без предварительного уведомления. Не используйте эту информацию в окончательном варианте дизайна.

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

Перед размещением заказа получите последние версии спецификаций в региональном офисе продаж Intel или у местного дистрибьютора.

Копии документов с порядковым номером, ссылки на которые содержатся в этом документе, а также другую литературу Intel можно получить, позвонив по телефону 1-800-548-4725 либо на сайте: http://www.intel.com/design/literature.htm

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

Intel, эмблема Intel и Atom являются товарными знаками корпорации Intel в США и в других странах.

© Intel Corporation, 2014. Все права защищены.

*Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

Том Пантелс, Шень Гуо, Радж Шри Чабуксвар

Download as PDF

Содержание

Введение. 3

Почему важно создать хороший сенсорный интерфейс?. 3

Обработка сенсорного ввода. 4

Экономия электроэнергии за счет оптимизации сенсорного ввода. 4

Программы для анализа сенсорного ввода в Windows. 5

Примеры.. 7

Казуальная многопользовательская мультисенсорная игра с замедленным откликом на касания  7

Трехмерная казуальная игра с исчезновением реакции на касания. 11

Заключение. 14

Справочные материалы.. 15

Введение

Эффективное взаимодействие с пользователем — крайне важный аспект современных программных продуктов. Другие функции и характеристики важны с точки зрения функциональности устройства, но все они не будут иметь значения при недостаточно быстром отклике на сенсорное управление и при его недостаточном удобстве. С момента появления Windows 8 жесты стали основным способом взаимодействия с ультрабуками под управлением Windows, планшетами и смартфонами. Эффективность таких систем частично зависит от того, насколько сенсорное управление повышает удобство пользователей и насколько удобство пользователей зависит от скорости работы и быстроты отклика сенсорного интерфейса.

Время отклика — это длительность промежутка между началом движения пальца по экрану для выполнения жеста и появлением на экране наглядной реакции на выполняемый жест. Время отклика обычно измеряется довольно короткими промежутками (порядка 100—500 мс). Важно определить и оптимизировать недостаточно быстро работающие компоненты обработки сенсорного ввода, чтобы добиться наибольшего удобства для пользователей.

Реализация сенсорного управления в приложениях для Windows — это совершенно новое направление (от измерений до анализа и оптимизации). Не всегда можно исходить из того, что если приложение постоянно обновляет сцену, то оно будет быстро реагировать на сенсорные жесты пользователя. В этой статье обсуждаются способы измерения скорости отклика, методы анализа при оптимизации сенсорного управления в системах с архитектурой Intel (IA), а также инструменты, необходимые для анализа проблем, связанных с реагированием приложений на касания.

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

Почему важно создать хороший сенсорный интерфейс?

Ультрабуки и планшеты получают все более широкое распространение на рынке, а сенсорное управление является одним из важнейших факторов для удобства пользователей. Устройства с сенсорным управлением буквально повсюду: это телефоны, планшеты, ультрабуки и моноблоки. Последние представляют собой настольные ПК, у которых системный блок встроен в заднюю часть монитора. Компания Gartner, занимающаяся ИТ-исследованиями, считает, что к 2015 году свыше 50 % компьютеров, приобретенных для пользователей младше 15 лет, будут оснащены сенсорными экранами [1].

Выпустив Windows 8, корпорация Майкрософт запустила Магазин Windows — это централизованный портал, на котором разработчики публикуют свои приложения, а пользователи могут их приобретать. Если приложение медленно реагирует на сенсорные жесты пользователя, то оно получит плохую оценку в магазине, что, без сомнения, скажется на показателях продаж.

Рисунок 1. Роль программного обеспечения в сенсорном управлении

На рис. 1 показана важная роль программного обеспечения и драйверов: во всем наборе технологий, отвечающих за сенсорное управление, 3 из 5 уровней являются программными (то есть образуют 60 %). Неудовлетворительное время отклика обычно является именно программной проблемой.

Обработка сенсорного ввода

Реализовать поддержку сенсорного ввода и жестов в десктопных приложениях для Windows можно тремя способами. Полную информацию об использовании этих сенсорных API см. в статье «Сообщения и очереди сообщений» [7]. Сообщения WMGESTURE и WMTOUCH обратно совместимы с Windows 7, а сообщения WMPOINTER — нет. У каждого из них есть как достоинства, так и недостатки. Сообщения WMPOINTER проще всего в реализации, но предоставляют меньше всего возможностей управления. Для сообщений WMTOUCH требуется писать наибольший объем кода, но они поддерживают самые широкие возможности управления. Сообщения WMGESTURE по своим характеристикам находятся на промежуточном уровне. Для поддержки сенсорного управления в приложениях для Магазина Windows можно использовать много разных способов — от класса GestureRecognizer, обрабатывающего сенсорный ввод и манипуляции, до API DirectManipulation, которые появились в Windows 8.1.

Экономия электроэнергии за счет оптимизации сенсорного ввода

Еще одним важным фактором удобства программы для пользователей является экономное потребление электроэнергии. Многое зависит от того, сколько электроэнергии потребляет приложение и как оно влияет на длительность работы системы от аккумулятора. Если приложение быстро расходует заряд аккумулятора, пользователи не будут его запускать. Высокое потребление электроэнергии обычно обусловлено значительной нагрузкой на ресурсы системы, т. е. ЦП, ГП и даже устройства хранения данных, выполняющие ненужную работу. В приведенных ниже примерах показаны эти проблемы и подчеркнут дополнительный эффект: зачастую при оптимизации сенсорного ввода также снижается и потребление электроэнергии. Этот дополнительный эффект мы также называем «бонусом за экономию электричества».

Программы для анализа сенсорного ввода в Windows

Для оптимизации сенсорных приложений для Windows можно использовать множество инструментов и программ. Правильное использование всех этих программ для измерения и анализа крайне важно для выявления проблем, связанных с сенсорным управлением. Ниже приводится краткое описание таких программ, их назначение и применимость к определенным аспектам анализа сенсорного ввода.

А.        Средства измерения

1.    Измерение времени отклика с помощью камеры высокого разрешения

i.   Запишите сенсорное взаимодействие на видео, а затем вручную переходите от кадра к кадру для получения значений времени отклика.

2.   Системный монитор Windows

i.   Входит в состав Windows, позволяет анализировать работу ЦП и выводить другие показатели системы.

ii.  Эта программа собирает информацию с шагом в 1 секунду и выводит наглядное представление работы системы при запущенном приложении.

3.   Intel® Power Gadget

i.   Собирает метрику электропитания, например потребляемую мощность пакета (ЦП и ГП).

4.   Регистратор производительности Windows (WPR)

i.   Входит в состав Windows 8/8.1 ADK.

ii.  WPR обладает пользовательским интерфейсом (WPRUI), дающим возможность выполнять трассировку для сбора определенных метрик работы системы, таких как использование ЦП, операции фиксации виртуальной памяти, потребление электроэнергии и т. п.

5.   FRAPS

i.   Выдает кадровую скорость приложения (в кадрах в секунду) и работает только в десктопных приложениях.

ii.  На веб-сайте заявлена поддержка только Windows 7, но можно использовать и для десктопных приложений под управлением Windows 8/8.1.

Б.        Средства анализа

1.    Анализатор производительности Windows (WPA)

i.   Входит в состав Windows 8/8.1 ADK.

ii.  WPA используется для загрузки ETL-файла, созданного программой WPR, поэтому можно выполнять подробный анализ.

2.   Intel^® VTune™ Amplifier XE 2013

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

ii.  Дает подробное представление о расписании потоков.

3.   Intel^® Performance Bottleneck Analyzer (PB A)

i.   Предоставляет расширенные возможности анализа для оптимизации скорости отклика программ.

4.   GPUView

i.   Входит в состав Windows 8/8.1 ADK. Позволяет подробно анализировать работу очереди контекста ЦП и аппаратной очереди ГП. При сборе этой информации используйте в WPRUI параметр трассировки «Работа ГП».

5.   Intel^® Graphics Performance Analyzer (Intel GPA)

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

В.        Какие вопросы следует задавать при использовании этих программ

1. Intel Power Gadget показывает, что потребляемая мощность пакета (ЦП и ГП) существенно превышает обычную?

2.   Анализатор производительности Windows показывает высокую нагрузку на ЦП?

• Экран при этом обновляется?
• Если в нагрузке на ЦП наблюдаются пики, что при этом происходит на экране? Возможно, анимация, которая запускается через каждые 3 секунды, увеличивает нагрузку на ЦП с такой же частотой.

3.   GPUView показывает, что очередь ЦП/ГП заполнена?

4.   Что Intel Performance Bottleneck Analyzer показывает на временной шкале?

■      Примените фильтрацию по модулю, потребляющему больше всего ресурсов ЦП, и посмотрите, какие происходят действия модуля и потока.

5.   Приложение изменило разрешение тактового таймера системы с 15,6 мс (по умолчанию в Windows) на меньшее значение?

■      Если приложение меняет разрешение тактового таймера системы на меньшее значение, например на 1 мс, приложение будет слишком часто выполнять вызовы Update и Draw, из-за чего может быть заполнена очередь контекстов ЦП и очередь ГП.

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

Примеры

Для этих примеров мы использовали камеру высокого разрешения, чтобы получать среднее время отклика порядка 200 мс. В приведенных примерах приложения не только слишком медленно реагировали на касания, но и в некоторых случаях вообще никак не реагировали на них.

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

1.   Описание проблемы

У этого десктопного приложения для Windows наблюдаются задержки порядка 170 мс. Хуже того, это приложение зачастую вообще не реагирует на действия пользователя (при жестах не изменяется экран). Поскольку это приложение — спортивная игра, из-за отсутствия реакции на касания часто засчитывался несправедливый результат.

2.   Использование различных средств для выявления проблем

Первое использованное нами средство — системный монитор Windows, поскольку он собирает данные о том, что происходит в системе, когда запущено приложение. Если рассмотреть использование приложением ресурсов при отсутствии сенсорных жестов, можно понять, где возникнут узкие места при обработке жестов. Здесь можно увидеть завышенную нагрузку на определенные ресурсы (использование ЦП, скорость переключения контекста, скорость прерываний и пр.), если она составляет 100 % или превышает пороговые значения, полученные в ходе анализа прежних нагрузок.

Рисунок 2.Приложение бездействует, ЦП загружен на 100 %

На рис. 2 показано, что одно ядро ЦП (процессор 0) загружено на 100 %. Это означает, что одноядерное приложение израсходовало все ресурсы процессора при обновлении изображения, которое не изменяется визуально.

Следующая программа — Intel Power Gadget — использовалась для того, чтобы оценить влияние полной загрузки приложением одного ядра ЦП. Мы открыли командную строку от имени администратора, перешли в папку установки и ввели команду:

PowerLog3.0.exe -duration <длительность выполнения в секундах> -file <файл журнала.csv>

После выполнения команды мы ввели имя файла журнала и нажали клавишу «Ввод». На рис. 3 показано потребление электроэнергии пакетом (ЦП и ГП) в период, когда приложение было запущено, но не обрабатывало сенсорные команды. По оси X — частота выборки, с которой программа читала показатели MSR, а по оси Y — потребляемая мощность процессора в Вт [3].

Рисунок 3.Потребление электроэнергии пакетом (ЦП и ГП) в режиме бездействия, Вт

Такое же поведение наблюдалось при выполнении сенсорных жестов, как показано в графиках нагрузки на ЦП, причем уровень потребляемой мощности оставался примерно одинаковым и при обработке жестов, и без жестов. Это явно указывает на то, что что-то потребляло все ресурсы, из-за чего реакция на касания была затруднена. Пока приложение не было запущено, потребляемая мощность системы составляла около 2,5 Вт. Это означает, что приложение вызвало увеличение потребляемой мощности на 9 Вт. Что же привело к повышению мощности, потребляемой ЦП и ГП, на 9 Вт?

Затем мы использовали программу Intel GPA, которая показала 350 кадров в секунду, когда приложение не обрабатывало сенсорные жесты, и 210 кадров в секунду при обработке сенсорных жестов. Этот вопрос постоянно обсуждается, но принято считать, что человеческий глаз не может отличить отрисовку со скоростью 60 кадров в секунду от скорости 120 кадров в секунду. Это означает, что, с точки зрения пользователя, изображение при 60 кадрах в секунду было бы точно таким же, как при 210 кадрах в секунду.

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

Рисунок 4. Снимки экрана GPUView с заполненными очередями ГП/ЦП

Что привело к загрузке ЦП на 100 % и к заполнению очередей ЦП/ГП?

Мы использовали программу WPRUI, выбрав трассировку только использования ЦП, чтобы снизить издержки, вызванные самой этой программой. При анализе программ, находящихся в состоянии бездействия, следует учитывать и издержки программы, применяемой для анализа. На этом этапе мы уже знали, что приложение заполняло очереди ЦП/ГП. Итак, что вызывалось перед графическим модулем? Изучив стек вызовов к графическому модулю, мы обнаружили возможную причину бесполезной работы.

Рисунок 5.Стек вызовов приложения

Изучив стек вызовов, показанный на рис. 5, мы обнаружили, что метод Game::Tick вызывался перед вызовом D3D9 Present, который обращался к графическому модулю igdumd32.dll. Этот метод Game::Tick непреднамеренно задал разрешение тактового таймера системы равным 1 мс вместо 15,6 мс, принятого в Windows по умолчанию. См. рис. 6.

Рисунок 6.Метод Game::Tick изменил разрешение тактового таймера системы

Поэтому приложение выполняло вызовы Update и Draw через каждую 1 мс, то есть при вызове метода Game::Tick. Вызов этих методов каждую миллисекунду также приводил к слишком частому пробуждению ЦП, который не переходил в состояния более глубокого сна (С-состояния), а также к ненужному повышению нагрузки на ГП.

3.  Результат

Существуют API, с помощью которых можно запретить приложению изменять разрешение тактового таймера системы и синхронизировать приложение с частотой вертикальной развертки экрана (Vsync). После использования этих API мы добились того, что ЦП больше не тратил 100 % времени своей работы на вызовы Update и Draw.

Рисунок 7. Использование ЦП после оптимизации

Поскольку ЦП больше не выполнял ненужные расчеты Update и вызовы Draw каждую миллисекунду, очередь контекстов ЦП и очередь ГП уже не были заполнены. На снимке экрана на рис. 8 показана работа при 60 кадрах в секунду, поскольку частота вертикальной развертки экрана составляла 60 Гц.

Рисунок 8.Работа оптимизированных очередей ЦП и ГП

Кадровая скорость приложения была теперь ограничена 60 кадрами в секунду, поскольку пакеты присутствия передавались синхронно с частотой вертикальной развертки монитора, составляющей 60 Гц. За счет оптимизации потребления приложением ресурсов при бездействии (изображение на экране не меняется, сенсорные жесты не обрабатываются) нам удалось добиться более плавного и быстрого реагирования на касания. Среднее время отклика оптимизированного приложения составило около 110 мс (тогда как ранее оно составляло около 170 мс), причем касания уже не пропускались (ранее приложение иногда на них вообще не реагировало).

Дополнительный выигрыш: потребляемая пакетом мощность сократилась на 8,5 Вт. Теперь пользователи могли дольше играть в эту игру на мобильном устройстве без подзарядки.

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

Трехмерная казуальная игра с исчезновением реакции на касания

1.      Описание проблемы

В этом примере мы рассматриваем трехмерную игру для десктопного режима Windows 8, использующую сообщения WMTOUCH для обработки сенсорного ввода. В ходе игры пользователь проводит по экрану в разные стороны, чтобы игровой персонаж выполнял различные действия (прыгал, скользил, приседал и пр.). Если никакие жесты не выполняются, то игровой персонаж все время просто бежит по заданному направлению.

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

1. При последовательном выполнении двух жестов, если интервал времени между ними был слишком мал, на второй жест игра обычно не реагировала.
2. Если протяженность жеста на сенсорном экране была слишком мала, то игра на такие жесты не реагировала.

2.      Использование различных средств для выявления проблем

• Изоляция проблемы. Определите, с чем связаны проблемы отклика на касания — с приложением или с платформой (оборудование, драйвер, ОС). Здесь рекомендуется запустить WPR, переключиться в приложение и выполнять одиночный жест касания в определенные моменты в ходе сбора данных, чтобы события касания и их длительность наглядно отображались при анализе.
  
  

Рисунок 9.Касания с откликом и касания без отклика

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

• Сравнение стеков вызовов «правильной» и «неправильной» работы интерфейса. Сравнение различных аспектов касаний, на которых есть отклик (правильная работа), и касаний без отклика (неправильная работа) часто показывает различия в том, какие функции вызываются приложением.
  
  Мы изучили стеки вызовов, содержащие FrameMove(), поскольку именно эта функция, исходя из ее названия, обновляет изображение на экране. В стеке вызовов «правильной работы» вызывается функция AvatarMovesToTheLeft::FrameMove, а при «неправильной работе» она не вызывается (см. рис. 10).
  
  

Рисунок 10.Стеки вызовов при касаниях с откликом и касаниях без отклика

• Трассировка стеков вызовов. С помощью трассировки стека вызовов «неправильной работы» мы определили место нарушения цепочки вызовов. Вызывались функции обработки сообщений Windows, в том числе PeekMessage, DispatchMessage, и даже функция игры WndProc. Это подтвердило, что весь сенсорный ввод был получен функцией обработки сообщений приложения, но функции xxxSlideLeftState или xxxSlideRightState, задающие режим бега игрового персонажа для предполагаемой команды, не были вызваны (см. рис. 11)..

Рисунок 11.Стек вызовов обработки сообщений при «неправильной работе»

3. Результат

A.     Причина отсутствия отклика на быстрый последующий жест состоит в том, что игра реагирует на жесты только в том случае, если игровой персонаж находится в состоянии «бег вперед». Если же он в другом состоянии, сенсорный ввод не обрабатывается. Например, после первого жеста состояние игрового персонажа изменяется с «бег вперед» на «скольжение вправо». Если второй жест будет выполнен раньше, чем состояние вернется к «бегу вперед», этот жест не будет обработан. Эту проблему удалось устранить путем кеширования сенсорных сообщений для соответствующего режима бега.

Б.    Причина отсутствия отклика на короткие жесты была связана с  функцией игры WndProc. Игра распознавала сенсорный жест только в случае, если его протяженность превышала 60 логических пикселей. Поэтому некоторые короткие жесты не обрабатывались. При одинаковом разрешении 60 логических пикселей на экране ультрабука соответствуют большему физическому расстоянию, чем на экране iPhone. Из-за этого короткие жесты в игре, перенесенной с платформы iPhone на ультрабук, будут с большей вероятностью неверно обрабатываться на экране ультрабука. Решение же состоит в том, чтобы установить пороговое значение для протяженности жеста на основе физического расстояния на экране, вычисляемого на основе количества точек на дюйм (DPI), а не логических пикселей.

Подведем итоги. Нам удалось определить, где возникают проблемы (на уровне приложения или на уровне платформы) путем сравнения вызовов API сообщений Windows для определения регистрации касаний операционной системой. Затем мы сравнили стеки вызовов жестов с ожидаемым откликом (правильная работа) и жестов без отклика (неправильная работа), чтобы определить различия в вызываемых функциях. И наконец, мы провели трассировку стека вызовов обработки сообщений, чтобы найти, где именно прерывается цепочка вызовов. Начало трассировки стека вызовов было в функциях, вызывавшихся из стека «правильной работы».

Заключение

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

Не всегда можно исходить из того, что если приложение постоянно обновляет сцену, то оно будет быстро реагировать на сенсорные жесты пользователя. Сцену следует обновлять лишь при необходимости, чтобы не расходовать впустую ресурсы системы, которые можно использовать для быстрого отклика на жест. Зачастую бесполезное обновление сцены с малозначимой анимацией приведет к заполнению очередей сообщений Windows, очередей ЦП или ГП, что может привести к значительным задержкам наглядного отклика на касания.

Справочные материалы

[1] Fiering, Leslie. Компания Gartner утверждает, что к 2015 году свыше 50 % ПК, приобретенных для пользователей младше 15 лет, будут оснащены сенсорными экранами. Gartner, 7 апреля 2010 г. Веб. 3 марта 2014 г.

[2] Chabukswar, Rajshree, Mike Chynoweth, Erik Niemeyer. Intel^® Performance Bottleneck Analyzer.Корпорация Intel, 4 августа 2011 г. Веб. 12 февраля 2014 г.

[3] Seung-Woo Kim, Joseph Jin-Sung Lee, Vardhan Dugar, Jun De Vega. Intel^® Power Gadget.Корпорация Intel, 7 января 2014 г. Веб. 25 марта 2014 г.

[4] Freeman, Jeffrey M. Вопросы и ответы по Intel Graphics Performance Analyzers (Intel GPA).Корпорация Intel, 17 декабря 2013 г. Веб. 25 марта 2014 г.

[5] H, Victor. «Смартфоны iPhone обладают наивысшей скоростью отклика на касания, более чем вдвое по сравнению с устройствами Android и Windows Phone».Phone Arena. Phonearena, 1 октября 2013 г. Веб. 26 марта 2014 г.

[6] Комплект средств для развертывания и оценки Windows (Windows ADK).Корпорация Майкрософт, 2 апреля 2014 г. Веб. 3 апреля 2014 г.

[7] Сообщения и очереди сообщений.Корпорация Майкрософт, 24 января 2012 г. Веб. 26 марта 2014 г.

[8] Intel^® VTune Amplifier XE 2014.Корпорация Intel, 6 марта 2014 г. Веб. 3 апреля 2014 г.

[9] Fraps 3.5.99. Fraps, 26 февраля 2013 г. Веб. 3 апреля 2014 г.

Материалы по теме

Создание удобного сенсорного интерфейса и оптимизация элементов управления для сенсорного ввода

Download Document

В этом учебном руководстве вы узнаете, как создать простую игру с помощью платформы Cocos2d-x 3.0 или более поздней версии в среде разработки Windows*, а также как скомпилировать игру для запуска под Windows и Android*.

Что такое Cocos2d-x?

Cocos2d-x — это межплатформенная платформа для игр (и других графических приложений, например интерактивных книг) на базе cocos2dдля iOS*, но с использованием C++, JavaScript* или Lua* вместо Objective-C*.

Одним из преимуществ этой платформы является создание игр, которые можно развертывать в различных операционных системах (Android, iOS, Win32, Windows* Phone, Mac*, Linux* и пр.), сохраняя одну и ту же базу кода, внося необходимые небольшие доработки для каждой ОС.

Консоль Cocos2d-x

Консоль cocos2d появилась в версии 3.0. Это программа командной строки, предоставляющая определенные функции управления проектами Cocos2d-x или Cocos2d-JS: можно создавать проекты, запускать их, собирать, отлаживать и т. д.

Создание вашей первой игры

1 - Загрузите последнюю версию платформы и распакуйте ее в среду разработки. В этом учебном руководстве использовалась версия 3.3rc0, платформа была распакована на рабочий стол (C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0).

Рисунок 1.Структура папок Cocos2d-x версии 3.3 RC0

2. Чтобы создать новый проект в cocos2d-x, используйте setup.py (сценарий на языке Python*), расположенный в папке платформы, для настройки всех переменных среды, необходимых для сборки приложений для Win32 и Android. Перед запуском setup.py нужно загрузить, установить и настроить перечисленные ниже компоненты.

• Android* SDK
• Android* NDK
• Apache Ant*

Если еще не установлена среда выполнения Python, загрузите версию 2.7.6 здесь: http://www.python.org/download/

Figure 2.setup.py location

3. Откройте командную строку (cmd.exe) и выполните следующие команды.

- Перейдите в папку сценария (папку платформы). 

cd C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0

- Запуститесценарийsetup.py.
python setup.py (илипросто setup.py)

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

- Сценарий запросит пути установки Android SDK, Android NDK и ANT.

• Путь к папке Android NDK

Рисунок 3.Консоль Cocos2d запрашивает путь к папке NDK

• Путь к папке Android SDK

Рисунок 4.Консоль Cocos2d запрашивает путь к папке SDK

• Путь к папке bin пакета Apache ANT

Рисунок 5.Консоль Cocos2d запрашивает путь к папке bin пакета ANT

После указания запрошенных путей снова откройте командную строку (cmd.exe). Это действие необходимо для использования консольных команд cocos2d.

4. Введите cmd.exe, чтобы открыть командную строку (команды консоли cocos2d можно выполнять только там), и снова откройте папку платформы.

cd C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0

На следующем этапе мы создадим новый проект Cocos2d-x.

cocos new MyGame –p com.Project.MyGame –l cpp –d Project

Рисунок 6.Созданный проект Cocos2d-x

Вот краткое описание параметров.

• new: создание нового проекта; после этого параметра необходимо указать имя проекта (в данном случае — MyGame).
• -p: задает имя пакета.
• -l: выбор языка программирования. Допустимые значения: cpp или lua.
• -d: папка, в которой платформа создаст структуру проекта.

Если все сработало без ошибок, проект будет создан в папке Project внутри папки, в которую была распакована платформа.

Рисунок 7.Структура папок MyGame

Созданный проект содержит базу кода игры (Classes), ресурсы (изображения, звук и т. д.) и по одному проекту для каждой поддерживаемой платформы.

Сборка приложений для Android*

Требования.

• Нужно настроить все переменные среды для сборки игровых приложений для Android (Android SDK, Android NDK и ANT). Если это еще не сделано, см. раздел «Создание вашей первой игры» в этой статье.
• Установите Java Development Kit (JDK)

Примечание. Консоль Cocos2d использует команду javac для сборки для Android, поэтому нужно добавить переменную среды JAVA_HOME (путь к JDK).

1. Нужно скомпилировать игру для нескольких архитектур, поскольку платформа по умолчанию не компилирует для архитектур x86 и armeabi-v7a. Отредактируйте файл Application.mk, находящийся в папке.

C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0\Project\MyGame\proj.android\jni

Рисунок 8.Расположение файла Application.mk

2. Добавьте в этот файл следующую строку.

APP_ABI := armeabi armeabi-v7a x86

Рисунок 9.Файл Application.mk последобавлениястроки APP_ABI

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

3. С помощью командной строки перейдите в папку платформы.

cd C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0

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

cocos run –s Project\MyGame –p android

Рисунок 10.Выполнение команды для компиляции и запуска игры для Android*

• run: компиляция и запуск проекта.
• -s: путь к папке проекта.
• -p: выбранная платформа.

Примечание. Чтобы только скомпилировать проект, не запуская его, введите команду
cocos compile –s Project\MyGame –p android

Если все сработает без ошибок, команда cocos2d-consoleбудет использовать adb (если настроены нужные переменные среды) для установки файла APK на подключенное устройство или в инициализированный эмулятор. Если они недоступны, команда будет ожидать доступности устройства или эмулятора, как показано на приведенном ниже рисунке.

Рисунок 11.Команда ожидает устройства или инициализированного имитатора

После инициализации эмулятора или подключения устройства появится следующее окно.

Рисунок 12.Экран игры на платформе Android*

Создание приложений для Win32 Apps (для Windows* 7 или классического режима Windows* 8)

Для сборки требуется Visual Studio* 2012или более поздней версии

1. В командной строке (cmd.exe) перейдите в папку, куда была распакована платформа:

cd C:\Users\intel-user\Desktop\cocos2d-x-3.3rc0

2. Выполните следующую команду для компиляции и запуска игры для Windows:

cocos run –s Project\MyGame –p win32

Рисунок 13.Выполнение команды для компиляции и запуска игры для Windows*

Вот краткое описание параметров.

• run: компиляция и запуск выбранного проекта.
• -s: путь к папке проекта.
• -p: выбранная платформа.

Примечание. Чтобы только скомпилировать игру, но не запускать ее, используйте команду compile вместо команды run:

cocos compile –s Project\MyGame –p win32

После выполнения команды run, если все сработало без ошибок, появится следующее окно.

Рисунок 14.Экран игры на платформе Windows*

Также можно скомпилировать и запустить проект игры с помощью Visual Studio.

1. В папке Project откройте в Visual Studio файл MyGame.sln, находящийся в папке proj.win32.

Рисунок 15.Структура папок проекта Win32

2. Для компиляции проекта нажмите клавишу F6 (или выберите в меню «Сборка» -> «Собрать решение»), затем нажмите клавишу F5 для запуска (или выберите в меню «Отладка» -> «Начать отладку»). После сборки и запуска должно появиться такое же окно, как после использования консоли.

Рисунок 16.Проект Win32 в Visual Studio*

Итак, теперь вы знаете, как создать игру и скомпилировать ее для Android (x86 и ARM*), Windows 7 и классического режима Windows 8.

Справочные материалы

Исходный код платформы Cocos2d-x распространяется по лицензии МТИ, его можно получить здесь.

Cocos2d-x и документация: http://www.cocos2d-x.org/

cocos2d-console: http://www.cocos2d-x.org/wiki/Cocos2d-console

Примечание

На момент написания этой статьи в финальной версии Cocos2d-x 3.3 была ошибка на этапе создания проектов, не позволяющая пользователям создавать проекты (подробнее
см. здесь). Эта проблема была исправлена в последнем предварительном выпуске, но в финальной версии Cocos2d-x она пока осталась.

• Введение
• Краткий курс истории алгоритма быстрой сортировки
• Краткое введение в алгоритм GPU-Quicksort
• Алгоритм GPU-Quicksort в OpenCL 1.2
• Преобразование GPU-Quicksort для OpenCL 2.0
• Требования для учебной программы
• Запуск учебной программы
• Заключение
• Справочные материалы
• Об авторе
• Загрузить код

Введение

В этом учебном руководстве показано использование двух полезных компонентов OpenCL™ 2.0: функций enqueue_kernel, позволяющих помещать в очередь ядра устройства, а также work_group_scan_exclusive_add и work_group_scan_inclusive_add, двух новых наборов функций групп обработки, которые были добавлены в OpenCL 2.0 для упрощения сканирования и упрощения операций над рабочими элементами в составе групп. В этом учебном руководстве эти функции демонстрируются в нашей собственной реализации алгоритма GPU-Quicksort в OpenCL, который, насколько мы знаем, является первой известной реализацией этого алгоритма в OpenCL. В учебном руководстве показан важный подход к проектированию: постановка в очередь ядер NDRange размера 1 для операций обслуживания и планирования, ранее выполнявшихся только на ЦП.

В этом руководстве вы узнаете об использовании инструментов Intel® для OpenCL. Пакет Intel® SDK для приложений OpenCL™ — это платформа разработки приложений OpenCL™ на архитектуре Intel®. Помимо SDK, инструмент Intel® VTune™ Amplifier XE применяется для анализа и оптимизации приложений на платформах Intel как на ЦП, так и на ГП, и этот инструмент поддерживает OpenCL. Дополнительные сведения об инструментах Intel для OpenCL см. по адресу http://intel.com/software/opencl.

В создании, редактировании и публикации этой статьи, в разработке кода и монтаже видео мне помогли Дипти Джоши (Deepti Joshi), Аллен Хакс (Allen Hux), Аарон Кунце (Aaron Kunze), Диллон Шарлет (Dillon Sharlet), Адам Лейк (Adam Lake), Михаль Мроцек (Michal Mrozek), Бен Эшбоу (Ben Ashbaugh), Аял Закс (Ayal Zaks), Юрий Кулаков (Yuri Kulakov), Джозеф Уэллс (Joseph Wells), Линн Пэтнэм (Lynn Putnam), Джерри Боу (Jerry Baugh), Джерри Макэр (Jerry Makare) и Крис Дэйвис (Chris Davis). Спасибо им! Кроме того, сердечно благодарю мою жену Эллен и моих детей Майкла и Селин за их непоколебимую поддержку и понимание.

Краткий курс истории алгоритма быстрой сортировки

Изобретатель алгоритма быстрой сортировки — сэр Чарльз Энтони Ричард («Тони») Хоар (C.A.R. Hoare). Он изобрел этот алгоритм в 1960 году во время обучения в аспирантуре Московского государственного университета, где он изучал теорию вероятности под руководством профессора Андрея Николаевича Колмогорова. Тони Хоар выучил русский язык во время службы в Королевском флоте, где его дядя был командиром корабля. Работая над проблематикой машинного перевода с одного языка на другой, Хоар пытался придумать алгоритм сортировки по возрастанию для слов каждого входящего предложения на русском языке. Основной принцип алгоритма быстрой сортировки заключается в следующем: сортируемая последовательность разделяется вокруг так называемого опорного элемента. Опорный элемент может быть выбран из последовательности различными способами, при этом все элементы меньше опорного размещаются в левой части массива, все элементы больше опорного размещаются справа, а элементы, равные опорному, размещаются в середине массива. После разделения массива алгоритм быстрой сортировки снова применяется к левой и правой частям последовательности.

Рисунок 1. Разделение последовательности в алгоритме быстрой сортировки

Краткое введение в алгоритм GPU-Quicksort

Первый известный алгоритм быстрой сортировки для ЦП разработали и описали Шубхабрата Сенгупта (Shubhabrata Sengupta), Марк Харрис (Mark Harris), Яо Чжань (Yao Zhang) и Джон Оуэнс (John D. Owens) в своей работе «Примитивы сканирования для вычислений на ГП». Представленный здесь алгоритм GPU-Quicksort впервые описали Дэниэл Сидермэн (Daniel Cederman) и Филиппас Цигас (Philippas Tsigas) в работе «GPU-Quicksort: практическая реализация алгоритма быстрой сортировки для графических процессоров»; он представляет собой усовершенствованную версию первого алгоритма быстрой сортировки для ГП. Описываемый алгоритм был изначально написан на CUDA* для запуска на дискретных видеоадаптерах Nvidia*, но его очень легко реализовать и в OpenCL для запуска на любом оборудовании, поддерживающем API OpenCL. Этот алгоритм разработан таким образом, чтобы использовать высокую пропускную способность ГП, он хорошо работает с драйверами OpenCL 1.2 (Intel® HD Graphics 4600) и OpenCL 2.0 (Intel® HD Graphics 4600, Intel® HD Graphics 5300 и более поздние версии). Отличный обзор алгоритма GPU-Quicksort приводится в разделе 3.1 статьи Сидермэна и Цигаса.

Как и первоначальный алгоритм быстрой сортировки, GPU-Quicksort рекурсивно разделяет последовательность элементов вокруг опорного элемента вплоть до сортировки всей последовательности. Поскольку этот алгоритм написан для ГП, он включает два этапа, где на первой этапе несколько групп обработки обрабатывают разные части одной и той же последовательности до тех пор, пока части последовательности не становятся достаточно маленькими, чтобы их можно было полностью отсортировать каждой рабочей группой на втором этапе.

Основной принцип алгоритма GPU-Quicksort состоит в разделении входной последовательности на блоки и назначении их разным рабочим группам. Каждая рабочая группа участвует в разделении входной последовательности по опорным элементам в двухэтапном процессе: сначала каждый элемент группы обработки вычисляет количество элементов, которые меньше и больше опорного элемента в своем блоке. Встроенные функции сложения со сканированием используются для вычисления суммы нарастающим итогом элементов, которые меньше и больше опорного. Дополнительный массив служит для выделения пространства для каждой группы обработки. На втором проходе элементы меньше и больше опорного записываются в выделенное пространство. И наконец, последняя группа обработки заполняет промежуток значением опорного элемента.

Рисунок 2. Разделение последовательности в алгоритме GPU-Quicksort

Алгоритм GPU-Quicksort в OpenCL 1.2

GPU-Quicksort в OpenCL 1.2 — это непосредственная реализация алгоритма, описанного в статье Сидермэна и Цигаса. Три части представляют собой фрагмент ЦП, реализуемый функцией GPUQSort; ядро первого этапа ГП реализовано функцией ядра OpenCL gqsort_kernel OpenCL, а ядро второго этапа ГП — функцией ядра OpenCL lqsort_kernel. Функция GPUQSort последовательно запускает gqsort_kernel до разделения первоначальной последовательности на настолько маленькие блоки, что каждый блок может быть отсортирован одной группой обработки. Затем GPUQSort запускает lqsort_kernel для завершения работы сортировки.

Для реализации GPU-Quicksort требуются барьеры и атомарные функции, доступные в OpenCL 1.2 и поддерживающиеся практически всем современным оборудованием, поддерживающим OpenCL 1.2. В частности, в реализации gqsort_kernel используются функции atomic_add, atomic_sub и atomic_dec. Барьеры широко применяются как в gqsort_kernel, так и в lqsort_kernel.

Использование OpenCL 1.2 связано со следующими недостатками:

1. нехватка примитивов сканирования групп обработки, из-за чего для реализации сумм префиксов требовалось использовать алгоритм, описанный в известной статье Гая Блеллока (Guy Blelloch);
2. частый обмен данными между ЦП и ГП для запуска gqsort и последующего запуска lqsort;
3. необходимость выполнения операций обслуживания перед запуском ядер в ЦП, хотя необходимые данные на этот момент уже готовы и доступны в ГП.

Все эти три недостатка удалось устранить в OpenCL 2.0. Вы увидите, что путем устранения этих недостатков удалось значительно повысить производительность алгоритма.

Преобразование GPU-Quicksort для OpenCL 2.0

В этом разделе описываются изменения, сделанные при переходе от OpenCL 1.2 к OpenCL 2.0, где используются новые возможности постановки в очередь на стороне устройства и сканирования групп обработки.

Функции групп обработки могут повысить производительность и читаемость кода OpenCL C

Самый первый и простейший этап преобразования GPU-Quicksort для OpenCL 2.0 — использование готовых функций сканирования групп обработки: work_group_scan_inclusive_add и work_group_scan_exclusive_add в gqsort_kernel и lqsort_kernel. Мы добились не только заметного прироста производительности (примерно на 8 %), но и повышения четкости и ясности кода, простоты его обслуживания. Размер кода, связанного с вычислением сумм префиксов, удалось снизить почти втрое.

Блоки дают возможность воспользоваться вложенной параллельной обработкой с помощью постановки в очередь на стороне устройства

Затем мы переделали логику, сортирующую записи после каждого запуска gqsort_kernel в записи, пригодные для обработки функцией lqsort_kernel, и в записи, требующие дальнейшего деления, а также вычисляющую блоки и родительские записи и запускающую либо gqsort_kernel, либо lqsort_kernel из C++ в OpenCL C. Функция lqsort_kernel будет запускаться только в самом конце запуска GPU-Quicksort. В нашей первой реализации эта логика находилась в gqsort_kernel, вследствие чего требовались дополнительные глобальные переменные и атомарные функции, а функция gqsort_kernel работала относительно медленно, хотя общая производительность несколько возросла по сравнению с версией для OpenCL 1.2. Мы переместили эту логику в отдельную функцию relauncher_kernel, которая теперь запускается для самого первого ядра и по окончании каждого запуска gqsort_kernel.

       // now let’s recompute and relaunch
       if (get_global_id(0) == 0) {
           uint num_workgroups = get_num_groups(0);
           queue_t q = get_default_queue();
           enqueue_kernel(q, CLK_ENQUEUE_FLAGS_WAIT_KERNEL,
                          ndrange_1D(1),
                          ^{ relauncher_kernel(d, dn,
                             blocks, parents, result, work, done, done_size,
                             MAXSEQ, num_workgroups);
                           });
       }

Обратите внимание, что relauncher_kernel запускается только для одиночных рабочих элементов (ndrange = 1). Изоляция логики relauncher от qsort_kernel позволила значительно упростить qsort_kernel и повысить производительность алгоритма.

Несколько замечаний о постановке relauncher_kernel в очередь: мы используем новую возможность OpenCL 2.0 — блоки. Поскольку ядрам не требуются локальные аргументы памяти, мы используем блоки типа void (^) (void). Блоки аналогичны лямбда-функциям C++, но у них другой синтаксис. Блок получает переданные ему параметры, поэтому упраздняется трудоемкая работа по заданию аргументов ядра с помощью эквивалента clSetKernelArg. Также следует отметить, что num_workgroups вычисляется вне блока, а вычисленное значение передается в блок. Обратите внимание, что в приведенном выше примере кода num_workgroups записывается в значение: это именно то, что нам нужно. Если бы мы использовали непосредственно get_num_groups(0) вместо num_workgroups, то эту функцию следовало бы вызывать после постановки в очередь и выполнения блока, содержащего вызов relauncher_kernel, поэтому значение, переданное в relauncher_kernel, было бы равно 1, а не количеству групп обработки в gqsort_kernel. Дополнительные сведения о синтаксисе блоков в OpenCL C см. в спецификации OpenCL C [3].

Функция relauncher_kernel запускает либо gqsort_kernel, либо lqsort_kernel в зависимости от того, осталась ли доступна работа (work_size != 0) для gqsort_kernel.

       if (work_size != 0) {
           // Calculate block size, parents and blocks
           ...

           enqueue_kernel(q, CLK_ENQUEUE_FLAGS_WAIT_KERNEL,
                          ndrange_1D(GQSORT_LOCAL_WORKGROUP_SIZE * blocks_size,
                                     GQSORT_LOCAL_WORKGROUP_SIZE),
                          ^{ gqsort_kernel(d, dn,
                                           blocks, parents, result, work, done,
                                           done_size, MAXSEQ, 0); });
       } else {
           enqueue_kernel(q, CLK_ENQUEUE_FLAGS_WAIT_KERNEL,
                     ndrange_1D(LQSORT_LOCAL_WORKGROUP_SIZE * done_size,
                                LQSORT_LOCAL_WORKGROUP_SIZE),
                     ^{ lqsort_kernel(d, dn, done); });
       }

После запуска первого relauncher_kernel из ЦП все последующие запуски ядер выполняются из ГП. После полной сортировки входных данных управление возвращается центральному процессору.

Рисунок 3.Последовательность кодирования ядра GPU-Quicksort в OpenCL 2.0

Требования для учебной программы

Для сборки и запуска этой учебной программы нужен ПК, соответствующий следующим требованиям.

• Процессор серии Intel® Core™ с кодовым названием Broadwell.
• Microsoft Windows* 8 или 8.1.
• Intel® SDK для приложений OpenCL™ версии 2014 R2 или более поздней.
• Microsoft Visual Studio* 2012 или более поздней версии.

Запуск учебной программы

Учебная программа представляет собой консольное приложение, формирующее массив случайных целых чисел без знака размером Ширина*Высота. Затем выполняется сортировка копий этого массива с помощью std::sort, обычной однопоточной быстрой сортировки, за которой следует ряд итераций сортировки с помощью GPU-Quicksort в OpenCL 2.0.  Эта учебная программа поддерживает несколько параметров командной строки.

Попробуйте запустить учебную программу с параметрами 5 gpu intel 8192 8192 show_CL.

Заключение

Процессор Intel с ГП Intel® HD Graphics 5300 или более мощным представляет собой сложное оборудование, которое в сочетании с драйвером, поддерживающим OpenCL 2.0, способно, однако, значительно повысить производительность работы кода OpenCL. В OpenCL 2.0 поддерживается ряд удобных и мощных возможностей для программирования ГП. Мы рассмотрели только две таких возможности: функцию enqueue_kernel и функции work_group_scan_exclusive_add и work_group_scan_inclusive_add. Эти функции позволяют добиться резкого повышения производительности, они упрощают код и делают его более удобочитаемым. Прочтите другие учебные материалы Intel о других возможностях OpenCL на веб-сайте поддержки Intel® SDK для приложений OpenCL™. 

Справочные материалы

1. Intel® SDK для приложений OpenCL™ — руководство по оптимизации.
2. Спецификация API Khronos OpenCL 2.0.
3. Спецификация Khronos OpenCL 2.0 для языка C.
4. Статья о быстрой сортировкев Википедии.
5. Начало моей работы в компании «Эллиот», Тони Хоар.
6. Примитивы сканирования для вычислений на ГПШубхабрата Сенгпута, Марк Харрис, Яо Чжань и Джон Оуэнс,«Графическое оборудование», 2007 г., стр. 97–106, август 2007 г.
7. GPU-Quicksort: практическая реализация алгоритма быстрой сортировки для графических процессоровДэниэл Сидермэн и Филиппас Цигас, «Журнал экспериментальных алгоритмов», том 14, 2009 г., статья № 4.
8. Суммы префиксов и их применение, Гай Блеллок
9. Документация в Интернете по функциям enqueue_kernel
10. Документация в Интернете по функциям сканирования групп обработки с включением.
11. Документация в Интернете по функциям сканирования групп обработки с исключением. /li>
12. Intel® SDK для приложений OpenCL™.
13. Intel® SDK 2013 R2 для приложений OpenCL™ — руководство по оптимизации.
14. Полный контрольный список для оптимизированного приложения OpenCL.
15. Написание оптимального кода OpenCL с помощью Intel® OpenCL SDK  - в формате PDF.

Об авторе

Роберт Иоффе (Robert Ioffe) работает в должности технического инженера-консультанта в отделе Software and Solutions Group корпорации Intel. Роберт — опытный специалист по программированию OpenCL и оптимизации нагрузки OpenCL на ГП Intel Iris и Intel Iris Pro, он прекрасно знает графическое оборудование Intel. Роберт принимал активное участие в разработке стандартов Khronos, занимался прототипированием самых последних функций и обеспечением их работоспособности в архитектуре Intel. В последнее время Роберт работал над прототипированием возможностей вложенной параллельной обработки (функции enqueue_kernel) OpenCL 2.0; он написал ряд примеров, демонстрирующих эту функциональность, включая алгоритм GPU-Quicksort для OpenCL 2.0. Кроме того, он записал и выпустил два видеоролика по оптимизации ядер OpenCL; сейчас он работает над третьим видеороликом, посвященным возможностям вложенной параллельной обработки.

Также вас могут заинтересовать следующие материалы.

Ковер Серпинского в OpenCL 2.0

Оптимизация простых ядер OpenCL: оптимизация модульного ядра

Оптимизация простых ядер OpenCL: оптимизация ядра Собеля

Загрузить код

Download PDF

Введение

Пакет Intel® RealSense™ SDKпо своей архитектуре отличается от своего предшественника — пакета Intel® Perceptual Computing SDK. Если вы, будучи разработчиком, использовали Intel Perceptual Computing SDK для разработки приложений, вы быстро оцените улучшенную модель программирования в новом SDK, предоставляющую доступ к поддерживаемым режимам работы через несколько популярных платформ разработки приложений. В этой статье мы описываем основные изменения в Intel RealSense SDK.

Содержание

• Обзор архитектуры
• Упрощенная иерархия классов
• Руководство по переходу на новые API

Обзор архитектуры

Ядро SDK, модуль ввода-вывода и модули алгоритмов образуют основу SDK. Ядро SDK помогает управлять конвейером выполнения приложения и модулями ввода-вывода (камеры). Модули алгоритмов образуют промежуточный уровень для отслеживания рук, распознавания жестов, отслеживания лица, распознавания речи и других режимов работы. Эти алгоритмы предоставляют интерфейсы для разработки приложений с помощью платформ разработки — C++, C#, Unity*, Java*, Processing* и т. д. На верхней ступени этого набора технологий находятся приложения Intel RealSense SDK (рис. 1).

Рисунок 1.Архитектура Intel® RealSense™ SDK

Это улучшение будет весьма очевидным для разработчиков приложений, знакомых с Intel Perceptual Computing SDK. Прежние версии интерфейсов SDK можно было использовать только на платформах Unity и Java (рис. 2).

Рисунок 2.Архитектура Intel® Perceptual Computing SDK

Большая часть функций SDK была доступна только для разработчиков на C++/C#, из-за чего Unity и другие платформы разработки приложений оказывались в неблагоприятных условиях. В Intel RealSense SDK это ограничение устраняется за счет однородного доступа к возможностям ядра и промежуточного уровня посредством интерфейсов, разработанных для каждой платформы. На рис. 3 видно, что поддержка DLL-библиотек для всех платформ была полностью переделана. Интерфейс C++/C# теперь доступен через интерфейс PInvoke вместо оболочки C++/CLI C# в Intel Perceptual Computing SDK. Если говорить о Unity, интерфейс на базе PXCUPipeline в прежнем SDK заменен на интерфейс C# на базе PInvoke. Для платформ Java и Processing интерфейс на базе PXCUPipeline заменен полностью переработанной оболочкой JNI.

Рисунок 3. Однородный доступ к API во всех платформах разработки приложений

Упрощенная иерархия классов

Рисунок 4.Иерархияклассов Intel® RealSense™ SDK

Структура интерфейсов в Intel Perceptual Computing SDK отличалась высоким уровнем иерархичности. Для выполнения простых задач требовалась длительная последовательность операций инициализации, настройки и получения данных. В Intel RealSense SDK эта иерархическая структура упрощена, обеспечивается более удобный доступ к разным функциям и режимам работы.

Как показано выше на рис. 4, PXC[M]SenseManager заменяет класс UtilPipeline ядра SDK. SenseManager отвечает за организацию и управление конвейером выполнения. PXC[M]CaptureManager осуществляет управление всеми устройствами камер и потоков вместо интерфейса UtilCapture в Perceptual Computing SDK. Обратите внимание, что интерфейс PXC[M]Capture также обеспечивает более удобный доступ к данным о глубине. В Intel Perceptual Computing SDK для получения данных глубины и вершин требовалось получать доступ к двум разным потокам. В Intel RealSense SDK эти данные доступны в одном потоке. Интерфейс PXC[M]Face3D управляет модулем отслеживания лица вместо интерфейса PXC[M]Face, а PXC[M]HandAnalysis занимается отслеживанием жестов и рук вместо интерфейса PXC[M]Gesture.

Более подробные сведения об этих модуля см. в следующем разделе — руководстве по переходу на новые API.

Руководство по переходу на новые API

Переработан не только весь набор SDK, но и свыше 50 % API из Intel Perceptual Computing SDK переделаны в Intel RealSense SDK. Большинство изменений обусловлены появлением поддержки трехмерных сцен в Intel RealSense SDK: за счет этого улучшены некоторые существующие режимы, такие как отслеживание лица и рук. Рассмотрим некоторых из этих усовершенствований.

Модуль отслеживания лица

С точки зрения возможностей в модуле отслеживания лица теперь поддерживается 78 реперных точек с различными значениями определения выражения лица в двухмерном и трехмерном режимах. Для сравнения: в Intel Perceptual Computing SDK поддерживалось не более 7 реперных точек. Благодаря введению параметра глубины повышается достоверность полученных данных. Кроме того, в Intel Perceptual Computing SDK требовалось по отдельности настраивать обнаружение лица, обнаружение реперов и распознавание лица, из‑за чего весь процесс анализа лиц был крайне громоздким. Модуль анализа лица и связанные с ним API были переработаны с учетом этих аспектов. Вместо модуля PXC[M]FaceAnalysis используется модуль PXC[M]Face3D с одноуровневой структурой. Этот модуль достаточно настроить всего один раз перед получением значений обнаружения лица, реперных точек, выражения лица и значений распознавания лица (рис. 5).

Рисунок 5.Сравнениемодуляанализалицав Intel® Perceptual Computing SDK ив Intel® RealSense™ SDK

Модуль отслеживания рук

Модуль отслеживания рук был значительно доработан в Intel RealSense SDK. По сравнению с данными для 7 реперных точек руки и 10 стандартными жестами в Intel RealSense SDK теперь поддерживаются данные для 22 точек, идентификация пальцев, идентификация правой и левой руки с параметрами ориентации и поворота для трехмерного взаимодействия, а также набор стандартных жестов. Интерфейс PXC[M]Gesture, применявшийся в Intel Perceptual Computing SDK, заменен интерфейсом PXC[M]HandAnalysis для более удобного доступа к данным о руках.

В таблице 1 (см. ниже) приведена сводка основных улучшений в Intel RealSense SDK. Рекомендуем разработчикам прочесть справочное руководство по SDK, входящее в состав бета-версии, для получения более подробной информации о каждом API в этих интерфейсах.

Таблица 1.Сравнение Intel® Perceptual Computing SDK и Intel® RealSense™ SDK 

Заключение

Пакет Intel RealSense SDK обладает целым рядом преимуществ над предыдущим поколением Intel Perceptual Computing SDK. Улучшены многие существующие режимы работы, такие как алгоритмы отслеживания лица и рук; усовершенствован механизм доступа к API для большинства поддерживаемых платформ разработки приложений. Благодаря однородности доступа к API и улучшениям на промежуточном уровне получилась очень удобная платформа, с помощью которой разработчики приложений могут осваивать новые возможности взаимодействия с пользователями.

Дополнительные материалы

Технология Intel® RealSense™ — обзор: https://software.intel.com/ru-ru/articles/realsense-overview
Руководства по проектированию взаимодействия с пользователем: https://software.intel.com/ru-ru/articles/realsense-ux-design-guidelines

Об авторе

Мегана Рао (Meghana Rao) работает техническим маркетинговым инженером в подразделении Intel Software and Services. Она помогает разработчикам понимать возможности платформ Intel и писать приложения, удобные для пользователей.

Intel, эмблема Intel, Ultrabook и RealSense являются товарными знаками корпорации Intel в США и в других странах.
© Intel Corporation, 2015. Все права защищены.
* Прочие наименования и товарные знаки могут быть собственностью третьих лиц.

В ответах на распространенные вопросы вы найдете информацию об аппаратных требованиях Intel® RealSense™ SDK и новых возможностях, представленных в версиях Gold R1 и R2.

Требования

Каковы аппаратные требования для использования Intel® RealSense™ SDK?

• Процессор Intel® Core™ 4-го поколения (Haswell) или более новый.
• 8 ГБ свободного пространства на жестком диске.
• Камера Intel RealSense 3D.

Каковы требования в отношении программного обеспечения?

• Microsoft Windows* 8.1
• Microsoft Visual Studio* C++ 2010–2013 с пакетом обновления SP1 или более новым.
• Microsoft .NET 4.0 или более поздней версии для разработки на C#.
• Unity* PRO 4.1.0 или более поздней версии для разработки игр Unity.
• Processing* 2.1.2 или более поздней версии для разработки приложений Processing.
• openFrameworks* v0071 или более поздней версии для разработки приложений openFrameworks.t
• Havok Vision* SDK 2012.2.1 или более поздней версии для разработки приложений Havok Vision SDK.
• Java* JDK 1.7.0_11 или более поздней версии для разработки приложений Java.
• Любой из следующих браузеров для разработки на JavaScript*:
  • Microsoft Internet Explorer 10.0.13
  • Google Chrome* 33.0.1750.146
  • Mozilla Firefox* 27.0.1

Можно ли использовать Intel RealSense SDK с другими камерами?

Нет, этот комплект работает только с фронтальной камерой Intel RealSense.

Существует ли версия этого комплекта для ОС Linux*?

Нет.

Производительность

Какова загрузка ЦП при использовании RealSense SDK по сравнению с Intel® Perceptual Computing SDK?

30 % для одного модуля и менее 50 % для объединенных модулей. Это приблизительная оценка. Производительность может меняться в зависимости от различных факторов.

Unity

Какие версии Unity поддерживаются?

Unity v4.1 Professional и выше.

Что такое Unity Toolkit?

Unity Toolkit — это разработанный компанией Intel программный пакет для разработчиков игр Unity, обеспечивающий взаимодействие с Unity Inspector с помощью операций перетаскивания. Его возможности позволяют обойтись без написания большого количества шаблонов, которые необходимы при использовании Intel Perceptual Computing SDK.

Существуют ли особые требования для использования Unity Web Player?

Никаких специальных разрешений не требуется.

Есть ли в RealSense SDK какие-либо ограничения в отношении Unity, как это было в Intel Perceptual Computing SDK?

Нет. Все имеющиеся в этом пакете возможности доступны для разработчиков игр и приложений Unity.

Распознавание лиц

Сколько лиц распознается одновременно?

Четыре.

Сколько лиц могут одновременно иметь реперные точки?

Одно.

Какие движения головы отслеживаются?

Поворот вокруг поперечной, вертикальной и продольной осей.

Сколько реперных точек используется?

78

На какие части лица распространяется отслеживание реперных точек?

На глаза, брови, нос, рот и подбородок.

Поддерживает ли Intel RealSense SDK определение выражения лица? Если да, то какие мимические черты распознаются?

Да. Intel RealSense SDK поддерживает распознавание следующих мимических черт:

• улыбка;
• поднятые брови;
• нахмуренные брови;
• открытый рот;
• закрытые глаза;
• движение зрачков.

Поддерживает ли Intel RealSense SDK определение эмоций? Если да, то какие эмоции распознаются?

Да, распознавание эмоций поддерживается, но пока на экспериментальном уровне. Определяются следующие эмоции.

Эмоция	R1	R2
Гнев
Отвращение
Страх
Радость
Печаль
Удивление
Презрение
Позитивное настроение
Негативное настроение
Нейтральное выражение лица

Жесты

Какие жесты поддерживаются в бета-версии SDK?

В настоящее время SDK поддерживает следующие жесты.

Жест	R1	R2
Разведенные пальцы
Знак в виде буквы V
Постукивание пальцами
Взмах руки
Сведение и разведение двух пальцев
Сжатый кулак
Большой палец вверх
Большой палец вниз
Щелчок двумя пальцами
Смахивание пальцем вверх
Смахивание пальцем вниз
Смахивание пальцем влево
Смахивание пальцем вправо

Будет ли распознаваться такой жест, как перо в руке?

Нет, такой жест не поддерживается.

Когда планируется выпустить инструмент для работы с настраиваемыми жестами?

Выпуск запланирован на 2015 год. Конкретные сроки еще не определены.

Речь

Какие режимы речи поддерживает Intel RealSense SDK?

Режим команд и режим диктовки.

Вопросы на другие темы

Насколько я понимаю, нет обратной совместимости между Intel RealSense SDK и Intel Perceptual Computing SDK. Означает ли это, что придется переписывать код приложений для их использования с новой камерой и SDK выпуска 2014 года?

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

Могут ли различные приложения получать данные от одной камеры? Если да, то как промежуточное ПО обрабатывает разные параметры разрешения, используемые различными приложениями?

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

Если в приложении А меняется один параметр, получит ли приложение Б уведомление о таком изменении?

Приложение Б может непосредственно отслеживать изменение параметров устройства.

Можно ли запрашивать устройство о состоянии электропитания? (Включена камера или выключена?)

Да.

Может ли подчиненная система запрашивать параметры, установленные основной системой?

Да.

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

Драйверы и микропрограммное обеспечение для камеры доступны у производителей оборудования. Для специальных камер необходимо использовать микропрограммное обеспечение и драйверы, доступные на сайте Creative Labs Intel RealSense.

Набор Unity* Toolkit для технологии Intel® RealSense™ входит в стандартную установку Unity. Этот набор содержит все библиотеки и сценарии, необходимые для запуска технологии Intel RealSense в Unity. Набор упрощает работу, поскольку свойства сценариев становятся доступны в Inspector.

Назначение

Это учебное руководство поможет вам создать и запустить простое учебное приложение Intel RealSense с помощью Unity Toolkit. Таким образом, мы не будем подробно рассматривать все доступные настройки заданного сценария вращения.

Что входит в состав этого руководства

В этом учебном руководстве рассматриваются действия, необходимые для вращения куба в зависимости от движений руки.

Условия

Прочтите файл sdktoolkit.pdf, чтобы получить общее представление о том, как работает эта надстройка Unity. Если пакет Intel RealSense SDK установлен в папку по умолчанию, этот файл находится в папке Program Files (x86)\Intel\RSSDK\doc\PDF. Также предполагается, что вы обладаете базовыми навыками работы с Unity, например, умеете импортировать внешний пакет, сможете добавить куб в сцену и применить сценарий к игровому объекту.

Требования

Unity Professional 4.1 или более поздней версии.

Встроенная в устройство камера Intel® RealSense™ 3D или внешняя камера.

Итак, начнем

Импорт плагин VisualStudio* (необязательно)

Этот шаг не обязателен, но я использую плагин, поскольку мне Visual Studio нравится больше, чем среда разработки MonoDevelop*. Чтобы использовать этот бесплатный плагин, загрузите его здесь: http://unityvs.com/.

Если этот пункт отсутствует, необходимо вручную импортировать плагин, перейдя в его папку на жестком диске.

Импорт сцены Unity* EnemyShip

Я решил, что это демо ничуть не проиграет, если вместо обычного куба использовать модель фантастического космического корабля. Этот игровой объект содержится в бесплатном пакете Space Shooter, который можно получить в магазине Unity. Весь пакет мне не нужен, поэтому я импортировал пакет Space Shooter в отдельный проект Unity, а затем экспортировал только космический корабль. Но это всего лишь мои личные предпочтения. Для этого учебного руководства можно использовать и простой объект куба.

Импорт UnityToolkit

Пакет, включающий Unity Toolkit для Intel RealSense, содержит все необходимые компоненты для манипулирования игровыми объектами. Пакет Unity находится в папке \RSSDK\Framework\Unity. Если пакет Intel® RealSense™ SDK установлен в папку по умолчанию, папка RSSDK будет находиться в папке C:\Program Files (x86).

Импортировать Unity Toolkit можно таким же образом, как и любой другой пакет. При этом можно выбрать нужные компоненты и параметры. В данном случае мы используем параметры по умолчанию и импортируем все.

Как видно на следующем рисунке, внутри папки Assets появилось несколько новых папок.

• Папки Plugins и Plugins.Managed содержат DLL-библиотеки, необходимые для Intel RealSense SDK.
• Папка RSUnityToolkit содержит все сценарии и ресурсы для запуска этого пакета.

Впрочем, нет смысла описывать все папки. Изучить их содержимое вы сможете самостоятельно.

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

Добавьте направленный источник света, чтобы подсветить корабль, так его будет лучше видно.

Добавление масштаба к игровому объекту

Чтобы добавить возможности масштабирования к игровому объекту, нужно добавить сценарий ScaleAction. Сценарий ScaleActionScript находится внутри папки RSUnityToolkit во вложенной папке Actions. Просто возьмите сценарий мышью и перетащите его на корабль в представлении сцены.

Теперь можно просмотреть параметры сценария ScaleAction в Unity Inspector.

Здесь я свернул все параметры, чтобы показать три основные области сценария: событие Start, переключатель Scale и событие Stop.

Теперь приступим к настройке параметров

• Начиная с события Start, разверните стрелку, чтобы отобразить триггер по умолчанию. В этом случае я не хочу использовать Gesture Detected, а хочу использовать Hand Detected. Щелкните правой кнопкой мыши Gesture Detected и выберите Remove.
• Нажмите кнопку Add события Start и выберите Hand Detected.
• В Which Hand выберите ACCESS_ORDER_RIGHT_HANDS.

Теперь параметры должны выглядеть так.

Теперь нужно задать событие остановки.

• Разверните событие Stop и удалите Gesture Lost.
• Нажмите кнопку «Добавить» события Stop и выберите Hand Lost.
• Рядом с Which Hand выберите ACCESS_ORDER_RIGHT_HANDS.

Теперь параметры должны выглядеть так.

Изменять Scale Trigger не потребуется, поскольку это единственный возможный вариант. Поэтому воспользуемся доступным по умолчанию.

Вот как должен выглядеть весь набор параметров на этом этапе.

Поздравляем! Все готово.

Сохраните сцену.

Сохраните проект

и запустите игру!