Aspectos de Comunicação em uma Aplicação Distribuída de Realidade Virtual Utilizando Java e VRML
Tatiana Cavalcanti Fernandes Alexandre Sztajnberg
UERJ - Universidade do Estado do Rio de Janeiro Instituto de Matemática e Estatística
Rua São Francisco Xavier, 524, 6o andar - Maracanã CEP 20.590-900 - Rio de Janeiro - RJ - Brasil
tatiana@ime.uerj.br, alexszt@ime.uerj.br
Abstract. Nowadays Internet application development is focused on systems that allow interaction of groups of users and data sharing. In this scenario, Virtual Reality is considered an important technique to provide user interfaces that are, both, intuitive and attractive. The possibility of sharing a single-view virtual environment with a group of users, and the interface and interactivity provided by Virtual Reality was the base of the present work. Initially, some basic concepts and features of Virtual Reality are presented, as well as the problems and mechanisms involved in the implementation of a Distributed Virtual Reality System (DVRS). An example application was developed, using VRML to describe a virtual world, and Java, combined with multicast technique, was used to implement control and communication among the machines. The developed DVRS allows many users to share the same virtual environment to exchange information.
1 Introdução
A Realidade Virtual é uma forma de interface que permite ao usuário interagir em um ambiente virtual gerado por computador, podendo ser imersiva ou não imersiva. A Realidade Virtual imersiva é baseada no uso de dispositivos especiais como: capacetes (HMD - Head Mounted Display), luvas e roupas especiais, que determinam a sensação de imersão no ambiente virtual. O objetivo é fazer com que o usuário sinta-se envolvido pelo ambiente, como se estivesse atuando no mundo real. Portanto, esses dispositivos são destinados a estimular os sentidos do usuário, isolando-o de tal forma que seja possível apenas ver imagens geradas pelo sistema, ouvir sons tridimensionais e ver seus movimentos corporais transformados em ações no ambiente virtual[Kir-97][Bat-99].
Basicamente, a Realidade Virtual não imersiva utiliza os dispositivos comuns aos computadores, como monitores, mouse e teclado, além de alguns outros que estimulam parcialmente os sentidos do ser humano, propiciando um grau considerável de imersão. É utilizada principalmente por possuir custo reduzido e facilidade de uso[Kir-97][Ziv-97].
2 Sistemas Distribuídos de Realidade Virtual
Aplicações que envolvem Realidade Virtual podem constituir sistemas monousuários ou multiusuários. Os sistemas de Realidade Virtual multiusuários podem ser baseados no modelo centralizado ou distribuído [Kir-97].
2.1 Modelo Centralizado
No modelo centralizado, pode-se ter vários usuários conectados através da rede compartilhando o mesmo mundo virtual. Quando um usuário realiza uma alteração nesse ambiente, todas as outras estações devem receber uma mensagem de atualização.
O pedido de alteração do mundo virtual é uma comunicação ponto-a-ponto entre a estação do usuário que está solicitando o pedido e o servidor. Ao receber o pedido, o servidor deve alterar o mundo virtual e avisar às demais estações das alterações realizadas. Isso é feito através do envio de mensagens, onde a comunicação pode ser unicast, broadcast ou multicast.
2.2 Modelo Distribuído
No modelo distribuído, o mundo virtual pode ser replicado (no caso de mundos virtuais pequenos) ou particionado (no caso de mundos virtuais de grande porte).
2.2.1 Mundos Virtuais Replicados
Num sistema replicado, de forma similar ao modelo centralizado, pode-se ter vários usuários conectados através da rede. Entretanto, no modelo distribuído replicado, cada usuário possui uma cópia do mundo virtual. Quando um integrante deste mundo realiza uma alteração na sua réplica, o seu sistema deve comunicar a atualização ocorrida aos demais participantes. Uma mensagem deve ser enviada aos sistemas de todos os outros usuários, para que estes possam atualizar suas respectivas cópias do mundo virtual.
Nesse modelo, a comunicação é feita utilizando-se a técnica de broadcast (ou difusão), na qual a informação é propagada a todos os membros de uma aplicação.
2.2.2 Mundos Virtuais Particionados
No modelo distribuído particionado, o mundo virtual é dividido em várias partes que representam ambientes onde o usuário pode estar inserido. Ao entrar no sistema, cada membro recebe apenas a réplica da parcela na qual está localizado, constituindo um grupo com os outros integrantes dessa mesma região ou parcela. Dessa forma, os usuários são divididos em grupos de tal forma que, ao alterarem sua réplica do mundo, seus sistemas enviem uma mensagem de atualização apenas ao grupo ao qual pertençam.
Ao navegarem no mundo virtual, os usuários poderão passar de uma determinada região para outra. Quando isso acontecer, deverão receber a réplica desta região, passando a fazer parte do grupo associado a ela. Toda alteração feita por um membro do grupo deve ser comunicada ao restante. Isso pode ser feito através da técnica de multicast, também chamada difusão seletiva.
2.3 Por que Sistemas Distribuídos de Realidade Virtual?
Existem algumas vantagens em se distribuir o processamento necessário para simular um ambiente virtual[Pry-96]:
Um sistema de realidade virtual possui requisitos de tempo real e, portanto, processamento complexo, envolvendo vários passos que podem ser executados de forma concorrente. Distribuindo o processamento por várias máquinas, podemos efetuar significativas melhorias de desempenho.
Um SDRV permite que diversos usuários compartilhem um mesmo ambiente, como ocorre em simulações de operações militares, treinamento de astronautas e teleconferências.
3 Exemplo
A aplicação utilizada como exemplo neste trabalho consiste de um SDRV (Sistema Distribuído de Realidade Virtual), onde um ambiente virtual é compartilhado por vários usuários, que são representados neste por um avatar. Na definição da arquitetura optou- se por um modelo distribuído replicado, onde cada usuário possui uma réplica do mundo virtual e de todas as suas informações, ou seja, possui localmente um banco de dados usado para as operações que se fizerem necessárias. Esse modelo foi escolhido pela vantagem de não precisar de um servidor centralizado para armazenar o banco de dados, embora manter a consistência se torne uma tarefa mais complexa.
Cada usuário é responsável por avisar aos demais participantes sobre uma alteração na sua réplica do ambiente. Estes, por sua vez, ao receberem uma mensagem de atualização, devem alterar a sua réplica do mundo de acordo com as informações recebidas. Portanto, o sistema de todo usuário pertencente ao mundo virtual, é responsável por auxiliar na manutenção da consistência do ambiente virtual compartilhado e, consequentemente, da aplicação.
A técnica de multicast é utilizada na comunicação entre as máquinas com o objetivo de minimizar o tráfego de rede. Ao executar a aplicação, o usuário deve informar uma identificação e, em seguida, é cadastrado no grupo de multicast predefinido para os participantes do mundo virtual. Depois disso, vários sockets são abertos, um para cada operação permitida pelo sistema. Desta forma, todos os usuários ativos no ambiente virtual em um determinado momento, vão estar conectados a um único grupo de multicast e com vários sockets abertos nesse grupo.
No desenvolvimento do trabalho, utilizou-se a linguagem VRML para modelar o mundo virtual e Java para realizar a comunicação entre os usuários. As duas linguagens interagem através de uma interface predefinida (scripts) que será apresentada em maiores detalhes.
3.1 Recursos de Hardware e Software utilizados no desenvolvimento:
• Plataforma: WindowsNT, Windows98, Windows95
• Cosmo Player 2.1 (plug-in para visualizar arquivos VRML)
• JDK 1.2 (pacote de classes Java)
• VRML97 (biblioteca VRML)
• 3D Studio Max 2.5 (ambiente utilizado como ferramenta de apoio na construção do mundo virtual)
3.2 Arquitetura da Aplicação
A figura 1 apresenta a arquitetura da aplicação. Inicialmente, o usuário executa o arquivo expoBrasil500.html que abre a página de boas vindas da aplicação e executa o applet AppletConexao.class. Em seguida, o usuário deve digitar uma identificação que será usada para conectá-lo ao ambiente virtual compartilhado.
Figura 1. Arquitetura da Aplicação
O módulo ClienteServidor.class é executado a partir do
AppletConexao.class, recebe essa identificação e publica o nome do usuário utilizando o socket socketConexao em um grupo de multicast predeterminado no programa. Em seguida, se junta ao grupo de multicast através do socket socketTabela
esperando que algum outro usuário envie a tabela de participantes. Os participantes ativos recebem o pedido, incluem o usuário novo em suas tabelas locais e em suas réplicas do mundo virtual, retornando a tabela de participantes já atualizada. O usuário novo, ao receber a tabela, cria os diversos sockets que serão necessários para fazer a comunicação entre as estações e manter o mundo virtual consistente. Observe que existe um único grupo de multicast ao qual os usuários se juntam e diversos sockets nesse mesmo grupo que trocam as informações necessárias. A figura 2 apresenta trechos em Java do código da aplicação que definem os sockets, o grupo de multicast e as portas utilizadas pelo programa.
MulticastSocket socketConexao;
MulticastSocket socketDesconexao;
MulticastSocket socketTabela;
MulticastSocket socketMensagem;
MulticastSocket socketAtualizacao;
InetAddress group;
private static final int PORTA_CONEXAO = 4445;
private static final int PORTA_DESCONEXAO = 4446;
private static final int PORTA_TABELA = 4447;
private static final int PORTA_MSG = 4448;
private static final int PORTA_ATUALIZACAO = 4449;
private static final String GRUPO = "230.0.0.1";
Figura 2. Definição dos sockets necessários a aplicação Cliente / Servidor
Receber Conexão Receber Desconexão Rec. Atualização Posição
Mundo Virtual Receber Mensagem
Pedir Desconexão Informar Atualização Enviar Mensagem Pedir Conexão
A figura 3 ilustra trechos do código da aplicação para se abrir um socket para o envio e recebimento de mensagens. De forma semelhante, os outros sockets são criados, cada qual com uma porta associada, mas todos no mesmo grupo de multicast, especificado pela constante GRUPO = “230.0.0.1”;
//Abrindo o socket para o envio e recebimento de mensagens try{
socketMensagem = new MulticastSocket(PORTA_MSG);
group = InetAddress.getByName(GRUPO);
socketMensagem.joinGroup(group);
}catch(IOException e){
e.printStackTrace();
System.out.println(
"Não me juntei ao grupo de recebimento de mensagens");
}
Figura 3. Procedimento para se criar um socket para envio/recebimento de mensagens
Depois de efetuados esses passos, o módulo ClienteServidor.class inicia os outros módulos do sistema (veja figura 4), disponibilizando ao novo participante as diversas funcionalidades da aplicação. O sistema do usuário pode então receber pedidos de conexão e desconexão, enviar e receber mensagens do grupo de multicast e trocar informações sobre as atualizações executadas nas diversas cópias do mundo virtual.
Enquanto estiver conectado ao mundo virtual, o usuário pode caminhar pelo ambiente, visualizar os outros participantes que são representados por um avatar e interagir com eles através de um chat.
Ao sair do ambiente, cada integrante deve enviar uma mensagem ao grupo informando sua desconexão, para que possa ser retirado das réplicas dos mundos virtuais e das tabelas dos usuários remotos conectados ao sistema. Antes de se desconectar, entretanto, o sistema deve fechar todos os módulos e os sockets, saindo do grupo de multicast.
//Iniciando os módulos do sistema atualizador = new Atualizador();
mundoVirtual = new MundoVirtual(tabela,identificacao);
recebeConexao = new ReceberConexao(socketConexao, socketTabela, mundoVirtual, group,
PORTA_TABELA);
recebeDesconexao = new ReceberDesconexao(socketDesconexao, mundoVirtual);
recebeAtualizacaoPosicao = new ReceberAtualizacaoPosicao
(socketAtualizacao,mundoVirtual);
recebeMensagem = new ReceberMensagem(socketMensagem);
Figura 4. Código referente a Iniciação dos módulos do sistema
3.3 Sincronização das Réplicas do Mundo Virtual
Quando um participante efetua uma alteração em sua cópia do ambiente, deve-se informar a atualização ocorrida a todos os outros integrantes do mundo virtual. Para isso, a aplicação utiliza mensagens de multicast que são enviadas através da rede para o grupo associado ao sistema. Similarmente, ao receber uma mensagem de atualização, o
sistema do usuário deve atualizar seu mundo virtual local. O objetivo é manter o ambiente consistente.
A sincronização das réplicas de um mundo virtual é feita em etapas.
Primeiramente, quando um participante se movimenta no ambiente, é gerado um evento do browser (Cosmo Player) para um nó Script localizado no arquivo VRML, que possui a descrição do mundo virtual. Ao receber a informação da ocorrência do evento, o nó Script precisa tratá-lo, realizando uma chamada para um objeto script Java. Nesse objeto pode-se, então, definir as ações que devem ser tomadas em resposta ao evento ocorrido.
Veja o código da figura 5, no qual é apresentado o nó ProximitySensor
(predefinido pela linguagem VRML), responsável por capturar as mudanças de posição do usuário local informadas pelo browser e repassá-las ao nó Script associado. O nó
ROUTE (linha 25) conecta os dois nós anteriores estabelecendo uma rota com origem em
PS.position_changed (eventOut) e destino em SC.posicao_mudou (eventIn). Ao receber o evento, o nó Script invoca o tratador especificado no campo url, que na verdade é um módulo da aplicação escrito em Java, chamado ScriptInterface.class. Nesse módulo é possível especificar as ações que desejamos que sejam tomadas. Assim, podemos codificar de tal forma que essa informação seja colocada na rede, permitindo aos demais usuários a atualização de suas réplicas do mundo virtual.
1 DEF PS ProximitySensor{
2 exposedField SFVec3f center 0 0 0 # (-,) 3 exposedField SFVec3f size 0 0 0 # [0,) 4 exposedField SFBool enabled TRUE
5 eventOut SFBool isActive
6 eventOut SFVec3f position_changed 7 eventOut SFRotation orientation_changed 8 eventOut SFTime enterTime
9 eventOut SFTime exitTime 10 }
11
12 DEF SC Script {
13 url "file:///C:/ProjetoFinal/VRML/ScriptInterface.class"
14
15 field SFNode node USE CONE 16
17 eventIn SFVec3f posicao_mudou 18 eventOut MFNode novoObjeto 19 eventOut MFNode deletarObjeto 20
21 directOutput TRUE 22 mustEvaluate TRUE 23 }
24
25 ROUTE PS.position_changed TO SC.posicao_mudou 26 ROUTE SC.novoObjeto TO cena.addChildren
27 ROUTE SC.deletarObjeto TO cena.removeChildren Figura 5. Tratamento de eventos através de scripts
Observe o código apresentado na figura 6 relativo ao módulo
ScriptInterface.class. O evento enviado pelo nó Script é recebido pelo método
processEvent(), que obtém a nova posição do usuário (linha 2), transforma no tipo
Posicao (linha 6) definido para a aplicação e invoca o método
posicaoAlterada(posicao) no módulo MundoVirtual.class (linha 13), informando a nova posição do usuário local.
1 public void processEvent(Event e){
2 posicao_mudou = (ConstSFVec3f)e.getValue();
3 System.out.println("A posicao mudou para: " + posicao_mudou);
4 5
6 Posicao posicao = new Posicao (posicao_mudou.getX(), 7 posicao_mudou.getY(), 8 posicao_mudou.getZ());
9
10 ClienteServidor cliente = ClienteServidor.obterInstancia();
11 MundoVirtual mundoVirtual = cliente.obterReferenciaMundo();
12
13 mundoVirtual.posicaoAlterada(posicao);
14 }
Figura 6. Método processEvent() com as ações a serem executadas como resposta ao evento
O método posicaoAlterada(posicao), como podemos observar na figura 7, apenas repassa a informação para o módulo ClienteServidor.class, que envia uma mensagem de multicast aos outros participantes.
public void posicaoAlterada(Posicao posicao){
cliente.enviarPosicaoUsuario(localAvatar, posicao);
}
Figura 7. Método posicaoAlterada da classe MundoVirtual.class
A figura 8 apresenta o método que envia a informação da atualização do usuário local, retornando uma mensagem de erro caso não consiga completar a operação.
public void enviarPosicaoUsuario(String usuario,Posicao novaPosicao){
//Preparar envio da nova posição do usuário ao grupo de Multicast System.out.println("Vou enviar atualizacao: " + usuario + ".");
try{
ByteArrayOutputStream pacote = new ByteArrayOutputStream();
ObjectOutputStream escritorRegistro = new ObjectOutputStream (pacote);
escritorRegistro.writeObject(usuario);
escritorRegistro.writeObject(novaPosicao);
group = InetAddress.getByName(GRUPO);
byte[] registro = pacote.toByteArray();
DatagramPacket packet = new DatagramPacket(registro,
registro.length, group,
PORTA_ATUALIZACAO);
socketAtualizacao.send(packet);
System.out.println("Atualização enviada");
pacote.close();
}catch(IOException e){
e.printStackTrace();
System.out.println(
"Não enviei nova posição do usuário ao grupo de Multicast");
} }
Figura 8. Método enviarPosicaoUsuario da classe ClienteServidor.class
Ao receber uma mensagem de atualização de algum outro participante, o usuário local deve fazer o caminho inverso. O módulo ReceberAtualizacaoPosicao.class
ao receber uma mensagem cuja identificação não seja do usuário local, invoca o método
atualizarPosicao(usuario,posicao) no módulo MundoVirtual.class, como se pode observar pela figura 9.
while (conectado){
byte[] msg_in = new byte[255];
DatagramPacket packetRegistro = new DatagramPacket
(msg_in,msg_in.length);
try{
socketAtualizacao.receive(packetRegistro);
}catch(IOException e){
e.printStackTrace();
System.out.println(
"Não consegui receber a atualização da posição do usuário");
} ....
if (!localAvatar.equals(usuario)){
mundoVirtual.atualizarPosicao(usuario, posicao);
}
Figura 9. Trecho de código do módulo ReceberAtualizacaoPosicao.class
De forma semelhante, o método atualizarPosicao() repassa a identificação do usuário remoto e sua nova posição para o método alterarPosicao(usuario, posicao) em ScriptInterface.class (veja figura 10).
public void atualizarPosicao(String usuario, Posicao posicao){
System.out.println("Usuário que será atualizado: " + usuario);
tabela.put(usuario,posicao);
//Atualizar Mundo Virtual
scriptInterface.alterarPosicao(usuario,posicao);
}
Figura 10. Método atualizarPosicao() do módulo MundoVirtual.class
De acordo com a figura 11, o método alterarPosicao(), converte a posição do usuário no tipo SFVec3f, reconhecido pela linguagem VRML (linha 5), passando imediatamente o valor para o campo do nó Transform, chamado translation (linha 7). A posição do usuário remoto é então atualizada na cópia local do mundo virtual.
1 public void alterarPosicao(String usuario, Posicao posicao){
2 //Obtendo referência ao campo a ser alterado do nó Transform 3 BaseNode node = (BaseNode)tabela.get(usuario);
4
5 SFVec3f nova_posicao =
6 (SFVec3f)((Node)node).getExposedField("translation");
7 nova_posicao.setValue(posicao.getX(),posicao.getY(),
posicao.getZ());
8 System.out.println("A posição nova é: " + nova_posicao);
9 }
Figura 11. Método alterarPosicao() do módulo ScriptInterface.class
O procedimento para incluir e excluir um usuário é semelhante ao apresentado anteriormente. Entretanto, em vez de receber um evento gerado no mundo virtual, o nó
Script gera um evento que atualize o mesmo. Portanto, os eventos de inclusão e exclusão serão eventOut, diferentemente do evento eventIn posicao_mudou.
3.4 Diagrama de Blocos
O diagrama de blocos da figura 12 apresenta o esquema da aplicação. Como visto anteriormente, o módulo de cada usuário possui as funções de cliente / servidor.
Mundo Virtual VRML
Cliente / Servidor Java
Mundo Virtual VRML
Cliente / Servidor Java Mundo
Virtual VRML
Cliente / Servidor Java
Figura 12. Diagrama de blocos da aplicação
Para se conectar ao sistema distribuído, o módulo do usuário abre um socket para um grupo preestabelecido de multicast, no lugar do endereço IP de Internet. Em seguida, este módulo faz uma solicitação de conexão do usuário ao mundo virtual, passando como parâmetro sua identificação e esperando como resposta a tabela de participantes. Esta deve ser enviada por algum outro usuário como um flag de que seu pedido obteve êxito. A partir deste momento, qualquer alteração que o usuário fizer no mundo virtual deverá se refletir nas outras estações, por intermédio de mensagens de multicast colocadas na rede, utilizando os sockets específicos para cada função.
O módulo representado pelo mundo virtual é a interface entre o usuário e a aplicação, um ambiente gráfico e amigável no qual os participantes atuam.
Por último, a figura 13 apresenta a tela principal da aplicação, uma sala de exposição onde os usuários podem interagir.
Figura 13. A aplicação exemplo
4 Conclusões
Sistemas de realidade virtual exigem uma considerável capacidade de processamento das máquinas nas quais executam, mesmo considerando-se ambientes virtuais mais simples. Entretanto, são os ambientes virtuais compartilhados que exigem maior atenção por parte dos desenvolvedores. Em tais ambientes, todas as alterações realizadas por um usuário devem ser enviadas pela rede, para que a alteração seja refletida por todas as cópias do mundo virtual. O número de mensagens pode gerar um tráfego excessivo de informações na rede e, assim, degradar o desempenho do sistema e o nível de interação do usuário com o mesmo. Na aplicação exemplo, observou-se o impacto da quantidade de processamento exigida e o que pode ser feito para melhorá-la. Por exemplo, utilizou- se multicast para reduzir o número de mensagens, e de certa forma admitiu-se que a ordenação das mensagens era mantida pelo subsistema de comunicação, aliviando o processamento. Comparando-se com implementações baseadas em recursos centralizados [Ziv-97], a implementação desenvolvida mostrou-se mais eficiente pois minimiza o tráfego concentrado num único ponto da rede. Na arquitetura apresentada por [Ziv-97], o servidor central se transforma em um gargalo, embora exista uma thread executando para cada cliente. Toda a informação a ser enviada pela rede às outras estações, deve obrigatoriamente passar pelo servidor, que atende às solicitações e avisa a todos os clientes sobre as ações executadas. A escalabilidade desta solução fica comprometida em situações de muita interação entre usuários e com grandes grupos.
Além disso, se o servidor falhar, todos os clientes são afetados e a aplicação é interrompida. Esses problemas foram, em parte, resolvidos em nosso exemplo pela distribuição de processamento entre as máquinas dos participantes e a replicação das informações, fazendo com que todos sejam simultaneamente clientes e servidores.
Assim, se qualquer uma das máquinas falhar, o sistema não é seriamente afetado, pois as informações não estão concentradas em um único ponto da rede.
No prosseguimento deste trabalho, o estudo de alternativas para realizar a comunicação poderá apontar soluções ainda mais eficientes. Por exemplo, RMI (Remote Method Invocation) poderia ser utilizado como alternativa ao uso de sockets, uma vez que já faz parte da especificação de Java e possui algumas otimizações na comunicação e serialização de objetos. Entretanto, RMI não seria aplicado diretamente na
comunicação de grupo (multicast). Outra alternativa viável seria a utilização do JSDT (Java Shared Data Toolkit) [JSD-00], que foi elaborado para este tipo de aplicação, desde que, uma máquina central que funcione como registry esteja disponível. De um modo geral, a utilização de middlewares com suporte para publish/subscribe, que independam de um servidor central, também poderia ser estudada como mecanismo para a comunicação.
Bibliografia
[Bat-99] Battisti, G. e Tarouco, L. M. R., “Telepresença com Realidade Virtual para Gerenciamento de Rede”, 17º Simpósio Brasileiro de Redes de Computadores, maio de 1999.
[Bru-98] Brutzman, Don. “The Virtual Reality Modeling and Java”;
Comunications of the ACM, Vol. 41, nº 6, pp. 57-64, junho de 1998.
[Cal-93] Calvin, J., Dickens, A., Gaines, B., Metzger, P., Miller, D. e Owen, D.,
“The SIMNET Virtual World Architecture”, IEEE Virtual Reality Annual International Symposium, Seattle, Washington, setembro/1993.
[Car-97] Carey, R. e Bell, G., “The Annotated VRML 2.0 Reference Manual”.
Addison Wesley, Reading Mass.,
http://www.best.com/~rikk/Book/book.shtml 1997.
[Car-98] Carey, Rikk, “The Virtual Reality Modeling Language Explained”, IEEE MultiMedia, pp. 84-93, julho-setembro de 1998.
[Cra-98] Crawford III, George, “Objective Viewpoint: The Java3D Programming Model”, ACM CROSSROADS, pp. 5-9, primavera de 1999.
[Isd-93] Isdale, Jerry, “What´s Virtual Reality”, version 2.1,
http://www.cms.dmu.ac.uk/~cph/VR/whatisvr.html, outubro de 1993.
[JSD-00] Java Shared Data Toolkit Home Page,
http://java.sun.com/products/java-media/jsdt/index.html, abril de 2000 [Kir-97] Kirner, Claudio, “Sistemas de Realidade Virtual”, Grupo de Pesquisa em
Realidade Virtual - Departamento de Computação – UFSCAR, http://www.dc.ufscar.br/~grv/tutrv/tutrv.htm, 1997.
[Nad-97] Nadeau, Dave. “Introduction to VRML 97”;
http://www.sdsc.edu/~nadeau/courses/Siggraph97,1997
[Pry-96] Pryce, Nat, “The Use of Behavior Specifications in Distributed Virtual Environments”,
http://www.newcastle.research.ec.org/cab...dicals/1996/papers/virtualenv -pryce.html, abril de 1996.
[Roe-95] Roehl, Bernie, “Distributed Virtual Reality – An Overview”, http://sunnee.uwaterloo.ca/~broehl/distrib.html, First Draft, junho de 1995.
[Rya-99] Ryan, M. D. e Sharkey, P. M., “Investigating the Transparency of Distribution in a Distributed Virtual Environment”, http://www.cyber.rdg.ac.uk/ISRG/, março de 1999
[Sin-99] Singhal, S. e Zyda, M., “Networked Virtual Environments – Design and Implementation”, julho de 1999.
[Tei-99] Teixeira, Renata Cruz, “Uma Plataforma Escalável para Sistemas Distribuídos de Realidade Virtual”, Dissertação de Mestrado, COPPE/PEE/UFRJ, agosto de 1999
[VRM-97] VRML 97, “Internacional Specification ISO/IEC 14772-1”, http://www.vrml.org, Dezembro 1997
[Ziv-97] Ziviani, Artur, “Implementação de Ambiente Virtual Distribuído Baseado em Java e VRML”, Dissertação de Graduação, DEL/EE- PEE/COPPE, dezembro de 1997.
