Web tabanlı eğitimde karşılaşılan sorunlar ve çözümler

No Capítulo 3 apresentamos outros trabalhos relacionados a ferramentas de criação ambientes virtuais. Nesse capítulo, após apresentar a nossa ferramenta o SAMVC apre- sentamos uma comparação entre o nosso trabalho e os trabalhos discutidos no Capítulo

CAPÍTULO 5. EXPERIMENTOS E RESULTADOS 47

3.

A Tabela 5.2 compara o nosso trabalho com os trabalhos do Capítulo 3: ARCO, CHEW e museuM, PEVEp. A Comparação é feita com base em seis aspectos: multi- usuário (se o sistema permite a interação multi-usuário), criação/edição de espaço (se é possível criar ou editar o espaço do museu de uma forma dinâmica, em outras palavras, se é possível mudar a estrutura do museu depois de criação), ferramentas de edição (se o sistema fornece ferramentas para editar a exposição do museu, como a mudança do lo- cal de uma obra de arte), guia virtual (se o sistema permite interagir com guias virtuais), realidade aumentada (se o sistema suporta ferramentas de realidade aumentada).

Tabela 5.2: Comparação entre os trabalhos.

ARCO CHEW MuseuM PEVEP SAMVC Multi-usuário Não Não Não Sim Sim Criação/Edição

do espaço

Não Não Não Sim Sim

Ferramentas de Edição

Sim Sim Não Sim Sim

Guia Virtual Não Não Não Não Sim Realidade Au-

mentada

Sim Não Não Não Não

Como pode ser visto na Tabela 5.2, o nosso sistema oferece mais apoio na criação e edição de museus do que as abordagens encontradas na literatura. Ressaltamos que a edi- ção do espaço do museu (inserir, remover ou mover obras) na nossa ferramente pode ser feito após o museu ser criado. A qualquer momento, o curador pode alterar o espaço físico de seu museu virtual. Esta tarefa é impossível nas abordagens baseadas em VRML. Além disso, como uma vantagem, a nossa abordagem tem suporte a conexão multi-usuários.

O SAMVC não oferece suporte para aplicações de realidade aumentada como a ARCO. Mas, também podemos citar como vantagem o fato de que ele suporta aplicações de re- alidade mista, através da inserção de dispositivos de animação, que pode ser (ou não) presente no ambiente real e na versão virtual.

Capítulo 6

Conclusão

Neste trabalho apresentamos o SAMVC: uma ferramenta para criação e edição de mu- seus virtuais através da web. Com esta ferramenta curadores podem criar os seus próprios museus virtuais 3D de uma forma simples e mais dinâmica que os museus construídos em

VRML.

Através do editor de museus é possível posicionar os quadros no museu utilizando a própria interface de visualização do mesmo. Depois de estarem salvos os museus podem ser disponibilizados a outros usuários comuns da Internet. Os visitantes podem navegar através das salas e visualizar o acervo do museu. Os visitantes também podem interagir com outros visitantes através do uso de avatares e da ferramenta de chat acoplada aos museus.

O SAMVC foi desenvolvido como parte do projeto GT-MV e demonstra grande po- tencial para se tornar uma ferramenta disponível para toda a comunidade interessada. Seu desenvolvimento rendeu dois artigos internacionais [Dantas et al. 2009] e [Dantas et al. 2010] e está sendo escrito no momento um capítulo de livro já aceito em primeira fase. Além disso, a plataforma do SAMVC serviu como base para outros projetos de pesquisa conforme exposto no Capítulo 5.

O desenvolvimento do SAMVC trouxe ao Natalnet o domínio da tecnologia de cri- ação de ambientes virtuais. Esse domínio foi transcrito numa ferramenta que facilita a criação de ambientes virtuais. Os ambientes criados foram demonstrados na forma de museus. Desde sua criação até hoje, já foram construídos mais de 70 museus utilizando o SAMVC. Alguns destes museus foram logicamente construídos para teste, mas ainda assim demonstram a facilidade de uso da ferramenta.

Apesar dos resultados positivos que foram alcançados e discutidos anteriormente no Capítulo 5, houve também resultados insatisfatórios. Esses resultados insatisfatórios fo- ram contornados por soluções paliativas e não ideais. Esses resultados insatisfatórios e suas soluções são discutidos a seguir e representam algumas lições aprendidas ao longo do desenvolvimento do SAMVC.

6.1

Lições aprendidas

A fim de tornar o SAMVC acessível por qualquer navegador e por máquinas sem pla- cas de vídeo e com pouca memória RAM (menos de 1 GB), foi decidido que a ferramenta

do SAMVC seria distribuída na forma de Applet [Robbins 2006]. A estratégia de usar o

Applet como meio de distribuição da aplicação não foi realmente uma boa solução. Além

da necessitar prévia instalação das APIS de terceiros (Java3D, JMF) utilizadas no nosso sistema, a memória disponível para um Applet é restrita. Isso faz com que em pouco tempo, a aplicação fique instável pela falta de memória. Uma alternativa para contornar a pouca quantidade de memória foi à criação de um Cache de imagens. A textura usada nas salas do museu tende a ser muito semelhante. Portanto, não há a necessidade de carregar a mesma imagem várias vezes. Essa solução foi uma boa abordagem, mas mesmo assim, não resolveu totalmente o problema.

O uso da memória também foi otimizado em relação às Obras do tipo Quadro. A imagem do Quadro, geralmente, é em alta resolução. Carregar essa imagem para dentro do Ambiente Virtual é muito custoso, portanto, adotou-se uma mudança de resolução das imagens para diminuir o uso da memória. Houve uma perda de qualidade na visualiza- ção da obra dentro do ambiente virtual, mas a imagem original pode ser vista quando o visitante a seleciona o aplicativo do cliente.

Outro ponto em que foi feito uma otimização para diminuir o uso de memória foi à alteração do Loader do formato MSH. O Loader passou a fazer um cache das informa- ções que compõem o objeto (textura, material, vértices, etc). Com isso, o sistema passou a suportar uma quantidade maior de objetos tridimensionais. Mesmo assim, dependendo da quantidade de salas e obras que compõe o museu, a memória chega ao seu limite. A solução adotada foi converter o applet para uma aplicação WebStart. Feito isso, pode- mos configurar o tamanho necessário da memória que o nosso sistema irá utilizar. Outro ponto positivo para o WebStart foi da instalação automática da API Java3D. O JMF ficou sendo a única API que deverá ser instalada antes de utilizar o nosso sistema.