UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BIBLIOTECA DE FUNÇÕES PARA UTILIZAÇÃO DO KINECT EM APLICAÇÕES NUI E JOGOS ELETRÔNICOS por Gabriel Schade Cardoso Itajaí (SC), junho de 2012

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BIBLIOTECA DE FUNÇÕES PARA UTILIZAÇÃO DO KINECT EM APLICAÇÕES NUI E JOGOS ELETRÔNICOS Interação Humano Computador, Computação Gráfica e Jogos eletrônicos por Gabriel Schade Cardoso Relatório apresentado à Banca Examinadora do Trabalho Técnico-científico de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Dra. Ana Elisa Ferreira Schmidt ITAJAÍ (SC), JUNHO DE 2012

3 Dedico este projeto inteiramente à minha família e meus amigos, pois sem eles eu não teria forças para realiza-lo.

4 AGRADECIMENTOS Agradeço primeiramente a minha família, namorada e amigos por todo o suporte dado durante este período. Agradeço à minha mãe Eulália por dar todo o suporte emocional que eu precisei e por ter compreendido os momentos de mau humor e estresse dos dias difíceis. Agradeço também ao meu pai João pelo suporte financeiro sempre que precisei. Graças a estas duas pessoas me tornei hoje a pessoa que sou e sempre vou amá-los por isso. Agradeço também à minha namorada Priscila e ao meu grande amigo Rafael que são duas grandes pessoas que me ajudaram a passar noites e mais noites em claro estudando e pesquisando, que acreditaram em mim e que me deram as forças necessárias para que eu sempre pudesse me levantar e seguir em frente até nos momentos mais difíceis. Agradeço também a minha irmã Juliana, que cedeu seu notebook para que eu pudesse terminar o trabalho no momento em que mais precisei. Agradeço ainda, a meus amigos de meu antigo trabalho Bona, Victorino e Fran que sempre me apoiaram e me deram forças para seguir em frente, acreditando em meu potencial. É claro que não posso deixar de agradecer a todos os professores que, de uma forma ou de outra, agregaram conhecimento e lições valiosas que me tornarem o profissional que sou hoje e que ajudaram a moldar um pouco de minha personalidade, certamente coisas que terei para o resto da vida. Entre os professores fica um agradecimento especial para o professor Bughi, que fez com que eu me apaixonasse por desenvolvimento e avaliou este projeto com rigidez, tornando o resultado final melhor, ao professor Adhemar que também avaliou este projeto e o fez um projeto melhor, ao professor Rudimar, por ter apresentado o artigo desenvolvido a partir deste projeto no SBGames 2012 e claro, para a professora Ana Elisa, que além de ter se tornando uma grande amiga neste ano, que acreditou em mim e em meu potencial, teve papel fundamental neste trabalho, me ajudando muito a crescer e a me tornar uma pessoa e um profissional melhor. A todas estas pessoas fica o meu sincero obrigado.

5 Saudações aos loucos. Aos desajustados. Aos rebeldes. Aos criadores de caso. As peças redondas nos buracos quadrados. Os que veem as coisas de forma diferente. Eles não gostam de regras. E eles não têm nenhum respeito pelo status quo. Você pode citá-los, discordá-los, glorificá-los ou difamá-los. Mas a única coisa que você não pode fazer é ignorá-los. Porque eles mudam as coisas. Eles empurram a raça humana para frente. Enquanto alguns os veem como loucos, nós vemos como gênios. Porque as pessoas que são loucas o suficiente para achar que podem mudar o mundo, são as que de fato, mudam... (Rob Siltanen e Ken Segall)

6 RESUMO SCHADE, Gabriel. Biblioteca de Funções para utilização do Kinect em Aplicações GUI e Jogos Eletrônicos. Itajaí, Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, Formas inovadoras de interação têm sido propostas por interfaces focadas ao paradigma de interface natural ao longo dos anos. Os usuários não necessitam ter grande conhecimento em computação para interagir com softwares em diversas áreas. A primeira interface de usuário a aparecer foi a CLI (Command Line Interface) que utiliza comandos de entrada textuais específicas para desempenhar funções em um aplicativo, em seguida, surgiu a GUI (Graphical User Interface) que utilizam janelas gráficas e são as mais utilizadas em sistemas operacionais e aplicações até hoje; e finalmente a NUI (Natural User Interface) que visa utilizar uma linguagem natural para a interação humana com o aplicativo, como gestos, poses e comandos de voz. Algumas empresas como Microsoft e Nintendo desenvolveram hardwares que possuem o propósito de tornar estas interfaces naturais presentes em algumas aplicações, principalmente na área de jogos. O presente projeto apresenta uma biblioteca de funções que foi desenvolvida para facilitar aos desenvolvedores migrar da interface padrão de suas aplicações para a interface cinética do hardware Microsoft Kinect. Isto pode ser feito através de poses, comandos de voz e gestos, sem que seja necessário um conhecimento aprofundado no Kinect e em sua SDK. Também foi criada uma integração com a engine de jogos Unity já que esta engine não possui integração nativa com o Kinect. Para testar e validar o funcionamento da biblioteca criada foi alterada a interface de um projeto de um jogo já desenvolvido pela ferramenta Unity para a interface do Kinect. Palavras-chave: Kinect. Unity. NUI. Software Development Toolkit. Integração

7 ABSTRACT Innovative ways of interaction have been proposed by user interfaces oriented towards natural interface paradigm over the past few years. Users don t need to be computer savvy anymore in order to be able to interact with software in many areas. Drawing an evolution timeline, the first type of UI to appear was the CLI (Command Line Interfaces) which use textual input specific commands to perform functions in an application; then GUI (Graphical User Interfaces) which use graphical windows and are used in most operating systems and applications up to today; and finally the NUI (Natural User Interfaces) that aims to use natural language for human interaction with the application, such as gestures, poses, or voice commands. Some companies like Microsoft and Nintendo have developed hardware for the purpose of making these natural interfaces present in many applications, especially in the games area. This project created a development library to easy up the migration of standard interface s applications to a NUI interface using the Microsoft Kinect resources. This library created a integration between Kinect resources and the game engine Unity, as this engine does not have native integration with Kinect. To test and validate the operation of the library created, was changed the interface of a game ever developed by Unity to the Kinect interface. Keywords: Kinect. Unity. NUI. Software Development Toolkit. Integration

8 LISTA DE FIGURAS Figura 1. Captura de tela de uma interface CLI no Windows Figura 2. Screenshot do sistema operacional Windows Figura 3. Gestos em uma tela de toque Figura 4. Xbox dashboard Figura 5. Jogos eletrônicos utilizando NUI Figura 6. Sensor 3D PrimeSense Figura 7. Sensor Kinect Figura 8. Principais funcionalidades do SDK Figura 9. Exemplo de utilização de Mocap Figura 10. Articulações disponibilizadas pela SDK do Kinect Figura 11. Ângulo entre articulações Figura 12. Vetores e articulações no espaço R Figura 13. Vetores com as distâncias no espaço R Figura 14. Cálculo do ângulo entre os vetores V e W Figura 15. Exemplo da utilização da lei dos cossenos Figura 16. Exemplo de utilização da projeção ortográfica paralela Figura 17. Visão principal da ferramenta Unity Figura 18. Inputs da engine Unity Figura 19. Comunicação entre a ferramenta de captura de entradas e o Kinect Figura 20. Organização dos componentes na tela Figura 21. Formulário Home Figura 22. Formulário Record New Pose Figura 23. Formulário Compose Subposes Figura 24. Esqueleto de feedback para testar a pose Figura 25. Pose reconhecida X Pose não reconhecida Figura 26. Formulário Test Pose Figura 27. Formulário Compose Voice Command Group Figura 28. Formulário Test Voice Command Group Figura 29. Estrutura do arquivo XML de um grupo de comandos de voz Figura 30. Estrutura do arquivo XML de pose Figura 31. Fluxograma de funcionamento da KinectServer Figura 32. Interface da KinectServer Figura 33. Comunicação entre a KinectUnity de entradas e o Kinect Figura 34. Poses aceitas no jogo Figura 35. Jogo em execução Figura 36. Gráfico de comparação entre os algoritmos para cálculo de ângulos Figura 37. Criando uma conexão com o sensor via KinectScan Figura 38. Criando uma conexão com o sensor via KinectServerClient Figura 39. Criando uma conexão com o sensor via KinectUnity através de scripts na Unity. 84 Figura 40. Comunicação das threads da aplicação cliente e da KinectScan Figura 41. Arquivo XML de um grupo de comandos de voz Figura 42. Arquivo XML de uma pose Figura 43. Casos de uso para ferramenta de criação de poses Figura 44. Diagrama de Classe resumido da DLL KinectScan Figura 45. Documentação do projeto

9 LISTA DE QUADROS Quadro 1. Comparativo entre CLI e GUI Quadro 2. Configurações do sensor PrimeSense Quadro 3. Exemplo de código fonte utilizando a classe Input Quadro 4. Legenda para diagramas de classe Quadro 5. Atributos da tag Voice Commands Quadro 6. Atributos da tag Commands Quadro 7. Atributos da tag Pose Quadro 8. Atributos da tag Joint Quadro 9. Atributos da tag SubPose Quadro 10. Atributos da tag Angle Quadro 11. Atributos da tag Law_Of_Cosines_Result Quadro 12. Principais métodos da KinectScanner Quadro 13. Objetos para efetuar a requisição Quadro 14. Detecção de uma pose com 1 subpose Quadro 15. Detecção de uma pose com 10 subpose Quadro 16. Detecção de uma pose com 20 subpose... 81

10 LISTA DE EQUAÇÕES Equação Equação Equação Equação

11 LISTA DE ABREVIATURAS E SIGLAS CLI DLL GUI IHC IR NUI RF RGB RGBD RNF RN SDK Command Line Interface Dynamic-Link Library Graphical User Interface Interação humano-computador Infra-Red Natural User Interface Requisito Funcional Red, Green, Blue Red, Green, Blue, Depth Requisito Não Funcional Regra de Negócio Software Development Kit

12 15 SUMÁRIO 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA INTERFACES COM O USUÁRIO Interfaces CLI e GUI Interfaces NUI JOGOS ELETRÔNICOS O que são jogos eletrônicos? Motores de jogos eletrônicos Jogos eletrônicos utilizando NUI MICROSOFT KINECT Detalhando o Microsoft Kinect Microsoft Kinect SDK Esqueleto Mapeamento de movimentos Reconhecimento de Fala UNITY O que é a Unity? Scripts Desenvolvimento TECNOLOGIAS UTILIZADAS NA CRIAÇÃO DA BIBLIOTECA FERRAMENTA PARA REGISTRAR ENTRADAS KINECTSCAN KINECTSERVER KINECTEVENTS KINECTUNITY PROJETO FEITO NA UNITY MODIFICADO RESTRIÇÕES CONCLUSÕES OBJETIVOS RESULTADOS Algoritmos para cálculo do ângulo Complexidade de utilização da biblioteca proposta... 82

13 TRABALHOS FUTUROS CONSIDERAÇÕES FINAIS APÊNDICE A. FUNCIONAMENTO ENTRE AS THREADS DA KINECTSCAN E SEU LISTENER APÊNDICE B. EXEMPLO DE ARQUIVOS XML DE ENTRADAS 94 APÊNDICE C. PROJETO DA FERRAMENTA PARA REGISTRAR ENTRADAS APÊNDICE D. PROJETO DA DLL KINECTSCAN D.1. REQUISITOS D.2. Diagrama de classe APÊNDICE E. PROJETO DA KINECTSERVER E.1. Requisitos APÊNDICE F. PROJETO DA DLL KINECTUNITY F.1. Requisitos APÊNDICE G. DOCUMENTAÇÃO DO PROJETO...106

14 17 1 INTRODUÇÃO O desenvolvimento de jogos digitais no Brasil é um mercado que vem crescendo a cada ano incentivando a oferta de vários cursos de graduação e pós-graduação voltados para esta área (SANTOS, 2012). A etapa de desenvolvimento dos jogos tornou-se menos complexa, comparada a realidade de alguns anos atrás, devido às diversas ferramentas de codificação, frameworks e bibliotecas que auxiliam os desenvolvedores e designers durante o projeto, desenvolvimento, teste e publicação dos games. A ferramenta Unity (UNITY, 2012) é um exemplo de ferramenta que veio facilitar e agilizar o projeto de desenvolvimento de jogos digitais. A Unity ou Unity 3D como também é conhecida, é uma engine para jogos (TECMUNDO, 2011) em 3D criado pela empresa Unity Tecnologies (UNITY, 2012). Este software possui duas versões principais, sendo elas: a versão paga, Unity Pro, que pode ser comprada e a versão gratuita conhecida apenas por Unity (UNITY, 2012). Um elemento importante na criação de um jogo é a definição da forma de interação com o usuário, este elemento vem se modificando muito nos últimos anos indo além dos controles dos consoles. A Interface com o usuário é parte fundamental de todo o software, a forma de comunicar-se com uma aplicação pode alterar o resultado da experiência de um usuário tanto positivamente, quanto negativamente (OLIVEIRA NETTO, 2004), especialmente para os jogos eletrônicos. Para dar flexibilidade, naturalidade e fácil aprendizado às interfaces com o usuário a empresa Microsoft desenvolveu o hardware Microsoft Kinect(KINECT, 2011) onde uma forma de interface totalmente inovadora capta movimentos do usuário, criando assim, uma possibilidade de interação com softwares e jogos apenas com linguagem natural do corpo. O Microsoft Kinect inicialmente era chamado de Projeto Natal, fazendo referência a cidade brasileira Natal, isso ocorreu devido ao fato de um dos pesquisadores da equipe da Microsoft, Alex Kipman ser brasileiro. O Kinect foi lançado no Brasil no dia 18 de novembro de 2010 e vem atraindo novos usuários para esta nova forma de interface que revolucionou a maneira de interagir com aplicações e jogos (INFOWESTER, 2012). Em fevereiro de 2011 a Microsoft anunciou um kit de desenvolvimento (SDK) do Kinect para a plataforma Windows (MICROSOFT, 2012) que pode ser obtido de forma gratuita. Com este kit a Microsoft permite que desenvolvedores possam criar aplicativos nas linguagens C++, C# e Visual Basic utilizando os recursos de hardware do Kinect. Com as

15 18 funcionalidades fornecidas no SDK do Kinect é possível utilizar todos os recursos do sensor, tais como: câmera RGB, câmera de profundidade (infravermelho) e microfones. Além do SDK oficial existem algumas implementações não Microsoft, destacando-se, o chamado OpenNI (OPENNI,2012) que possibilita desenvolver programas com a interface do Kinect em linguagens como C PROBLEMATIZAÇÃO Formulação do Problema O hardware Microsoft Kinect oferece uma interface mais natural com o usuário e suas aplicações, mas desenvolver uma aplicação nova com esta interface ou migrar a interface de aplicações já existentes pode se tornar um trabalho custoso e complexo. Uma integração entre uma aplicação e os sensores de movimentos e sons do Microsoft Kinect pode gerar resultados muito positivos para a experiência do usuário, já que o hardware visa oferecer interfaces naturais. Esta integração deve levar em conta o caráter genérico das aplicações, oferecendo assim um framework de integração. Mantendo as características customizáveis em relação à associação dos movimentos de entrada do usuário através do Kinect com os comportamentos da aplicação em relação a cada entrada Solução Proposta Como uma proposta de integração, foi desenvolvida uma biblioteca de funções que permite que diversas aplicações utilizem as funções do sensor de movimento. A biblioteca de funções visa facilitar o trabalho do desenvolvedor/programador possibilitando que, com o mínimo de alterações, sua aplicação possa migrar da interface padrão para a interface natural do Kinect. A biblioteca que foi criada mapeia os movimentos do usuário obtidos através do Kinect em tempo real durante a execução da aplicação e compara com arquivos de entrada (poses e comandos de voz) previamente gravados na pasta do projeto. Estes arquivos previamente gravados são utilizados para identificar tipos de entrada válidos, ou seja, entradas que alteram o comportamento da aplicação.

16 19 Para criar os arquivos de entradas pré-definidas foi desenvolvida uma ferramenta de captura de entradas, onde o usuário pode criar suas entradas personalizadas. A biblioteca foi modelada e implementada de forma com que a comunicação do Kinect fique encapsulada em uma DLL. Desta forma, a DLL que se comunicará com o Kinect apenas despacha o reconhecimento de alguma entrada, seja ela através de uma pose ou de um comando de voz, sem necessidade de conhecer a aplicação final, o que torna a biblioteca extensível para diversos tipos de aplicação, bastará criar um listener que interprete os eventos despachados. Além dos arquivos dos eventos de reconhecimento de alguma entrada customizada, a biblioteca também disponibiliza alguns eventos prontos, sendo eles: reconhecimento de gestos pré-definidos, imagem da câmera RGB, esqueleto do usuário, alteração do estado do sensor e alteração no estado de um evento. A biblioteca também conta com uma aplicação que se conecta com o Kinect através da DLL desenvolvida neste projeto para encapsular as funções do Kinect. Esta aplicação tem como funcionalidade fornecer os serviços do Kinect via sockets, propondo assim, uma segunda forma de comunicação entre o Kinect e a aplicação final. Para estudo de caso foi utilizado um projeto desenvolvido na ferramenta Unity, pois apesar do amplo conjunto de funcionalidades já existentes, esta engine ainda não possui uma forma de interação nativa com o periférico Microsoft Kinect.

17 OBJETIVOS Objetivo Geral Desenvolver uma biblioteca de funções - SDK -, juntamente com uma proposta de framework que ofereça um subconjunto de funcionalidades do Kinect para integração das funções de entrada através de poses e comandos de voz para outras aplicações, utilizando como estudo de caso a integração com a ferramenta Unity Objetivos Específicos Pesquisar e estudar a respeito do desenvolvimento de aplicações utilizando os kits de desenvolvimentos existentes para o Microsoft Kinect, especialmente o SDK oficial fornecido pela Microsoft; Estudar a ferramenta Unity para desenvolvimento de jogos; Estudar formas para se desenvolver uma biblioteca de funções que integrem a captura de movimentos a partir do Kinect com a ferramenta Unity; Estudar métodos computacionais para detecção e comparação de poses definidas a partir das informações capturadas pelo Kinect; Implementar a biblioteca de integração do Kinect com outras aplicações de acordo com os estudos e análises anteriores; Utilizar a biblioteca criada para adaptar um projeto de jogo digital já elaborado anteriormente com a Unity para integrar sua interface com o Kinect; Efetuar testes de funcionalidade visando à validação das ferramentas implementadas de acordo com os requisitos especificados;

18 Metodologia Foram necessárias cinco etapas para o êxito deste projeto, afim de cumprir os objetivos específicos descritos. Sendo estas etapas: estudos e análises, modelagem, implementação, testes e documentação. Na etapa de estudos e análises, foi definido exatamente o tema/problema deste projeto e adquirido o conhecimento necessário sobre as soluções e tecnologias existentes com o objetivo de propor a melhor solução para a problemática proposta. Foram analisadas ferramentas para desenvolvimento com o Kinect; feito um estudo sobre diferentes técnicas para detecção de movimentos; e também foi estudado sobre a engine para desenvolvimento de jogos - Unity. Em função do conhecimento adquirido durante a fase de estudos e análises, algumas modificações no projeto proposto foram realizadas: Não será implementado a detecção de gestos customizados, apenas a detecção de poses e de comandos de voz (vide seção 3.3); O escopo de utilização do SDK desenvolvido foi ampliado, não sendo mais exclusivamente direcionado para a engine Unity como havia sido proposto; a estrutura do SDK permitirá a integração de qualquer outra aplicação que possua entradas compatíveis com os recursos oferecidos pelo Microsoft Kinect. Para uma integração com a engine Unity foi desenvolvido uma aplicação que fornece as funcionalidades da biblioteca através de sockets. Na etapa de modelagem foram definidas as especificações para o funcionamento da solução proposta, sendo estes especificados de forma descritiva, através de figuras e diagramas. Na etapa de implementação foram codificadas todas as ferramentas e DLLs propostas neste projeto, sendo especificados os padrões e o funcionamento da biblioteca de forma descritiva e através de figuras (vide seção 3 ).

19 22 Na etapa de testes foram testadas as funcionalidades propostas pelo projeto e analisado os resultados, visando ter um melhor resultado final. Estes testes e resultados são especificados através de figuras e de forma descritiva na seção 4. A etapa documentação visou registrar todo o processo pertinente à pesquisa científica, desde a apresentação do problema, a modelagem da solução, padrões utilizados na implementação e resultados obtidos. Nesta etapa é registrado o problema e a justificativa da solução proposta, fornecendo uma fundamentação teórica.

20 Estrutura do trabalho Este documento está estruturado em quatro capítulos. O primeiro capítulo, Introdução, oferece uma visão geral sobre a problemática e define os objetivos que devem ser cumpridos ao longo do desenvolvimento deste trabalho. O capítulo 2, Fundamentação Teórica, apresenta em mais detalhes as pesquisas e análises que foram feitas para que seja possível efetuar o desenvolvimento do projeto proposto. Além disso, neste capítulo também há uma imersão breve no histórico e na descrição dos softwares e hardwares que serão utilizados. O capítulo 3, Desenvolvimento, apresenta a definição do design da biblioteca de funções proposta neste trabalho, mostrando detalhes que foram utilizados para o desenvolvimento do projeto, desde a modelagem até a implementação. Por fim o capítulo 4, Conclusão, é feito um fechamento do trabalho, onde são mostrados os resultados do projeto como um todo, além das dificuldades encontradas e suas resoluções.

21 24 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentados os principais conceitos envolvidos no projeto proposto: interfaces e tipos de interação; jogos eletrônicos e sua interação com o usuário; uma abordagem mais aprofundada sobre o sensor Microsoft Kinect e sobre a engine para criação de jogos Unity. 2.1 Interfaces com o Usuário O conceito de formas de interfaces com o usuário evoluiu e se alterou ao longo do tempo. No início a interface era vista como a forma de que o hardware e um software aplicativo promoveriam a comunicação entre o humano e o computador. Atualmente dentro do conceito de interface encontram-se também os aspectos relativos à percepção; cognição e habilidades motoras e viso-motoras do usuário (OLIVEIRA NETTO, 2004). É por meio da interface que o usuário interage com a aplicação, o que a torna parte essencial de toda e qualquer aplicação. Na construção de qualquer software deve ser analisada tanto a parte funcional quanto a parte de interface. A interface tem como objetivo fornecer uma interação com o usuário da forma mais amigável possível, ou seja, oferecer ao usuário maneiras simples e consistentes de interação. Para o projeto de um software também é interessante analisar tanto a perspectiva do desenvolvedor, quanto a perspectiva do designer na etapa de definição da interface com o usuário (WINOGRAD, 1996). O modo como os usuários e os sistemas computacionais interagem é chamada de estilo de interação (SHNEIDERMAN, 1998). Os estilos de interação que compõe as interfaces mais conhecidas são: CL (Command Line), GUI (Graphical User Interface) e NUI (Natural User Interface) Interfaces CLI e GUI A interface CLI (Command Line Interface) é um dos estilos de interação mais conhecidos, esta interface foi a primeira a ser oferecida nos sistemas operacionais DOS, MAC OS e outros. Atualmente ela ainda pode ser utilizada em um sistema operacional como o Windows 7, por exemplo, através da aplicação Command Prompt. A Figura 1 mostra um exemplo de interface CLI.

22 25 Figura 1. Captura de tela de uma interface CLI no Windows 7 O usuário interage diretamente com o sistema ou aplicação CLI através da utilização de comandos de texto específicos, como o comando dir, na imagem acima. Este tipo de interação também permite ao usuário uma maior liberdade de iniciativa e flexibilidade ao usuário, pois oferece a funcionalidade de criação de comandos parametrizados para executar determinadas funções (OLIVEIRA NETTO, 2004). Por estes motivos as interfaces baseadas em linguagens de comandos são consideradas mais eficientes que os outros tipos existentes (PREECE, Jenny et al. 1994), porém para os usuários iniciantes essa linguagem pode ser complicada, pois exige domínio sobre a linguagem de comandos. Outro fator que dificulta a utilização das interfaces CLI deve-se ao fato de que, sistemas operacionais diferentes podem oferecer comandos totalmente distintos em sua interface CLI, fazendo com que o usuário de aplicações CLI multi-plataformas tenha de aprender múltiplos conjuntos de comandos para poder interagir com os aplicativos através de suas interfaces CLI. Em busca de interfaces mais intuitivas para usuários iniciantes surgiu o estilo de interação conhecido como GUI (Graphical User Interface). Este tipo de interação pode ser definido como sendo um conjunto de opções exibidas em uma tela para o usuário. Ao contrário da CLI, o tipo de interface baseada no conceito GUI possui botões, menus, caixas de

23 26 seleção e marcação, ícones e outros recursos gráficos que possam indicar ao usuário como interagir com a máquina (OLIVEIRA NETTO, 2004). A Figura 2 mostra uma das primeiras interfaces GUI oferecidas ao usuário em um sistema operacional. Figura 2. Screenshot do sistema operacional Windows 3.11 Outra novidade introduzida através das interfaces gráficas foi o uso do mouse, um periférico que é controlado via software e simula um ponteiro através do qual o usuário consegue pressionar os botões e os outros componentes visuais da interface apresentada na tela. Segundo Preece et al. (1994) as aplicações que utilizam o tipo de interação GUI possuem um nível de manipulação e aprendizado bastante simples, basta que a interface seja bem projetada em termos de design e usabilidade para que o usuário consiga navegar pelo sistema sem muitas dificuldades.

24 27 Profissionais da área de IHC (Interação humano-computador) possuem papel fundamental na construção de um software que utilize interfaces gráficas, pois quando as formas de interação através de uma interface GUI são bem projetadas e construídas, o software pode aumentar em muito sua produtividade (OLIVEIRA NETTO, 2004). O Quadro 1 faz uma comparação das características dos tipos de interface CLI e GUI: Propriedade CLI GUI Facilidade Devido à memorização e familiaridade necessária para usuários operarem nesta interface ela se torna muito difícil para novos usuários. Controle Multitarefa Velocidade Recurso necessário Usuários possuem muito mais controle do sistema de arquivos e do sistema operacional, para efetuar uma cópia de um arquivo para outro diretório, por exemplo, basta uma linha de comando. São capazes de executar processos em multitarefa, mas não oferecem a possibilidade de ver vários formulários abertos, por exemplo. A digitação de comandos para executar tarefas pode ser mais veloz do que procurar a mesma funcionalidade com o mouse, mas requer muito mais treinamento. Um computador que execute somente uma interface CLI não necessita de muito recurso. Acesso remoto Alguns computadores ou dispositivos só podem ser acessados através de CLI. Quadro 1. Comparativo entre CLI e GUI Fonte: Adaptado de ComputerHope (2012). Alguns usuários possuem dificuldade para operar o mouse no início, mas o tempo necessário para aprendizado é muito menor Também oferece bastante controle ao usuário, mas algumas tarefas podem ser mais trabalhosas nesta interface, usuários avançados às vezes optam pela CLI ao fazer algumas operações mais específicas. Possui um sistema de janelas que permitem ao usuário visualizar, manipular e controlar vários formulários simultaneamente Com o mouse e o teclado a navegação entre as janelas se torna rápida com pouco tempo de aprendizado. Para a visualização de elementos como ícones, fontes imagens e vídeos, as interfaces gráficas demandam mais recursos. Não são todos os computadores ou dispositivos de rede que podem ser acessados via interfaces gráficas Interfaces NUI Entre os estilos de interação de interfaces a NUI (Natural User Interface) é sem dúvida uma das formas mais eficientes de interação com o usuário, já que permite ao usuário utilizar a linguagem natural do próprio corpo, como por exemplo, gestos e falas em sua língua tradicional.

25 28 Ainda não é possível criar um sistema que compreenda totalmente as especificidades da linguagem natural humana, já que muitos dos gestos comuns às pessoas possam parecer vagas ou ambíguas no meio computacional. Na construção de uma aplicação que possua este estilo de interação são utilizados algoritmos para interpretar um subconjunto de comandos, como por exemplo, gestos e comandos de voz já previstos pelo sistema. (OLIVEIRA NETTO, 2004). A NUI é um termo utilizado em vários tipos de tecnologia, tais como reconhecimento de voz, periféricos com touchscreen (telas sensíveis ao toque) e algumas interfaces conhecidas como cinéticas, ou seja, ligadas diretamente a movimentos do corpo, como por exemplo, o Microsoft Kinect. O maior objetivo da NUI é criar interfaces que sejam de fácil manipulação para os usuários, onde não necessitaria de uma curva de aprendizagem tão longa quanto nas interfaces CLI ou GUI. As aplicações que oferecem interfaces NUI, como o próprio termo diz, devem ser naturais aos usuários, oferecendo formas de interação com a aplicação que seja independente de conhecimento computacional. Um grande exemplo são as interfaces oferecidas em dispositivos como os tablets e smartphones, onde usuários como crianças e idosos conseguem interagir com aplicações com uma curva de aprendizagem bastante rápida e intuitiva (ASHLEY; WEBB, 2012). Segundo Bill Buxton (2012), pesquisador da Microsoft Research reconhecido como um dos pioneiros na área de IHC (interação humano-computador), a forma mais natural de um usuário utilizar uma interface é quando o usuário faz o uso de habilidades que foram previamente aprendidas sem que o mesmo note isto. Em geral, os usuários que estão acostumados com as interfaces GUI, ao se deparar com um botão em uma aplicação que segue os conceitos NUI, executada em um dispositivo touchscreen, entendem que devem pressionar a tela no local do botão, o que é feito normalmente com o mouse nas aplicações que não possuem touch, ou seja, uma habilidade previamente desenvolvida que dá sentido a um gesto. (ASHLEY, James; WEBB, Jarret, 2012). A Figura 3 ilustra os gestos mais comuns em uma superfície touchscreen, que são respectivamente: pressionar a tela e retirar o dedo rapidamente (tap) em um ponto, pressionar

26 29 a tela e permanecer segurando por um tempo maior, deslizar o dedo pela tela (geralmente ligado à barra de rolagem) e por último o movimento de pinça (geralmente ligado ao efeito de zoom). Figura 3. Gestos em uma tela de toque. Fonte: ASHLEY e WEBB (2012). Uma vantagem que os gestos em superfícies sensíveis ao toque e interfaces cinéticas possuem em relação ao reconhecimento de comandos por voz é a independência do idioma nativo de cada usuário. A criação de um reconhecimento de voz é um procedimento complexo já que é necessário que a aplicação possua um algoritmo com certa inteligência a fim de identificar o comando de forma correta, independente, por exemplo, dos sotaques diferentes entre os usuários. A linguagem gestual de qualquer interface cinética, incluindo o Kinect, é considerada boa e de fácil adaptação, quando são tratados dois dos conceitos essenciais da área de usabilidade, que são o affordance e o feedback (ASHLEY; WEBB, 2012). O feedback em uma aplicação NUI geralmente consiste em notificar o usuário quando uma pose ou um gesto são reconhecidos. No XBox dashboard, por exemplo, ao reconhecer que a mão do usuário está sobre algum quadro em que o usuário possa interagir, o sistema

27 30 exibe uma animação para notificar o usuário que, caso ele não altere a posição de sua mão, o sistema acionará ação correspondente. Neste mesmo dashboard quando o usuário diz em voz alta a palavra XBox, é exibido um ícone em forma de microfone e uma mensagem ao usuário notificando que ele pode executar algum comando de voz juntamente com todos os comandos de voz que podem ser reconhecidos são exibidos abaixo de cada quadro, como a Figura 4 ilustra. Figura 4. Xbox dashboard. O affordance são os indicativos da aplicação que guiam o usuário, como por exemplo, na Figura 4 do dashboard do Xbox, o ícone do microfone exibido indica que o usuário pode utilizar um comando de voz. As respostas da aplicação ao usuário (feedback) e os indicativos certos (affordance), somados a interface NUI, tornam a experiência de uso fácil, simples e intuitiva, cumprindo os requisitos da NUI. 2.2 Jogos Eletrônicos O que são jogos eletrônicos? Jogos eletrônicos são um nicho de programas de computador focados principalmente em prover o entretenimento ao usuário. No cenário atual este tipo de aplicação possui uma grande indústria cultural que evolui constantemente (MENDES, 2006).

28 31 Os jogos eletrônicos atualmente estão presentes em plataformas diversas e com diferentes grupos de jogadores. Praticamente todo o tipo de pessoa possui um perfil para certo grupo de jogos específicos; qualquer tipo de dispositivo capaz de executar um programa de computador pode executar algum tipo de jogo (MENDES, 2006). Segue a lista com os principais tipos de aparelhos que podem executar este tipo de programa: Computadores; Consoles específicos; Celulares e Smartphones; Televisores e Smart Tvs; Hardwares voltados para este tipo de software, como por exemplo, minigames Motores de jogos eletrônicos Os chamados motores de jogos, são componentes de softwares que disponibilizam funcionalidades focadas e específicas para o desenvolvimento de um jogo. Basicamente, é um agrupador de funcionalidades fundamentais ao desenvolvimento de um projeto de jogos, que podem variar desde a interoperabilidade entre os periféricos de controle até a renderização dos objetos de uma cena (BESSA et al. 2007). A quantidade de componentes providos por um motor de jogo pode variar muito; em sua maioria, são feitos com diferentes módulos para diferentes funcionalidades, como por exemplo, módulo para renderização de personagens, controle da física sobre a cena, controle de entrada de dados do usuário, controle de áudio, controle de threads e vários outros pontos, que podem tornar o desenvolvimento de um motor de jogo mais complexo até do que o desenvolvimento do próprio jogo. Alguns dos motores mais utilizadas são: Unity, 3D GameStudio, Truevision3D, Unreal Engine e Microsoft XNA Game Studio (GREGORY, 2009) Jogos eletrônicos utilizando NUI A NUI provê benefícios a qualquer tipo de aplicação, mas a área de jogos em especial busca a melhor interação com o usuário a todo o momento (OLIVEIRA NETTO, 2004).

29 32 Os jogos eletrônicos também podem ser considerados sistemas de computadores. A experiência que um jogo transfere ao usuário é passada através de uma série de regras, somadas com objetivos, atividades e ações dinâmicas do usuário. Este processo é comumente chamado de Jogabilidade (VALE, 2005). Ao longo dos anos, para diferenciar a jogabilidade, o mercado de consoles vem buscando alternativas com diferentes tipos de hardware, desde controles mais específicos e cheios de botões até as interfaces mais naturais fornecidas pelos consoles Nintendo Wii, Wii U e o Microsoft Xbox que possui o acessório para comandos de voz e interface cinética Kinect (VALE, 2005). A Figura 5 mostra respectivamente os hardwares supracitados. Figura 5. Jogos eletrônicos utilizando NUI 2.3 Microsoft Kinect O Microsoft Kinect foi uma criação da empresa Microsoft, utilizado inicialmente como acessório ao console Xbox 360, o aparelho possui cerca de vinte e cinco centímetros de largura e possui alguns componentes que o permitem captar movimentos do corpo humano e mapear o esqueleto de uma pessoa em até 20 pontos diferentes.

30 33 O Microsoft Kinect nasceu de uma parceria entre a empresa Microsoft e uma empresa israelita chamada PrimeSense, ambas possuíam a mesma visão para o quesito interface: A tecnologia torna-se mais abrangente, mais intuitiva e mais fácil de se familiarizar quando interage diretamente com o corpo humano citou Aviad Maizels, fundador e presidente da Prime Sense(LEADBETTER, 2010). A Figura 6 mostra o layout do hardware da PrimeSense. Figura 6. Sensor 3D PrimeSense Fonte: Adaptado de LEADBETTER (2010). O sensor PrimeSense é menor que o sensor da Microsoft possuindo quatorze centímetros de largura, possui dois microfones, ao invés de quatro como o Kinect e não possui o eixo motorizado para direcionar a câmera( PRIMESENSE, 2011). O Quadro 2 mostra as configurações gerais do sensor da empresa PrimeSense:

31 34 Propriedade Especificação Campo de visão horizontal 58 graus Campo de visão vertical 45 graus Campo de visão diagonal 70 graus Profundidade do tamanho da imagem VGA (640 x 480) Resolução espacial x/y a dois metros de distância do sensor 3 mm Profundidade da resolução z a dois metros de distancia do sensor 1 cm Rendimento máximo da imagem (frame-rate) 60 FPS Alcance da operação 0.8 metros à 3.5 metros Tamanho de imagens e cores UXGA (1600 x 1200) Número de microfones Dois Entradas digitais de áudio Quatro Interface dos dados e alimentação de energia USB 2.0 Consumo 2.25 W Dimensões 14cm x 3.5cm x 5cm Ambientes de operação Fechado Iluminação do ambiente Qualquer tipo Temperatura do ambiente 0 C - 40 C Quadro 2. Configurações do sensor PrimeSense Fonte: Adaptado de LEADBETTER (2010) Detalhando o Microsoft Kinect O sensor da Microsoft foi bastante aprimorado em relação ao PrimeSense, o software interno, conhecido como NITE foi descartado fazendo com que o Kinect tenha um reconhecimento do esqueleto do corpo e um sistema para reconhecimento de comandos de voz totalmente diferente do PrimeSense. O hardware possui quatro microfones, duas câmeras, um emissor de luz infravermelha e um eixo motorizado, conforme Figura 7.

32 35 Figura 7. Sensor Kinect Fonte: Adaptado de Microsoft (2012). A câmera RGB do sensor é utilizada para captar imagens do mundo real de forma similar a uma webcam, esta câmera permite que o Kinect tenha um reconhecimento facial muito bom, além de permitir que o sensor tire fotos ou grave vídeos. O emissor e a câmera de luz infravermelha permitem que o sensor consiga captar a distância de um objeto em relação ao sensor, ou seja, reconhecer a profundidade, além de altura e largura como na câmera RGB. A tecnologia utilizada pela PrimeSense e adquirida pelo Kinect chama-se Light Coding (LEADBETTER, 2010). Esta técnica se baseia basicamente em luz infravermelha. O emissor de luz infravermelha do Kinect projeta a luz por todo o ambiente. Em seguida a câmera infravermelha obtém estes pontos luminosos, através de um processamento interno também herdado da PrimeSense o sensor traduz estes pontos para um mapa de profundidade, somando este mapa com a imagem da câmera RGB obtém-se uma imagem onde cada pixel possui um componente de profundidade também conhecida como imagem RGBD (Red- Green-Blue-Depth), ou seja, as imagens da câmera RGB e da câmera de profundidade são sincronizadas no espaço e no tempo (ALBITAR, chadi; GRAEBLING, Pierre; DOIGNOM, Christophe, 2007). Através do resultado obtido pelas câmeras, o Kinect passa por um processo de avaliação da imagem capturada a fim de reconhecer cada articulação de cada esqueleto de cada pessoa presente na cena. Para efetuar este processo a Microsoft desenvolveu um algoritmo próprio com dois objetivos principais: eficiência computacional e robustez. Os quatro microfones que ficam ao longo do sensor, permitem que o periférico receba como entrada de informação o som. Estes microfones ficam espalhados pelo Kinect e desta

33 36 forma, é possível perceber de onde o som está vindo. Além disso, com um processamento interno feito pelo próprio Kinect estes microfones são capazes de entender comandos feitos por meio da voz. O eixo motorizado é utilizado apenas para movimentar a parte superior do sensor para cima ou para baixo, alterando assim o posicionamento das câmeras Microsoft Kinect SDK A Microsoft disponibiliza em seu site o download gratuito do SDK (software development kit) para implementações utilizando o hardware Microsoft Kinect (KINECTSDK, 2012). O SDK é composto por várias aplicações que mostram o funcionamento básico do Kinect, como por exemplo mapear um esqueleto ou exibir a imagem da câmera RGB. Além das aplicações também é fornecida a DLL Microsoft.Kinect, onde estão contidas todas as classes, enumerados e estruturas necessárias para manipular o Kinect em uma aplicação (MSDN, 2012). A classe principal do SDK é a KinectSensor, através dela é possível manipular todas as funcionalidades do Kinect. Esta classe também define quais as funcionalidades do sensor estão ligadas e desligadas; inicialmente o KinectSensor vem com todas as funcionalidades desligadas. Estas funcionalidades são acessadas através das propriedades ColorStream que controla a funcionalidade interligada a câmera RGB do sensor; DepthStream que está ligada diretamente com a captação da profundidade dos objetos em frente ao sensor; SkeletonStream que é a propriedade que mapeia o corpo humano dos jogadores em frente ao sensor e AudioSource que controla as funcionalidades interligadas aos microfones do sensor. Além destas propriedades principais a classe também oferece acessos às propriedades ElevationAngle que retorna o ângulo de elevação do eixo motorizado; Status, que pode indicar se o Kinect está ligado, desconectado, com algum erro e outros tipos de status; KinectSensors, para acessar uma coleção com todos os Kinects ligados a máquina que está executando a aplicação e outras propriedades para controle de IDs dos sensores, utilizados para controle em situações em que há mais de um sensor simultaneamente.

34 37 sensor Kinect. A Figura 8 ilustra como a classe KinectSensor e suas propriedades interagem no Figura 8. Principais funcionalidades do SDK Esqueleto Apesar de utilizar o hardware proposto pela PrimeSense o Kinect possui uma forma própria para reconhecer o esqueleto do usuário através de uma rede neural desenvolvida pela própria Microsoft (LEADBETTER, 2010). Para efetuar o reconhecimento de diferentes tipos de movimentos a Microsoft treinou a rede neural que reconhece esqueletos com diferentes tipos de mocaps. A Figura 9 ilustra a utilização de um mocap para gravação de um movimento para um jogo de golf.

35 38 Figura 9. Exemplo de utilização de Mocap Fonte: (2010) A detecção do esqueleto do usuário através do SDK do Kinect é disponibilizado por meio de 20 articulações que são mapeadas pelo software interno do Kinect. Desenvolvido e treinado pela Microsoft, através destas 20 articulações é possível identificar e distinguir todos os pontos relevantes para interpretar um movimento de um usuário. Através destes pontos é possível obter as posições espaciais X,Y e Z de cada articulação, permitindo a descrição tridimensional dos movimentos capturados. A Figura 10 ilustra a disposição bidimensional das articulações no esqueleto de um usuário.

36 39 Figura 10. Articulações disponibilizadas pela SDK do Kinect Fonte: Mapeamento de movimentos As expressões corporais das pessoas podem ser classificadas em duas principais categorias de acordo com o tipo de movimento: as poses e os gestos (ASHLEY, James; WEBB, Jarret, 2012). A diferença entre estes dois tipos de movimento pode ser explicada de forma bastante simples: a pose é uma forma estática de manter o corpo enquanto o gesto é um movimento em um espaço de tempo. Estes dois tipos de movimento são utilizados na linguagem corporal humana. Em uma partida de futebol, quando um jogador encontra-se em posição de impedimento, o árbitro auxiliar levanta sua bandeira mantendo-se em uma pose para comunicar ao árbitro que a jogada deve ser paralisada. Quando duas pessoas se despedem geralmente utilizam o gesto de aceno de forma automática, pois é natural às pessoas executar este gesto nesta situação. O Microsoft Kinect SDK não oferece nenhum tipo de biblioteca ou API para mapear gestos ou poses. Para efetuar os processos para detecção destes movimentos é necessário ao desenvolvedor criar algoritmos de detecção e reconhecimento de poses e gestos.

37 Detecção de poses A posição tridimensional das articulações do esqueleto de um usuário em frente ao sensor define a pose em que o usuário se encontra. Para efetuar a detecção e reconhecimento dessas poses deve sempre ser analisado o relacionamento entre as articulações de um mesmo esqueleto e nunca suas posições espaciais, pois os usuários podem estar posicionados espacialmente em coordenadas distintas ou possuir estaturas diferentes, mas ainda assim estarem realizando a mesma pose. Existem variadas técnicas para fazer o reconhecimento de uma pose, dentre as quais se destaca como mais utilizada o método de cálculo de ângulo entre articulações, conforme ilustra a Figura 11. Nesta técnica efetua-se o reconhecimento da posição relativa de uma articulação em relação à outra através do ângulo formado entre os dois vetores definidos pelos pontos das articulações (KEAN, Sean; HALL, Jonathan; PERRY, Phoenix, 2012) (ASHLEY, James; WEBB, Jarret, 2012). Figura 11. Ângulo entre articulações Fonte: (ASHLEY, James; WEBB, Jarret, 2012) Segundo Ashley, Webb (2012) e Kean, Hall, Perry (2012) o método de cálculo de ângulo entre três articulações é capaz de mapear um maior número de poses. Para distinguir corretamente uma pose é necessário selecionar as três articulações que estejam envolvidas,

38 41 pode-se efetuar dois diferentes cálculos: o produto escalar, para calcular o ângulo entre os vetores no espaço 3D e a lei dos cossenos para se calcular o ângulo sobre um plano 2D. Para o produto escalar devem ser utilizadas três articulações, onde suas coordenadas espaciais são definidas como vértices de dois vetores (V e W) definidos no espaço R3 (FOLEY, James D. et al. 1997), como ilustra a Figura 12. Figura 12. Vetores e articulações no espaço R3 Após estabelecer as articulações que serão utilizadas no cálculo do ângulo e obtermos o vetor é necessário aplicar o cálculo chamado produto escalar, onde conseguimos identificar um ângulo entre dois vetores em um sistema de coordenadas 3D euclidiano (FOLEY, James D. et al. 1997), abaixo segue a Equação 1 que é a equação para calcular o produto escalar. Equação 1

39 42 Para efetuar este cálculo é necessário possuir as informações referentes a distância do vetor em cada eixo, para continuar com o exemplo da Figura 12, a Figura 13 ilustrará distâncias hipotéticas em cada coordenada de cada vetor. Figura 13. Vetores com as distâncias no espaço R3 Para efetuar o cálculo V.W é utilizado o produto escalar de vetores, ou seja, soma-se o resultado do produto de cada coordenada dos vetores (FOLEY, James D. et al. 1997), a Equação 2 ilustra o cálculo citado. Equação 2 Por fim o cálculo também utiliza o produto entre o módulo do vetor V ( V ) e o módulo do vetor W ( W ) (FOLEY, James D. et al. 1997), esta multiplicação pode ser executada através do cálculo descrito na Equação 3.

40 43 Equação 3 Seguindo o exemplo da Figura 12 e da Figura 13 a resolução do cálculo seria da forma que a Figura 14 ilustra abaixo. Como foram usados valores hipotéticos o resultado é apenas ilustrativo. Figura 14. Cálculo do ângulo entre os vetores V e W Para efetuar o cálculo do ângulo 2D, utiliza-se a fórmula da lei dos cossenos. Nesta fórmula são utilizadas as articulações e suas respectivas coordenadas X e Y (após a conversão para o plano 2D), de forma arbitrária as três articulações são classificadas em dois pontos auxiliares e um ponto central, após ter sido feito o processo de classificação das articulações aplica-se a lei dos cossenos conforme a Equação 4. Isso ocorre devido ao fato de que a trigonometria básica não é aplicável a triângulos obtusângulos, ou seja, triângulos que possuam um ângulo maior do que 180 graus (ASHLEY, James; WEBB, Jarret., 2012). Equação 4

41 44 Através desta fórmula é possível calcular o ângulo referente à articulação definida como ponto central, os valores listados na fórmula são: a é igual à distância entre o ponto central e um dos pontos auxiliares, b é igual à distância entre o ponto central e o outro ponto auxiliar e c é igual à distância entre os pontos auxiliares, formando assim o triângulo que mapeia estes pontos (ASHLEY, James; WEBB, Jarret., 2012). A Figura 15 exemplifica com o mesmo exemplo do cálculo do produto escalar. Figura 15. Exemplo da utilização da lei dos cossenos A lei dos cossenos é utilizada sobre superfícies planas, ou seja, em duas dimensões, para tanto, uma etapa de projeção das coordenadas 3D para os planos frontal (XY), lateral (YZ) e superior (XZ) é necessária. Neste trabalho foi selecionada a projeção ortográfica paralela para implementar esta transformação (FOLEY, James D. et al. 1997). Neste trabalho foi implementada a projeção ortográfica paralela (FOLEY, James D. et al. 1997) para efetuar o cálculo do ângulo 2D através da lei dos cossenos. Nesta etapa um dos eixos do espaço 3D é simplesmente descartado. A Figura 16 ilustra o funcionamento dessa projeção sobre um objeto em um sistema de coordenadas em 3D.

42 45 Figura 16. Exemplo de utilização da projeção ortográfica paralela Detecção de gestos Para detecção de gestos a bibliografia pesquisada se refere às três seguintes técnicas: por algoritmo especializado; por redes neurais ou por comparação à um gesto previamente armazenado (ASHLEY, James; WEBB, Jarret., 2012). A detecção de gestos por algoritmo especializado é a forma menos complexa para se detectar um gesto. Neste modelo de detecção é implementado uma série de regras e condições que produzem um resultado no fim do processamento, indicando se o gesto a ser detectado foi ou não executado pelo usuário (ASHLEY, James; WEBB, Jarret., 2012). Esta forma é eficiente para detectar gestos simples, mas cada gesto precisa ser implementado com diferentes parâmetros o que cria um problema a respeito do reuso de códigos; a cada gesto novo inserido na aplicação terá de ser feita uma nova implementação para detecção do mesmo. O processo de detecção por rede neural é uma forma complexa e não trivial, não muito indicada para aplicações simples. Este processo consegue detectar e classificar com facilidade gestos similares, porém o processo de criação de uma rede neural é algo custoso e além da criação a rede também deve passar por processos de treinamentos para que ela se torne efetivamente boa em reconhecer os gestos para qual foi treinada (KEAN, Sean; HALL, Jonathan; PERRY, Phoenix, 2012).

43 46 A detecção por um exemplo previo consiste em registrar os movimentos de um usuário através de um software especializado em captura e em tempo de execução da aplicação comparar por frames os possíveis gestos a serem detectados. É um processo custoso e complexo, pois envolve o tempo de execução do gesto como quarta dimensão, além do movimento no espaço (BUXTON, 2012) Reconhecimento de Fala Conforme pesquisas da Microsoft, interagir com comandos de voz em uma aplicação é geralmente a forma que os usuários preferem como interface em relação a interfaces de gestos e interfaces com algum tipo de controle (KINECTAUDIO, 2011). O hardware do Kinect possui quatro microfones dispostos ao longo do sensor, além de reconhecer os comandos de voz, também identificam qual a direção do áudio. Os dados referentes aos comandos de voz são previamente tratados pelo próprio Kinect antes de serem enviados ao Xbox ou ao PC (KINECTAUDIO, 2011). O sistema para reconhecimento de voz também possui uma funcionalidade para cancelamento de eco acústico, que visa diminuir o ruído e melhorar a eficiência do reconhecimento destes comandos. A Microsoft também utilizou uma rede neural para treinar o reconhecimento de voz devido à quantidade de sotaques diferentes além das diferenças de articulações e velocidades da fala que mudam para cada individuo (KINECTVIDEOAUDIO, 2011). Apesar do SDK do Kinect possuir a integração com os comandos de voz do hardware é necessário efetuar o download da SDK para reconhecimento de voz, já que não é feito todo o processamento no próprio Kinect, a SDK para reconhecimento de voz se encontra disponível para download no próprio site da Microsoft sem custo nenhum (KINECTSDK, 2012). Como ilustrado na Figura 8, através da propriedade AudioSource é possível interagir e definir quais os comandos de voz que serão utilizados e se deve ser utilizado o cancelamento do eco acústico. Inicialmente os comandos de voz são reconhecidos apenas no inglês dos Estados Unidos, mas é possível fazer o download de pacotes de extensão de reconhecimento para as linguagens: inglês para Grã-Bretanha, Irlanda, Austrália, Nova Zelândia e Canadá,

44 47 francês para França e Canadá, italiano para a Itália, japonês para o Japão e espanhol para a Espanha e México (KINECTSDK, 2012). 2.4 Unity O que é a Unity? A Unity oferece um conjunto de ferramentas voltadas a auxiliar os desenvolvedores durante as etapas básicas de desenvolvimento de jogos desde a programação, oferecendo uma API; até a publicação, oferecendo uma maneira fácil de tornar o jogo multiplataforma. É possível, por exemplo, publicar o trabalho final para as plataformas: Mac OSX App, Windows, Navegadores Web; dispositivos móveis com sistemas ios e Android; para desenvolvedores autorizados também é possível disponibilizar o trabalho final para os consoles Wii, Playstation 3 e Xbox 360 (UNITY,2012). A Figura 17 ilustra a tela principal da ferramenta que é composta pelos painéis: Scene, que mostra a cena do jogo que está sendo desenvolvida; Game, que mostra como a cena iniciará no jogo; Hierarchy, que mostra as informações referentes aos objetos que estão inseridos na cena; Project, que exibe todos os artefatos do projeto e o painel Inspector que exibe informações do item ou opção selecionada. Figura 17. Visão principal da ferramenta Unity

45 Scripts A ferramenta Unity provê ao desenvolvedor um mecanismo de Scripts que podem ser codificados nas linguagens JavaScript, C# e Boo (Unity,2012). Os scripts são trechos de código escritos pelo desenvolvedor do jogo que implementam a parte da animação dos personagens e objetos de uma cena através de chamadas às funções de animações oferecidas pela Unity; sem eles nada se moveria ou interagiria dentro do universo virtual. Como citado anteriormente, a Unity permite a utilização de scripts na linguagem C#, esta linguagem faz parte do framework.net desenvolvido pela Microsoft. Apesar disso, existe um projeto open-source de um compilador paralelo chamado Mono (MONO, 2012). Este compilador tem como principal objetivo tornar o C# multiplataforma e, para que isso seja possível este compilador não permite a utilização de nenhuma classe base do Windows. A Unity, desde sua versão 3 até atualmente na versão 4, utiliza o compilador Mono em sua versão 2.6, que inicialmente aceita apenas as classes do framework.net em sua versão 2.0, mas é possível utilizar plug-ins no projeto com DLLs na versão 3.5 do.net framework, desde que, nesta DLL não haja nenhuma classe incompatível com a versão anterior do framework. A Unity fornece uma tabela que mostra a compatibilidade entre o Mono e o framework.net (MONOCOMPATIBILITY, 2012). Os scripts criam as funcionalidades dos objetos no mundo virtual, incluindo a parte de interação entre o personagem principal e o jogador. A forma como os jogadores interagem com o personagem na Unity são definidos pelos Inputs (entradas) criados pelo desenvolvedor. A ferramenta Unity fornece a classe estática Input para a detecção de quando o jogador está jogador está ou não pressionando uma das entradas configuradas pelo desenvolvedor. O Quadro 3. Exemplo de código fonte utilizando a classe Input ilustra um pequeno trecho de código onde esta classe é utilizada. Para manter a compatibilidade de métodos, o projeto desenvolvido utiliza os métodos da classe Input, como descrito na seção 3.4.

46 49 // Método chamado a cada frame da cena do jogo void Update() { if (Input.GetAxis("Horizontal") > 0) { /* A entrada Horizontal pode possuir valor positivo ou negativo * para saber qual o valor acionado nesta input deve-se * avaliar o valor da entrada. * Neste caso a entrada foi acionada com o valor positivo. */ } else if (Input.GetAxis("Horizontal") < 0) { // Neste caso a entrada foi acionada com o valor negativo. } if ( Input.GetButtonDown("Jump") ) { // Neste caso a input possui apenas um valor. } } Quadro 3. Exemplo de código fonte utilizando a classe Input Inputs podem possuir somente valores positivos, ou valores positivos e negativos, por exemplo, conforme ilustrado na Figura 18, a entrada cujo nome é Horizontal possui os botões right e left definidos como positivos e negativos respectivamente, pois o usuário pode se mover para frente e para trás, representando dois estados inversos; já a entrada cujo nome é Jump possui apenas o botão space definido como positivo, pois o usuário possui apenas um estado (valor positivo) para poder pular. Figura 18. Inputs da engine Unity

47 50 3 DESENVOLVIMENTO Neste capítulo serão descritos os processos que foram utilizados para desenvolver o projeto, desde seu planejamento e modelagem até a implementação, descrevendo os padrões utilizados e os resultados gerados. O objetivo geral deste projeto foi desenvolver uma biblioteca de funções - SDK - que permita criar uma integração entre a forma de interface cinética do Microsoft Kinect e diferentes tipos de aplicação que possam ser beneficiadas pela interface NUI. Para estudo de caso será feito uma integração com o motor para criação de jogos Unity. O SDK a ser desenvolvido tem por objetivo facilitar o trabalho de um desenvolvedor que busca utilizar o Kinect como interface para controlar sua aplicação, oferecendo um nível de abstração em relação à API a ser aprendida, exigindo o mínimo possível de conhecimento a respeito deste periférico e seu respectivo SDK. 3.1 Tecnologias Utilizadas na Criação da Biblioteca Para criação desta biblioteca foi escolhido utilizar a linguagem de programação C#, já que esta é uma das linguagens da Microsoft que podem ser utilizadas para desenvolvimento de aplicações que utilizam o SDK oficial do Kinect e também é uma das linguagens utilizadas para a criação de scripts na Unity, evitando assim a necessidade da criação de uma interoperabilidade entre linguagens diferentes. Como ferramenta de desenvolvimento foi utilizado o Microsoft Visual Studio 2010 (VISUALSTUDIO, 2012) até setembro, após isso foi utilizado sua atualização, o Microsoft Visual Studio 2012, através dessas ferramentas também foram criados os diagramas de classe, pois dessa forma foi possível criar as classes a partir dos diagramas, simplificando a criação da estrutura da biblioteca. Os diagramas de classe criados no Visual Studio possuem ícones para diferenciar propriedades, métodos, atributos, eventos, etc. O Quadro 4 possui as legendas dos ícones:

48 51 Ícone Legenda Atributos Privados Propriedades Públicas Métodos Eventos Herança de classe Associação (multiplicidade = 1) Associação (multiplicidade = N) Quadro 4. Legenda para diagramas de classe A biblioteca criada é uma solução.net nomeada de KinectProject, esta solução é composta pelos projetos: Ferramenta para captura de entradas; DLL para interação com o Kinect que foi nomeada de KinectScan; Aplicação para se conectar com o Kinect através de sockets que foi nomeada de KinectServer; DLL que contém todos os eventos de interação entre o KinectProject e a aplicação cliente, que foi nomeada de KinectEvents; DLL para plugin no Unity que foi nomeada de KinectUnity. Esta biblioteca foi desenvolvida de forma que seja possível mapear uma série de eventos do Kinect para diferentes tipos de aplicações. Para que este objetivo possa ser alcançado, foi feita a separação entre as DLLs do projeto conforme citado acima, buscando seguir a filosofia dispatcher-listener. No início do projeto, o Kinect não reconhecia o idioma português para reconhecimento de fala, então nesta biblioteca todos os comandos de voz a serem executados estão em inglês. Além disso, esta biblioteca deve ser desenvolvida para auxiliar desenvolvedores independentemente de sua nacionalidade, para isso, foi escolhido o idioma inglês para as descrições na aplicação, bem como para nome de métodos e classes e seus respectivos comentários que poderão ser utilizados por futuros desenvolvedores na produção de novos listeners.

49 52 Todas as entradas customizáveis (poses e comandos de voz) que devem fazer parte do jogo que está sendo criado pelo usuário utilizando a ferramenta Unity que não estão no pacote inicial devem ser registradas a partir da ferramenta que é disponibilizada junto à biblioteca. Esta aplicação utilizará as câmeras e os microfones do Kinect e algumas informações oferecidas pelo próprio usuário para registrar arquivos de poses e comandos de voz. 3.2 Ferramenta para registrar entradas A ferramenta para registrar as entradas foi desenvolvida após a criação da DLL KinectScan, pois toda a interação desta aplicação com o Kinect é feita a partir da KinectScan, ou seja, esta aplicação não possui nenhuma utilização direta do SDK do Kinect o que a torna um listerner para os eventos gerados pela KinectScan. A Figura 19 exibe o fluxograma para comunicação entre o Kinect e esta aplicação. Figura 19. Comunicação entre a ferramenta de captura de entradas e o Kinect Esta ferramenta deve ser utilizada para a criação das entradas customizáveis (poses e comandos de voz). Ela busca oferecer uma interface simples e objetiva, seguindo em parte os padrões para as Modern UI style applications propostos pela Microsoft. Esta aplicação possui uma única janela dividida em três principais painéis:

50 53 Painel do formulário corrente; Painel de configurações; Barra de comandos de voz. O painel de configurações e a barra de comandos de voz ficam ocultos inicialmente, liberando mais espaço para o formulário principal. A Figura 20 ilustra a organização dos componentes citados. Figura 20. Organização dos componentes na tela A classe que gerencia a janela principal possui os métodos que inicializam a KinectScan e assinam seus eventos, além disso, a janela principal também possui seu próprio evento: KinectEventReceived, que é utilizado para repassar o evento da KinectScan para o formulário corrente. Os comandos de voz que esta aplicação interpreta podem ser utilizados por todos os formulários da aplicação. Para iniciar o reconhecimento de comandos de voz basta dizer a palavra Kinect e a aplicação entrará em modo Speech.

51 54 No modo Speech é mostrado ao usuário todos os comandos de voz que podem ser ditos com uma funcionalidade similar ao reconhecimento de voz no console Xbox 360. Ao entrar no modo Speech a aplicação exibe o componente barra de comandos de voz. Este componente indica ao usuário as ações que ele pode executar através de comandos de voz. Este componente é separado dos formulários e da janela principal, ou seja, há um desacoplamento entre os componentes da aplicação, para que os formulários sejam alertados quando a aplicação está no modo Speech a classe referente à barra de comandos de voz possui os eventos: SpeechModeOn e SpeechModeOff que são interpretados pelo formulário corrente. Para efetuar a comunicação entre os três painéis da aplicação há uma classe estática chamada UIFunctionsManager, esta classe encapsula todo o funcionamento da interface do usuário, desde as funções para exibir formulários de diálogos ao usuário até as funções de navegação. Esta classe gerencia todos os formulários da aplicação e os eventos que são interpretados pelos mesmos. A aplicação descarta o uso da barra de título padrão do Windows e possui uma própria barra de título. Esta barra de título possui as funcionalidades Home e Settings, que respectivamente, leva o usuário de volta a tela inicial ou abre o painel de configurações do formulário corrente. O painel de configurações da aplicação é sensível a contexto, ou seja, o seu conteúdo varia de acordo com o formulário corrente. Tornando consistente o modo de o usuário interagir com as configurações da aplicação. Toda configuração da aplicação é armazenada em um arquivo XML para que o usuário não precise reconfigurar ao reabrir a aplicação. Para manter a consistência de navegação entre os formulários a aplicação possui os botões para navegação entre os formulários (exceto no formulário Home ) sempre nos mesmos locais (Canto superior direito), além disso, toda navegação pode ser feita por comandos de voz, a palavra necessária é exibida na barra de comandos de voz. Em seu formulário principal Home, esta aplicação conta com seis live tiles que oferecem informações sobre as tarefas que o usuário pode executar ao entrar nelas. Estas informações são fornecidas através de um ícone como affordance, do título da tile (localizado no canto inferior e esquerdo) e em frases que contam ao usuário a respeito da tarefa antes dele iniciar. A Figura 21 ilustra este formulário da aplicação.

52 55 Estas tiles também foram implementadas para possuir um redimensionamento inteligente. Este redimensionamento oculta as informações por ordem de prioridade de acordo com o tamanho disponível na tile. A Figura 21 mostra as tiles com todas as informações, caso a tile tenha o tamanho reduzido por redimensionamento da janela é oculto primeiramente o ícone e após isso, caso seja mais reduzida ainda, as frases são removidas, deixando apenas o título visível. Figura 21. Formulário Home No formulário Home o usuário possui as seguintes opções: criar uma nova pose, editar uma pose, ver a documentação do projeto, criar um novo comando de voz, editar um comando de voz e contatar o desenvolvedor Criar uma nova pose Ao pressionar o tile Create a new pose o usuário é enviado para o módulo de criação de pose, este módulo é subdividido em três formulários, onde cada formulário tem sua respectiva função. Estas funções são: gravar, compor e testar a pose. Durante a função de gravar uma pose o formulário Record New Pose é exibido, este formulário é dividido em três painéis principais: o painel da esquerda contém a visualização da câmera RGB com o esqueleto sobreposto ao corpo (isto pode ser alterado nas configurações deste formulário); o painel da direita contém uma imagem do esqueleto do

53 56 usuário (apenas depois do usuário executar a gravação da pose); e por fim acima destes dois painéis existem dois campos que são necessários para a gravação da pose: nome e tempo de espera para que a pose seja ativada. A Figura 22 ilustra o formulário Record New Pose após a pose ter sido gravada. Figura 22. Formulário Record New Pose Para gravar uma pose o usuário simplesmente deve preencher os campos e posicionarse em frente ao sensor de forma que todo seu corpo esteja sendo rastreado, posicionar-se na pose que deseja gravar e dizer a frase Record Pose com a aplicação no modo Speech, lembrando que para entrar no modo Speech é necessário dizer a palavra Kinect. Caso o esqueleto do usuário não esteja todo rastreado pelo Kinect, como por exemplo, algum objeto em frente a uma articulação do usuário, o sistema exibe um alerta notificando o problema, neste caso em especial o alerta desaparece após 5 segundos, não exigindo que o usuário retorne ao computador para ajustar o problema da pose. Caso a operação tenha sido feita com sucesso a imagem do esqueleto é jogada no painel ao lado e permanecerá sendo exibida a pose capturada de forma estática, ao contrário do painel que exibe a imagem da câmera RGB que sempre permanece em movimento, mesmo que o usuário já tenha gravado a pose.

54 57 Para passar para o próximo formulário é necessário que todos os campos (incluindo a pose no painel) tenham sido informados pelo usuário, caso ele tente prosseguir o sistema exibe um alerta notificando o problema Compor subposes O formulário Compose Subposes é onde o desenvolvedor criará as subposes que dão significado para o reconhecimento da pose, a Figura 23 ilustra uma pose composta por quatro subposes. Durante a fase de reconhecimento de poses na aplicação, tomando-se como exemplo a pose exibida na Figura 23, será necessário calcular os ângulos envolvendo as articulações dos braços e a posição das pernas. Cada conjunto de três articulações (subposes) formam um ângulo que é calculado através do cálculo do produto escalar em 3D e da lei dos cossenos sobre as projeções em 2D ( vide seção ). Figura 23. Formulário Compose Subposes. Ao clicar no botão Save a aplicação executa algumas validações (as validações são especificadas nos cenários dos casos de uso), caso estas validações se cumpram o sistema registra um arquivo XML contendo as informações necessárias para posterior tratamento da pose pela aplicação.

55 58 É fortemente aconselhável utilizar a ferramenta de teste desta aplicação antes de gravar o arquivo, para uma melhor calibragem na margem de erro e melhorar a escolha das subposes envolvidas Testar Pose O formulário Test Pose é utilizado para verificar o reconhecimento da pose que está sendo criada. Este formulário possui uma opção (no painel de configurações) para exibir um esqueleto de feedback ao usuário, caso esta opção esteja ativada, a aplicação desenha um esqueleto de referência com as articulações envolvidas na pose circuladas no fundo do painel onde o esqueleto do usuário é exibido em tempo real. A Figura 24 ilustra a imagem do esqueleto de feedback. Figura 24. Esqueleto de feedback para testar a pose Para notificar se a pose que o usuário está executando está ou não reconhecida, a aplicação exibe uma mensagem em um quadro acima do painel que pode variar entre Recognized (para quando a pose está reconhecida) ou Unrecognized (para quando a pose não está sendo reconhecida). A aplicação também altera a cor do esqueleto do usuário em tempo real. Estas diferenças podem ser visualizadas na Figura 25.

56 59 Figura 25. Pose reconhecida X Pose não reconhecida Este formulário também exibe uma tabela contendo as informações das subposes que compõe a pose a ser testada e as informações do esqueleto do usuário em tempo real para cada ângulo entre as articulações de cada subpose. Este formulário visa facilitar o acerto do desenvolvedor em relação à criação de subposes e definição da margem de erro, pois sem um teste efetivo é complicado definir se uma pose está ou não bem definida, já que em alguns casos as subposes a serem utilizadas não são naturais de se pensar. A Figura 26 mostra uma pose sendo testada e reconhecida.

57 60 Figura 26. Formulário Test Pose Criar um novo comando de voz Ao acessar a tile para Create a new voice command a aplicação envia o usuário para o formulário Compose Voice Command Group, ou seja, compor grupo de comandos de voz, neste formulário o usuário deve informar qual o nome e o nível de confiança referente ao grupo de comandos de voz e quais os comandos contidos neste grupo. Para efetuar a manutenção dos itens inclusos a aplicação oferece uma barra com os botões para incluir e excluir um comando de voz. Neste mesmo formulário também é exibido o botão de gravar, que ao ser pressionado gera o arquivo referente ao grupo de comando de voz. A Figura 27 exibe um grupo de comando de voz referente a cumprimentos sociais entre pessoas.

58 61 Figura 27. Formulário Compose Voice Command Group Testar um grupo de comandos de voz A aplicação também conta com um formulário de teste de comandos de voz, neste formulário é exibido uma barra com o botão para iniciar o teste e uma grade contendo todos os comandos de voz que o usuário inseriu no grupo. A grade onde ficam os comandos de voz apresenta algumas colunas que, respectivamente exibem o melhor nível de confiança obtido no teste daquele comando, e um check box indicando se o comando foi ou não aceito (para um comando ser aceito o melhor nível de confiança obtido deve ser maior ou igual ao nível de confiança informado pelo usuário no formulário de composição de grupo de comandos de voz). Quando todos os comandos de voz são aceitos a aplicação exibe uma mensagem de sucesso ao usuário e retorna ao formulário de composição. Ao pressionar o botão para iniciar o teste dos comandos a aplicação automaticamente entra em modo Speech, mas a frase da barra indica que também podem ser ditos todos os comandos de voz exibidos na grade. A Figura 28 ilustra o grupo de comando de voz exibido na Figura 27 sendo testado.

59 62 Figura 28. Formulário Test Voice Command Group Editar uma pose ou um comando de voz Quando o usuário pressiona a tile para editar um grupo de comando de voz ou editar uma pose a aplicação exibe um diálogo para o usuário informar o arquivo XML que contém a entrada que será editada, em ambos os casos, após a confirmação do arquivo, a aplicação direciona o usuário para o formulário de composição de poses (vide item ) ou composição de grupo de comandos de voz (vide item ), dependendo do arquivo.

60 Documentação Ao pressionar a tile Documentation, é exibida ao usuário a documentação de todas as DLLs que podem ser utilizadas pelo desenvolvedor em seu projeto, para facilitar o uso, a documentação do projeto segue o padrão de documentação da MSDN Contatar Desenvolvedor A tile Contact Me direciona o usuário para a página do Facebook do autor da aplicação (Gabriel Schade Cardoso), esta tile também informa um para contato Documentação e Requisitos da Aplicação Para maiores detalhes referentes à documentação e requisitos gerados durante a etapa de projeto verificar APÊNDICE C Arquivo de grupos de comandos de voz A Figura 29 ilustra a hierarquia do arquivo XML gerado para o registro de um grupo de comandos de voz. Figura 29. Estrutura do arquivo XML de um grupo de comandos de voz. O arquivo de um grupo de comandos de voz será do tipo XML e deve conter as informações suficientes para que seja possível mapear os grupos a partir da DLL KinectScan. Um arquivo deste tipo pode ser visualizado no APÊNDICE B, Figura 41.

61 64 O Quadro 8 mostra os atributos de uma tag do tipo Voice_Commands, estes atributos armazenam as informações necessárias para identificar as propriedades referentes aos grupos de comandos de voz. Atributo Tipo Legenda Ocorrência Name String Identifica o nome do grupo de comandos de 1 voz Confidence Double Identifica o nível de confiança mínimo para 1 Level que uma das palavras da lista seja reconhecida Commands Tag Commands Tag referente aos comandos de voz N Quadro 5. Atributos da tag Voice Commands O Quadro 8 mostra os atributos de uma tag do tipo Command, estes atributos armazenam as informações necessárias para identificar cada comando de voz dentro de um grupo de comandos de voz. Atributo Tipo Legenda Ocorrência Command String Identifica o comando de voz 1 Quadro 6. Atributos da tag Commands Arquivo de pose Para o arquivo de pose devem ser armazenados, tanto os dados da pose quanto os dados do esqueleto do usuário, para que posteriormente este arquivo possa ser editado através da aplicação de registro de entradas. A Figura 30 ilustra a hierarquia do arquivo XML gerado para o registro de uma pose.

62 65 Figura 30. Estrutura do arquivo XML de pose. O arquivo de poses também é do tipo XML e contém as informações necessárias para que seja possível mapear a pose a partir da DLL KinectScan. Este arquivo pode ser visualizado no APÊNDICE B, Figura 42.

63 66 Abaixo segue os quadros para descrever os atributos de cada tipo de tag, o tipo do atributo, a legenda e o número de vezes que o atributo aparece na tag. O Quadro 7 mostra os atributos de uma tag do tipo Pose que é a tag principal do arquivo, estes atributos armazenam as informações necessárias para que seja possível avaliar se a pose do usuário em tempo de execução é igual a pose armazenada no arquivo. Atributo Tipo Legenda Ocorrência Name String Nome da Pose 1 Waiting_Time Int Tempo de espera em frames para 1 ativar a pose User_Skeleton Tag User_Skeleton Tag que armazena a posição de 1 cada uma das articulações do usuário SubPoses Tag SubPoses Tag que armazena o conjunto de subposes 1 Quadro 7. Atributos da tag Pose A tag User_Skeleton possui como atributo um conjunto de vinte tags do tipo Joint, ou seja, esta tag armazena todas as articulações mapeáveis do esqueleto do usuário e suas posições nos eixos X, Y e Z. O Quadro 8 exibe os atributos da tag Joint. Atributo Tipo Legenda Ocorrência ID Int Identifica qual a articulação do esqueleto esta tag se 1 refere. X Double Posição no eixo X 1 Y Double Posição no eixo Y 1 Z Double Posição no eixo Z 1 Quadro 8. Atributos da tag Joint A tag SubPoses possui como atributo um conjunto de N tags do tipo subpose, onde N é o número de subposes que o usuário da aplicação selecionou para dar significado para a pose. O Quadro 9 mostra os atributos de uma tag do tipo Subpose, estes atributos armazenam as informações necessárias para identificar cada subpose para reconhecimento posterior.

64 67 Atributo Tipo Legenda Ocorrência Angle_Error_Margin Double Indica qual a margem de erro permitida para 1 o ângulo ser aceito Auxiliary_Joint_1 Tag Joint Tag para identificação da articulação auxiliar 1 um Center_Joint Tag Joint Tag para identificação da articulação central 1 Auxiliary_Joint_2 Tag Joint Tag para identificação da articulação auxiliar 1 dois Angle Tag Angle Tag para armazenar os resultados dos cálculos dos ângulos Quadro 9. Atributos da tag SubPose Por fim, o Quadro 10 exibe os atributos da tag Angle, onde são armazenados os resultados dos cálculos, tanto por produto escalar quanto por lei dos cossenos, o resultado do cálculo da lei dos cossenos é composto por três valores, um em cada plano de projeção, esta separação também é feita no arquivo XML, o Quadro 11 exibe os atributos da tag Law_Of_Cosines_Result. Atributo Tipo Legenda Ocorrência Scalar_Product_Result Double Indica o resultado do 1 cálculo do produto escalar feito através das articulações que compõe a subpose Law_Of_Cosines_Result Tag Law_Of_Cosines_Result Tag para armazenar os valores do resultado do cálculo do produto escalar em cadaplano de projeção 1 Quadro 10. Atributos da tag Angle Atributo Tipo Legenda Ocorrência Plan XY Double Indica o resultado do cálculo da lei dos 1 cossenos sobre o plano de projeção XY Plan XZ Double Indica o resultado do cálculo da lei dos 1 cossenos sobre o plano de projeção XZ Plan YZ Double Indica o resultado do cálculo da lei dos cossenos sobre o plano de projeção YZ 1 Quadro 11. Atributos da tag Law_Of_Cosines_Result

65 KinectScan A DLL KinectScan efetua a interação diretamente com o dispositivo Kinect através de seu SDK. A aplicação cliente criada pelo desenvolvedor deve interagir com esta DLL, pois ela que possui a responsabilidade de efetuar a varredura do usuário durante a execução da aplicação final que visa ter o Kinect como interface. Apesar do SDK do Kinect permitir múltiplos sensores, a KinectScan possui a limitação de somente um sensor Kinect na aplicação. Então para garantir que haja somente uma instância de um objeto KinectScanner (principal classe da KinectScan) esta classe segue o padrão de projeto Singleton. Esta DLL funciona seguindo a filosofia dispatcher-listener. Com isto é possível criar uma comunicação fracamente acoplada entre um disparador de eventos e um ouvinte. A KinectScan possui um conjunto de eventos para que a aplicação cliente interaja com o sensor. Cada evento pode ser assinado de forma independente, ou seja, esta DLL só executará o processamento necessário para disparar os eventos assinados pela aplicação cliente. Os objetos referentes a eventos fornecidos pela DLL são: Imagem da câmera RGB; Informações do esqueleto do usuário; Detecção de gestos pré-definidos na DLL; Detecção de poses gravadas na aplicação para registro de entradas; Detecção de comandos de voz gravados na aplicação para registro de entradas; Alteração do estado do sensor; Alteração do estado de algum outro evento. O evento de imagem de câmera RGB simplesmente repassa o vetor de bytes correspondente a imagem, quadro por quadro, o que quer dizer que evento será disparado a cada quadro do Kinect (cerca de 30 quadros por segundo). No evento que retorna as informações do esqueleto do usuário existe uma conversão de tipos, partindo das premissas que esta DLL visa evitar a comunicação entre o SDK do Kinect e a aplicação final. O esqueleto do usuário é representado pela classe Skeleton presente no namespace do SDK do Kinect e é necessário convertê-la para um tipo que represente o esqueleto do usuário no namespace da biblioteca.

66 69 O evento de detecção de gestos não é customizável como os eventos de detecção de poses e comandos de voz. A KinectScan atualmente reconhece somente os gestos de Swipe para a direita e/ou para a esquerda. O gesto conhecido como Swipe significa mover a mão para alguma direção em um espaço de tempo, um movimento similar ao que é feito na maioria dos smartphones com o dedo para desbloquear a tela. Caso a aplicação assine este evento, toda vez que este gesto é detectado pela KinectScan um evento é disparado contendo a informação referente a direção do gesto que foi reconhecido. Para esta funcionalidade foi utilizado uma biblioteca de terceiros conhecida como KinectToolBox (KINECTTOOLBOX, 2012). O evento de reconhecimento de poses feito pela KinectScan rastreia o esqueleto do usuário em tempo de execução e compara com os arquivos previamente gravados pela aplicação de registro de entradas. Para comparação das poses gravadas com o esqueleto atual do usuário, esta DLL compara os ângulos de cada subpose, que são calculados através do produto escalar. O cálculo do ângulo pela lei dos cossenos utilizando a projeção ortogonal paralela nos planos XY, XZ e YZ também foi implementado, mas por possuir um custo computacional maior, foi selecionado o cálculo do produto escalar, conforme resultados apresentados na seção Quando o evento de reconhecimento de poses é ligado, a KinectScan abre todos os arquivos gravados pela aplicação de registro de entradas (os arquivos devem estar no mesmo diretório e este diretório deve ser informado pelo usuário) e inicia uma coleção de objetos do tipo Pose. A cada quadro do esqueleto do usuário, a KinectScan efetua uma comparação das poses com a posição atual do usuário. Este procedimento de comparação possui três comportamentos dependendo do estado atual da coleção de objetos de pose. Cada objeto deste tipo possui a propriedade status, que é utilizada nesta comparação. Caso todas as poses estejam com o status igual a not_started, ou seja, não iniciada, a KinectScan efetua uma busca em toda a coleção de poses para verificar se alguma pose pode ser reconhecida de acordo com o esqueleto atual do usuário. Caso alguma possa ser reconhecida, a DLL atualiza a propriedade status para in_progress. Caso alguma das poses possua o status in_progress a DLL verifica apenas se a pose com este estado pode ser reconhecida de acordo com o atual esqueleto do usuário. Caso seja,

67 70 a DLL efetua uma contagem de quantos quadros esta pose está marcada com este estado e, quando esta contagem alcança o tempo definido na propriedade WaitingTime o status da pose é marcado como accepted sendo gerado um evento de reconhecimento de pose, notificando que esta pose foi reconhecida. Caso a pose não seja mais reconhecida o contador é zerado e o status retorna para not_started. Caso alguma das poses possua o status accepted a DLL verifica apenas se a pose com este estado ainda é reconhecida de acordo com o atual esqueleto do usuário, caso a pose ainda seja reconhecida a DLL não efetua nenhuma operação. Caso não seja reconhecida, a DLL gera um novo evento notificando que esta pose foi interrompida e reinicia o status dela para not_started. O evento de reconhecimento de comando de voz inicia o serviço de comando de voz do Kinect através do SDK passando como parâmetro para comandos aceitáveis, todos os comandos de voz contidos nos arquivos. A classe principal que efetua a comunicação com o Kinect se chama KinectScanner. Esta classe conta com uma coleção de objetos do tipo KinectSpeechScanner, onde cada objeto se encarrega de verificar o reconhecimento de um grupo de comandos de voz. Estes SpeechScanners podem ser ativados e desativados livremente através de métodos fornecidos pela KinectScan. Cada vez que um comando de voz é dito, é verificado se o scanner do comando que foi dito está ativo e se o nível de confiança do comando foi maior do que o nível de confiança mínimo do grupo; caso estas condições sejam cumpridas é gerado um evento de comando de voz pela KinectScan. O evento de alteração do estado do sensor é disparado sempre que o estado do sensor Kinect é alterado, ou seja, caso ele seja desconectado do computador, desconectado da energia ou alterado seu estado para qualquer outro. O evento gerado notifica o usuário em qual estado o sensor está. O funcionamento do evento de alteração de estado dos outros eventos é necessário, pois a KinectScan funciona de forma assíncrona em relação à seu listener. Quando o listener solicita a alteração de estado de um evento, há um tempo de sincronização entre a solicitação e a alteração de fato. Para permitir que o listener execute alguma operação no momento em que um evento possui o estado alterado existe este evento, que é disparado quando o evento

68 71 de fato alterou seu estado. Este evento envia as seguintes informações para o listener: evento que alterou o estado, estado anterior e novo estado. Os principais métodos fornecidos pela KinectScanner são listados no Quadro 12. Estes métodos podem alterar o estado da KinectScanner e dos eventos. Os possíveis estados dos eventos são: running, stopped e paused. Estes e os demais métodos, eventos e propriedades públicas das classes KinectScanner, KinectSpeechScanner e EventQueue podem ser visualizados no diagrama de classe mostrado na documentação do projeto no APÊNDICE D. Método Comportamento Initialize() Inicia a conexão com o sensor Kinect. StartNomeDoEvento(?) Inicia o evento descrito no nome do método (existem vários métodos de start, pois dependendo do tipo do evento ele requer parâmetros de tipos diferentes). Stop(EventType event) Para o evento referente ao valor do enumerado passado por parâmetro. Pause(EventType event) Pausa o evento referente ao valor do enumerado passado por parâmetro. Resume(EventType event) Retoma o evento referente ao valor do enumerado passado por parâmetro. Status(EventType event) Retorna o estado atual do evento referente ao valor do enumerado passado por parâmetro. Terminate() Finaliza a conexão com o sensor e para todos os eventos correntes da KinectScanner. Quadro 12. Principais métodos da KinectScanner Quando um evento é iniciado através do método Start, a KinectScan inicializa os serviços do Kinect e começa a processar as informações necessárias para o reconhecimento da pose ou comando de voz associado a este evento; quando este for detectado, o evento é enviado para a aplicação cliente. No estado de pausa, todos os serviços com o Kinect e processamento interno permanecem, porém o evento pausado não é mais adicionado na fila de eventos. Para interromper o processamento e desligar os serviços do sensor é necessário utilizar o método Stop. Além destas três classes principais a DLL KinectScan também encapsula todas as funções para comparação de poses, funções matemáticas e funções para leitura e escrita dos arquivos XML referentes às entradas customizadas.

69 KinectServer Esta aplicação, assim como a ferramenta para captura de poses também é um cliente da DLL KinectScan. A principal finalidade da KinectServer é criar uma forma de acesso remoto as funcionalidades disponíveis na KinectScan, para que dessa forma, aplicações que não suportem o framework.net 4.5 possam interagir com o sensor. A KinectServer permite ao usuário iniciar um serviço que pode ser acessado via TCP IP para interação com o Kinect, ou seja, a aplicação final pode fazer requisições por socket para o servidor interagir com o Kinect utilizando a DLL KinectScan. Por padrão, foi definido que o serviço fica no endereço IP de loopback, ou seja, (mesma máquina que está fornecendo o serviço também está consumindo) e na porta 1234, mas há uma classe que permite a configuração destas propriedades. A aplicação que consumir o serviço do KinectServer deve conectar-se através do IP e porta citados acima e oferecer um stream de conexão para que as informações possam ser compartilhadas (classe NetworkStream na plataforma.net (MSDN[2], 2012)). A Figura 31 ilustra o fluxograma de funcionamento entre uma aplicação cliente e a KinectServer. Figura 31. Fluxograma de funcionamento da KinectServer

70 73 Para a interação entre a KinectServer e a aplicação cliente trafegam pela stream de conexão compartilhada os objetos serializados (convertidos para bytes). Estes objetos variam entre: eventos (disparados da KinectServer para a aplicação cliente) e requisições (disparados da aplicação cliente para a KinectServer). Os eventos em sua maioria são os mesmos eventos disparados pela KinectScan, porém no caso da KinectServer existem alguns eventos exclusivos para que o servidor sempre entregue uma resposta para qualquer requisição. Estes eventos são: ResponseEvent e GetElevationAngleEvent. O evento ResponseEvent simplesmente retorna uma mensagem ao usuário notificando o sucesso ou a falha de alguma operação, enquanto que o GetElevationAngleEvent retorna o ângulo de elevação do sensor Kinect, quando este é solicitado. O Quadro 13 ilustra todos os tipos de objetos de requisição que a aplicação cliente pode utilizar para efetuar a comunicação com a KinectServer. Requisições ClearEventQueueRequest GetElevationAngleRequest SetElevationAngleRequest Comportamento Solicita que o servidor limpe a fila de eventos da KinectScan. Solicita que o servidor retorne o ângulo de elevação do sensor. Solicita que o servidor insira o valor enviado em uma propriedade deste objeto ao ângulo de elevação do sensor. StartNomeDoEventoRequest Existem vários objetos para iniciar os eventos da KinectScan, um para cada tipo de evento, já que alguns eventos necessitam de parâmetros para serem inicializados. Esta requisição solicita ao servidor que inicie um evento. PauseRequest ResumeRequest StopRequest StatusRequest TryGetEventRequest Quadro 13. Objetos para efetuar a requisição Solicita ao servidor que o evento enviado em uma propriedade deste objeto seja pausado. Solicita ao servidor que o evento enviado em uma propriedade deste objeto seja retomado. Solicita ao servidor que o evento enviado em uma propriedade deste objeto seja parado. Solicita ao servidor que retorne o estado do evento enviado em uma propriedade deste objeto. Solicita ao servidor que envie o primeiro objeto da fila de eventos, caso a fila esteja vazia o servidor retorna um evento de mensagem para notificar isso a aplicação cliente. Para atender estas requisições o servidor conta com um sistema multithreads, ou seja, cada requisição é tratada em sua própria thread. Sempre há uma, e somente uma thread escutando a porta definida para a conexão com o servidor (padrão 1234). Quando o servidor

71 74 recebe uma requisição, é aberta uma nova thread para esta requisição e a thread principal volta a escutar a porta de conexão novamente. Esta aplicação oferece uma interface gráfica para que seja possível iniciar e parar o servidor e visualizar as informações referentes ao sensor Kinect e a DLL KinectScan. Na interface também é possível visualizar um log do servidor, que descreve cada requisição, resposta ou evento reconhecido pelo servidor, esta interface pode ser visualizada na Figura 32. Figura 32. Interface da KinectServer A documentação do projeto da aplicação KinectServer pode ser visualizada no APÊNDICE E. 3.5 KinectEvents A KinectEvents é uma DLL que funciona em conjunto com a KinectScan. A KinectEvents possui as classes de modelo da aplicação (poses, comandos de voz, subposes, etc); as classes que representam dados do Kinect, como por exemplo, a classe que representa o esqueleto do usuário, e os enumerados e as classes de comunicação (requests para o

72 75 KinectServer e events disparados da KinectScan), enquanto que a KinectScan encapsula a conexão com o sensor e as funções referentes às operações com o sensor. As únicas funções encapsuladas nesta DLL são as funções para serializar e desserializar os objetos de comunicação, pois todo o tráfego de bytes que ocorre entre o KinectServer e seu cliente são objetos de comunicação convertidos em bytes. Caso a aplicação final seja cliente direto da KinectScan não é necessário utilizar nenhuma função de serialização, pois o objeto retornado é um Event no seu estado original. Esta aplicação também possui uma classe chamada KinectServerClient que deve ser utilizada para criar a comunicação com o servidor da aplicação KinectServer. Esta classe possui as propriedades para configurar a porta e o IP de conexão. Além disso, ela possui o método público SendRequest, que espera como parâmetro um objeto do tipo Request. Este método se encarrega de converter o objeto de Request para bytes e enviá-lo ao servidor. Para que a aplicação cliente possa obter a resposta do servidor esta classe conta com o evento ResponseFromServer, este evento é disparado toda vez que o servidor responde a uma requisição, passando por parâmetro o evento disparado pelo servidor. 3.6 KinectUnity A DLL KinectUnity tem como principal característica ser um consumidor dos eventos da DLL KinectScan, ou seja, todo o tratamento aos eventos disparados pela classe KinectScanner da DLL KinectScan serão implementados nesta DLL. A Figura 33 ilustra a comunicação entra a KinectUnity e o sensor Kinect. Figura 33. Comunicação entre a KinectUnity de entradas e o Kinect

73 76 Esta DLL faz a integração entre a ferramenta Unity e o sensor de movimento Kinect. Esta DLL possui códigos que interagem diretamente com as classes que manipulam a entrada de dados nos projetos da Unity, sobrecarregando uma classe chamada Input. A KinectInput (classe utilizada para sobrecarregar a classe Input) possui todos os métodos da classe Input e os métodos para verificar se alguma entrada (pose, gesto ou comando de voz) foi ativada pelo usuário. Quando a classe KinectInput é criada ela cria três objetos do tipo Dictionary (Hashtable). Estes dicionários utilizam uma chave contendo o nome das entradas que o usuário pode efetuar através de poses, gestos ou comandos de voz e um valor ligado a esta chave que pode variar entre verdadeiro ou falso. O método que verifica as entradas do KinectInput simplesmente verifica o valor do campo no dicionário de dados e retorna ao script do jogo se a entrada está ou não acionada, para que o script efetue o tratamento relativo à entrada. Assim como a KinectScanner esta classe também é um Singleton, não permitindo que haja mais de uma instância dela mesma na aplicação. A classe KinectInput também possui o método SendRequest que recebe um objeto do tipo Request por parâmetro, internamente o método é simplesmente repassado para a classe KinectServerClient, permitindo assim que o usuário envie uma requisição do servidor através de um script C# de um projeto na Unity. A proposta inicial desta DLL era efetuar uma comunicação entre o Kinect e a Unity através da DLL KinectScan, porém, mesmo com a Unity utilizando scripts na linguagem C#, ela não possui um compilador.net padrão da Microsoft e sim o compilador Mono, explicado anteriormente, e desta forma, existe um atraso na implementação dos recursos mais atuais disponibilizados pela Microsoft. Em sua versão 3.5.6f4(versão atual na data deste trabalho) a Unity possui este compilador na versão 2.6. Esta versão do compilador não aceita nenhuma DLL.NET que esteja ou que possua uma dependência no framework 4.0 ou superior. A DLL do Kinect é executada sobre o framework 4.0, logo, a KinectScan possui uma dependência no framework.net 4.0, o que impossibilita a conexão direta entre a KinectUnity e a KinectScan. Após perceber este problema foram pesquisadas soluções alternativas em alguns trabalhos similares: Kinect Wrapper, que utilizava o Kinect SDK em sua versão em C++ (KINECTWRAPPER, 2012) e o Kinect Daemon, onde a conexão com o Kinect era feita através de um servidor Socket (KINECTDAEMON, 2012).

74 77 Apesar de contribuírem com ideias para a solução implementada, nenhuma das soluções apresentadas nos dois projetos poderiam ser diretamente utilizadas neste trabalho, pois eles fazem conexão diretamente com o Kinect e a Unity e a proposta do trabalho era conectar a Unity ao Kinect através da KinectScan. A primeira tentativa de solução para a dependência do.net 4.0 foi seguir o exemplo da Kinect Wrapper, visto que baseado nas pesquisas iniciais ela parecia oferecer melhores resultados, já que não dependia de uma segunda aplicação executando (serviço). Foi escrito uma nova versão da KinectScan em C++, porém o funcionamento interno das threads na KinectScan utilizava DLLs no namespace do Windows (classe Dispatcher) e estas DLLs não podem ser utilizadas no compilador Mono, o que impossibilitou a adoção desta solução. Então, uma segunda implementação baseada na ideia de serviço apresentada no trabalho KinectDaemon, foi criada a aplicação KinectServer e a classe KinectServerClient, permitindo desta forma que a KinectUnity se conecte à KinectScan através da aplicação servidor. 3.7 Projeto feito na Unity modificado O projeto feito na Unity selecionado para efetuar a modificação de sua interface foi baixado através da AssetStore (loja disponível dentro da ferramenta Unity). Este projeto (5 Unity games examples: C#) é um exemplo de cinco jogos que utilizam scripts na linguagem C#. Para alteração da interface, foi selecionado o jogo Jump Game. Para que este jogo pudesse ter sua interface alterada, do teclado para o Kinect, foi necessário criar uma pasta chamada Plugins, dentro desta pasta é necessário importar as DLLs KinectEvents e KinectUnity. Após a importação das DLLs foi possível instanciar um objeto da classe KinectInput via script e interagir com a aplicação de servidor KinectServer. É necessário também que a aplicação KinectServer esteja sendo executada, visto que é através dela que ocorre a comunicação entre o jogo e o Kinect. O jogo Jump Game trata-se de um jogo plataforma em 2D, onde o personagem fica constantemente pulando e são sorteados os locais de várias plataformas, o dever do jogador é saltar entre estas plataformas e não deixar o personagem cair delas.

75 78 Após sair do chão o personagem não pode mais cair das plataformas. Inicialmente o personagem utilizava as setas no teclado para se movimentar, após a adaptação da interface utilizando a biblioteca criada neste projeto, o usuário deve posicionar-se na frente do Kinect e executar as poses que foram introduzidas ao jogo ou os comandos de voz: Right e Left tanto as poses quanto os comandos de voz são utilizados para movimentar o personagem para as direções direita ou esquerda. A Figura 34 ilustra as poses que são aceitas no jogo (lembrando que a imagem que é obtida da câmera do Kinect é invertida entre direita e esquerda como um espelho). Figura 34. Poses aceitas no jogo A pontuação do jogador é acumulada pela altura máxima que o usuário conseguiu chegar com o personagem. A Figura 35 ilustra a imagem do jogo sendo executado.

76 79 Figura 35. Jogo em execução 3.8 Restrições O projeto possui algumas restrições descritas na lista abaixo devido à inviabilidade de de implementação no tempo estabelecido e ao escopo do trabalho: Não foi implementado nenhum algoritmo para detecção de gestos (foi utilizado um projeto de terceiros); Não foi implementado nenhum algoritmo para reconhecimento de voz, mas foi utilizado o disponibilizado pela Microsoft; Não foi implementado o reconhecimento de voz em nenhum outro idioma além do padrão (inglês Estados Unidos); O algoritmo para detecção de pose foi feito no mínimo com três articulações; Os problemas com detecção do esqueleto do Kinect, como por exemplo, luz ou falta de espaço não foram considerados.

77 80 4 CONCLUSÕES Neste capítulo estão descritos os resultados obtidos após a implementação e testes deste projeto, sugestões para trabalhos futuros, cumprimento dos objetivos e conclusões que podem ser obtidas após a realização deste projeto. 4.1 Objetivos Todos os objetivos específicos listados na seção foram cumpridos ao longo do desenvolvimento deste projeto. Todos os estudos e pesquisas podem ser visualizados na seção FUNDAMENTAÇÃO TEÓRICA, onde constam especificações sobre o Kinect, a Unity, as formas para comparação de pose e sobre o Microsoft Kinect SDK. A implementação e utilização da biblioteca pode ser visualizada na seção Desenvolvimento, onde é exibida de forma descritiva e através de figuras desde a criação até a utilização da biblioteca. Todos os resultados dos testes de acordo com os requisitos propostos podem ser visualizados na seção seguinte (Resultados). O objetivo geral (vide seção ) mostra-se cumprido ao longo deste projeto, visto que ao final da implementação e após algumas adaptações foi possível integrar a biblioteca criada com um projeto na ferramenta Unity. 4.2 Resultados Nesta subseção são descritos os resultados obtidos através de testes e análises, bem como as conclusões que se pode tirar a partir dos mesmos Algoritmos para cálculo do ângulo Os dois algoritmos para detecção de poses foram analisados no que diz respeito a sua performance em tempo de resposta. Foram implementados e avaliados os algoritmos para cálculo de ângulo através do produto escalar e através da lei dos cossenos, descritos na seção 3.1

78 81 O experimento utilizado para tal avaliação entre os dois algoritmos de cálculos para detecção de pose consiste em um teste de repetição onde eram cálculados várias vezes os ângulos de um conjunto de subposes. Estes testes foram medidos por tempo na unidade milisegundos e foi extraido uma amostragem de 101 testes. Houve o descarte da primeira rodada de teste, pois na primeira execução os objetos são alocados em memória influenciando no tempo final, o que torna o primeiro teste sempre mais lento que os demais. Os quadros 14, 15 e 16 ilustram o resultado extraido desta avaliação. Avaliação por tempo Lei dos Cossenos Produto Escalar Mais rápido: 3, ms < 0 ms Mais lento: 3,6014 ms < 0 ms Média: 3, ms < 0 ms Total: 358,0317 ms < 0 ms Quadro 14. Detecção de uma pose com 1 subpose Avaliação por tempo Lei dos Cossenos Produto Escalar Mais rápido: 15,4671 ms < 0 ms Mais lento: 15,686 ms 1,3028 ms Média: 15,60167 ms 0, ms Total: 1560,167 ms 7,3018 ms Quadro 15. Detecção de uma pose com 10 subposes Avaliação por tempo Lei dos Cossenos Produto Escalar Mais rápido: 15,5461 ms < 0 ms Mais lento: 31,2006 ms 15,6545 ms Média: 15,7582 ms 0, ms Total: 1575,82 ms 31,2154 ms Quadro 16. Detecção de uma pose com 20 subposes

79 82 Com o resultado destes testes é possível visualizar que o cálculo de ângulos através do produto escalar se mostra mais eficiente independente do número de subposes. Portanto, a DLL KinectScan passou a utilizar apenas o cálculo de ângulos através do algoritmo produto escalar. O gráfico na Figura 36 ilustra a comparação entre os algortimos testados utilizando o tempo médio. Figura 36. Gráfico de comparação entre os algoritmos para cálculo de ângulos Complexidade de utilização da biblioteca proposta Ao longo da implementação do projeto ocorreu um problema de compatibilidade entre o compilador Mono e o SDK proposto pela Microsoft, para mitigar este problema foi desenvolvida a aplicação KinectServer (vide seção 3.4) e a classe KinectServerClient. Através destas duas implementações a integração entre o hardware Kinect e a ferramenta Unity se mostrou bem sucedida. Como exemplo de funcionamento este projeto apresenta as duas formas de conexão com o sensor Kinect: a primeira através da utilização direta da KinectScan (demonstrada na aplicação para registro de entrada) e a segunda através da utilização do KinectServerClient (implementado na KinectUnity).

80 83 Todos os eventos possíveis disparados pela KinectScan são exemplificados neste projeto na ferramenta para registro de entradas (vide seção 3.2), exceto a detecção de gestos. O projeto alterado na Unity (vide seção 3.7) também exemplifica a detecção de poses e comandos de voz a partir de arquivos XML via scripts. Para exemplificar as diferentes formas de utilização do sensor Kinect e a facilidade de interação com o mesmo através da biblioteca proposta, a Figura 37, Figura 38 e a Figura 39 mostram as linhas de código necessárias para integrar uma aplicação ao Kinect. Figura 37. Criando uma conexão com o sensor via KinectScan

81 84 Figura 38. Criando uma conexão com o sensor via KinectServerClient Figura 39. Criando uma conexão com o sensor via KinectUnity através de scripts na Unity

82 85 Em todos os exemplos é possível estabeler a comunicação com o sensor e assinar eventos em menos de dez linhas, o que mostra o sucesso quanto facilidade de utilização do sensor com a biblioteca proposta. Para um auxílio sobre a forma de se utilizar as DLLs, o projeto também oferece a documentação das DLLs que podem ser utilizadas pelo desenvolvedor (vide APÊNDICE C). 4.3 Trabalhos Futuros Durante o desenvolvimento deste trabalho foram identificadas algumas funcionalidades interessantes de serem incorporadas ao projeto, que ficam como sugestões para trabalhos futuros. A remoção da limitação de um único sensor ligado a KinectScan pode prover um mecanismo interessante para certos tipos de aplicações, como por exemplo, aplicações que visam efetuar um mapeamento 3D de locais ou objetos, ou para aplicações que necessitam de mais usuários. Para efetuar isso deve-se pensar em uma forma de gerenciamento dos sensores através do Id de cada sensor e utilizar uma coleção de objetos do tipo KinectScanner ao invés de apenas uma instância. A remoção da limitação de um cliente para o KinectServer também pode ter um resultado interessante, algo similar a um broadcast entre várias aplicações executando em paralelo conectadas ao servidor. Apesar de possuir o reconhecimento para gestos, a KinectScan provê apenas o reconhecimento do gesto swipe para as duas direções. Incluir um catálogo maior de gestos, ou criar um mecanismo de customização de gestos pode gerar grandes avanços neste trabalho, visto que gestos assim como poses e comandos de voz são uma forma de interação bastante natural ao usuário. Uma extensão de idiomas para reconhecimento de fala pode ser uma nova funcionalidade interessante, permitindo uma interação mais natural, já que o usuário não precisaria falar somente em inglês. E por fim, a própria utilização do sensor para aplicações fora da solução proposta na área de jogos pode demonstrar mais ainda os resultados positivos da NUI dentro da computação.

83 Considerações Finais Da maneira com que foi projetado o desenvolvimento da biblioteca será possível integrá-la com qualquer tipo de aplicação que aceite o uso dos recursos do Kinect como forma de interface, o que amplia o alcance do uso da biblioteca proposta. Ao decorrer das pesquisas e análises também foi notado que o reconhecimento de gestos genéricos não tem uma implementação trivial e nem genérica. Após alguns estudos mais aprofundados foi concluído que a implementação de reconhecimento de gestos genéricos fugiria do escopo de complexidade inerentes ao TTC e portanto esta característica não será agregada à biblioteca. Optou-se por incluir no projeto além dos reconhecimentos de entradas customizadas (poses e comandos de voz) mais funcionalidades do Kinect (vide seção 3.3). Desta forma, além de customizar diferentes tipos de entradas também é possível utilizar recursos do Kinect, como por exemplo a câmera RGB. A implementação deste projeto foi desafiadora e inovadora. O trabalho proposto não somente criou uma conectividade do Kinect com uma aplicação ou um jogo específico, como ofereceu uma integração que busca ser a mais genérica e flexível possível para tornar o desenvolvimento com o Kinect mais simples e rápido. Com a ferramenta proposta os desenvolvedores de aplicações e jogos podem migrar para esta interface de forma mais simples, sem exigir conhecimento aprofundado no desenvolvimento focado para o hardware Kinect. Foram seguidas as específicações propostas no capítulo Desenvolvimento e houve um bom gerenciamento das mudanças ao longo do desenvolvimento, o que fez com que este projeto alcansasse todos os seus objetivos, conforme descrito na seção 4.1.

84 87 REFERÊNCIAS ALBITAR, Chadi; GRAEBLING, Pierre; DOIGNOM, Christophe. Robust Structured Light Coding for 3D Reconstruction Disponível em: < Acessado em 26 abr ASHLEY, James; WEBB, Jarret. Beginning Kinect Programming with the Microsoft Kinect SDK. 1. ed. Apress BESSA, Aline; SOUSA, Caio T.; BEZERRA, Carlos E.; MONTEIRO, Ivan; BANDEIRA, Humberto; SOUZA, Rodrigo. O Desenvolvimento de um Motor Multiplataforma para Jogos 3D. Disponível em:< > BLAKE, Andrew; KIPMAN, Alex; MOORE, Richard; FINOCCHIO, Mark; SHARP, Toby; COOK, Mat; FITZGIBBON Andrew; SHOTTON Jamie. Real-Time Human Pose Recognition in Parts from Single Depth Images. Disponível em: < Acessado em 26 abr BLAKE, Andrew; KIPMAN, Alex; MOORE, Richard; FINOCCHIO, Mark; SHARP, Toby; COOK, Mat; FITZGIBBON Andrew; SHOTTON Jamie. Real-Time Human Pose Recognition in Parts from Single Depth Images: Supplementary Material Disponível em: < Acessado em 26 abr BUXTON, Bill. Gesture Based Interaction. Disponível em: < Acessado em 10 jun COMPUTERHOPE. Command Line VS GUI Disponível em: < Acessado em 28 abr FOLEY, James D.; DAM, Andries van; FEINER, Steven K.; HUGHES, Jhon F. Computer Graphics: Principles and Practice. 2. ed. Boston: Addison-Wesley, GREGORY, Jason. Game engine architecture. 1. Ed. New York: A K Peters/CRC Press, 2009.

85 88 INFOWESTER. Microsoft lança Kinect para Windows Disponível em: < Acessado em 15 mar KEAN, Sean; HALL, Jonathan; PERRY, Phoenix. Meet the Kinect. 1. ed. Apress KINECT. Apresentando o Kinect Disponível em: < BR/kinect>. Acessado em 15 mar KINECTWRAPPER. Microsoft Kinect Bringing the Kinect SDK in to Unity Disponível em: < _Microsoft_SDK>. Acessado em 20 set KINECTDAEMON. Unity3d and Microsoft Kinect SDK Disponível em: < seethroughskin.com/blog/?p=1159>. Acessado 22 de set KINECTTOOLBOX. Kinect Toolbox Disponível em:< Acessado em 18 set KINECTSDK. Kinect for Windows Disponível em:< Acessado em 15 mar KINECTAUDIO. Kinect Audio: Preparedness Pays Off Disponível em: < Acessado em 25 abr KINECTVIDEOAUDIO. Audio and Video Research in Kinect Disponível em: < Acessado em 25 abr LEADBETTER, Richard. PrimeSense: Além do Natal Disponível em: < Acessado 26/04/2012 MENDES, Cláudio Lúcio. Jogos Eletrônicos: diversão, poder e subjetivação 1. ed. Campinas: Papirus, 2006.

86 89 MICROSOFT. Kinect for Windows Disponível em:< Acessado em: 10 mar MONO. Mono Project Disponível em:< Acessado em: 22 out MONOCOMPATIBILITY. Mono Compatibility. Disponível em:< Acessado em: 22 out MSDN. Microsoft.Kinect Disponível em:< Acessado em: 24 abr MSDN[2]. NetworkStream Class Disponível em:< Acessado em: 20 set OLIVEIRA NETTO, Alvin Antônio de Oliveira. IHC: Interação Humano Computador - Modelagem e Gerência de Interfaces com o Usuário. 1. ed. Florianópolis: VisualBooks, OPENNI. OpenNI Disponível em:< Acessado em: 10 mar PREECE, Jenny; ROGERS, Yvonne; SHARP, Helen; BENYON, David; HOLLAND, Simon; CAREY, Tom. Human-Computer Interaction. 1. ed. Nova Jersey: Addison-Wesley, PRIMESENSE. Natural Interaction Disponível em:< >. Acessado em 26 abri SANTOS, Rafael. Desenvolvimento de games no Brasil Vale a Pena? Disponível em: < Acessado em 15 mar SHNEIDERMAN, Ben. Designing the User Interface: Strategies for Effective Human- Computer Interaction. 3. ed. Nova Jersey: Addison Wesley, TECMUNDO. O que é engine ou motor gráfico? Disponível em:< Acessado em: 15 mar. 2012

87 90 UNITY. Site do fabricante Disponível em: < >. Acesso em: 09 mar UNITY3DBRASIL. Fórum brasileiro Disponível em:< Acessado em: 10 mar VISUALSTUDIO. Visual Studio Disponível em: < >. Acessado em: 10 mar VALE, Felique Roque do. Jogos de Computador e Sistemas Emergentes Disponível em:< Acessado em 16 maio WINOGRAD, Terry. Bringing Design to Software Disponível em: < Acessado em 21 abr

88 91 GLOSSÁRIO SDK Socket Dispatcher Listener Motor de Jogos Um software development kit (SDK), nada mais é do que uma coleção de funções pré-desenvolvidas que um desenvolvedor pode utilizar na criação de sua aplicação, como por exemplo, o SDK do Kinect, que fornece métodos para acessar o periférico em linguagem de alto nível Portas virtuais para a conexão de programas em um computador via um protocolo de rede. Programa que despacha eventos para outros programas. Programa que escuta os eventos de um programa dispatcher. Programa utilizado para criação de jogos que fornece várias funcionalidades aos desenvolvedores e designers.

89 92 APÊNDICE A. FUNCIONAMENTO ENTRE AS THREADS DA KINECTSCAN E SEU LISTENER A interação da KinectScan (dispatcher) com seu listener ocorre principalmente a partir da classe KinectScanner. Quando a propriedade Instance da classe KinectScanner é acessada pela primeira vez o objeto é criado, nas demais vezes o objeto é apenas repassado, utilizando a mesma instância. Quando este objeto é criado ele executa um método de processamento em um thread paralela à thread da aplicação, este método fica varrendo constantemente a lista de eventos verificando se algum evento dentre os fornecidos teve seu estado alterado, caso sim, são executadas as operações necessárias para cumprir o que foi solicitado. Todo o processamento quando o evento está sendo executado e quando um evento é disparado ocorre nesta thread de processamento. Desta forma a thread em que a KinectScanner executa a comunicação com o Kinect é separada da thread da aplicação final. Então para comunicação entre a aplicação final e a thread da KinectScanner existe um objeto chamado EventQueue (fila de eventos). Este objeto está agregado a classe KinectScanner e é inicializado juntamente com a própria KinectScanner (antes da KinectScanner entrar no método de processamento). Este objeto é inicializado na thread da aplicação cliente e em seu próprio construtor este objeto armazena a thread da aplicação cliente em um objeto do tipo Dispatcher, este tipo de objeto é fornecido na DLL WindowsBase, do framework.net e é utilizado para despachar métodos para uma outra thread paralela a que este objeto está sendo usado. Cada vez que um evento é gerado ele é adicionado nesta fila de eventos, o listener desta DLL pode consumir estes eventos através do método GetEvent() na classe EventQueue. Caso o listener deseje também é possível interpretar o evento EventAdded, este evento notifica a aplicação sempre que um novo objeto de evento é adicionado no objeto EventQueue. A Figura 40 ilustra a comunicação entre as threads da aplicação e a thread de processamento da KinectScan.

90 Figura 40. Comunicação das threads da aplicação cliente e da KinectScan 93

91 94 APÊNDICE B. EXEMPLO DE ARQUIVOS XML DE ENTRADAS A Figura 41 e a Figura 42 ilustram os arquivos XML de grupo de comandos de voz e de pose respectivamente. Figura 41. Arquivo XML de um grupo de comandos de voz

92 Figura 42. Arquivo XML de uma pose 95

93 96 APÊNDICE C. PROJETO DA FERRAMENTA PARA REGISTRAR ENTRADAS Este apêndice lista os requisitos funcionais, não funcionais, regras de negócio, casos de uso e seus respectivos cenários, ou seja, toda a documentação relacionada ao projeto da ferramenta para registrar entradas. C.1. Requisitos Abaixo segue a lista com os requisitos funcionais relacionados à ferramenta para registrar entradas: RF01 Esta aplicação deve reconhecer o esqueleto do usuário; RF02 Esta aplicação deve permitir ao usuário criar uma pose; RF03 Esta aplicação deve permitir ao usuário criar um conjunto de subposes dentro de uma pose; RF04 Esta aplicação deve permitir ao usuário criar um conjunto de comandos de voz; RF05 Esta aplicação deve gerar um arquivo XML para que seja possível armazenar as informações necessárias para o reconhecimento de uma pose ou comando de voz; RF06 Esta aplicação deve permitir ao usuário efetuar o teste de sua pose e calibre o grau de tolerância de erro; RF07 Esta aplicação deve permitir ao usuário efetuar testes em seus comandos de voz para que calibre seu grau de confiança. Abaixo segue a lista com os requisitos não funcionais: RNF01 O framework desenvolvido deve ser flexível para a facilidade da migração de uma interface padrão de uma aplicação para a interface do Kinect;

94 97 RNF02 Esta aplicação deve ser desenvolvida de forma que seja possível interagir com comandos de voz para criar uma pose; RNF03 Esta aplicação deve utilizar a câmera RGB e o reconhecimento de esqueletos do Kinect. Abaixo segue a lista com as regras de negócio: RN01 O formulário Compose Pose só deve ser habilitado após a criação de uma pose; RN02 Uma pose deve ser formada por uma ou mais subposes; RN03 Uma subpose deve ser formada por três articulações.

95 98 C.2. Casos de Uso e Cenários Segue os casos de uso e seus respectivos cenários para a aplicação que registra e gera os arquivos XML referente às entradas. A Figura 43 ilustra os quatro casos de uso principais desta aplicação e suas dependências. Figura 43. Casos de uso para ferramenta de criação de poses Cenário do caso de uso UC01 Criar uma pose Cenário principal 1. O usuário entra na tile Create a New Pose 2. O usuário digita no formulário Record Pose os campos obrigatórios: Name e Waiting Time ; 3. O usuário fica em frente ao Kinect, fica na pose em que deseja gravar e diz a frase Record Pose em voz alta; 4. A aplicação deve jogar a imagem do esqueleto do usuário para o painel ao lado da câmera RGB.

96 99 Cenário do caso de uso UC02 Criar a composição de subposes dentro de uma pose Pré-condição 1. O usuário deve executar os processos descritos no caso de uso anterior ( UC01 Criar uma pose ) e entrado no formulário para compor um pose; Cenário principal 1. O usuário deve digitar o valor da margem de erro do ângulo da subpose no campo Error Margin, após isso pressionar o botão Add cujo ícone é o sinal de soma; 2. A aplicação deve alterar o ícone e a descrição do botão Add para a descriçao Cancel e para o ícone de pausar ( ); 3. O usuário deve pressionar as três articulações que compões a subpose (cada joint pressionado possui a cor alterada para branco para que a aplicação não permita adicionar duas vezes a mesma articulação); 4. A aplicação deve pintar novamente o esqueleto da cor padrão e inserir um registro de subpose na grade da direita. Cenário alternativo No passo 1 caso o usuário não digite o valor da margem de erro do ângulo a aplicação exibirá uma mensagem de notificação e não permitirá proceguir. No passo 3 o usuário pode pressionar o botão Cancel que substituiu o botão Add O usuário deve clicar no botão Cancel cujo ícone é o caractere X ; 3.2. A aplicação deve pintar novamente o esqueleto da cor padrão. Cenário de exceção Caso o usuário não tenha registrado nenhuma pose o sistema não permitirá ao usuário entrar na aba Compose. Cenário do caso de uso UC03 Testar uma pose Pré-condição 1. O usuário deve executar os processos descritos nos casos de uso anteriores ( UC01 Criar uma pose e UC02 Criar a composição de subposes dentro de uma pose ) e após isso o usuário deve ter entrado no formulário para testar uma pose; Cenário principal 1. O usuário deve se posicionar de frente ao Kinect;

97 O sistema deve exibir as informações referentes a pose a ser testada e a pose atual do usuário, exibindo os valores dos ângulos; 3. O usuário deve efetuar a pose que deseja testar; 4. O sistema deve exibir a mensagem de feedback para identificar se a pose foi ou não reconhecida. Cenário do caso de uso UC04 Criar um arquivo XML de uma pose Pré-condição 1. O usuário deve executar os processos descritos nos casos de uso anteriores ( UC01 Criar uma pose e UC02 Criar a composição de subposes dentro de uma pose ); Cenário principal 1. A aplicação possuir uma configuração para o usuário selecionar o diretório em que o arquivo será gravado; 2. O usuário deve selecionar o diretório; 3. O usuário deve pressionar o botão Save cujo ícone é um disquete. 4. A aplicação deve gerar um arquivo XML no formato descrito no projeto (Arquivo de pose) conforme as informações do usuário. Cenário de exceção Após o passo 3 a aplicação deve validar os campos obrigatórios: Name e Waiting Time da aba Record e também deve ser verificado se há uma ou mais subposes adicionadas, caso estas validações não sejam cumpridas deve ser exibida uma mensagem ao usuário notificando o que falta ser preenchido. Caso o usuário não selecione um diretório válido a aplicação deve exibir uma mensagem notificando que o diretório é inválido. Cenário do caso de uso UC05 Criar Comandos de Voz Cenário principal 1. O usuário deve entrar na tile Create a New Voice Command ; 2. O usuário deve preencher os campos: Group Name e Confidence Level ; 3. O usuário deve preencher o campo Command e pressiona o botão Add cujo ícone é o sinal de soma; 4. A aplicação possuir uma configuração para o usuário selecionar o diretório em que o arquivo será gravado; 5. O usuário deve selecionar o diretório; 6. O usuário pressiona o botão Save cujo ícone é um disquete. 5. A aplicação deve gerar um arquivo XML no formato descrito no projeto (Arquivo de grupos de comandos de voz) conforme as informações do usuário.

98 101 Cenário de exceção Após o passo 6 a aplicação deve validar os campos obrigatórios: Group Name e Confidence Level e também deve ser verificado se há um ou mais comandos de voz adicionados, caso estas validações não sejam cumpridas deve ser exibida uma mensagem ao usuário notificando o que falta ser preenchido. No passo 6 caso o usuário não selecione um diretório válido a aplicação deve exibir uma mensagem notificando que o diretório é inválido. Cenário do caso de uso UC06 Testar Comandos de voz Pré-condição 1. O usuário deve executar os processos descritos no caso de uso anterior ( UC05 Criar Comandos de Voz ) e entrar no formulário para teste de grupo de comandos de voz; Cenário principal 1. O usuário deve pressionar o botão Test ; 2. A aplicação deve permitir ao usuário dizer os comandos do grupo; 3. Quando o comando dito pelo usuário atingir o nível de confiança necessário para ser reconhecido a aplicação deve marcar o check box da grade de teste como verdadeiro; Cenário alternativo Após o passo 1 o botão Test é substituído pelo botão Stop O usuário deve clicar no botão Stop ; 2.2. A aplicação deve cancelar o teste dos comandos de voz e retornar ao estado anterior.

99 102 APÊNDICE D. PROJETO DA DLL KINECTSCAN D.1. Requisitos Abaixo segue a lista com os requisitos funcionais relativos à KinectScan: RF01 Esta DLL deve reconhecer poses e falas através das entradas fornecidas pelo sensor Kinect; RF02 Esta DLL deve abrir e mapear todos os arquivos de poses gravados pela aplicação; RF03 Esta DLL deve possibilitar ao desenvolvedor criar vários vocabulários de reconhecimento de fala (scanners) diferentes; RF04 Esta DLL deve possibilitar ao desenvolvedor ativar ou desativar diferentes scanners de fala em diferentes momentos; RF05 Esta DLL deve disparar um evento quando reconhecer uma pose; RF06 Esta DLL deve disparar um evento quando reconhecer uma fala com o grau de confiança maior do que o proposto pelo desenvolvedor. Abaixo segue a lista com os requisitos não funcionais relativos à KinectScan: RNF01 Esta DLL deve ser desenvolvida de forma que seja possível interagir com diferentes tipos de aplicação. Abaixo segue a lista com as regras de negócio relativas à KinectScan: RN01 Esta DLL possui dependência do framework.net 4.5.

100 103 D.2. Diagrama de classe A Figura 44 ilustra um diagrama de classes resumido da DLL KinectScan, contendo somente suas principais classes com seus respectivos atributos, propriedades, métodos e eventos públicos(as). Figura 44. Diagrama de Classe resumido da DLL KinectScan

101 104 APÊNDICE E. PROJETO DA KINECTSERVER Este apêndice lista os requisitos funcionais, não funcionais, regras de negócios relacionadas ao projeto da aplicação KinectServer. E.1. Requisitos Abaixo segue a lista com os requisitos funcionais da KinectServer: RF01 Esta aplicação deve se conectar com o sensor Kinect; RF02 Esta aplicação deve permitir ao usuário utilizar todos os eventos da KinectScan; RF03 Esta aplicação deve permitir conexão de um cliente via sockets; RF04 Esta aplicação deve responder todas as requisições do cliente com um evento. Abaixo segue a lista com os requisitos não funcionais da KinectServer: RNF01 Esta aplicação deve utilizar a DLL KinectScan para comunicação com o sensor Kinect. Abaixo segue a lista com as regras de negócio da KinectServer: RN01 Esta aplicação suporta apenas um cliente;

102 105 APÊNDICE F. PROJETO DA DLL KINECTUNITY Este apêndice lista os requisitos funcionais e não funcionais relacionados ao projeto da DLL KinectUnity. F.1. Requisitos Abaixo segue a lista com os requisitos funcionais relativos à KinectUnity: RF01 Esta DLL deve implementar os eventos disparados pela DLL KinectScan; RF02 Esta DLL deve interligar o reconhecimento de uma pose, gesto ou de um comando de voz com uma entrada da ferramenta Unity. Abaixo segue a lista com os requisitos não funcionais relativos à KinectUnity: RNF01 Esta DLL deve permitir criar uma integração entre o hardware Kinect e o software Unity.

103 106 APÊNDICE G. DOCUMENTAÇÃO DO PROJETO Para auxiliar os desenvolvedores que utilizarão esta biblioteca de funções todo o projeto foi documentado no padrão XML oferecidos pela linguagem C#. Como resultado a ferramenta para registro de entradas possui uma tile para abrir esta documentação com um formato similar ao da documentação padrão do MSDN (MSDN, 2012). A Figura 45 ilustra a primeira página de abertura da documentação, onde são exibidos os namespaces do projeto. Figura 45. Documentação do projeto