UARhere - TP2

Lil

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 O que é o projecto

o Contactos

específicos

gerais

• Ajuda / apoio ao utilizador

o Sistemas de ajuda integrados / sensíveis ao contexto

tooltips

mensagens de erro

o 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

Email

Password

Dados pessoais

• Nome / Apelido

• Data nascimento

• Foto

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

Envio mail validação / confirmação

• LOGIN

o Autenticação (email/pass)

o 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

Like

Share

o Inserção de conteúdos

Textos

Galeria de fotos

Galeria de videos

Comentários

Like

Share

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)


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


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.

1 2 3 Não registado

Registado Admin.

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

2 3

1 2 3

1 2 3

1 2 3

legenda: CMS Content management system todos os itens operacionalizados pelo utilizadores através de um website,plugin módulo externo que a integrar no CMS com recurso a um browser.

engine3D motor de gráficos 3D para navegação virtual

modelador objectos 3D * utilizador registado existe apenas no cenário 2 e 3.linguagem de programaçãoeditor de imagens / fotografiaseditor de audio

rato ou tecladorato ou tecladorato ou tecladorato ou teclado

rato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou teclado


CMSCMSCMS

CMSCMSCMSCMS

Cenário

3

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

na aproximação a outros utilizadores (avatares), aparece janela para colocação de texto

Chat

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

fechar aplicação

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

Texto informativo

Audio

Imagem

Video

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

Visualização da info do utilizador

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.

Ajuda à navegaçãoDisponibilizaçã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)

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)

Comentários

Like

Share

Timeline histórica

navegação numa linha temporal com datas pré-definidas

Pontos de interesse seleccionáveis, com informação resumida

Inserção de comentários

Like

Share

Inserção de conteúdos

Textos

Galeria de videos

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

LOGIN

Autenticação (email/pass)

Recuperação de password

REGISTO utilizador

Preenchimento questionário

Email

Password

Dados pessoais

Nome / Apelido

Data nascimento

Prestar ajuda / apoio ao utilizador

Perfis (utilizadores) Tecnologia

CMS + pluginCMS + pluginCMS + plugin

foto

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

Envio mail validação / confirmação

CMSCMSCMSCMS

CMSCMSCMS

CMS + pluginCMS + pluginCMS + plugin

Área administrativa

Sistema de Pesquisa

Sistemas de ajuda autónomos

Como interagir com a aplicação

perguntas mais frequentes (FAQ)

por módulosControlo da Interação

Visualização de Informação sobre projecto

Visita Virtual

Área de conteúdos

Área informativa

Requisitos Funcionais

Sistemas de ajuda integrados / sensíveis ao contexto

tooltips

mensagens de erro

Quem é a equipa

O que é o projecto

Contactos

específicos

gerais

CMS + pluginCMS + pluginCMS + pluginCMS + plugin

CMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + pluginCMS + plugin

CMS + pluginCMS + pluginCMS + pluginCMS + plugin

Engine 3D

(embebido no site)

Engine 3D

Engine 3D

Engine 3DEngine 3DEngine 3DEngine 3DEngine 3DEngine 3D

Engine 3D

Engine 3DEngine 3D

Engine 3D

Engine 3DEngine 3DEngine 3DEngine 3DEngine 3DEngine 3DEngine 3DEngine 3D

Engine 3D

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

CMS (back-office)

rato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou teclado


sem interacçãobotão esquerdo do rato

botão na interface ou tecla (M)

botão na interface ou tecla (M)botão na interface ou tecla (M)

sem interacção do utilizadorbotão na interface ou tecla (H)botão na interface ou tecla (F)

botões na interface ou teclas (S/+/-)

botão na interface ou tecla (T)

setas direcionais (teclado)movimento do rato

botão na interface ou tecla (i)

controlo por botoes na interfacecontrolo por botoes na interfacecontrolo por botoes na interfacecontrolo por botoes na interface

rato ou tecladorato ou teclado

rato ou teclado

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

teclado

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

rato ou tecladorato ou tecladorato ou tecladorato ou tecladorato ou teclado

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


• 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


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


• 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


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)


• 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


• 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



- 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


- Acessível, com muitos recursos;

- Compatível com plugins e filtros de photoshop;



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




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

Módulo Engine 3D

Unity 3D ShiVa3D Torque 3D Unreal Engine

Módulo Modelação

3D Max Cinema 4D Blender

Módulo CMS

Drupal Joomla Wordpress

Requisitos minímos de

Sistema


Sistema


Sistema

Facilidade de uso

Facilidade de uso

Facilidade de uso

Flexibilidade Flexibilidade Flexibilidade

Comunidade Comunidade Comunidade

Experiência do grupo



Frameworks / plugins



Curva de aprendizagem



TOTAL 30 17 28 17 TOTAL 25 20 24 TOTAL 18 20 25

Legenda

Requisitos mínimos

Facilidade de uso

Flexibilidade

Comunidade



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

Plugins

Números de sistemas operativos compatíveis; Abrangência de hardware;

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

Escala (1 a 5)

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

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

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

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

Nível de usabilidade e ergonomia;

Módulo Editor

ImagemPhotoshop CS4

Corel Paint Shop Pro Picnik Gimp

Módulo Editor Áudio

Adobe Audition Audacity Nuendo


Sistema


Sistema

Facilidade de uso Facilidade de uso

Flexibilidade Flexibilidade

Comunidade Comunidade







TOTAL 27 17 19 18 TOTAL 21 24 19

Resumo Soluções Tecnológicas | Requisitos funcionais

Áreas (grupos de req. funcionais) Tecnologia (para o utilizador)

Área Informativa

Área de Conteúdos

Visita Virtual

Área de Administração

Transversal ao projecto:

Aplicação de navegação virtual (embebida no website - necessita plugin

Ferramenta Edição de Som

PC'sEngine 3D

Servidor + Domínio

Tecnologia de background

website (através de browser)



Plugin para gestão de utilizadores

Plugin para gestão de ficheiros multimédia

Outros plugins

Soluções Tecnológicas

CMS

CMS - Backoffice

CMS

CMS

Adobe Photoshop CS4/5

Audacity

(a detalhar futuramente)

Plugin para implementação Timeline

Engine 3D

CMS

Ferramenta de Modelação 3D

Ferramenta de Edição de Imagem

Ferramenta de Edição de Som

Soluções escolhidas

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


Ferramenta de Modelação 3D

Ferram. Edição de Imagem

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

PCs:

2x Laptop HP DV5-1050

1x Apple MacBook PRO 13"

1x Toshiba Satellite 300-145

Plugins CMS:

unity-wordpress-blog-plugin

openID

lightbox-gallery

video-playlist-and-gallery-plugin

si-contact-formServidor + Domínio

Unity 3D

Wordpress

3D Studio Max 2011

ANEXO:

Guião de perguntas Este guião de conversa serve, apenas, para efectuar um levantamento (não exaustivo) dasexpectativasqueopúblico‐alvodaaplicaçãotememrelaçãoaambientesdenavegaçãovirtual.Édessaforma,umtextoinformaldeapoioaogruponasconversascomosparticipantes.Objectivos:‐Perceberquaisasfuncionalidadeseasnecessidadesqueopúblico‐alvodafuturaaplicaçãodoprojectoUARhere(comunidade interessadanaevoluçãodocampusdeSantiago)considerammaisrelevantesaoníveldoambientetridimensionalParticipantes:Efectuou‐se um estudo das necessidades dos utilizadores, no que concerne a aplicação. Oconjuntodeparticipantessubdividiu‐senosseguintessubconjuntos1: 3utilizadoresque,comfrequência,interagemcomambientesdenavegaçãovirtual; 3utilizadoresque,raramente,interagemcomambientesdenavegaçãovirtual;

1. Nunca 1 2 3 4 SempreComquefrequênciainteragescomambientesdenavegaçãovirtual?

Enumeraalgunsproblemasque,frequentemente,assistescomestetipodenavegação.Dequemodocostumas interagir comestesambientes (instalaçãonoPCouviaWeb)?Comopreferes?2.De1a5,qualoníveldeimportânciadasseguintesfuncionalidades: 1 2 3 4 5Interacçãocomobjectospresentes Contribuição/Partilhadeconteúdos 1 SegundoVirzi eNielsen, bastam5participantesparadetectar amaioriadosproblemasdeusabilidade.

Páginapessoaldoutilizador Serviçochat 3.Qualapreferênciadevisualização?

(a) Vistaprimeirapessoa;(b) Vistatopodemodoavertodoocenário;(c) Vistadelado;

4.Preferênciaquantoaoníveldoambientevirtual?

(a) Teclado;(b) Rato;(c) Botõesrepresentadosnainterface;

Razão?_____________________________________________________________________________________________5.Preferênciaquantoaoníveldenavegaçãoentreosdiversosambientes?(a)Teletransporteepontosdereferência;(b)Mapaclicável;(c)Menu2D;(d)OpçõesnaWebPage;6.ConsiderandoodesenvolvimentodeumaaplicaçãodenavegaçãovirtualemquepudessesnavegareverificaraevoluçãohistóriadocampusdaUniversidadedeAveiro,oquegostariasquefosseimplementado?Queinformaçãorelevantegostariasdeaceder?Comogostariasqueseprocessasseanavegação?

UARhere - TP2

Documents

Transcript of UARhere - TP2