CoReactive: Um Sistema de Colaboração para Ambientes Virtuais Distribuídos

Transcrição

1 CoReactive: Um Sistema de Colaboração para Ambientes Virtuais Distribuídos Artur Lira dos Santos Grupo de Pesquisa em Realidade Virtual e Multimídia (GRVM) Centro de Informática (CIn) Universidade Federal de Pernambuco (UFPE) Av. Professor Moraes Rego, S/N, Prédio da Positiva, 1º Andar Recife PE, CEP als3@cin.ufpe.br Abstract This paper describes CoReactive, a collaborative system for virtual environments which requires physics simulation involving a large number of objects. This work proposes the creation of a communication layer implemented on top of physics engines, benefiting both from the concepts of deterministic simulation and from events synchronization in order to decrease the network data transfer rate to its minimum level, therefore enabling a distributed simulation of several physical elements. Being the deterministic simulation essential to CoReactive s proper functioning, this paper also presents some results of determinism tests executed on the main physics engines. Resumo Este artigo descreve o CoReactive, um sistema colaborativo para ambientes virtuais que requerem simulação física envolvendo um grande número de objetos. Este trabalho propõe a criação de uma camada de comunicação em rede, implementada para engines físicos, tirando proveito dos conceitos de simulação determinística e sincronização de eventos para reduzir ao máximo possível a carga de transferência de dados pela rede, possibilitando uma simulação distribuída com muitas instâncias físicas. Como a simulação determinística é um requisito essencial para o funcionamento correto do CoReactive, este artigo também demonstra resultados de testes de determinismo realizados nos principais engines físicos. 1. Introdução Este artigo descreve alguns tópicos relacionados ao projeto ReActive [1], um engine físico que inclui o conceito de reatividade para o desenvolvimento de aplicações que executam simulação física. Tal projeto pretende oferecer uma camada de comunicação em redes de computadores que funciona com engines físicos, objetivando a implementação de sistemas de colaboração em tempo real. Esta parte do projeto é referida como CoReactive, e será descrita neste trabalho. Conceitos como sincronização remota de objetos e orientada a eventos [2], problemáticas no uso de sistemas estocásticos e testes de determinismo em engines físicos são temas abordados neste artigo. Na próxima seção é fornecida uma breve visão de alguns conceitos ligados ao CoReactive. Na seção 3, são apresentados os trabalhos relacionados, como engines físicos disponíveis para uso não comercial. A seção 4 apresenta as técnicas existentes para a sincronização de estados em sistemas colaborativos. A seção 5 analisa possíveis conseqüências do uso de engines físicos na construção de um sistema colaborativo determinístico, enquanto a seção 6 descreve a proposta do CoReactive. A seção 7 demonstra os testes realizados para a verificação de quais engines físicos se comportam de maneira determinística. Na seção 8 são apresentados alguns cenários para utilização do CoReactive em Sistemas Colaborativos Determinísticos. Por fim, a seção 9 apresenta as conclusões e trabalhos futuros. 2. Conceitos Relacionados Esta seção descreve brevemente alguns dos conceitos relevantes para o estudo de simulações em sistemas colaborativos que utilizem engines físicos. 2.1 Engines Físicos Pode-se definir um engine físico como um sistema computacional desenvolvido com a finalidade de simular computacionalmente a Física Clássica seguindo o modelo Newtoniano, ou seja, utilizando os conceitos básicos de massa, velocidade, atrito e resistência do ar [3]. Com base neste conceito, um engine físico é responsável por realizar todas as simulações relacionadas ao movimento de partículas e

2 corpos, além das suas interações, como colisão e campos de força. Tais engines geralmente são componentes de um sistema mais abrangente que, tirando proveito das informações resultantes na simulação física, apresentam uma visualização realística dos resultados ao usuário. O grau de realismo que um engine físico pode oferecer está diretamente relacionado com o nível de precisão matemática da sua implementação. A partir deste conceito é possível dividir os engines físicos em dois grupos: simuladores de alta precisão e simuladores em tempo real [3]. Os engines físicos de alta precisão envolvem simulações que requerem maior poder de processamento para realizar cálculos precisos e são utilizados principalmente no meio acadêmico, entre físicos e astrônomos. Tais engines, por serem partes de sistemas que requerem alto poder de processamento, não oferecem resultados imediatos, diferenciando-se da classe de engines físicos em tempo real. Como exemplo clássico do uso de simulações real-time temse os jogos eletrônicos, que precisam dar uma aparência mais realista ao produto final, mas com pouco impacto no desempenho do jogo. 2.2 Sistemas Colaborativos Determinísticos A definição de um Sistema Colaborativo (SC) segue o conceito de um sistema de software distribuído [4], no qual os usuários podem interagir com o sistema de forma que o estado temporal do programa é resultado da colaboração dos eventos realizados pelos usuários. É importante observar que o referido conceito de colaboração se define a partir dos eventos de entrada realizados pelos usuários e não pela interação entre os mesmos. Esta observação leva ao raciocínio de que em um sistema colaborativo, não necessariamente os usuários estejam colaborando entre si. Um bom exemplo deste caso são os jogos de computador que fornecem ao usuário a possibilidade de jogar em rede. Tais jogos, dependendo do seu estilo podem tanto fomentar a competição como a colaboração entre os usuários. Entretanto, o estado temporal de tais jogos depende apenas da colaboração dos eventos de entrada realizados pelo usuário. Todo SC pode ser classificado entre dois subgrupos, são eles: Sistemas Colaborativos Determinísticos (SCD) e Sistemas Colaborativos Estocásticos (SCE) [4]. Um SCD garante que o seu comportamento é completamente previsível e conseqüentemente toda alteração neste tipo de sistema pode ser refeita tendo como base os eventos de entrada realizados. Isto significa que se uma simulação em um SCD for repetida várias vezes com os mesmos eventos de entrada, o estado final do sistema será obrigatoriamente o mesmo. Já um SCE não tem a capacidade de garantir tal previsibilidade. Um SCD pode facilmente ser transformado em SCE se adicionarmos elementos aleatórios, e tais elementos não pertencerem ao conjunto de eventos de entrada. Como estes dados aleatórios modificarão o estado temporal do sistema de forma que o próprio sistema é incapaz de detectar, já que estas alterações não pertencem ao grupo de eventos de entrada, o sistema se comportará de forma estocástica. Dentre os sistemas distribuídos é bastante comum encontrar sistemas estocásticos, pois como o aplicativo está separado em diversos equipamentos, operações simples podem levar a resultados diferentes. Este é um caso comum em operações que envolvam números reais representados no formato de ponto flutuante, pois cada equipamento pode ter uma arquitetura de hardware diferente para lidar com tais números, gerando resultados com pequenas variações, mas suficientes para definir o sistema como estocástico. Um SCD oferece algumas vantagens sobre um SCE. Primeiramente, como um SCD se comporta de maneira previsível, a transferência de dados em redes pode ser reduzida ao extremo para o caso de um sistema distribuído. Um SCE precisa enviar mais informação para evitar inconsistência de dados. 3. Trabalhos Relacionados Antes de iniciar o desenvolvimento do projeto CoReactive, foi preciso fazer um levantamento dos principais engines físicos existentes, a fim de verificar quais destes se preenchem alguns requisitos necessários para o funcionamento correto com o CoReactive. A biblioteca Bullet [5] é dividida em dois módulos, um para o sistema de detecção de colisão e outro para a dinâmica de corpos rígidos. Uma característica importante desta divisão é que o módulo de detecção de colisão é independente do módulo responsável pela dinâmica, possibilitando ao desenvolvedor substituir um dos módulos por uma implementação que seja mais adequada ao seu sistema. O ODE [6] (Open Dynamics Engine) é um simulador de corpos rígidos, que suporta corpos articulados, através do conceito de juntas. Como exemplo, pode-se citar as dobradiças de uma porta ou janela. Como o Bullet, a biblioteca ODE oferece um módulo de colisão que pode ser facilmente substituído. Por último, o AGEIA PhysX [7] é um poderoso middleware de física para a criação de ambientes

3 físicos dinâmicos. O PhysX, apesar de gratuito, possui o código fechado e suporta as principais plataformas para jogos e aplicações gráficas, tais como Playstation 3 e XBOX 360. Pela abrangência de plataformas e facilidade de programação, o uso deste engine é bastante difundido em diversas aplicações e jogos comerciais. Além disto, a placa AGEIA PhysX foi a primeira PPU (Physics Processing Unit) dedicada para computadores desktop construída para melhorar a performance da simulação física, sendo este um diferencial do PhysX. Recentemente, foi anunciada a compra da AGEIA pela NVIDIA [8], significando que todo o processamento do PhysX, antes restrito à CPU e PPU, será agora transferido para poderosas placas gráficas GeForce da série 8 e mais modernas. 4. Técnicas de sincronização de Sistemas Colaborativos com Engines Físicos A simulação física é peça fundamental em muitos jogos recentes, sendo conseqüência direta da busca pelo aumento no grau de realismo em tais aplicativos. Entretanto, a inserção de tais engines em um contexto mais complexo nem sempre ocorre de maneira trivial. Um jogo multiplayer, por exemplo, traz a dificuldade adicional de se implementar uma interface entre o engine físico e a camada de comunicação. Tendo em vista tais dificuldades de integração, uma alternativa é a criação de uma interface única entre o engine físico e a camada de comunicação. Desta forma, evita-se a realização de duas integrações separadas uma com o loop do jogo e outra com a camada de comunicação. Para a implementação eficiente da camada de comunicação, é preciso observar dois fatores do ambiente no qual o sistema estará contextualizado. O primeiro é a largura de banda disponível, pois para algumas das técnicas de sincronização, a taxa de transmissão é diretamente proporcional ao número de objetos ou instâncias físicas presentes na simulação. Assim, para simulações complexas, a largura de banda pode alcançar o nível de saturação. O segundo fator está relacionado à latência da rede, problema freqüente nos jogos multiplayer, em que os jogadores geralmente estão conectados por diversos tipos de enlaces, como ISDN, xdsl e WiFi. Uma rede com alta latência degrada a experiência do usuário, podendo inviabilizar o uso do sistema. Para contornar tais problemas, é preciso implementar técnicas de sincronização que busquem melhorar o desempenho do sistema e da própria rede. Em relação às simulações físicas, três técnicas são bastante utilizadas: sincronização por objetos remotos, lockstep e bucket synchronization. 4.1 Sincronização por objetos remotos A sincronização por objetos remotos é uma das técnicas mais utilizadas em jogos e sistemas com poucas instâncias de objetos. Utiliza a idéia de centralizar todos os cálculos importantes do sistema em uma máquina, enquanto as outras receberão os estados de todas as instâncias de objetos do programa. Desta forma, as máquinas que recebem as informações não precisam realizar os cálculos que a máquina central está executando. Entretanto, uma grande desvantagem neste tipo de sincronização é a necessidade de largura de banda suficiente para transmitir todo o estado atual (dados das instâncias dos objetos) do sistema. Um sistema que trabalha com muitas instâncias necessitará de uma rede com grande largura de banda, o que muitas vezes não corresponde à realidade. Para resolver o problema citado anteriormente, podem-se utilizar técnicas que utilizam o conceito de simulação simultânea [2]. Ao invés de passar o estado de cada objeto remoto, executa-se exatamente a mesma simulação em cada máquina, passando para cada uma um conjunto idêntico de comandos ou eventos que serão calculados ao mesmo tempo nas diferentes máquinas. Esta forma de sincronização é complexa para ser implementada pelos requisitos de consistência de dados entre as máquinas, mas traz benefícios para a rede, já que é bem menos custoso enviar eventos do que todos os estados dos objetos remotos envolvidos na simulação. A técnica de sincronização por objetos remotos foi implementada e testada num aplicativo demonstrativo do projeto VisGas, financiado pelo CNPq, em que se exibe a simulação de risers, estruturas utilizadas para extração de petróleo e gás entre o solo oceânico e a superfície. Figura 1. Aplicativo Demonstrativo do VisGas

4 Utilizando a arquitetura cliente-servidor, criou-se um sistema no qual o servidor realiza todos os cálculos da simulação física, e envia os estados de orientação e posição dos 600 objetos (cápsulas e esferas) aos clientes. O engine físico (neste caso o PhysX) é utilizado apenas no servidor. No lado cliente, ocorre somente o funcionamento do engine gráfico OGRE [9], responsável pela renderização e exibição na camada de apresentação. Para evitar altas taxas de transmissão, o envio dos estados foi limitado em 40 Hz. Como a visão humana é capaz de perceber diferenças de imagem no mínimo em cerca de 1/30 segundo, não ocorrem descontinuidades perceptíveis ao olho humano, já que a cada 1/40 segundo um novo quadro é processado e exibido. Entretanto, mesmo limitando o número de envios por segundo, a taxa de transmissão alcança valores em torno de 2,54 Mbps. 4.2 Lockstep Synchronization Na técnica de Lockstep [2], cada usuário espera pelos eventos dos outros participantes do sistema. Enquanto o usuário não receber todos os eventos dos outros, o mesmo não pode passar para o próximo frame. Isto é valido para todos os usuários do sistema. Figura 2. Lockstep Synchronization A grande vantagem dessa técnica, ilustrada na Figura 2, é a garantia de pequenas taxas de transmissão, já que apenas eventos são repassados. Para isto, é preciso que todas as partes formem um sistema determinístico, ou seja: se um evento A ocorre no usuário 1 e o mesmo vai do estado X para o estado Y, o usuário 2 também deverá processar o evento A e passar do estado X para o estado Y. A técnica de Lockstep pode ser utilizada em um modelo cliente-servidor e também num modelo peerto-peer [10]. O modelo cliente-servidor necessita que todos os clientes enviem ao servidor todos os eventos, que então serão repassados para os demais clientes. Já em peer-to-peer, cada usuário envia seus eventos diretamente para todos. Esta forma é ainda mais vantajosa em redes que suportam multicast. Entretanto, independente da arquitetura escolhida ser cliente-servidor ou peer-to-peer, existem alguns problemas ao se utilizar Lockstep. Um deles é quando uma das partes da rede sofre de alta latência, pois o tempo de resposta final para cada loop corresponde ao tempo de resposta da parte mais lenta da rede. 4.3 Bucket Synchronization Em Bucket Synchronization, similarmente ao Lockstep, cada usuário espera pelos eventos dos outros participantes do sistema. Entretanto, a diferença entre as duas técnicas está na existência de um buffer dos eventos recebidos em cada uma das partes do sistema. O próprio nome da técnica (bucket balde em inglês) se refere a este buffer. Quando um evento chega, é armazenado no buffer e será calculado e renderizado apenas em frames futuros. Como exemplo, quando os eventos do loop 1000 chegarem, os mesmos só serão executados no loop Assim, caso aconteça um atraso em uma das partes, a simulação continuará acontecendo já que existe um buffer de eventos que fornecem as informações para que a simulação ocorra. A técnica Bucket Synchronization foi utilizada no jogo Age Of Empires, da Microsoft [11]. Seus desenvolvedores realizaram uma pesquisa com usuários em relação à percepção dos eventos sob diferentes níveis de latência. Ao observarem que um intervalo de tempo em torno de 100 a 200 milissegundos não era perceptível aos usuários e a taxa de atualização do jogo deveria ser de 20 Hz, definiram um buffer para dois eventos, já que não seria perceptível para o usuário caso o evento ocorresse 100 milissegundos depois. 5. Conseqüências do uso de Engines Físicos em Sistemas Colaborativos Determinísticos As técnicas de sincronização orientadas a eventos requerem que a simulação ocorra da mesma forma em todos os nós participantes. É preciso então ter a garantia de determinismo, em que todo o código envolvido deve realizar as mesmas operações ou seqüências de instruções caso seja chamado na mesma ordem várias vezes. Sendo assim, se o mesmo conjunto de instruções for executado n vezes, os n estados finais do programa serão idênticos a cada execução. Os problemas para alcançar estas garantias surgem quando o sistema utiliza bibliotecas externas. Muitas vezes tais bibliotecas são complexas, oferecendo uma gama de serviços difíceis de serem testados quanto ao

5 determinismo. É preciso então realizar testes de todas as funcionalidades utilizadas em tais bibliotecas, analisando a arquitetura da máquina usada para testes, sistema operacional, e versões das bibliotecas. Tais problemas se aplicam aos engines físicos, que são complexos e nem sempre apresentam documentação sobre os seus comportamentos. Um ponto preocupante em relação ao determinismo em engines físicos é a necessidade dos mesmos realizarem integrações no tempo, já que o estado de toda simulação física é dependente da variação do tempo. Como o tempo precisa ser integrado, se a forma de se implementar o contador ou timer não for bem definida, os resultados terão como conseqüência a imprevisibilidade. Não se pode então, por exemplo, utilizar o conceito de se consultar a informação de tempo a um processador, pois não há garantia de que os processadores de cada nó informarão a mesma variação de tempo. Uma alternativa é simplesmente informar a variação do tempo para o simulador de forma constante, significando que o integrador receberá sempre a mesma variação de tempo. Para isto, a variação do tempo passa a fazer parte do conjunto de eventos e não de estados do sistema. Um sistema colaborativo de simulação em tempo real que utiliza técnicas de sincronização como lockstep e timebucket, por ser inerentemente um SCD, precisa dispor de engines físicos que garantam o determinismo do sistema. Caso o engine físico se comporte de maneira estocástica, é preciso adaptá-lo para que se comporte de maneira determinística. Se alterar o código de tal engine não for possível por motivos como inacessibilidade, contratos ou licenças, é preciso então, procurar engines alternativos ao atualmente escolhido, pois é mais fácil alterar um componente do sistema do que alterar todo o sistema. Modificar a arquitetura de um sistema determinístico pode trazer impactos indesejáveis, já que a escolha por um SCD é feita para resolver problemas críticos como limite nas taxas de transmissão em redes e consistência dos dados. 6. CoReactive Visando obter um sistema colaborativo de ambientes virtuais com simulações físicas determinísticas, surge a proposta do CoReactive, uma camada de comunicação em redes de computadores implementada no topo de diversos engines físicos. O CoReactive utiliza conceitos de simulação determinística e sincronização de eventos para reduzir a carga de transferência de dados pela rede, já que tais ambientes virtuais podem envolver um grande número de instâncias físicas. O sistema oferecerá então lockstep e bucket synchronization como formas de sincronização de eventos. A escolha entre as duas técnicas de sincronização por parte do usuário é útil para adequar o sistema em diferentes arquiteturas de redes. Um sistema de redes menos confiável e com um nível de latência acima de 100 ms terá uma performance melhor utilizando bucket synchronization, enquanto que um sistema de rede com baixa latência será mais eficiente com o uso da técnica de lockstep, pois não terá a sobrecarga de buffers e sincronização adicional necessárias no bucket synchronization. Figura 3. Principais Classes do CoReactive Atualmente o CoReactive encontra-se na fase final do planejamento e implementação do protótipo. As principais classes da interface para o cliente são demonstradas em alto nível no diagrama UML da Figura 3. Os cenários de testes de determinismo de engines físicos foram concluídos e os resultados estão descritos na seção Testes de Determinismo de Engines Físicos Como o CoReactive tem como requisito importante ser compatível com pelo menos um engine físico e a documentação da maioria destes sistemas não descreve em detalhes o comportamento de suas bibliotecas, foi preciso a realização de testes exaustivos para se escolher o mais estável e correto. Desta forma, PhysX, Bullet e ODE foram os engines escolhidos para a bateria de testes. É importante observar que em relação ao PhysX foram realizados testes tanto em simulação por hardware (usando a PPU da AGEIA) como por software.

6 Figura 4. Cena de Testes Para facilitar o processo de testes de colisões entre instâncias físicas, criou-se uma cena física com uma caixa oca, visualizada na Figura 4. Na sua região interna, estão inseridos corpos rígidos, como caixas, esferas, cápsulas e pirâmides, confinados a um subespaço. Definindo movimentos que atuem sobre a caixa, causam-se diversos tipos de colisões entre os corpos. Capturando as posições de tais corpos rígidos durante uma variação de tempo e executando a mesma simulação repetidamente, torna-se possível detectar a existência ou não de variações nos resultados. No teste realizado, a caixa executava um movimento harmônico simples (MHS) [3]. A cena de simulação física da Figura 4 apresenta as seguintes características, utilizando ponto flutuante de precisão simples: Gravidade: [ ]; Coeficientes de atrito: 0.5; Plano na origem da Cena; Caixa Oca; o Dimensão [ 22m 22m 22m]; o Espessura 2m; Tronco de Pirâmide (Forma Convexa); Torre de 55 Cubos, esferas, cápsulas e troncos de pirâmides. Os testes desta cena física foi realizado em 4 máquinas diferentes, com configurações descritas na Tabela 1. Processador Máquina I Athlon 64 X2 Dual Máquina II Athlon Máquina III Athlon Máquina IV Pentium Ghz M. RAM 2 GB 1 GB 1 GB 1 GB Windows Windows Windows Windows SO XP 32 bits 2000 XP 64 bits XP 32 bits Placa PhysX? Não Não Sim Sim Tabela 1. Máquinas de Testes O levantamento dos dados ocorreu da seguinte forma: a cada 60 ciclos do loop da simulação, eram enviadas para um arquivo de saída as matrizes de orientação e posição de todas as formas físicas na cena. Depois de duas execuções em máquinas diferentes, os arquivos foram comparados. Se o resultado corresponder a arquivos idênticos, significa que há uma alta probabilidade dos tipos de objetos e tipos de colisões agirem de forma determinística. Caso contrário, significa que o sistema não é determinístico. Após duas séries de testes de 5, 10 e 15 minutos para cada engine e cada máquina, a simulação em software no PhysX resultou em arquivos idênticos para todas as saídas. Para garantir um resultado mais preciso, outra bateria de testes foi realizada, mas desta vez com intervalos de tempo de 8 horas. Novamente, as saídas resultaram em arquivos idênticos. Tais resultados indicam alta probabilidade do PhysX se comportar de maneira determinística, pelo menos em relação aos corpos rígidos e suas colisões. Já com a simulação do PhysX em hardware, utilizando a mesma cena dos testes em software, os resultados foram diferentes. Simulando várias vezes na mesma máquina, as saídas não são semelhantes para todos os tempos de testes, como demonstra a Tabela 2. Entretanto, simplificando o ambiente para apenas um cubo, a simulação se comporta de maneira determinística. Adicionando mais um cubo, a simulação começa a apresentar um comportamento aleatório. A partir destas observações, infere-se que a implementação do sistema de colisão em hardware não processa os dados de maneira estática, podendo gerar resultados completamente diferentes para entradas iguais, significando que uma simulação em hardware não poderá ser utilizada num SCD. O ODE engine apresentou um comportamento determinístico para corpos rígidos. Entretanto, a adição juntas na simulação gerou resultados imprevisíveis. O Bullet apresentou ausência de determinismo em todos os tipos de elementos físicos envolvidos na simulação física, apesar da variação nos resultados ser pequena e visualmente imperceptível. Entretanto, como qualquer alteração pode grandes variações de resultados, o Bullet, assim como o ODE não pode ser utilizado num SCD sem alterações na implementação. PhysX PhysX Software Hardware ODE Bullet 5 minutos Deterministico Determinístico Estocástico Estocástico 15 minutos Deterministico Determinístico Estocástico Estocástico 1 hora Deterministico Estocástico Estocástico Estocástico 8 horas Deterministico Estocástico Estocástico Estocástico Tabela 2. Resultados dos Testes de Determinismo

7 A partir dos resultados encontrados, pode-se concluir que o único engine que apresenta determinismo dentre os três analisados é o PhysX quando simulado em software. Desta forma, a alternativa encontrada para se desenvolver o CoReactive é de se utilizar como engine físico o PhysX em software. 8. Aplicações Diante das características apresentadas num SCD, aplicativos como simuladores de vôo e sistemas dedicados ao treinamento de mão de obra em engenharia são alguns exemplos de programas que podem explorar as inovações oferecidas por um SCD como o CoReactive, pois tais aplicativos normalmente demandam altas taxas de transmissão de dados, que podem ser amenizados utilizando o conceito de sincronizações orientadas a eventos. Dentre tais aplicativos, pode se exemplificar o projeto VisGas, voltado para o treinamento colaborativo em projetos de perfuração de poços de petróleo. Projetos de novos jogos em rede que buscam elevar o grau de realismo, mas se encontram atualmente limitados pelas taxas de transmissão em rede e também poderão ser beneficiados pelo uso do CoReactive nas suas implementações, pois o mesmo também propõe o suporte à uma camada de abstração de rede, possibilitando a colaboração entre aplicações de simulação física de forma mais simples e otimizada. 9. Conclusão e Trabalhos Futuros A principal contribuição do CoReactive para uma simulação física distribuída se define na implementação de uma camada de comunicação orientada a eventos, reduzindo as taxas de transmissão dos dados. Outro importante fator para o uso de um SCD em conjunto com o CoReactive se refere à exatidão na exibição da simulação em máquinas ou terminais diferentes, significando que a exibição será equivalente em todos os pontos de acesso do sistema distribuído. Os resultados encontrados nos testes dos engines possibilitou a determinação do PhysX como o escolhido para ser utilizado na implementação do CoReactive. Dependendo da necessidade de adição de um novo simulador físico, pode-se estudar a possibilidade de alteração da implementação do ODE, engine de código e licença aberta. Agradecimentos O autor agradece ao CNPq, que financia parcialmente o CoReactive. Referências [1] G. F. Almeida, A. L. Santos, R. F. Anjos, F. B. Breyer, M. W. S. Almeida, R. Farias, V. Teichrieb e J. Kelner. ReActive - Engine Reativo de Física, X Symposium on Virtual and Augmented Reality, SVR 2008, 2008, João Pessoa, Brasil. [2] S. Jamin, Class Notes Networking Multiplayer Games, University of Michigan, Disponível em: Computer Game Design and Implementation Course site. URL: 16.pdf, visitado em Maio de [3] Eberly, D.H., Game Physics, Elsevier Science, New York EUA, [4] K. Drira, A. Martelli, T. Villemur. Cooperative Environments for Distributed Systems Engineering. Springer, New York EUA, [5] Bullet Physics Library. Disponível em: Bullet site. URL: visitado em Julho de [6] Open Dynamics Engine. Disponível em: ODE site. URL: visitado em Outubro de [7] AGEIA PhysX. Disponível em: AGEIA site. URL: visitado em Agosto de [8] NVIDIA. Disponível em: NVIDIA site. URL: visitado em Agosto de [9] OGRE. Disponível em: OGRE site. URL: visitado em Outubro de [10] El-Rewini, H., e M. Abd-El-Barr, Advanced Computer Architecture and Parallel Processing, Wiley-Interscience, Hoboken EUA, [11] P. Bettner, e M. Terrano, 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond, Game Developers Conference, Disponível em: Gamasutra site. URL: m, visitado em Março de 2008.