Equipe: Carlos Maciel Elias Colleto Gustavo Hagenbeck Ítalo Macedo Telmo Filho Thyago Cassimiro

1. Equipe: Carlos Maciel Elias Colleto Gustavo Hagenbeck Ítalo Macedo Telmo Filho ThyagoCassimiro Vinícius de Oliveira

2. Introdução OGRE • Motor gráfico orientado a objeto (orientado à cena); • Facilitar o desenvolvimento de aplicações gráficas; • Licença GPL; • Qualidade e eficiência;

3. Introdução Orientado à cena Grafo da cena: “The scenegraph is an object-oriented structure that arranges the logical and often (but not necessarily) spatial representation of a graphical scene.” (1) • Organizar objetos em cenas; • Transformações; • Hierarquia; • Otimização; • Preparação;

4. Introdução Questões Técnicas Implementação: • C++ Abstração • Biblioteca utilizada (OpenGL, Direct3D) Simplicidade • Não suporta física, áudio, porém é de simples uso;

5. Introdução Facilidade • Tratamento de classes de vetores e matrizes • Gerenciamento de memória • Adicionar plugins • Toolkits variados • Áudio • Física • Gerenciador de componentes • Scripting Language • Gerenciamento de cenas (grafo de cenas);

6. Introdução Flexibilidade • Compatível com a maioria dos Sistemas Operacionais (SO); Portabilidade • Facilmente exportável (3D Studio Max, Maya, Blender, LightWave, Milkshape, Sketchup…);

7. Introdução Comunidade • Amplamente difundida; • Muitos frameworks disponíveis; • Alta produtividade;

8. Características Características de produtividade • Interface simples e fácil de usar orientada a objetos feita para minimizar o esforço necessário para renderizar cenas em 3D, e ser independente de implementações de 3D, exemplo: Direct3D/OpenGL. • Framework de exemplo extensiva permite você colocar seu aplicativo para rodar rápido e fácil. • Requisitos comuns como manejo de render states, spatialculling, mexendo com transparências são feitas para você automaticamente, te poupando tempo precioso. • Design limpo e organizado com documentação completa de todas as classes da engine. • Comprovado, engine estável usada em vários produtos comerciais.

9. Características Suporte a plataformas e 3D APIs • Suporte a Direct3D e OpenGL. • Suporte a Windows (todas as principais versões), Linux e Mac OSX. • Compila no Visual C++ e Code::Blocks no Windows. • Compila no GCC 3+ no Linux / Mac OSX (usando XCode).

10. Características Suporte a Material / Shader • Poderosa linguagem de declaração de materiais te permite manter os materiais fora de seu código. • Suporta Vertex e Fragmentprograms (shaders), tanto programas em baixo-nível escritos em assembler, e programas em alto-nível escritos em Cg, DirectX9 HLSL, ou GLSL e provê suporte automático para várias constantes comuns como matrizes de worldview, informações de estado de luz e objectspaceeyeposition, etc. • Suporta todos os operadores de função fixa como multitexture e multipassblending, geração de coordenada de texturas e modificação, operações de alpha e cores independentes para hardware não-programável ou para materiais de baixo custo. • Suporta efeitos com vários "passes", com interação se necessário. • Suporte para múltiplas técnicas de materiais significa que você pode fazer efeitos alternativos para uma grande variedade de placas e o OGRE automaticamente usa o que é melhor suportado.

11. Características Suporte a Material / Shader • Suporte a Material LOD (LevelofDetail, ou Nível de Detalhe), permite que seus materiais possam reduzir o custo de acordo com o quão distantes eles ficam. • Carregar texturas de arquivos PNG, JPEG, TGA, BMP ou DDS, incluindo formatos incomuns como texturas 1D, texturas volumétricas, cubemaps e texturas comprimidas (DXT/S3TC). • Texturas podem ser providas em tempo real por plugins, por exemplo uma alimentação de vídeo. • Suporte a texturas projetivas fácil de usar.

12. Características Meshes (Malhas) • Formatos de malhas flexíveis são aceitos, separação dos conceitos de vertex buffers, index buffers, vertexdeclarations e buffer mappings. • BiquadricBezierpatches para superfícies curvadas. • Malhas progressivas (LOD), geradas manualmente ou automaticamente. • Agrupamento de geometria estática.

13. Características Animação • Suporte sofisticado de animação por esqueletos. • Combinação de várias animações com pesos variáveis. • Skinning com peso de "bones" multiplos/variáveis. • Pipelines de skinning em software ou hardware com compartilhamento de buffer inteligente. • Controle de bones manual. • Modos de interpolação configurável, troca de precisão por velocidade. • Suporte de animação de formas flexiveis. • Morphanimation para aplicativos onde você deseja fazer simples combinações lineares entre formatos. • Pose animation para animação de superfícies modernas, permitindo combinar várias poses com pesos variáveis ao longo de uma timeline, por exemplo expressão / formas da boca para fazer animações faciais. • Ambas as técnicas podem ser implementadas em hardware ou software dependendo do suporte de hardware.

14. Características Animação • Animação de SceneNodes para caminho de câmeras e técnicas similares, usando interpolação de spline quando necessário. • Trilhas de animação genéricas podem aceitar objetos plugáveis para te possibilitar animar qualquer parâmetro de qualquer objeto ao longo do tempo.

15. Características Características de Cena • Administração flexível de cenas, altamente customizável, vinculada a nenhum tipo de cena. Use classes pre-definidas para organização das cenas se elas servem ou então coloque sua próprias subclasse para ganhar total controle sobre a organização das cenas. • Vários plugins exemplo demonstram várias formas de manipulação da cena específica para um particular tipo de layout (ex: BSP, Octree). • Gráfico de cena hierárquico; nodes permitem objetos serem anexados uns aos outros e seguir o movimento movimento dos outros, estruturas articuladas e etc. • Várias técnicas de renderização de sombras, tanto técnicas modulativas como aditivas, stencil e texturizadas, cada uma altamente configuável e tomando total vantagem de qualquer aceleração de hardware disponível. • Características de consulta de cena.

16. Características Efeitos Especiais • Sistema de "Compositor", permitindo efeitos de postprocessing em tela-cheia serem definidos fácilmente, via scripts se desejado. • Sistema de Partículas, incluindo emissores extensíveis, affectors e renderizadores (customizável através de plugins). Sistemas podem ser definidos em scripts de texto para fácil modificação. Uso automático de "particlepooling" para máxima performance. • Suporte á Skyboxes, Skyplanes e Skydomes, muito fácil de usar. • Billboarding para sprites. • Ribbontrails (rastro) • Objetos transparentes administrados automaticamente (ordem de renderização e depth buffer todos já configurados para você).

17. Características Outras Características • Infraestrutura comum de resources para administração de memória e carregar de arquivos comprimidos (ZIP, PK3). • Arquitetura de plugins flexível permite a engine ser estendida sem precisar recompilar. • 'Controllers" te permitem organizar valores derivados entre objetos de forma fácil, ex: mudar a cor de uma nave baseado nos escudo restante. • Debugging memory manager para identificar vazamento de memória (memory leak). • ReferenceAppLayer provê um exemplo de como combinar o OGRE com outras libraries, por exemplo ODE para colisão e física. • XMLConverter para converter formatos eficientes em binário para/de arquivos XML.

18. Arquitetura

19. Arquitetura Root • É o primeiro objeto a ser criado e o último a ser destruído. É o ponto de entrada do sistema OGRE. • Através dele pode-se configurar e acessar todo o sistema. • Objetos importantes do sistema tais como SceneManager e RenderSystem são referenciados a partir de Root.

20. Arquitetura SceneManager • É responsável por organizar o conteúdo da cena. • É o SceneManager que cria e gerencia todas as câmeras, objetos móveis, luzes e materiais (propriedades da superfícies de objetos). • Envia a imagem a ser processada para o RenderSystem. • Através dele nós e objetos móveis podem ser criados e acessados: • SceneManager::createLight() / getLight(); • SceneManager::createSceneNode() / getSceneNode(); SceneManager::createCamera() / getCamera();

21. Arquitetura RenderSystem • Classe abstrata que define a interface OGRE e a API 3D. • Responsável pela execução de comandos de renderização e configura opções da API gráfica utilizada. • Não deve ser acessada diretamente. • Exceto quando se necessita criar múltiplas janelas de renderização, ou quando se deseja acessar dados presentes apenas no RenderSystem.

22. Arquitetura Entity • É uma instância de um objeto móvel na cena. • Possui uma malha geométrica associada (mesh). Pode-se utilizar várias entities referenciando um mesmo mesh. • São criadas através do método SceneManager::createEntity(), passando como parâmetro um nome para a entidade e o nome do arquivo .mesh. • Cada Entity tem um Material que pode ser modificado através do método subEntity::setMaterialName(), proporcionando uma aparência diferente ao Mesh que originou.

23. Arquitetura SceneNode • Tem como função agrupar entidades, luzes, câmeras e objetos associados e armazenar informações relativas a posição, orientação e escala destes dentro da cena. • Toda entidade deve estar associada a um SceneNode para se tornar visível. • Existe uma hierarquia de SceneNode, cuja raiz pode ser acessada através do método SceneManager::getRootSceneNode(). Para criar nós filhos utiliza-se o método SceneNode::CreateChildSceneNode(). • Pode-se aplicar transformações espaciais às entidades associadas a cada SceneNode e seus filhos. • Pode-se realizar uma busca por SceneNode através do método: sceneManager->getSceneNode(“nomeDoSceneNode”).

24. Arquitetura Camera • Representa um ponto de vista da cena. • É simbolicamente representado como um nó com propriedade de Frustum. • Essa propriedade representa uma área restrita de visualização, com atributos como campo de vista (ângulo de abertura), relação entre altura e largura, planos que delimitam o volume de visualização (near plane e far plane). • Possui também orientação e posição, podem ser alteradas dinamicamente. • Câmeras são criadas através do SceneManager associando a um nome.

25. Geometria • Vérticies e materiais • Meshes e sub-meshes • Entities e sub-entities • Hardware buffers

26. Vértices e Materiais • Dados 3d sãorepresentadosatravés de “indexed face sets”, que é feitopor um array de vértices e um array de índices. Issopermitequeosvérticessejamprocessadosapenasumavez • Para renderizar é precisodescrevercomoutilizaresses dados, é aíqueentramosmateriais (egrelacionartextura e com coordenadas de textura)‏ • Materiaispodem ser vistoscomo “programas” querecebem dados de vértices e índices

27. Materiais • Definemgrande parte darenderização • Precisa ser bemtrabalhadoquando se querportabilidade. É precisofornecerdiferentesmaneiras de se obter um mesmoefeito, a fim de queumadelassejacompatível com a plataforma/placa de vídeo • São umalista de técnicas. Umatécnicaconsisteem um oumaispassos. OGRE fazotimizaçõesparareduzir a troca de contexto e garantir a ordemcorretapara, porexemplo, efeitos de transparência

28. Meshes e sub-meshes • Meshes:sãounidadeslógicasquerepresentamobjetos, ex: carro, personagem, robô. Facilitam a manipulação e renderização de objetos. São compostospordiferentespartescadauma com diferentesmateriais • Sub-Meshes:Essaspartessãoos Sub-Meshes, quesãoatômicos, contémapenas dados de vértice/índice e têm um único material. • Meshes armazenamoutrasinformaçõescomométodospararenderização de sombras, grupo de recursos, status, etc.

29. Entities • Materiaismudam com frequencia, mantendoos dados de vertice/indice (ex: várioscarrosnumacorrida)‏ • Entitiessãoponteirospara Meshes, maspodemsobreporosmaterias das Sub-Meshes, através das Sub-Entitiesqueexistemparacada Sub-Mesh • Entities guardaminformaçoes de como o mesh aparecenacena. Como: flags (ex: se é visívelounão), bounding box, fila (ray query)‏

30. Entities

31. Sub-Entities • Sub-entity estão relacionadas com sub-mesh. • Possuem seu próprio material • Ao terem seu material alterado apenas uma Entity sofrerá mudança, ao passo em que uma sub-mesh é alterada, várias Entitys sofrerão mudanças.

32. Hardware Buffers • Dados de vértice e índicesãorepresentadosatravés de uma das formasmaiseficientes, chamada de “mecanismo de estadoda arte”. No caso, significautilizar Hardware Buffers. • È umaárea de memória RAM fora do núcleo do sistema, geralmente é a vídeo RAM. São eficientesporquelimitam a transferência entre a CPU e a GPU, e fazem com queos dados estejammaispróximos do local de uso. São muitomenosflexíveis e quememória do sistema, e emalgunscasosgeramduplicação de dados (egcolisão)‏ • São muitomenosflexíveisque a memória RAM

33. Exemplo • Ninja é um Mesh • Corpo é um sub-mesh • Espada é um sub-mesh

34. Scripts Definição: Arquivos de texto que servem como meio alternativo ao código fonte para a criação de recursos pelo engine. Initialization Scripts • Faz o carregamento dos plugins, auto-preenchimento das opções de configuração e definição de caminhos para os recursos utilizados pela aplicação. “plugins.cfg”, “ogre.cfg” e “resources.cfg” • Plugins.cfg => Localiza a pasta onde estarão localizados os plugins listados desse arquivo. • Ogre.cfg => Localiza pastas e arquivos compactados que possuem mais arquivos de scripts. • Resources.cfg => Contém os valores configurados mais recentemente pelo usuário.

35. Scripts • Particle Scripts Scripts de partículas permitem que sejam definidos sistemas de partículas para serem instanciados no código, sem ser necessário codificar as próprias configurações no código-fonte, permitindo mudanças rápidas. Sistemas de partículas definidos em scripts são usados como modelos e muitos sistemas podem ser criados a partir deles em tempo de execução.

36. Scripts • Particle Scripts • Scripts de sistemas de partículas são carregados em tempo de inicialização pelo sistema: por default ele procura em todos os locais de recursos comuns por arquivos com a extensão “.particle” e os processa. • Uma vez processados, o código pode instanciar sistemas baseados nos scripts.

37. Scripts • Particle Scripts • Exemplo de script de partículas: // A sparkly purple fountain Examples/PurpleFountain { material Examples/Flare2 particle_width 20 particle_height 20 cull_each false quota 10000 billboard_type oriented_self

38. Scripts // Area emitter emitter Point { angle 15 emission_rate 75 time_to_live 3 direction 0 1 0 velocity_min 250 velocity_max 300 colour_range_start 1 0 0 colour_range_end 0 0 1 } // Gravity affector LinearForce { force_vector 0 -100 0 force_application add } // Fader affector ColourFader { red -0.2 green -0.25 blue -0.25 } }

39. Scripts • Overlay Scripts • Scripts de superposição oferecem a habilidade de definir superposições em um script que pode ser reusado facilmente. Eles também são carregados e processados em tempo de inicialização, quando o sistema procura por arquivos de extensão “.overlay”.

40. Scripts • Overlay Scripts • Exemplo de Overlay Scripts // The name of the overlay comes first MyOverlays/ANewOverlay { zorder 200 container Panel(MyOverlayElements/TestPanel) { // Center it horizontally, put it at the top left 0.25 top 0 width 0.5 height 0.1 material MyMaterials/APanelMaterial // Another panel nested in this one container Panel(MyOverlayElements/AnotherPanel) { left 0 top 0 width 0.1 height 0.1 material MyMaterials/NestedPanel } } }

41. Scripts • Font Definition Scripts • OGRE usa fontes baseadas em texturas. A forma final de uma fonte é um objeto Material gerado pela fonte e um conjunto de informações de coordenadas de texturas de “glyph”(caracter).

42. Scripts • Font Definition Scripts • Existem duas formas de usar fontes em OGRE: • Criar uma textura de fonte usando um pacote de arte ou uma ferramenta de criação de fontes. • Fazer o OGRE gerar uma textura de fonte baseada em uma fonte truetype.

43. Scripts • Font Definition Scripts • Os arquivos de definições de fontes “.fontdef” são buscados, carregados e processados em tempo de inicialização e seu formato básico é: <font_name> { type <image | truetype> source <image file | truetype font file> ... ... custom attributes depending on type }

44. Ambientes de desenvolvimento • Eclipse • NetBeans • Code::Blocks • DevC++ • Visual C++

45. Ambientes de desenvolvimento Eclipse • Requisitos • Ogre4J ou Ogre4Eclipse

46. Ambientes de desenvolvimento NetBeans • Requisitos • Ogre4J

47. Ambientes de desenvolvimento Eclipse + CDT • Requisitos • Eclipse C/C++ DevelopmentTools • MinGW • MSYS • OgreSDK

48. Ambientes de desenvolvimento Code::Blocks • Requisitos • MinGW • OgreSDK para Code::Blocks

49. Ambientes de desenvolvimento DevC++ • Requisitos • Versão 4.9.9.1 • OgreDevPak

50. Ambientes de desenvolvimento Visual Studio • Requisitos • Microsoft Platform SDK(PSDK) • OgreSDK