UARhere - TP2 by Paulo Alexandre Dias

UARhere

Projecto – 3ºAno -‐ NTC Tp2 – Requisitos Funcionais e Viabilidade Técnica

Liliana Costa – 46201 Maria Silva – 46758 Paulo Dias – 47167 Pedro Martins -‐ 47645

Requisitos do Projecto Após a determinação do conceito do projecto e a elaboração do estudo do estado da arte, chega a hora de listar os diferentes requisitos funcionais e, também, não funcionais do projecto. Posteriormente, estes requisitos serão convertidos em tarefas ligadas às competências de cada elemento da equipa UARhere e assinalados no GANTT. É de referir que, em primeira instância, consideraram-‐se: os objectivos relativamente à aplicação em termos de armazenamento e visualização de conteúdos e a recolha das preferências e utilização de aplicações de navegação tridimensional por parte dos utilizadores -‐ a fim de melhor compreender e subdividir os requisitos do projecto. 1. Objectivos do Projecto Objectivos principais: •

Elaborar uma aplicação online que retrate, a evolução do Campus de Santiago, num determinado intervalo temporal;

•

Alojar a aplicação num website e informação sobre o projecto;

•

Proporcionar a navegação e interacção do utilizador no ambiente imersivo online que retrate a evolução temporal do Campus de Santiago;

Objectivos secundários: •

Permitir a inserção e edição de conteúdos por parte do utilizador;

•

Proporcionar diferentes acessos à aplicação por parte do utilizador (área de registo + área de login);

•

Reutilizar o conteúdo, utilizando noutros cenários de interacção+ Projecção + Interacção;

•

Exportar a aplicação para dispositivos móveis, e outras plataformas relevantes (xbox, wii)

2. Constrangimentos

Para que a solução em termos de desenvolvimento da aplicação seja efectuada de uma forma, consciente e criteriosa, enumeraram-‐se os seguintes constrangimentos a ter em atenção: •

A equipa não possui competências ao nível da programação orientada a objectos e em programação de nível avançado;

•

Faltam de 4 meses para a conclusão do período de tempo de entrega do projecto;

•

Grupo de trabalho com apenas 4 elementos, embora grupo seja bastante dinâmico;

•

Pretende-‐se aplicação com o máximo de compatibilidade, a todos os níveis, para atingir o máximo de utilizadores possível;

•

Recursos históricos, embora imensos, encontram-‐se muito dispersos e a maior parte sem registo digital, o que origina muito tempo dispendido em tratamento de gestão/conversão de conteúdos;

•

Elementos do grupo de trabalho leigos a nível de conhecimentos sobre arquitectura e termos técnicos utilizados na área;

•

Pouca experiência do grupo em game engines.

3. Preferências de utilização de Ambientes de navegação virtual Com vista a perceber as diferentes funcionalidades a integrar na aplicação e adequar às necessidades/preferências do público-‐alvo, elaboraram-‐se algumas questões a um conjunto de 6 participantes (3 utilizadores que, com frequência, interagem com ambientes de navegação virtual e 3 cuja interacção é feita raramente). Analisando os diferentes resultados, pode-‐se concluir que:  No que diz respeito aos problemas que os utilizadores se deparam, frequentemente, com este tipo de navegação, são: a ocorrência de bugs (ícones clicáveis mas que não despoletam informação), problemas quanto ao nível do processamento da aplicação, falta de qualidade e realismo, tempo de loading e de execução dos menus;  A interacção com os ambientes de navegação é feita, na sua maior parte, através da instalação no computador, dado que não há dependência com a ligação à Internet;  As funcionalidades que o universo de utilizadores considerou como sendo mais importantes, foram: a interacção com os objectos presentes e a contribuição/partilha de conteúdos;  Em termos de visualização, a vista em primeira pessoa é referida como sendo a preferida, bem como o teclado e rato, quanto ao nível de interacção;  No que concerne a navegação entre os diversos ambientes, o público-‐alvo prefere que seja feito através de um mapa clicável ou menu 2D;  O conjunto de inquiridos ainda referiu que informações sobre os cursos e directores, número de alunos, contribuição com conteúdos relativo a cada departamento e apresentação (exemplo do Google Maps) e navegação por cada edifício, seriam aspectos relevantes a considerar no desenvolvimento do projecto UARhere; Alguns tópicos de auxílio à elaboração dos requisitos do projecto 1. Como é que o utilizador acede à aplicação? Funciona em que suporte? O utilizador acede à aplicação através do Website (browser). 2. Como é feita a interacção 3D com o browser? Através do teclado ou rato. Possivelmente, a interacção também será feita com a interacção gestual do utilizador ou comando Wii.

3. É necessário a identificação do utilizador? Talvez. 4. Porquê? Há diferentes níveis de acesso à informação? Na opção de envio de conteúdos e chat entre os diferentes utilizadores, é necessário o perfil de utilizador registado, para além do utilizador não registado e administrador. 5. Que tipo de conteúdos integra a aplicação? Para além do conteúdo visual, integra, também, som. 6. Enquanto espectadores, que informações temos acesso? Como se processa a navegação dentro da interface? Enquanto espectadores, temos acesso à informação sobre o projecto, acesso à aplicação, interacção e visionamento sobre a informação de todos os conteúdos. 7. O que proporciona a aplicação em termos de experiência? Um ambiente 3D interactivo que permite ao utilizador explorar o Campus de Santiago, a sua história e evolução do património arquitectónico. Tendo em consideração os diferentes objectivos e a análise às respostas dos utilizadores relativas às suas preferências de interacção em ambientes virtuais, criaram-‐se 3 cenários de desenvolvimento da aplicação (1 obrigatório e 2 suplementares, seguido de 3 módulos complementares). Os diferentes perfis de utilizadores contemplados para o acesso à aplicação são:  Utilizador registado: contribui com a inserção e actualização de conteúdo e visualização de informação;  Utilizador não registado: visualiza informação mas não contribui na inserção e actualização de conteúdo;  Administrador: controlo total de todo o conteúdo inserido e desenvolvido;

4. Listagem dos requisitos funcionais do projecto UARhere Área Informativa •

•

Visualização de Informação sobre o projecto o

Quem é a equipa

O que é o projecto

Contactos 

específicos



gerais

Ajuda / apoio ao utilizador o

Sistemas de ajuda integrados / sensíveis ao contexto 

tooltips



mensagens de erro

Sistemas de ajuda autónomos 

Como interagir com a aplicação



Perguntas mais frequentes (FAQ)



Sistema de Pesquisa

Área de conteúdos •

REGISTO utilizador o

Preenchimento do questionário 



Password



Dados pessoais

 •

•

Nome / Apelido

•

Data nascimento

•

Foto

•

Existe ligação à UA (Docente / estudante / … )

Envio mail validação / confirmação

Autenticação (email/pass)

Recuperação de password

o •

Envio de password nova para email do utilizador

GALERIA (utilizadores registados / admins) o

Visualização de conteúdos 

Textos



Galeria de fotos



Galeria de videos



Comentários



Inserção de conteúdos 

Textos



Galeria de fotos



Galeria de videos



Comentários



Visita virtual •

Timeline histórica o

Entrada na aplicação de navegação virtual-‐ (pode ser necessário instalar plugin na 1ª utilização) 

Vista aérea do campus, escolha do ponto de partida da interacção •

Os vários pontos a escolher serão predefinidos no campus – dependem do período temporal escolhido (não se escolhe departamento a departamento – isso vai contra o propósito da aplicação, navegação pelo campus)



Ajuda à navegação •

Disponibilização de um mapa (sempre visível na interface para utilizador saber onde se encontra numa perspectiva geral)



•

Escolha de um novo ponto de acesso no campus (Botão MAP, acedido por rato ou teclado)

•

Escolha de um departamento específico (Botão MAP, acedido por rato ou teclado)

•

Existência de um espaço visível para informações do estado do sistema / ajudas contextuais)

•

Menu de ajuda à navegação on-‐demand (Botão HELP, acedido por rato ou teclado)

•

Aumento do ecrã para melhor visualização (Botão FULLSCREEN)

•

Possibilidade de desligar SOM ou regular Volume (Botão SOUND ON/OFF /VOL)

Escolha de novo período temporal (alteração imediata independente do local no campus onde se esteja) (Botão Timeline)



Navegação livre pelo espaço, utilizador escolhe percurso que pretender pelo campus



Interacção através de teclas de navegação e rato



Interacção com o objectos no campus (a aproximação a edificios/equipamentos relevantes despoleta um objecto/GUI (até então invisível) que permite obter informações sobre o equipamento em causa.



•

Texto informativo

•

Audio

•

Imagem

•

Video

Interacção com outros utilizadores existentes ao mesmo tempo na app •

Visualização da info do utilizador

•

Chat



Entrada nos edifícios NÃO permitida



Para fechar aplicação: botão na interface, escape ou ALT+F4, fechar o browser ou mudar de site/página.

Área Administrativa •

Selecção e filtragem de conteúdo multimédia enviado pelos utilizadores

•

Associação do conteúdo recebido a objectos específicos

•

Disponibilização da informação recebida na aplicação de navegação virtual

•

Alteração/Actualização da aplicação de navegação virtual

•

Actualização/integração de conteúdos do site Web

•

Resposta a pedidos/comentários/emails dos utilizadores (Manutenção e suporte)

•

Monitorização da performance da aplicação

•

Actualização da documentação de apoio

Cenários que integram os requisitos funcionais do projecto

O grupo de trabalho, após a primeira abordagem na resolução da enumeração dos requisitos

funcionais, deparou-‐se com a necessidade de criar 3 cenários possíveis que o projecto atravessará. O primeiro cenário, intitulado como real deal scene, tem características essenciais para o cumprimento dos objectivos gerais do projecto, destacando-‐se o facto de não existirem utilizadores registados, isto é, qualquer tipo de utilizador poderá navegar na aplicação. Este facto é um requerimento único que terá de ser cumprido pelo grupo de trabalho.

A criação do cenário 2, consiste numa fase que ainda poderá ser realizada pelo grupo de trabalho,

dependendo de questões técnicas e temporais, o acto da sua concretização. Caracterizado por possuir uma

diferenciação de tipo de utilizadores, beneficia aqueles que se registarem na plataforma Web, pois poderão inserir conteúdos na aplicação sendo a base de dados dos conteúdos actualizada de forma dinâmica e automática no site e, ao mesmo tempo, na aplicação de navegação virtual, necessitando apenas da validação garantida pelo administrador, que faz a gestão pelo backoffice. Apesar de não ser uma prioridade de topo para a equipa projectual, seria uma forma eficaz de enriquecer o projecto, daí ter-‐se em consideração a realização desta fase.

Finalmente o cenário 3 poderá ser considerado o “teatro dos sonhos” do grupo de trabalho,

intitulando-‐se assim como o cenário dream on scene. Com o intuito de dar maior interacção por parte do utilizador, os utilizadores registados poderão dialogar (chat), em realtime, com outros utilizadores da aplicação, isto enquanto navegam virtualmente pelo campus podendo dessa forma partilhar experiências entre muitas outras possibilidades. Inserir conteúdos na aplicação, Será uma tarefa árdua cumprir os requisitos desta fase, até porque, como já foi referido, o grupo de trabalho tem como alta prioridade o cumprimento de realização de navegação eficaz do utilizador, num ambiente 3D, no contexto da evolução temporal do campus de Santiago.

Implementação de Módulos Extra

Os módulos extra são componentes com potencial de serem realizados mas que são independentes do cenário escolhido ou do nível de profundidade que o trabalho atinja, sendo também independentes entre si. Dessa forma, exemplificando, poderá implementar-‐se um módulo, dois ou mesmo os três, conforme pertinência para o projecto, quer se concretize apenas o primeiro cenário ou outro qualquer. Este método justifica-‐se pelo facto dos programas com motor de navegação virtual 3D (aka game engines) a usar, permitirem a exportação das aplicações criadas para as mais diversas plataformas, pelo que o trabalho realizado para implementar a aplicação a embutir no website possa ser valorizado. CENÁRIO 1 – Real Deal Scene •

Não existe utilizador registado

•

Exceptuando os administradores, não existe distinção entre utilizadores e aquilo que eles podem aceder

•

Utilizadores não fornecem conteúdos para a aplicação

•

Actualização de conteúdos da aplicação de navegação 3D por parte da equipa é feita através do uso dos mesmos programas de implementação. É feita uma nova exportação da aplicação que vai substituir a anterior no site.

Actualização/Gestão/Permissão de conteúdos por parte de administradores é feita por backoffice

•

(CMS) CENÁRIO 2 – Million euros scene •

Existe utilizador não registado, registado e Admin

•

Apenas os U.registados têm total acesso às funcionalidades da app (excepto funcionalidades de administração)

•

Utilizadores podem fornecem conteúdos para a app.

•

Actualização/Gestão/Validação de conteúdos por parte de administradores é feita por backoffice (CMS)

CENÁRIO 3 -‐ Dream on scene •

Existe utilizador não registado, utilizador registado e admin

•

Apenas os U.registados e Administradores têm total acesso às funcionalidades da app. (excepto funcionalidades de administração)

•

Utilizadores registados podem fornecer conteúdos para a app.

•

Actualização/Gestão/Validação de conteúdos por parte de administradores é feita por backoffice (CMS)

•

Base de dados da app é actualizada pelos conteúdos inseridos no site.

•

Interacção entre utilizadores na aplicação de navegação 3D

•

Base de dados da aplicação de navegação 3D é actualizada automaticamente pelos conteúdos inseridos no site.

Os requisitos funcionais mais relevantes para o projecto são: o desenvolvimento da visita virtual

pelo campus, a timeline Web e a interacção através de teclas de navegação e rato. Estes requisitos são fundamentais para a compreensão do conceito do projecto, os que apresentam maiores desafios e incerteza técnica, pelo qual serão áreas de prototipagem. Para uma melhor visualização dos requisitos funcionais, cenários, módulos e tipos de utilizadores, eis o seguinte ficheiro com a respectiva listagem. Módulo Extra 1

Exportação para dispositivo mobile •

Aplicação instalada em smartphone (android / iPhone)

Utilizador escolhe espaço temporal na timeline (timeline na própria aplicação de navegação

•

virtual 3D) •

Utilizador navega pela aplicação da mesma forma que o faz na aplicação para Web

•

Possibilidade de interacção com sistema de GPS do dispositivo para localização geográfica do mapa do Campus.

Módulo Extra 2 Interfaces Naturais •

Aplicação instalada no PC (através de ficheiro executável)

•

Utilizador escolhe espaço temporal na timeline (timeline na própria aplicação de navegação virtual 3D) Utilizador navega pela aplicação através dos gestos realizados com as mãos e corpo e que

•

substituem, automaticamente, aqueles usados pelo teclado e rato (configuração dos gestos/comandos a usar é feita, programaticamente, na aplicação que gere o dispositivo kinect) Módulo Extra 3 Exportação para consolas de jogos (XBOX, Wii, PS3) •

Aplicação executada através de DVD inserido no dispositivo

•

Utilizador escolhe espaço temporal na timeline (timeline na própria aplicação de navegação virtual 3D) Utilizador navega pela aplicação através dos gestos realizados com os controladores respectivos

•

que substituem, aqueles usados pelo teclado e rato (a configuração de teclas a usar é alterada na altura da exportação para a respectiva plataforma) 5.Listagem dos requisitos não funcionais do projecto

Os requisitos não funcionais expressam como deve ser feito o projecto – os padrões de qualidade e servem de auxílio para perceber se o sistema está a ser eficiente de modo a satisfazer os diferentes requisitos funcionais. Definiram-‐se os seguintes requisitos não funcionais:

 Requisitos de segurança O sistema não permite que utilizadores não autorizados insiram/actualizem conteúdos. Apenas podem visualizar a informação;1  Requisitos de compatibilidade Garantia da compatibilidade com os diferentes browsers (exclusivo para websites) e resoluções; No caso da implementação do módulo mobile, garantir a visualização e funcionamento nos diversos dispositivos móveis;  Requisitos de usabilidade A aplicação centra-‐se no utilizador, tendo que obedecer a alguns requisitos do ponto de vista a garantir a eficácia, eficiência e satisfação do utilizador. Os requisitos, do ponto de vista da usabilidade a utilizar, incluem a título de exemplo: Visibilidade constante dos elementos relevantes, consistência geral, prevenção e recuperação de erros e ajuda e suporte;  Requisitos de entrega A entrega de todos os momentos de avaliação do projecto terá que ser feita atempadamente, sem descurar a qualidade dos mesmos. É necessário garantir um trabalho e respectivo planeamento contínuo para a entrega final em Junho.  Requisitos de fiabilidade e de desempenho Com vista à redução de falhas no sistema e ao aumento da confiança do utilizador na aplicação, é necessário garantir a diminuição dos erros do sistema, obtido através de um processo de debugging contínuo e iterativo. A aplicação terá que ser optimizada ao nível do conteúdo 3D de forma a proporcionar uma boa performance num número alargado de equipamentos.  Requisitos de acessibilidade De forma a alargar as potencialidades dos utilizadores, optar-‐se-‐á por um design inclusivo que seja acessível em termos de informação -‐ através de texto ou áudio, e ao nível da interacção -‐ através de rato ou teclado. 1 Entenda-‐se por utilizadores não autorizados – sem registo validado pelo sistema.

Perfis (utilizadores)

Cenário

Requisitos Funcionais

1 2 3

Não Registado registado

Admin.

Tecnologia por módulos

Controlo da Interação

Área informativa Visualização de Informação sobre projecto Quem é a equipa O que é o projecto Contactos específicos gerais Prestar ajuda / apoio ao utilizador Sistemas de ajuda integrados / sensíveis ao contexto tooltips mensagens de erro Sistemas de ajuda autónomos Como interagir com a aplicação perguntas mais frequentes (FAQ) Sistema de Pesquisa

2 3

Preenchimento questionário Email Password Dados pessoais Nome / Apelido Data nascimento foto Existe ligação à UA (Docente / estudante / … ) Envio mail validação / confirmação LOGIN Autenticação (email/pass) Recuperação de password Envio de password nova para email do utilizador GALERIA (utilizadores registados / admins) Visualização de conteúdos (navegação por listagem visual dos conteúdos categorizados) Textos Galeria de fotos Galeria de videos Inserção de comentários Like Share Inserção de conteúdos Textos Galeria de videos Comentários Like Share

navegação numa linha temporal com datas pré-definidas Pontos de interesse seleccionáveis, com informação resumida Escolha do periodo de tempo para navegação virtual. (ligação à app embebida na página)

Aplicação independente de navegação virtual (pode ser necessário instalar plugin na 1ª utiliz.) Entrada na aplicação de navegação virtual - Loading com info e logo Vista aérea do campus, escolha do ponto de partida da interacção (Os vários pontos a escolher serão predefinidos no campus - dependem do período temporal escolhido) Ajuda à navegação Disponibilização de um mapa (sempre visível na interface para utilizador saber onde se encontra numa perspectiva geral) Escolha de um novo ponto de acesso no campus (Botão MAP, acedido por rato ou teclado) Escolha de um departamento específico (Botão MAP, acedido por rato ou teclado) Existência de um espaço visível para info do estado do sistema / ajudas contextuais) menu de ajuda à navegação on-demand (Botão HELP, acedido por rato ou teclado) Aumento do ecrã para melhor visualização (Botão FULLSCREEN) Possibilidade de desligar SOM ou regular Volume (Botão SOUND ON/OFF /VOL) Escolha de novo período temporal (alteração imediata independente do local no campus onde se esteja) (Botão Timeline) Navegação livre pelo espaço, utilizador escolhe percurso que pretender pelo campus Visualização do percurso e objectos (360º) Interacção com o objectos no campus (a aproximação a edificios/equipamentos relevantes despoleta um objecto/GUI (até então invisível) que permite obter informações sobre ele. Texto informativo Audio Imagem Video

CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS

+ plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin + plugin

rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado

CMS CMS CMS CMS

+ plugin + plugin + plugin + plugin

rato ou teclado rato ou teclado rato ou teclado rato ou teclado

Visita Virtual Timeline histórica

CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS CMS

Área de conteúdos REGISTO utilizador

1 2 3

* * * * * * * * * * * * * *

Interacção com outros utilizadores existentes ao mesmo tempo na app Visualização da info do utilizador Chat na aproximação a outros utilizadores (avatares), aparece janela para colocação de texto

(embebido no site) Engine 3D Engine 3D

sem interacção botão esquerdo do rato

Engine 3D

botão na interface ou tecla (M)

Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D

botão na interface ou tecla (M) botão na interface ou tecla (M) sem interacção do utilizador botão na interface ou tecla (H) botão na interface ou tecla (F) botões na interface ou teclas (S/+/-)

Engine 3D

botão na interface ou tecla (T)

Engine 3D Engine 3D

setas direcionais (teclado) movimento do rato

Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D Engine 3D

botão na interface ou tecla (i) controlo por botoes controlo por botoes controlo por botoes controlo por botoes

na interface na interface na interface na interface

botão na interface ou tecla (u) botão na interface ou tecla (c) teclado

((Entrada nos edifícios NÃO permitida))

Engine 3D

botão na interface, tecla escape ou alt+F4, fechar/mudar página.

Monitorização da performance da aplicação

CMS (back-office) CMS (back-office) CMS (back-office) CMS (back-office) CMS (back-office) CMS (back-office) CMS (back-office)

rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado rato ou teclado

Actualização da documentação de apoio

CMS (back-office)

rato ou teclado

fechar aplicação

1 2 3

Área administrativa Selecção e filtragem de conteúdo multimédia enviado pelos utilizadores Associação do conteúdo recebido a objectos especificos Disponibilização da informação recebida na aplicação de navegação virtual Alteração/Actualização da aplicação de navegação virtual Actualização/integração de conteúdos do site web Resposta a pedidos/comentários/emails dos utilizadores (Manutenção e suporte)

legenda:

CMS

Content management system

plugin

módulo externo que a integrar no CMS

engine3D

motor de gráficos 3D para navegação virtual modelador objectos 3D linguagem de programação editor de imagens / fotografias editor de audio

todos os itens operacionalizados pelo utilizadores através de um website, com recurso a um browser.

* utilizador registado existe apenas no cenário 2 e 3.

Entretanto, os diferentes requisitos funcionais foram traduzidos em tarefas e acrescentadas e calendarizadas no GANTT do projecto. Tarefas a realizar (actualizadas no Gantt):

0. Planeamento •

Storyboard da aplicação;

•

Protótipo baixa-‐fidelidade;

•

Protótipo versão beta;

•

Protótipo versão alfa;

•

Estudos de usabilidade e acessibilidade;

1. Recolha de Informação •

História da UA

•

Levantamento do património Arquitectónico da UA;

•

Recolha de plantas dos edifícios, topografia;

•

Fotografia aos edifícios da UA;

•

Redacção da Informação sobre o projecto;

•

Redacção da Informação disponível na aplicação;

•

Recolha/Elaboração de materiais/texturas;

2. Desenvolvimento Gráfico •

Elaboração da marca do projecto UARhere;

•

Elaboração do template do website que suporta a aplicação;

•

Grafismo dos mecanismos de ajuda ao utilizador;

•

Grafismo da Timeline do período temporal;

2. Web

•

Programação da Timeline;

•

Ligação entre conteúdos/informação do website;

•

Integração do Unity no website;

3. 3D •

Modelação de edifícios;

•

Modelação do espaço envolvente;

•

Modelação de objectos

•

Texturização; 3. Unity

•

Iluminação;

3.1. Programação

•

Movimentação da câmara;

•

Interacção com objectos

Viabilidade Técnica Depois de detalhar os requisitos funcionais, segue-‐se a pesquisa das tecnologias que solucionam a satisfação desses requisitos, selecção e sua justificação da solução tecnológica.

MÓDULO ENGINE 3D Para cumprir com os objectivos pretendidos para o projecto, de construção de uma aplicação que permita navegar e interagir com o campus e seus objectos, é necessária uma ferramenta autor que permita esse tipo de interacção. A ferramenta autor terá de ter um motor que permita a renderização em tempo real dos objectos a mostrar, para que o utilizador tenha liberdade na escolha do caminho a seguir, e não fique limitado a um percurso pré-‐definido logo à partida. Dessa forma, fica desde logo rejeitada a escolha da ferramenta autor Adobe Flash, pois não permite esse tipo de renderização em tempo real. Existe outro filtro importante a ter em consideração. O focus do projecto é utilização de um sistema em 3D, pelo que há uma restrição nas ferramentas que permitem apenas a utilização de navegação em 2 Dimensões. Tendo isto em consideração, foram analisadas todas as ferramentas que existem no mercado, e após uma forte seriação, foram analisados, com mais rigor, as seguintes ferramentas: •

Unity3D

•

ShiVa3D

•

Torque 3D

•

Unreal Engine (UDK)

UNITY http://unity3d.com/ Developer: Unity Technologies Platformas de exportação: PC, Mac, iPhone, iPad, Wii, Xbox, Android, PS3 Suporte para Browser: Sim

•

PONTOS FORTES •

3 linguagens de programação: JavaScript, C# e Boo (dialecto de Python)

•

Versão Free sem período de teste

•

Recursos podem ser importados para o projecto através de drag-‐and-‐drop

•

Editores de script integrado e com várias hipóteses de escolha na comunidade

•

Publicação na Web com rápido motor 3D

•

Desenvolvimento para Macs e Windows

•

Implementação PhysX

•

Fácil exportação

•

Teste de cenário extremamente rápido com alteração de variáveis em tempo real

•

Enorme comunidade e ainda em crescimento, muito útil para resolver problemas

•

Partilha em PC, Mac, iPhone/iPad, PS3, Xbox, Wii, Android

•

Plugin Unity3D extremamento pequeno, com instalação rápida e sem necessidade de reiniciar browser.

•

PONTOS FRACOS •

Preço da versão PRO (1500€) e ADDONS (exportação para plataformas adicionais) (entre 400€ e 1500€ cada)

•

Versão free com splash screen forçado

•

Sem platforma 2D

•

Texturização algo limitada

•

Requisitos mínimos de sistema •

Windows: XP SP2 or later;

•

Mac OS X: Intel CPU & "Leopard" 10.5

•

Placa Gráfica com 64 MB of VRAM e pixel shaders.

ShiVa3D http://www.stonetrip.com/ Developer: stonetrip Platformas de exportação: Windows, Mac, Linux, iPhone, iPad, Android, Palm, Web e Wii Suporte para Browser: Sim

•

PONTOS FORTES •

Publicação para iPhone gratuita

•

Preços de venda baixos

•

Sem splash screens forçados

•

PONTOS FRACOS

•

Funciona em MAC mas apenas pelo parallels

•

Linguagem de programação LUA

•

Comunidade não muito forte

•

Linguagem interpretada e não reconvertida

•

Requisitos mínimos de sistema Windows XP or higher is required.

Placa gráfica 16Mb memória

TORQUE 3D http://www.garagegames.com/products/torque-‐3d Developer: GarageGames Platformas de exportação: PC, Mac, Xbox 360, Wii, iPhone, PS3, PSP Suporte para Browser: Sim

•

PONTOS FORTES •

Plataforma 2D e 3D

•

Loja de

•

Developer store -‐ É possivel comprar código ou recursos para a aplicação

•

Rede de mais de 150 mil developers (partilha de recursos, empregos etc)

•

Grande controlo sobre o ambiente de jogo

•

Capacidade de render superior comparando com a concorrência

•

Muita e boa documentação

•

PONTOS FRACOS •

Preços diferentes para as diferentes plataformas

•

Torque 3D apenas suporta C/C++ (TorqueScript )

•

Curva de aprendizagem muito acentuada

•

Não tem editor de GUI e material

•

Requisitos mínimos de sistema PC: Windows XP or Vista Intel or AMD Processor @ 1 Ghz 512 MB RAM (1GB recommended for Vista) 100% DirectX compatible video card with 256 MB video RAM required DirectX 9.0c+

OSX 10.6.1: Intel-‐based Macs only 2 GB RAM ATI or nVidia shader model 4.0+ video cards with 256 MB video RAM required XCode version 3.2 or better

C++ Compiler

UNREAL http://www.unrealengine.com/ Developer: Epic Platformas de exportação: PC, Mac, Xbox 360, PS3 Suporte para Browser: Não

•

PONTOS FORTES •

Motor muito forte

•

Luz em tempo real extremamente realista

•

Efeitos de camera incriveis, que permitem mudar o cenário completamente

•

Editores GUI / materiais bastante poderosos

•

PONTOS FRACOS

•

Muito lento na importação de recursos

•

Pagamento de royalties (25%)

•

Optimizado para jogos

•

Necessário programar practicamente todos os aspectos do jogo

•

HARDWARE NECESSÁRIO •

PC •

Windows XP SP2 or Windows Vista

•

2.0+ GHz processor

•

2 GB system RAM

•

SM3-‐compatible video card

•

3 GB free hard drive space

CONCLUSÕES e ESCOLHA Através de uma pequena análise efectuada às características de todas as ferramentas, a escolha não se apresenta fácil. Isto apesar do grupo ter maior inclinação para o Unity3D verifica-‐se que a hipótese Torque 3D é bastante forte, sendo mesmo um adversário de peso. As duas ferramentas são muito similares nos diversos pontos analisados, que foram considerados mais relevantes para o projecto. Entre eles destacamos a imensa comunidade de developers e curiosos q ambas têm, assim como uma curva de aprendizagem muito pequena. Outro dos pontos-‐chave presente nas duas aplicações é o facto de permitirem a exportação para as mais variadas plataformas, inclusive -‐ e mais relevante para o projecto, a exportação para web, o que aumenta consideravelmente o número de potenciais utilizadores da aplicação a criar. Estas duas aplicações também se destacam das demais pela quantidade enorme de tutoriais existentes na internet e ter uma interface de importação de conteúdos drag-‐and-‐drop, extremamente simples e eficaz.

A ferramenta ShiVa3D foi completamente posta de parte, enquanto a Unreal engine exige muitos conhecimentos (e muita prática) em programação orientada a objectos, e também está idealizada para criação de jogos. A escolha recai então entre o Unity3D e o Torque 3D, contudo existem alguns motivos que fazem o grupo escolher a primeira em detrimento da segunda. Dois desses motivos são extremamente relevantes. Em primeiro lugar o unity3D é gratuito (embora com algumas pequenas limitações a níveis de funcionalidades muito avançadas, que provavelmente não serão implementadas). Em segundo lugar, o unity3D usa o JavaScript como linguagem de programação, linguagem já estudada durante o curso, e que todos os elementos do grupo se sentem relativamente à vontade. Além disso, existem bastantes componentes de script pré-‐fabricadas pela comunidade, sejam em Javascript, C# ou Boo, que podem facilmente ser integradas no projecto. Mesmo que os scripts sejam de linguagens diferentes, o programa permite o seu uso em simultâneo, algo que o grupo consideram uma poderosa mais-‐valia.

Módulo CMS A criação de uma plataforma web não é um objectivo definido nos parâmetros do projecto UARhere. Existe unicamente a necessidade de expor a aplicação como objecto de utilização por parte dos utilizadores. Assim sendo, e de forma a atingir o maior número de utilizadores e diferentes perfis, é necessário colocar a aplicação (produzida em Unity 3D) num website. Todavia, por limitação temporal, o grupo de trabalho optou por não criar uma plataforma “de raíz”, e utilizar um CMS. Um CMS (Content Management Systems) consiste numa plataforma de gestão de conteúdo de websites, portais, servindo inclusive de intranet, integrando frameworks e/ou plugins necessários para criar, editar e inserir conteúdos, anulando a necessidade de programar exaustivamente, pois o seu objectivo passa por facilitar a criação, administração, distribuição, publicação e disponibilidade da informação. DRUPAL http://drupal.org/requirements Pontos fortes do Drupal •

Apropriado para programadores seniores e “amantes” de código;

•

Grande Comunidade que fornece feedback de plugins e discute problemas que surgem; Pontos fracos do Drupal

•

Difícil para quem não domina claramente código de programação Web;

•

Não aconselhável para designers;

•

Fraca estrutura gráfica dos templates disponibilizados;

Requisitos Mínimos do Sistema

•

3Mb de espaço no disco;

•

Webserver:

•

Apache 1.3;

•

Microsoft IIS5

•

Base de dados:

•

MySQL 3.23.17;

•

PHP 4.4.0;

WORDPRESS

http://wordpress.org/about/requirements/ Pontos fortes do wordpress •

Simplicidade de utilização;

•

Muito bom para partilha de informação sequencial (tipo blog);

•

Grande variedade de plugins e frameworks

Pontos fracos do wordpress •

Fraca comunidade (pouca partilha de frameworks e criticas demasiado generalistas);

•

Fracos upgrades (em quantidade e em qualidade)

Requisitos Mínimos do Sistema •

Webserver:

•

Apache 1.3;

•

Base de dados:

•

MySQL 4.1.2;

•

PHP 4.3.0;

JOOMLA http://help.joomla.org/content/view/1938/310/ Pontos fortes de Joomla •

Adapta-‐se a qualquer perfil (desde designers até programadores);

•

Comunidade enorme (facilita partilha de módulos e plugins);

Pontos fracos do Joomla •

Grandes diferenças entre as diferentes versões;

•

Demasiado simples a nível gráfico, comparativamente com o wordpress

Requisitos Mínimos do Sistema •

Webserver:

o Apache 1.3; •

Base de dados: o MySQL 3.23;

•

PHP 4.3.10;

Conclusão

O CMS escolhido para implementar o website foi o wordpress. Com o intuito de economizar tempo de construção do site, teve-‐se em elevada consideração o facto de todos os elementos do grupo possuírem conhecimentos de gestão e funcionamento do wordpress. No fundo, é a via mais eficaz, traduzindo-‐se assim numa curva de aprendizagem bastante inferior, comparativamente a outros CMS. Outro facto importante é a existência de um plugin do game engine escolhido, Unity 3D, existir unicamente para Wordpress. Este plugin destaca-‐se por possuir características que possibilitam uma melhor performance do “player” do unity num website. Sendo este facto exclusivo do wordpress, tornou-‐se ainda mais óbvia a escolhida feita pelo grupo de trabalho.

Módulo modelação de objectos 3D

Sendo um dos objectivos gerais do projecto a construção dos edifícios e dos espaços envolventes, traduzindo-‐se no ambiente virtual em 3D do Campus de Santiago, é primordial a necessidade de recorrer a uma ferramenta de modelação de objectos 3D. 3D Studio Max http://usa.autodesk.com/3ds-‐max/system-‐requirements/

Plataforma: Microsoft Windows XP Professional ou Homem edition

Hardware: •

Intel® Pentium® 4 1.4 GHz;

•

2 GB RAM (

•

Direct3D® 10 technology, Direct3D 9, or OpenGL-‐capable graphics card (256 MB or higher video card memory, 1 GB or higher recommended)

Pontos fortes do 3D Max •

Grande variedade de plugins

•

Grande Comunidade que fornece feedback de plugins e discute problemas que surgem;

•

Elevado número de objectos (modelos) disponíveis na internet;

•

Excelente para modelação;

•

Excelente para animação;

•

Opções de texturização bastante personalizadas;

Pontos fracos do 3D Max •

Dificil para iniciantes;

•

Programa não gratuito (e caro);

•

Curva de aprendizagem muito grande; Cinema 4D:

http://www.maxon.net/products/general-‐information/general-‐information/system-‐requirements.html

Plataforma: Windows •

Windows 7 (all variations)

•

Windows Vista (all variations)

•

Windows XP (Pro / Home) Service Pack 2 & 3

OS X •

Apple OS X 10.6 (and up)

•

Apple Mac OS X 10.5.8 (and up)

Hardware: Minimum CPU Requirements CINEMA 4D R12 and BodyPaint 3D R12 Minimum processor Windows PC •

Intel Pentium 4

•

Athlon 64

•

Sempron (K8 with SSE2)

•

VIA C7

Minimum processor Macintosh •

Intel CoreSolo

Pontos fortes do cinema 4d •

Crescente nos utlimos anos;

•

Grande variedade de plugins de texturização e sonorização;

•

Fácil de utilizar, comparativamente com o 3D Studio Max;

Pontos fracos do cinema 4d •

Interface pouco “ergonómica”;

•

Não possui scripting de User Interface;

•

Mais fraco para modelar objectos típicos de arquitectura (edifícios), comparativamente com o 3D Studio Max;

Blender: •

1 GHZ Single Core CPU

•

512 MB RAM

Pontos fortes de blender •

Opensource;

•

Simples de utilizar;

•

Grande comunidade de partilha de informação;

•

Importa modelos 3ds;

•

Suporta linguagem scripting comum (pinthon);

•

Exporta vídeo e scripts jogo 3d;

•

Muito bom para modelação;

Pontos fracos do blender •

Poucos plugins

•

Demasiado simples para a dimensão do projecto

•

Interface pouco intuitiva, especialmente nas versões 2.4;

•

Difícil para iniciantes;

CONCLUSÃO 3D Studio Max A ferramenta de modelação de objectos 3D escolhida foi o Autodesk 3D Studio Max. A maior razão para este software ter sido o escolhido foi o facto do grupo de trabalho ter experiência com a ferramenta. Todos os elementos do grupo já efectuaram projectos com o 3D Studio Max, até porque este foi leccionado na unidade curricular de Imagem Digital Dinâmica, no ano lectivo em que os elementos do grupo frequentaram a disciplina. Assim, concretizaram-‐se alguns trabalhos e formações específicas da

ferramenta. Este factos são preponderantes para a escolha da equipa projectual e vão ao encontro da prática que se pretende adoptar: “Tempo é dinheiro!”. Ora, se todos os elementos do grupo dominam a ferramenta, necessitarão então de um tempo de aprendizagem claramente menor, em relação a outro software de modelação 3D. Desta forma, a curva de aprendizagem será muito baixa, o que será menos um obstáculo que o grupo terá que enfrentar. Outro facto importante de ressalvar é a fácil integração que o 3D Studio Max tem com game engine escolhido, o Unity 3D. Não será necessário efectuar qualquer tipo de renderização na ferramenta de modelação. O Unity 3D possibilita a importação de ficheiros de extensão “.max” (ficheiro do 3D Studio Max), poupando-‐se assim tempo que se gastaria a renderizar.

Módulo Editor de Imagem A necessidade de possuir um editor de imagem prende-‐se ao facto de muitas texturas a serem utilizadas e integradas em objectos 3D, necessitarem de ajustes e pequenas edições, afim de provarem o efeito desejado como textura. Também é de referir, que o pelo projecto, passa uma fase de digitalização documental, especificamente fotografias e plantas, que ao serem digitalizadas, necessitaram de ajustes no âmbito da saturação e níveis das cores. PHOTOSHOP Vantagens -

Manipulação de níveis e saturação de cores

Compatibilidade vectorial;

Capacidade de implementar filtros e efeitos;

Integração de fontes;

Grande variedade e quantidade de plugins;

Grande comunidade que partilha experiências e tutoriais realizados com o programa;

Múltiplas plataformas (Windows; Mac OS, Linux);

Desvantagens -

Elevada dependência de plugins;

Complexo para iniciantes;

Licenças pagas com valores elevados

PICNIK Vantagens -

Rápido ao executar;

Fácil de usar;

Não é necessário instalar plugins e módulos;

Bons efeitos;

Desvantagens -‐ Pouco controlo (dificuldade em editar) sobre as imagens, comparativamente com o photoshop -‐ Inexistências de layers e mascaras; -‐ Poucas opções além dos efeitos; -‐ Necessário pagar anuidade para utilizar “opções avançadas”. GIMP Vantagens -

Rápido ao executar;

Não é necessário instalar plugins e módulos;

Gratuito;

Boa comunidade de partilha de tutoriais (especialmente vídeo tutoriais);

Compatível com múltiplas plataformas

Desvantagens -

Interface pouca intuitiva;

Alterna a performance do pc;

Difícil para iniciantes

COREL PAINTSHOP PRO Vantagens -

Rápido ao executar;

Acessível, com muitos recursos;

Compatível com plugins e filtros de photoshop;

Boa comunidade de partilha de tutoriais (especialmente vídeo tutoriais);

Compatível com múltiplas plataformas

Desvantagens

Fraco a executar em máquinas pouco recentes;

Limitado ao nível de capacidade de edição do tipo RAW

Conclusão O software de edição de imagem escolhido é o Adobe Photoshop. Para além de toda a potencialidade que a ferramenta em si possui, ao nível de plugins e filtros, deve-‐se realçar, mais uma vez, o facto de todos os elementos do grupo possuírem conhecimentos sobre a utilização deste software, que também foi leccionado na unidade curricular de Lab MM I. Como já foi referido noutros módulos, é essencial que a equipa projectual economize o máximo possível o seu tempo, pois muitas das escolhas realizadas pelo grupo de trabalho, foram sempre limitadas pelo factor tempo.

Módulo Editor de som A presença e existência de elementos sonoros no projecto UARhere tem o objectivo de aproximar a aplicação em si da realidade, transmitindo uma maior veracidade do ambiente e espaço em que o utilizador se poderá encontrar. Não só para diminuir a diferença entre o mundo virtual (típico da aplicação) e o mundo real, existe também a necessidade de presença sonora do tipo narrativo-‐vocal, que decorrerá sempre que o utilizador desejar saber informações sobre um dado edifício do campus. Desta forma, poderá continuar a sua navegação, e, simultaneamente, escutar as informações que vão sendo transmitidas pelo “narrador”. A fim de garantir maior qualidade sonora, tanto nos elementos sonoros de ambiente, assim como as informações via voz, é necessário utilizar uma ferramenta que permita editar os referidos elementos.

AUDITION http://www.adobe.com/products/audition/systemreqs/ Windows •

Intel Pentium 4 (1.4GHz para DV, 3.4GHz para HDV);

•

Microsoft Windows XP Professional oo Home Edition;

•

512MB de RAM;

•

10GB de Disco; Vantagens -

Bastante intuitivo;

Plugins muito bons;

Ideal para edições simples;

Múltiplas plataformas (Windows; Mac OS);

Desvantagens -

Fraco para compor;

Complexo para iniciantes;

Licença paga com valores elevados

AUDACITY http://audacity.sourceforge.net/download/windows http://audacity.sourceforge.net/download/mac Windows •

Intel Pentium 4 (1.4GHz para DV, 3.4GHz para HDV);

•

Microsoft Windows XP Professional ou Home Edition;

•

512MB de RAM; Mac

•

Mac OS X 10.1;

•

64MB de RAM;

•

300MHz processador; Vantagens -

Gratuito;

Exporta para a maior parte dos formatos de som;

Fácil de usar para iniciantes;

Bastante bom para edições simples;

Desvantagens -‐ Interface demasiado básica; -‐ Suporta poucos plugins; NUENDO http://www.steinbergusers.com/nuendo/nuendo_feat_req.php Windows

-‐ Processador Intel / AMD 2 GHz; -‐ 1 GB RAM; -‐ Windows XP Home Edition ou XP Professional; -‐ Windows DirectX compatível com hardware de audio; -‐ Porta usb para inserir activação de licença, via pen; Mac -‐ Power Mac G4 1 GHz ou Core Solo 1.5 GHz; -‐ 1 GB RAM; -‐ Mac OS X Versão 10.4; -‐ CoreAudio compativel com hardware áudio; -‐ Porta usb para inserir activação de licença, via pen; Vantagens -

Não é necessário instalar plugins e módulos;

Boa comunidade de partilha de tutoriais (especialmente vídeo tutoriais);

Compatível com múltiplas plataformas

Desvantagens -

Difícil para iniciantes;

Performance do programa é fraca a executar;

Conclusão e escolha de software de edição de som O software escolhido para efectuar edição de soma o longo do projecto é o Audacity. O facto de ser um software open-‐source, facilita bastante a utilização deste software, ao nível da instalação e execução do mesmo. A experiência do grupo de trabalho com o software foi uma das razões mais fortes para se optar pelo audacity. Todos os elementos do grupo já trabalharam com o programa, realizando até projectos em Lab MM I, onde foi leccionada a ferramenta. Desta forma, é uma grande vantagem possuir experiência, no âmbito projectual, com o programa, visto que é uma via de economizar tempo. É uma grande vantagem o facto do audacity ser uma ferramenta “ideal” para edições de som simples. O projecto UARhere não necessitará de uma exaustiva e pormenorizada edição de som. Unicamente, é imperial que os sons presentes na aplicação estejam com a qualidade mínima exigida. Assim sendo, serão efectuadas edições de som simples (cortes, retirar ruído, filtros), anulando-‐se a necessidade de se utilizar uma ferramenta demasiado complexa para o efeito.

Por fim, é bastante vantajoso que uma ferramenta como o Audacity, típica de edições de som pouco complexas, não limite os tipos de formatos a exportar. Este software exporta para múltiplos formatos, abrangendo assim a várias possibilidades de tipos de ficheiros de som que o grupo poderá optar.

Fig.1 – Explicação simplificada do funcionamento da aplicação O utilizador acede à aplicação do projecto UARhere através do browser, com a aplicação de navegação virtual importada. Todos os ficheiros e aplicação encontram-‐se alojados no servidor que estabelece a ligação à base de dados. Requisitos técnicos •

O Projecto e toda gestão que acarreta, quer de tempo e recursos, está a ser gerida pelo programa Zoho. Todas as funcionalidades a implementar vão ser geridas através do Zoho (www.zoho.com).

Conclusão Pretende-‐se agora fazer um resumo das opções tomadas durante estas duas últimas semanas que estão patentes no documento. Para começar referir novamente que o focus do projecto é a aplicação de navegação pelo campus de Santiago, permitindo ao utilizador inteirar-‐se de evolução do mesmo. Para tal, as componentes mais importantes do projecto, são, sem dúvida, a modelação dos objectos do campus, o mais fiel possível. Em paralelo, é necessária a criação de um sistema de navegação virtual, que dê “vida” a esses objectos. É aí que entra o engine 3D (motor de navegação virtual em 3 dimensões). O engine 3D que escolheu foi o Unity3D, pela sua capacidade de integração de componentes externos feitos pela comunidade, que também produz imensos tutoriais de ajuda a usar a aplicação. Além disso a aplicação é gratuita e usa uma linguagem de programação amiga dos elementos do grupo, o JavaScript. A ferramenta para criação dos objectos em 3 dimensões será o Autodesk 3D Studio Max 2011, dado ser uma ferramenta já perfeitamente dominada pelo grupo, e, entre outros motivos, ser muito simples e rápida a exportação para o Unity3D. Dado ser necessária o uso de texturas, por exemplo para os edifícios, vai ser necessário o uso de um programa de edição de imagem, que também servirá para criar o GUI (Graphical User Interface) necessária à aplicação. Para tal será usado o Adobe Photoshop, programa usado desde o 1º ano da licenciatura que este projecto termina. Esta aplicação também servirá para alguns pequenos ajustes em imagens necessárias para o website, que iremos falar já de seguida. Para a aplicação a criar ser usada por um grande número de pessoas, a melhor maneira será tê-‐la disponível na internet. A escolha do motor3D unity também tem algo a ver com isso, dado que ele permite a exportação para a web, sendo necessário apenas a instalação de um pequeno plugin no browser, que é instalado exactamente da mesma maneira que o plugin do Adobe Flash também para browser. Para a aplicação ficar disponível online é então necessário ter um website e ficou desde logo assente que não se faria um site de raiz, dado que seria praticamente um novo projecto, e se optaria por uma solução CMS. O CMS escolhido foi então o WordPress dada a experiência do grupo em projectos anteriores, e o uso de um plugin próprio para o unity3D, apenas para nomear dois dos motivos dessa escolha. Escolhido o CMS partiu-‐se para a procura de diversos plugins que

possibilitassem o ajuste do website às necessidades do projecto. Entre muitos, optou-‐se por escolher alguns plugins q permitem a gestão de utilizadores, a inserção e gestão de conteúdos multimédia e inserção de timeline. Para terminar, uma referência ao programa de edição de som, dado ser o áudio ser valência interessante do projecto, que certamente trará mais valias a nível de interacção e acessibilidade. O programa a usar para essa edição será o Audacity, mais um programa dominado pelo grupo, extremamente simples, mas suficiente para o nível de detalhe que se pretende. Verificou-‐se também se todos estes programas supracitados estão aptos a correr, com a rapidez e eficiência necessária, no hardware próprio (computadores) dos elementos do grupo, algo que se veio a confirmar. Uma última nota para o facto de não se fazer referência a servidores web, e tudo o que lhe seja anexo, que são essenciais para o website “viver”. O grupo acha que este não é o momento para se entrar nesse nível de detalhe técnico, aguardando um próximo trabalho-‐ prático para o fazer.

Fontes de consulta •

http://forum.unity3d.com/threads/60041-‐Unity-‐vs-‐UDK

•

http://simplegoogly.blogspot.com/2009/11/unity3d-‐vs-‐torque.html

•

http://8bitfeed.com/2009/09/unity-‐3d-‐vs-‐shiva-‐vs-‐torque/

•

http://www.jadbox.com/2009/04/haxe-‐vs-‐unity3d-‐vs-‐xna-‐vs-‐others/

•

http://www.unrealengine.com/

•

http://klumhru.wordpress.com/2010/07/20/unity3d-‐vs-‐udk/

•

http://unity3d.com/unity/system-‐requirements.html

•

http://www.unrealengine.com/

•

http://www.garagegames.com/products/torque-‐3d

•

http://www.slideshare.net/Webnific/cms-‐comparisson-‐3850088

•

http://webmais.com/comparacao-‐dos-‐cms-‐wordpress-‐joomla-‐drupal-‐e-‐plone/

•

http://designmess.com/article/wordpress-‐vs-‐joomla-‐vs-‐drupal-‐what-‐cms-‐best-‐you

•

http://speckyboy.com/2010/02/04/joomla-‐wordpress-‐and-‐drupal-‐should-‐you-‐look-‐outside-‐ the-‐big-‐3/

•

http://www.goodwebpractices.com/other/wordpress-‐vs-‐joomla-‐vs-‐drupal.html

Tabela de comparação de aplicações nos diversos módulos

Módulo Engine 3D

Módulo Modelação Unity 3D

ShiVa3D

Torque 3D

Unreal Engine

Módulo CMS 3D Max

Cinema 4D

Blender

Requisitos minímos de Sistema

Facilidade de uso

Flexibilidade

Comunidade

Experiência do grupo

Frameworks / plugins

Curva de aprendizagem

TOTAL

Legenda Requisitos mínimos

Escala (1 a 5) Números de sistemas operativos compatíveis; Abrangência de hardware;

Facilidade de uso

Nível de usabilidade e ergonomia;

Flexibilidade

Capacidade de importação e exportação de diferentes tecnologias;

Comunidade

Partilha de experiências, tuturiais e módulos/plugins por parte de utilizadores;

Experiência do grupo

Quantidade projectos realizados por elementos do grupo com o dado software;

Plugins

Diversidade e quantidade de plugins nos diversos componentes da aplicação (modelação, texturização, iluminação, animação, renderização, sonorização).

Curva de aprendizagem

Relação entre tempo e conteúdos aprendidos (Quanto mais estrelas tiver um programa, menor será a sua curva de aprendizagem)

TOTAL

Drupal

Joomla

Wordpress

Módulo Editor Imagem

Photoshop CS4

Corel Paint Shop Pro

Módulo Editor Áudio Picnik

Gimp

Requisitos minímos de Sistema

Facilidade de uso

Flexibilidade

Comunidade

Experiência do grupo

Frameworks / plugins

Curva de aprendizagem

TOTAL

Adobe Audition

Audacity

Nuendo

Resumo Soluções Tecnológicas | Requisitos funcionais Áreas (grupos de req. funcionais)

Tecnologia (para o utilizador)

Soluções Tecnológicas

Área Informativa

website (através de browser)

CMS

Área de Conteúdos

website (através de browser)

Tecnologia de background

Plugin para gestão de utilizadores

CMS

Plugin para gestão de ficheiros multimédia Outros plugins

Área de Administração

CMS - Backoffice

website (através de browser) website (através de browser)

Servidor + Domínio

CMS

Plugin para implementação Timeline Ferramenta de Modelação 3D

Visita Virtual

Aplicação de navegação virtual

Engine 3D

(embebida no website - necessita plugin

Ferram. Edição de Imagem

PC's

Ferramenta Edição de Som

Transversal ao projecto:

Competências ao nível de ling. markup xHTML, CSS e ling. de programação Javascript

Soluções escolhidas Engine 3D

Unity 3D

CMS

Wordpress

Ferramenta de Modelação 3D

3D Studio Max 2011

Ferramenta de Edição de Imagem

Adobe Photoshop CS4/5

Ferramenta de Edição de Som

Audacity

Servidor + Domínio

(a detalhar futuramente)

Plugins CMS:

PCs:

unity-wordpress-blog-plugin

2x Laptop HP DV5-1050

openID

1x Apple MacBook PRO 13"

lightbox-gallery

1x Toshiba Satellite 300-145

video-playlist-and-gallery-plugin

De acordo c/ req. mínimos das tecnologias escolhidas (ver listagem de viab. técnica)

si-contact-form

ANEXO:

Guião de perguntas Este guião de conversa serve, apenas, para efectuar um levantamento (não exaustivo) das expectativas que o público‐alvo da aplicação tem em relação a ambientes de navegação virtual. É dessa forma, um texto informal de apoio ao grupo nas conversas com os participantes. Objectivos: ‐ Perceber quais as funcionalidades e as necessidades que o público‐alvo da futura aplicação do projecto UARhere (comunidade interessada na evolução do campus de Santiago) consideram mais relevantes ao nível do ambiente tridimensional Participantes: Efectuou‐se um estudo das necessidades dos utilizadores, no que concerne a aplicação. O conjunto de participantes subdividiu‐se nos seguintes subconjuntos1:  3 utilizadores que, com frequência, interagem com ambientes de navegação virtual;  3 utilizadores que, raramente, interagem com ambientes de navegação virtual; 1. Nunca 1 2 3 4 Sempre Com que frequência interages com ambientes de navegação virtual? Enumera alguns problemas que, frequentemente, assistes com este tipo de navegação. De que modo costumas interagir com estes ambientes (instalação no PC ou via Web)? Como preferes? 2. De 1 a 5, qual o nível de importância das seguintes funcionalidades: 1 2 3 4 5 Interacção com objectos presentes Contribuição/Partilha de conteúdos 1 Segundo Virzi e Nielsen, bastam 5 participantes para detectar a maioria dos problemas de usabilidade.

Página pessoal do utilizador Serviço chat 3. Qual a preferência de visualização? (a) Vista primeira pessoa; (b) Vista topo de modo a ver todo o cenário; (c) Vista de lado; 4. Preferência quanto ao nível do ambiente virtual? (a) Teclado; (b) Rato; (c) Botões representados na interface; Razão? _____________________________________________________________________________________________ 5. Preferência quanto ao nível de navegação entre os diversos ambientes? (a) Teletransporte e pontos de referência; (b) Mapa clicável; (c) Menu 2D; (d) Opções na Web Page; 6. Considerando o desenvolvimento de uma aplicação de navegação virtual em que pudesses navegar e verificar a evolução história do campus da Universidade de Aveiro, o que gostarias que fosse implementado? Que informação relevante gostarias de aceder? Como gostarias que se processasse a navegação?