Faculdade de Engenharia do Porto

Transcrição

Sérgio Fernando Grilate Louro
MAICC – Sistema Multi-Agente para
Controlo de Câmaras Inteligentes
Faculdade de Ciências, Economia e Engenharia
Universidade do Porto
2004
Sérgio Fernando Grilate Louro
MAICC – Sistema Multi-Agente para
Controlo de Câmaras Inteligentes
Tese submetida à Faculdade de Ciências da Universidade do Porto
Para obtenção do grau de Mestre em Inteligência Artificial e Computação
sob orientação do Professor Doutor Eugénio da Costa Oliveira e pelo
Professor Doutor Luís Paulo Reis
Faculdade de Ciências, Economia e Engenharia
Universidade do Porto
2004
Agradecimentos
Este espaço é dedicado a todos aqueles que deram a sua contribuição para que este
trabalho fosse realizado. A todos eles deixo aqui o meu sincero agradecimento.
Em primeiro lugar agradeço ao Professor Doutor Eugénio da Costa Oliveira e ao
Professor Doutor Luís Paulo Reis pela forma como me orientaram no meu trabalho,
pela utilidade das suas recomendações e pela cordialidade e simpatia com que sempre
me receberam.
Quero igualmente expressar os meus agradecimentos ao corpo docente do Mestrado em
Inteligência Artificial e Ciências da Computação da Universidade do Porto pela
formação transmitida durante o ano lectivo de 2001/2002.
Finalmente uma última palavra de agradecimento aos meus familiares e amigos pelo
apoio e incentivo fornecido nos momentos certos.
VII
Resumo
A crescente evolução das capacidades de processamento gráfico dos computadores tem
permitido a visualização de simulações tridimensionais cada vez mais realistas. No
entanto essa evolução não tem sido acompanhada pelo desenvolvimento de
metodologias de controlo da câmara que permitam a visualização realista de alguns
cenários tridimensionais.
A aproximação do sistema MAICC – Muti Agent Intelligent Camera Control concentra-se no estudo de um Sistema Multi-Agente utilizando o servidor soccerserver
da liga simulada do campeonato do mundo de futebol robótico – RoboCup – como
plataforma multi-agente de ensaios. O sistema tem como maior contribuição o
desenvolvimento do Virtual3D, um visualizador tridimensional com acentuado realismo
das animações e dos sons, e ainda de um Sistema Multi-Agente para controlo inteligente
de câmara que permite a visualização de jogos em tempo real, ou em diferido,
utilizando conceitos cinematográficos. Para integrar as novas metodologias de
coordenação foi desenvolvida uma plataforma de comunicação, a MAS – Multi Agent
System, com o objectivo de facilitar e acelerar a comunicação entre os agentes do
sistema. A comunicação assenta na linguagem CAMERA LANGUAGE, desenvolvida
especificamente para o domínio da filmagem.
O sistema MAICC permite o controlo automático e inteligente de um realizador e um
conjunto de câmaras (previamente posicionadas no cenário) para dar ao espectador a
melhor imagem de visualização do cenário como se de uma filmagem televisiva se
tratasse. Desta forma, os objectivos do MAICC centram-se na implementação de um
sistema descentralizado preparado para tratamento autónomo de uma filmagem com
características de adaptabilidade no decorrer do jogo de futebol simulado.
Em resumo, esta tese encerra uma proposta de SMA para o controlo de câmara
inteligente para o cenário do futebol com capacidades cooperativas e adaptativas.
Os resultados obtidos, através da utilização de um SMA associando conceitos gráficos e
cinematográficos no controlo da câmara inteligente, confirmam uma melhoria da
qualidade da visualização em relação aos visualizadores tradicionais, permitindo
concluir que a coordenação entre agentes tem um papel fundamental na filmagem das
regiões de interesse do cenário associadas a uma sincronização dos planos de filmagem.
Palavras-chave: Agentes, Sistemas Multi-Agente, Computação Gráfica, Câmara
Virtual, Cinematografia, Realizador, Operador, Futebol Robótico.
IX
Abstract
The growing capacities of computers graphical processing allow the visualization of
more realistic three-dimensional simulations. However, that evolution was not followed
by the camera control for the visualization of some three-dimensional scenarios.
The MAICC (Multi Agent Intelligent Camera Control) system focus on the study of a
multi agent system using the Soccerserver server of the RoboCup simulated league as a
rehearsal multi agent platform. One of the biggest contributions of this system is the
development of Virtual3D, a three-dimensional visualizer with very realistic animations
and sounds and also the multi agent intelligent camera control system for the
visualization of real time games, as well as differed, using cinematographic concepts.
For the integration of this new coordination methodologies a communication platform
was developed, the MAS (Multi Agent System), which has, as main goal, to facilitate
and speed up the communication among the agents of the system. The communication
has a Camera Language as its basis developed specifically for the filming domain.
The MAICC system allows this way the intelligent and automatic control of a director
and a group of cameras (previously positioned in the scenario) in order to give the
spectator a best visualization image of the scenario as if it was a television transmission.
The MAICC goals focus on the implementation of a decentralized system prepared for
the autonomous treatment of a filming with adaptability characteristics during a
simulated soccer match.
This thesis has, in that sense, a proposal for a multi agent system for the control of
intelligent cameras in a soccer scenario with cooperation and adaptation capacities.
The results obtained, using a SMA and associating graphic and cinematographic
concepts in controlling the intelligent camera, confirm a better visualization quality
when comparing with the traditional visualizers. Therefore, we can conclude that the
coordination between agents plays a fundamental role in the filming of the interest
zones of the scenario associated with a synchronization of the filming plans.
Keywords: Agents, Multi-Agent Systems, Computer Graphics, Virtual Camera,
Cinematografy, Director, Cameraman, Robotic Soccer.
“O futuro não precisa apenas ser imaginado: precisa ser construído.”
G. Hampel e C.K. Pralahad
(“Competindo pelo Futuro”)
Email :
[email protected]
Homepage : http://www.sergio_louro.com
XIII
ÍNDICE
1
INTRODUÇÃO ....................................................................................................... 1
1.1
1.2
2
MOTIVAÇÃO E OBJECTIVOS ............................................................................... 1
ESTRUTURA DO TRABALHO ................................................................................ 2
COMPUTAÇÃO GRÁFICA E CINEMATOGRAFIA ...................................... 4
2.1
COMPUTAÇÃO GRÁFICA ............................................................................ 4
2.1.1
Breve história ............................................................................................ 4
2.1.2
A visão humana ......................................................................................... 5
2.1.3
Visualização científica e ambientes virtuais ............................................. 5
2.1.4
Câmara virtual e sua movimentação ........................................................ 6
2.1.5
Animação e simulação física .................................................................... 7
2.1.6
Parâmetros da câmara virtual em 3-Dimensões ...................................... 8
2.1.7
Pipeline de visualização tridimensional ................................................... 9
2.1.8
Bibliotecas gráficas ................................................................................ 10
2.2
CINEMATOGRAFIA .................................................................................... 10
2.2.1
Princípios da cinematografia ................................................................. 11
2.2.2
A diferença entre câmaras reais e virtuais ............................................. 12
2.2.3
Restrições físicas da câmara .................................................................. 12
2.3
CONCLUSÕES ................................................................................................... 13
3
CONTROLO CÂMARAS INTELIGENTES .................................................... 14
3.1
INTRODUÇÃO ................................................................................................... 14
3.2
SISTEMAS DE CÂMARAS INTELIGENTES ........................................................... 15
3.2.1
Jim Blinn – Sistema espacial .................................................................. 15
3.2.2
Gleicher - Assistente para controlo automático de câmara ................... 15
3.2.3
CamDroid – Sistema para controlo inteligente de câmara .................... 16
3.2.4
ConstraintCam - Controlo da câmara através de restrições ................. 18
3.2.5
DCCL – Linguagem declarativa para controlo de câmara .................... 21
3.2.6
FILM - O Cinematógrafo virtual ............................................................ 22
3.3
CONCLUSÕES ................................................................................................... 23
4
SISTEMAS MULTI-AGENTE ........................................................................... 25
4.1
AGENTES ......................................................................................................... 25
4.1.1
Conceito de agente.................................................................................. 25
4.1.2
Contexto de um agente ............................................................................ 28
4.1.3
Arquitecturas de agentes ........................................................................ 28
4.1.4
Agentes emocionais................................................................................. 31
4.2
ARQUITECTURAS BDI (“BELIEF-DESIRE-INTENTION”) .................................... 32
XIV
4.2.1
Estados mentais (crenças, desejos e intenções) ...................................... 33
4.2.2
Arquitectura IRMA de Bratman .............................................................. 34
4.2.3
Arquitectura PRS de Georgeff e Lansky ................................................. 35
4.2.4
Arquitectrua COSY de Burmeister e Sundermeyer ................................. 37
4.2.5
Arquitectura genérica de Wooldridge ..................................................... 39
4.3
SISTEMAS MULTI-AGENTE (SMA) ................................................................... 41
4.3.1
O conceito de Sistema Multi-Agente ....................................................... 41
4.3.2
Interacção e comunicação entre agentes ................................................ 42
4.3.3
Protocolos e níveis de comunicação ....................................................... 44
4.3.4
Linguagens de comunicação ................................................................... 44
4.3.5
Ontologias ............................................................................................... 45
4.3.6
Metodologias de concepção de um SMA................................................. 46
4.3.7
Avaliação de um sistema multi-Agente ................................................... 47
4.4
CONCLUSÕES.................................................................................................... 47
5
FUTEBOL ROBÓTICO ....................................................................................... 48
5.1
DESCRIÇÃO GERAL DO FUTEBOL ROBÓTICO SIMULADO .................................... 48
5.2
SERVIDOR SOCCERSERVER ............................................................................... 49
5.2.1
Descrição funcional do servidor ............................................................. 50
5.2.2
Domínios do simulador ........................................................................... 51
5.2.2.1 O campo de jogo e os agentes ............................................................. 51
5.2.2.2 Movimento e colisão de agentes ......................................................... 52
5.2.2.3 Protocolo de comunicação .................................................................. 52
5.2.3
Acções dos agentes no servidor .............................................................. 53
5.2.4
Percepções dos agentes ........................................................................... 54
5.2.4.1 Informação auditiva............................................................................. 54
5.2.4.2 Informação visual ................................................................................ 54
5.2.4.3 Informação física ................................................................................. 55
5.2.5
Estados de um jogo no servidor .............................................................. 55
5.2.6
Regras do jogo ........................................................................................ 55
5.3
DESCRIÇÃO DO SOCCER MONITOR ................................................................... 56
5.3.1
Descrição geral ....................................................................................... 56
5.3.2
Comunicação ........................................................................................... 56
5.3.2.1 Informação proveniente do servidor ................................................... 56
5.3.2.2 Comandos para o servidor ................................................................... 57
5.3.3
O Vídeo – LogPlayer ............................................................................... 57
5.4
ARQUITECTURAS DE VISUALIZAÇÃO DO FUTEBOL ROBÓTICO .......................... 58
5.5
ARQUITECTURAS DE VISUALIZAÇÃO 2D ........................................................... 58
5.5.1
Monitor Tradicional – Soccer Monitor ................................................... 58
XV
5.5.2
Soccer Monitor - Klaus Dorer ( Univ. de Freiburg, Alemanha ) ........... 59
5.5.3
FrameView - Arthur Merke ( Univ. de Karlsruhe, Alemanha ) .............. 59
5.5.4
SoccerScope – YowAI (Univ. Electro-Communications, Japão) ............ 60
5.5.5
SoccerDoctor - WrightEagle (Univ. Ciência e Tecnologia, China) ....... 61
5.5.6
TeamDesigner - FC Portugal (Univ. do Porto/Aveiro) .......................... 62
5.5.7
RoboBase - John Sear (Univ. de Manchester, Inglaterra) ..................... 62
5.5.8
Team Assistant – SBC (Univ. Shahid Beheshti, Irão ) ............................ 63
5.6
ARQUITECTURAS DE VISUALIZAÇÃO 3D .......................................................... 64
5.6.1
Virtual RoboCup – Universidade de Bielefeld, Alemanha ..................... 64
5.6.2
Magic Box - Wright Eagle (Univ. Ciência e Tecnologia), China ........... 65
5.6.3
Robolog - Oliver Obst ( Universidade of Koblenz), Alemanha .............. 65
5.6.4
The Venue (The Cave) – Univ. Vrije de Amesterdão, Holanda .............. 66
5.6.5
Caspian - (IUST Computer Engineering), Irão ...................................... 67
5.6.6
RA3DM - Isteam (Instituto Superior Técnico), Portugal ....................... 68
5.6.7
Avan – Universidade de Qazvin Islamic Azad, Irão ............................... 69
5.7
CONCLUSÕES ................................................................................................... 70
6
PROJECTO - MAICC ......................................................................................... 72
6.1
O VISUALIZADOR 3D – VIRTUAL3D ................................................................ 72
6.1.1
Descrição ................................................................................................ 73
6.1.2
Ambiente virtual ...................................................................................... 74
6.1.3
Arquitectura do sistema .......................................................................... 74
6.1.3.1 Componente gráfica 3D ...................................................................... 75
6.1.3.2 Componente de agentes ...................................................................... 75
6.1.3.3 Motor de som tridimensional .............................................................. 76
6.1.3.4 Componente de comunicação ............................................................. 76
6.1.3.5 Movimento das animações 3D ............................................................ 76
6.1.4
Posicionamento e descrição das câmaras utilizadas ............................. 77
6.1.5
Menu principal do visualizador Virtual3D ............................................. 78
6.2
CONTROLO DE CÂMARA INTELIGENTE.............................................................. 80
6.2.1
Descrição do modelo utilizado ............................................................... 80
6.2.2
Transformação da visualização .............................................................. 82
6.2.3
Modelo de Blinn ...................................................................................... 85
6.2.4
Representação dos objectos .................................................................... 86
6.2.5
Comandos de câmara e metódos sobre objectos .................................... 86
6.2.6
Formalização de restrições de câmara .................................................. 87
6.2.6.1 Restrições relativas ao ambiente ......................................................... 88
6.2.6.2 Restrições relativas ao objecto ............................................................ 88
6.2.6.3 Restrições da projecção ...................................................................... 89
XVI
6.2.7
Tarefas de visualização num jogo de futebol .......................................... 89
6.3
TOOLKIT MAS – MULTI AGENT SYSTEM ......................................................... 90
6.4
DESCRIÇÃO DOS AGENTES ................................................................................ 92
6.4.1
Agente realizador (CAgentDirector)....................................................... 92
6.4.2
Agente operador (CAgentCameraman) .................................................. 95
6.4.3
Agentes jogador (CAgentPlayer) ............................................................ 97
6.4.4
Agente bola (CAgentBall) ....................................................................... 98
6.4.5
Agente analisador (CAgentStats) ............................................................ 99
6.4.6
Agente público (CAgentPublic) ............................................................... 99
6.4.7
Agente árbitro (CAgentRefree) ............................................................. 100
6.5
A COMUNICAÇÃO DOS AGENTES DO SISTEMA MAICC ................................... 101
6.5.1
Descrição da comunicação ................................................................... 102
6.5.2
Sincronização das câmaras ................................................................... 103
6.5.3
A Linguagem CAMERA LANGUAGE ................................................... 104
6.5.3.1 Requisitos e especificação formal da linguagem .............................. 105
6.5.3.2 Regiões do cenário ............................................................................ 106
6.5.3.3 Períodos de tempo ............................................................................. 107
6.5.3.4 Intervenientes do cenário .................................................................. 107
6.5.3.5 Estatísticas do cenário ....................................................................... 107
6.5.3.6 Configuração da câmara .................................................................... 108
6.5.3.7 Intenções, qualidade e sincronismo da filmagem .............................. 108
6.5.3.8 Prioridade de visualização ................................................................. 109
6.5.3.9 Instruções do utilizador para o realizador ......................................... 109
6.5.3.10
Conclusões .................................................................................... 110
6.6
IMPLEMENTAÇÃO ........................................................................................... 110
6.6.1
Ambiente de desenvolvimento ............................................................... 110
6.6.2
Biblioteca gráfica .................................................................................. 111
6.7
CONCLUSÕES.................................................................................................. 112
7
ANÁLISE DE RESULTADOS .......................................................................... 113
7.1
CENÁRIOS ...................................................................................................... 113
7.2
CRITÉRIOS DE AVALIAÇÃO ............................................................................. 114
7.3
RESULTADOS OBSERVADOS ............................................................................ 114
7.3.1
Cooperação entre agentes para suavizar planos .................................. 114
7.3.2
Utilização de regiões de focagem definidas pelo realizador ................ 116
7.3.3
Qualidade de imagem versus sincronização ......................................... 116
7.4
CONCLUSÕES.................................................................................................. 117
8
CONCLUSÃO E TRABALHOS FUTUROS ................................................... 118
8.1
CONCLUSÕES.................................................................................................. 118
XVII
8.2
TRABALHOS FUTUROS ................................................................................... 119
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 121
ANEXOS ...................................................................................................................... 133
ANEXO A – ENTREVISTA COM JOSÉ PAULO VALENTE ............................................... 133
ANEXO B – SOCCERSERVER ESTADOS DO JOGO ......................................................... 135
ANEXO C – ESTRUTURA DOS FICHEIROS LOG DO SERVIDOR ...................................... 136
ANEXO D – INFORMAÇÃO DO SERVIDOR PARA VISUALIZADOR ................................. 137
ANEXO E – ALGORITMO LOOKAT SEGUNDO JIMM BLINN ......................................... 140
ANEXO F – ESTRUTURA DE DECISÃO DO AGENTE REALIZADOR .................................. 141
ANEXO G – SUAVIZAR MOVIMENTO DOS AGENTES NO CENÁRIO ................................ 142
ANEXO H – ALGORITMO DE FOCAGEM DO OPERADOR ............................................... 143
ANEXO I – MENSAGENS DE AGENTES NO VIRTUAL3D ............................................... 146
ANEXO J – TROCA DE MENSAGENS ENTRE AGENTES .................................................. 147
ANEXO L – CRIAR O VOLUME DE VISUALIZAÇÃO ....................................................... 148
ANEXO M – MÉTODOS SOBRE O VOLUME DE VISUALIZAÇÃO ..................................... 149
ANEXO N – RESULTADOS .......................................................................................... 150
ANEXO O – MANUAL DE UTILIZAÇÃO DO VIRTUAL3D .............................................. 151
ANEXO P - TERMINOLOGIA ........................................................................................ 159
ANEXO Q - WEBSITES ................................................................................................ 161
XVIII
LISTA DE FIGURAS
FIGURA 2.1:MOVIMENTOS POSSÍVEIS DE UMA CÂMARA VIRTUAL....................................... 7
FIGURA 2.2: PARÂMETROS DE CÂMARA VIRTUAL A 3D ...................................................... 9
FIGURA 2.3:POSICIONAR CÂMARAS PELA “ LINHA DE INTERESSE” [ARIJON, 76] .............. 11
FIGURA 3.1: ARQUITECTURA DO MODELO CAMDROID DE DUCKER ................................. 16
FIGURA 3.2: MÓDULO GENÉRICO DE UMA CÂMARA DE DUCKER ...................................... 17
FIGURA 3.3: ARQUITECTURA CONSTRAINTCAM DE BARES .............................................. 18
FIGURA 3.4: ARQUITECTURA DO MODELO DCCL DE HE E CHRISTIANSON, 1996. ............ 22
FIGURA 3.5: ARQUITECTURA DO MODELO FILM DE AMERSON E KIME............................ 22
FIGURA 4.1: REPRESENTAÇÃO DE UM AGENTE DELIBERATIVO GENÉRICO ........................ 29
FIGURA 4.2: REPRESENTAÇÃO DE UM AGENTE REACTIVO GENÉRICO ................................ 30
FIGURA 4.3: ARQUITECTURA IRMA, SEGUNDO [BRATMAN, 87] ...................................... 35
FIGURA 4.4: ARQUITECTURA PRS, SEGUNDO [RAO E GEORGEFF, 92] .............................. 36
FIGURA 4.5: ARQUITECTURA COSY, SEGUNDO [HADDADI, 96] ....................................... 38
FIGURA 4.6: ARQUITECTURA BDI GENÉRICA, SEGUNDO [WOOLDRIDGE, 99] ................... 39
FIGURA 4.7: ESTRUTURA DE UM SISTEMA MULTI-AGENTE .............................................. 42
FIGURA 4.8: AGENTE COM CAPACIDADES DE COMUNICAÇÃO ........................................... 43
FIGURA 5.1: ARQUITECTURA CLIENTE - SERVIDOR DO SOCCERSERVER ............................ 50
FIGURA 5.2: REPRESENTAÇÃO DO JOGADOR E BOLA NO SOCCERSERVER .......................... 51
FIGURA 5.3: VISUALIZAÇÃO NO SOCCER MONITOR ........................................................... 56
FIGURA 5.4: VISUALIZADOR TRADICIONAL PARA LINUX DO SOCCER SERVER.................. 58
FIGURA 5.5: VISUALIZADOR SOCCER MONITOR DE KLAUS DORER .................................. 59
FIGURA 5.6: VISUALIZADOR FRAMEVIEW DE ARTHUR MERKE ........................................ 60
FIGURA 5.7: VISUALIZADOR SOCCERSCOPE, JAPÃO ......................................................... 60
FIGURA 5.8: VISUALIZADOR SOCCER DOCTOR DOS WRIGHTEAGLE, CHINA. ................... 61
FIGURA 5.9: VISUALIZADOR TEAMDESIGNER, DAS UNIV. PORTO/AVEIRO ...................... 62
FIGURA 5.10: VISUALIZADOR ROBOBASE DE JOHN SEAR, UNIV. MANCHESTER. ............. 63
FIGURA 5.11: VISUALIZADOR TEAM ASSISTANT, UNIV. SHAHID BEHESHTI, IRÃO. .......... 63
FIGURA 5.12: VISUALIZADOR VIRTUAL ROBOCUP DA UNIV. BIELEFED, ALEMANHA. ..... 64
FIGURA 5.13: VISUALIZADOR MAGICBOX DOS WRIGHT EAGLE, CHINA. ......................... 65
FIGURA 5.14: VISUALIZADOR ROBOLOG DE OLIVER OBST, ALEMANHA.......................... 66
FIGURA 5.15: VISUALIZADOR “THE VENUE” .................................................................... 67
FIGURA 5.16: VISUALIZADOR CASPIAN, IUST, IRÃO. ...................................................... 68
FIGURA 5.17: VISUALIZADOR RA3DM DO IST, PORTUGAL. ............................................ 69
FIGURA 5.18: IMAGENS DO VISUALIZADOR AVAN, IRÃO. ............................................... 69
FIGURA 6.1: IMAGENS DO VISUALIZADOR 3D ................................................................... 74
FIGURA 6.2: ARQUITECTURA DO SISTEMA DO VISUALIZADOR .......................................... 74
FIGURA 6.3: ANIMAÇÃO DO JOGADOR UTILIZANDO KEYFRAME NO VIRTUAL3D ............. 76
XIX
FIGURA 6.4: POSICIONAMENTO DAS CÂMARAS NO ESTÁDIO JOSÉ DE ALVALADE ............ 77
FIGURA 6.5: IMAGENS DAS CÂMARAS REAIS NO VIRTUAL3D ........................................... 78
FIGURA 6.6: IMAGENS DAS CÂMARAS VIRTUAIS NO VIRTUAL3D ..................................... 78
FIGURA 6.7: VOLUME DE VISUALIZAÇÃO ......................................................................... 83
FIGURA 6.8: CAIXA DE COLISÃO (BOUNDINGBOX) DO JOGADOR E BOLA ......................... 86
FIGURA 6.9: ARQUITECTURA MULTI AGENT SYSTEM (MAS) .......................................... 90
FIGURA 6.10: ESTRUTURA DO PROCESSAMENTO DE MENSAGENS ..................................... 91
FIGURA 6.11: ARQUITECTURA DO AGENTE REALIZADOR ................................................. 93
FIGURA 6.12: ARQUITECTURA DE COMUNICAÇÃO DO AGENTE OPERADOR ....................... 96
FIGURA 6.13: DIAGRAMA DO MODELO DE MOVIMENTO DO JOGADOR .............................. 98
FIGURA 6.14: ESTATÍSTICAS DO AGENTE ANALISADOR .................................................... 99
FIGURA 6.15: TROCA DE MENSAGENS ENTRE OS PRINCIPAIS AGENTES ........................... 101
FIGURA 6.16: TROCA DE MENSAGENS ENTRE OS AGENTES (ACTORES) ........................... 103
FIGURA 7.1: RESULTADOS DA COOPERAÇÃO ENTRE AGENTES PARA SUAVIZAR PLANOS 115
FIGURA 7.2: RESULTADOS DE UMA FILMAGEM COM MENOS CÂMARAS .......................... 115
FIGURA 7.3: RESULTADOS DE UMA FILMAGEM COM E SEM REGIÕES .............................. 116
FIGURA 7.4: QUALIDADE DE IMAGEM VERUS SINCRONIZAÇÃO DE CÂMARAS ............... 117
FIGURA 10.1: IMAGEM GERAL DO VISUALIZADOR VIRTUAL3D ...................................... 151
FIGURA 10.2: MENU PRINCIPAL COM A SUB-OPÇÕES DA OPÇÃO FILE ............................. 152
FIGURA 10.3: SUB-OPÇÕES DA OPÇÃO LOGPLAYER ....................................................... 153
FIGURA 10.4: BARRA DE TEMPO DO JOGO ...................................................................... 154
FIGURA 10.5: SUB-OPÇÕES DA OPÇÃO PRINCIPAL VIEW ................................................. 154
FIGURA 10.6: BOUNDING BOX DOS AGENTES DO CENÁRIO ............................................ 154
FIGURA 10.7: DEFINIÇÃO DE UMA REGIÃO DE FILMAGEM .............................................. 155
FIGURA 10.8: SUB-OPÇÕES DA OPÇÃO PRINCIPAL CAMERAS .......................................... 155
FIGURA 10.9: SUB-OPÇÕES DA OPÇÃO PRINCIPAL EFFECTS ............................................ 156
FIGURA 10.10: DIFERENTES TIPOS DE RELVADO DO VIRTUAL3D ................................... 156
FIGURA 10.11: CAIXA COM A INFORMAÇÃO SOBRE O VISUALIZADOR ............................ 157
FIGURA 10.12: VISUALIZAÇÃO DO CENÁRIO COM A CÂMARA [1],[3] E [5] ..................... 158
XX
LISTA DE TABELAS
TABELA 1: PARÂMETROS DOS AGENTES NO SOCCERSERVER ............................................ 51
TABELA 2: COMANDOS DE UMA CÂMARA ......................................................................... 87
TABELA 3: MÉTODOS SOBRE UM OBJECTO ....................................................................... 87
TABELA 4: RESTRIÇÕES DIRECTAS RELATIVAS AO AMBIENTE .......................................... 88
TABELA 5: RESTRIÇÕES RELATIVAS A UM OBJECTO.......................................................... 88
TABELA 6:RESTRIÇÕES DIRECTAS DE PROJECÇÃO ............................................................ 89
TABELA 7: TAREFAS DE VISUALIZAÇÃO NUM JOGO DE FUTEBOL ...................................... 89
TABELA 8: REGIÕES DEFINIDAS PELO AGENTE REALIZADOR ........................................... 94
TABELA 9: SISTEMA DE VALORES DO AGENTE PÚBLICO .................................................. 100
TABELA 10: COMPORTADO DO AGENTE ÁRBITRO (SITUAÇÃO/ACÇÃO) ........................... 100
TABELA 11: CENÁRIOS PARA ANÁLISE DOS RESULTADOS ............................................... 113
TABELA 12: SOCCERSERVER ESTADOS DO JOGO ............................................................. 135
TABELA 13: MENSAGENS DE COMUNICAÇÃO ENTRE AGENTES DO VIRTUAL3D.............. 146
TABELA 14: TROCA DE MENSAGENS ENTRE OS AGENTES .............................................. 147
TABELA 15: RESULTADOS DA COOPERAÇÃO ENTRE AGENTES PARA SUAVIZAR PLANOS . 150
TABELA 16: RESULTADOS DE UMA FILMAGEM COM MENOS CÂMARAS ........................... 150
TABELA 17: RESULTADOS DE UMA FILMAGEM COM E SEM REGIÕES ............................... 150
TABELA 18: QUALIDADE DE IMAGEM VERSUS SINCRONIZAÇÃO .................................... 150
TABELA 19: TECLAS DE ATALHO DO VISUALIZADOR VIRTUAL3D .................................. 157
CAPÍTULO 1: INTRODUÇÃO
1
1 INTRODUÇÃO
Neste capítulo apresentam-se as motivações que estiveram na origem deste trabalho, os
diferentes objectivos que se pretendem alcançar e uma breve apresentação das
metodologias utilizadas para alcançar esses mesmos objectivos. No fim do capítulo
descreve-se a estrutura deste documento.
1.1 Motivação e Objectivos
A motivação principal para a realização desta dissertação surge da importância crescente
do paradigma dos Agentes e Sistemas Multi-Agente (SMA), sub-área da Inteligência
Artificial Distribuída (IAD). Os domínios de problemas distribuídos são sempre um
desafio motivador do ponto de vista de análise e da sua resolução. Contudo, só agora se
dispõem de metodologias de comunicação, coordenação, negociação e cooperação de
SMA que permitem abordar os problemas de uma forma mais eficiente e concreta. Por
sua vez, a aplicação destes sistemas não é linear pois existem problemas concretos que se
colocam a essa aplicação. Tal é devido às dimensões dos domínios considerados, e
consequente surgimento de problemas de escala (número de intervenientes, tamanho,
complexidade e número de interacções) que dificulta seriamente qualquer abordagem que
tente ser sistemática. Para além disso, os próprios recursos e métodos de implementação
revelam-se demasiado dependentes dos sistemas de execução estando sujeitos
directamente a factores como as latências e tipo de comunicação, heterogeneidade dos
sistemas, tipo de linguagem, etc.
A importância crescente do RoboCup como domínio de teste e problema standard para a
IAD e Robótica Inteligente constitui outra motivação forte deste trabalho. É sobre este
domínio complexo (dinâmico, contínuo, inacessível e não determinístico) que surge a
necessidade de visualizar a três dimensões todos os agentes (jogadores, bola) de uma
forma objectiva e automática como se de uma filmagem televisiva se tratasse. A
inexistência de um visualizador para jogos da liga simulada do RoboCup em que a
qualidade gráfica, animações, sistema de som e em que o modelo de filmagem dos
agentes do cenário não utilizasse modelos de controlo de câmara automatizado, foi outra
motivação relevante para a implementação do sistema MAICC (Muti Agent Inteligent
Camera Control) e consequentemente o visualizador tridimensional Virtual3D.
O domínio desta tese reflecte assim o problema de filmagem automática e inteligente em
cenários virtuais, nomeadamente do futebol robótico simulado. O MAICC surge como
tentativa para criar um sistema de controlo de câmara inteligente onde existem operadores
de câmara e um realizador, implicando necessariamente o uso de capacidades
distribuídas, coordenação, cooperação e negociação. Tais capacidades podem ser
realizadas com sucesso através de uma aproximação às metodologias de agente e sistemas
Multi-Agente para o domínio em causa.
2
Os objectivos específicos deste trabalho são os seguintes:

Estudo dos conceitos de agente, arquitecturas BDI, Sistemas Multi-Agente e de
metodologias de coordenação e cooperação entre agentes inteligentes autónomos;

Implementação de esquemas de decisão a um nível conceptual, descentralizado e
distribuído, através dos agentes e SMA, e ortogonais às suas implementações;

Estudo do domínio do controlo de câmaras inteligentes nas variadas vertentes,
incluindo os vários modelos de implementação propostos pelos vários autores e os
visualizadores a duas e três dimensões associados ao futebol robótico simulado;

Definição de linguagens que permitam a coordenação de agentes autónomos nos
domínios do controlo de câmara inteligentes (CAMERA LANGUAGE);

Integração gráfica de sistemas virtuais com agentes e controlo de câmara;

Implementação de um visualizador de futebol robótico simulado que permita a
visualização através de controlo de câmara inteligente;

Generalização, com a devida limitação, do sistema de coordenação e comunicação
de forma a serem aplicáveis a outros domínios de visualização.

Implementação de uma plataforma de comunicação para agentes que apresente
características de simplicidade na integração dos agentes em cenários dinâmicos e
que corresponda as exigências computacionais para o processamento gráfico.
Os objectivos propostos constituem uma originalidade na realização de uma filmagem
constituída por arquitectura multi-agente com a respectiva coordenação dos intervenientes
utilizando um controlo de câmara inteligente num cenário completamente gráfico. Os
objectivos anteriores foram todos cumpridos no trabalho proposto, sendo o resultado final
um visualização imersiva pelos espectadores como se de uma filmagem televisiva se
tratasse num cenário de futebol, em que existe um completa coordenação entre os agentes
para a realização da filmagem.
1.2 Estrutura do trabalho
Este trabalho encontra-se estruturado em oito capítulos dos quais o primeiro é composto
por esta introdução ao trabalho.
O capítulo dois apresenta as noções básicas de computação gráfica e os conceitos de
cinematografia mais relevantes para o trabalho.
No capítulo três é analisada a investigação realizada no âmbito do controlo de câmara
inteligente, os seus primórdios e evolução até ao estado-da-arte dos sistemas actuais.
O capítulo quatro apresenta a noção de agente computacional e os sistemas compostos por
agentes, designados vulgarmente por Sistemas Multi-Agente. Na noção de agente são
3
discutidas as definições apresentadas por diferentes autores. São também analisadas as
características dos ambientes em que estes operam e será efectuada uma análise detalhada
das arquitecturas mais comuns de agentes autónomos. A arquitectura de agente BDI
(“Belief-Desire-Intention”) será apresentada do ponto de vista de diversos autores. Nos
Sistemas Multi-Agente será feita uma distinção entre o conceito de SMA e a Inteligência
Artificial Distribuída apresentando as características comuns de um SMA. Será abordado
o conceito de comunicação de alto nível, tipos de comunicação, protocolos e níveis de
comunicação e linguagens entre os agentes inseridos no SMA. O capítulo conclui-se com
uma apresentação de metodologias para concepção de um SMA e como avaliar a
concepção do mesmo.
O capítulo cinco analisa o domínio do futebol robótico. Na descrição, para além de uma
análise da envolvente do futebol robótico e das competições internacionais RoboCup, é
dada particular relevância à descrição do simulador de futebol robótico – soccerserver e
ao monitor de visualização soccer monitor. Este simulador e monitor são descritos ao
detalhe de forma a facilitar a compreensão dos capítulos seguintes da tese. O capítulo
conclui-se com uma análise dos diferentes visualizadores a duas e três dimensões
desenvolvidos para este domínio do Futebol Robótico, apresentado os seus autores e suas
funcionalidades, focadas sempre para o controlo das câmaras.
No capítulo seis descreve-se o modelo MAICC, proposto para controlo de câmara
inteligente. Este capítulo contém a maioria das contribuições científicas originais da tese.
É feita uma descrição ao visualizador virtual3D desenvolvido para testar o modelo, sendo
apresentada a arquitectura funcional do visualizador. No controlo de câmara inteligente
são analisados os métodos e modelos para concepção do modelo MAICC. De seguida é
descrita a arquitectura dos agentes do modelo, assim como o seu estado no mundo, as
suas capacidades individuais e os seus mecanismos de decisão. É feita a análise à
plataforma desenvolvida de comunicação MAS (Multi Agent System) para responder as
exigências do desempenho da aplicação entre os agentes e o ambiente. É dado particular
destaque à linguagem de comunicação que permite a coordenação entre o realizador e os
operadores de câmara para controlo da visualização. O capítulo conclui-se com os
detalhes de implementação do modelo.
O capítulo sete analisa os resultados obtidos, em diversos cenário e utilizando diversos
critérios de avaliação, pelo sistema de controlo de câmara desenvolvido.
O oitavo e último capítulo apresentam as conclusões gerais deste trabalho e propõem
algumas perspectivas de desenvolvimentos futuros no âmbito dos Sistemas Multi-Agente,
controlo de câmara inteligentes e computação gráfica.
4
CAPÍTULO 2: COMPUTAÇÃO GRÁFICA E CINEMATOGRAFIA
2 COMPUTAÇÃO GRÁFICA E CINEMATOGRAFIA
Neste capítulo pretende-se efectuar uma abordagem global da computação gráfica a três
dimensões e dos diferentes conceitos de cinematografia, pretendendo-se assim dar a
conhecer a terminologia gráfica a ser usada no resto desta tese. Para uma descrição mais
completa sobre computação gráfica pode-se consultar variados textos, dos quais se
destacam [Foley et al., 00] [Angel, 02]. Para uma descrição mais aprofundada sobre
cinematografia pode-se consultar [Mascelli, 98].
2.1 COMPUTAÇÃO GRÁFICA
Tipicamente, a computação gráfica a três dimensões tenta simular o processo de
visualização do mundo real, sendo os objectos modelados geometricamente num sistema
de coordenadas devidamente normalizado. O efeito de luz nas superfícies dos objectos é
simulado através de transformação das superfícies a três dimensões em planos a duas
dimensões.
O conceito geral da computação gráfica é a ideia de uma pipeline gráfico1, em que a
entrada de dados para visualização é uma cena gráfica a 3-Dimensões constituída por
objectos (conjunto de polígonos), câmaras e luzes, em que a saída dos dados é uma
imagem da cena a 2-Dimensões para ser apresentada no ecrã.
2.1.1 Breve história
Existe um consenso entre os investigadores da história da Computação Gráfica que o
primeiro computador a possuir recursos gráficos de visualização de dados numéricos foi o
Whirlwind, desenvolvido pelo MIT2 nos anos 50. Este equipamento foi desenvolvido com
finalidades académicas e também possivelmente militares, pois no final da década o
comando de defesa aérea dos Estados Unidos desenvolveu um sistema de monitorização e
controle dos voos, SAGE (Semi-Automatic Ground Environment), que convertia as
informações capturadas pelo radar em imagem num tubo de raios catódicos (na época
uma invenção recente).
Uma das mais importantes publicações de Computação Gráfica, foi a tese de Ivan
Sutherland (Sketchpad – Machine Graphical Communication System), no início da década
de 60, que chamou a atenção das indústrias automobilísticas e aeroespaciais americanas.
Os conceitos de estruturação de dados, bem como o núcleo da noção de Computação
Gráfica interactiva, levaram a empresa General Motors a desenvolver o precursor dos
primeiros programas de desenho assistido por computador, designado de CAD (Computer
Aided Design).
1
Pipeline gráfico – Processo básico de gerar imagens por computador para aplicações em tempo real ou
interactivas.
2
MIT - Massachusetts Institute of Tecnology ( http://www.mit.edu )
5
Na década de 70 um outro factor foi fundamental para o desenvolvimento da Computação
Gráfica: o surgimento da tecnologia de circuitos integrados. Isto permitiu a popularização
das máquinas, em especial dos PC’s (Personal Computer).
Uma grande contribuição para o desenvolvimento da computação gráfica foi dada na
década de 80, derivado ao surgimento e queda dos preços das estações de trabalho
(workstations da SUN e Silicon Graphics), e dos primeiros dispositivos para interação a
três dimensões.
Para finalizar, da década de 90 até aos nossos dias, houve um crescimento das
capacidades de processamento e funcionalidades das estações gráficas e começaram a ser
popularizados os dispositivos para integração em 3D (realidade virtual).
2.1.2 A visão humana
Grande parte do avanço na Computação Gráfica deve-se ao facto de que na maior parte
dos sistemas informáticos os resultados são mostrados visualmente. Sendo assim, o
sistema visual humano torna-se a principal interface para os resultados [Myin, 00]. A
actual literatura sobre a visão humana está muito distante de abranger o seu
funcionamento ao detalhe [Gibson, 76].
O campo de visão do ser humano é quase um hemisfério, mas só uma pequena região
central deste campo é bastante perceptível. As regiões exteriores do campo de visão são
apenas sensíveis ao movimento. O resultado é que os humanos só podem estar atentos a
uma pequena região de uma imagem, embora o olhar possa trocar a atenção rapidamente
para outra nova região da imagem. A implicação cinematográfica é que o realizador,
quando está a editar o filme, tem de levar em conta que o espectador só está atento a uma
única região da imagem e não a várias em simultâneo.
Os Humanos têm a capacidade de modelar mentalmente o mundo em seu redor, incluindo
a sua orientação. Mudanças no campo de visão repentinamente produzem uma
contradição com o modelo metal induzindo a desconforto e desorientação nos assuntos.
Isto coloca limites na forma como devem ser editadas as imagens de um filme pelo
realizador [May, 00].
2.1.3 Visualização científica e ambientes virtuais
A visualização computacional é uma disciplina que se ocupa de apresentar, por meio de
recursos gráficos e interactivos da computação, informações para profissionais de
diferentes especialidades. A sub área visualização científica pretende apoiar e tornar mais
ágil o processo científico de descoberta, confirmação e reprodução de dados. A primeira
definição de visualização científica surgiu em 1987, no relatório “Visualization in
Scientific Computing”, como uma forma de comunicação que transcende as aplicações e
6
os limites tecnológicos. Também nesta época, o termo foi usado para sensibilizar a
National Science Fundation3 para a importância do uso de métodos de computação
gráfica associado às simulações com super computadores.
A visualização científica permite resumir de modo gráfico os resultados gerados pelas
aplicações da super computação, constituindo uma ajuda inestimável aos investigadores
no momento de analisar, interpretar os dados científicos e formular conclusões.
Alguns investigadores consideram que a visualização científica revolucionou a forma de
processar dados científicos, tendo-se tornado indispensável em muitas áreas. Surgem,
graças a ela, aplicações típicas em medicina, meteorologia, análise molecular,
aeronáutica, ecologia, microscopia e dinâmica dos fluidos, entre tantas outras.
O termo “ambiente virtual” é usado para definir o mundo digital criado a partir de
técnicas de computação gráfica. Uma vez que é possível explorar esse mundo por meio de
periféricos de input / output, o mundo transforma-se assim num ambiente virtual. Permite
oferecer aos utilizadores: uma forte sensação de presença dentro do ambiente virtual,
interactividade com os objectos tridimensionais e maior intuição no manuseamento dos
interfaces entre o utilizador e computador [Leston, 96]. Com o aumento das
funcionalidades e velocidade dos computadores no processamento de imagens e som, os
ambientes têm-se tornado cada vez mais realísticos. Com o aparecimento dos ambientes
virtuais 3D, muito esforço tem sido efectuado para apresentar métodos convenientes pelos
quais os utilizadores possam visualizar os objectos ou o próprio mundo. Para um maior
detalhe recomenda-se a leitura sobre o tema em: [Hubbold et al., 98], [Kay et al., 98] e
[Young e Malcolm, 98].
2.1.4 Câmara virtual e sua movimentação
A câmara virtual é um conceito importante na computação gráfica, pois representa o
ponto de vista sobre o qual os objectos pertencentes ao mundo virtual são projectados no
ecrã. Por definição, a parte crucial de qualquer ambiente virtual, como é vívido, depende
em grande parte da visão da câmara, pois é um dos meios primários pelos quais é
transferida a informação do ambiente virtual para o utilizador via ecrã.
Em geral são considerados sete graus de liberdade pelos quais uma câmara virtual é
controlada: 3 graus para mover no plano gráfico cartesiano (x, y, z), 3 graus para rotação
(pan, tilt e roll) e 1 grau para mudar o campo de visão (zoom). Outros parâmetros podem
controlar uma câmara mas nesta tese não são discutidos. Alguns desses parâmetros são: a
luz de ambiente, aspecto da imagem, “shutter speed4” e a profundidade do campo de
visão.
3
Fundação Nacional e da Ciência do EUA, http://www.nsf.gov
Shutter Speed - Velocidade de obstrução. É o tempo em que o obturador permanece aberto para expor o
filme.
4
7
Assim sendo, a câmara pode-se movimentar de quatro formas distintas e frequentemente
em conjunto, como se pode ver na figura 2.1. A câmara pode-se deslocar, isto é, mover
para uma nova posição x,y,z, pode girar na vertical (tilt) ou horizontal (pan), podendo
também rodar no seu próprio eixo (roll) [Nieuwenhuisen e Overmars, 02].
(a) Translação
(b) Pan
(vista de cima)
(c) Tilt
(vista de lado)
(d) Roll
(vista de frente)
Figura 2.1:Movimentos possíveis de uma câmara virtual
Em Computação Gráfica, recorre-se normalmente ao conceito de câmara virtual [Watt,
93] para definir um novo referencial, denominado Sistema de Coordenadas da Câmara
(Eye or Camera Coordinate System), cuja origem coincide com o centro de projecção
(posição da câmara) e cujo eixo dos ZZ é normal ao plano de visualização (View Plane) e
representa a direcção de observação.
O volume de visualização (Viewing Frustum) delimita o espaço em que um objecto é
visualizado dentro do volume, representando assim, o espaço de coordenadas em que os
objectos foram transformados, relacionando as técnicas de projecção com o plano de
visualização. Os objectos resultantes são expressos em termos de Coordenadas de Ecrã
(Screen Coordinates). Em rigor, as coordenadas resultantes desta transformação são
normalizadas pelo que se impõe um mapeamento destas no referencial determinado pelo
dispositivo físico de visualização (Device Dependent Coordinates) [Foley et al., 00]
[Lengyel, 02].
2.1.5 Animação e simulação física
A animação por computador foi considerada durante muitos anos como a nova ferramenta
multimédia para anúncios e efeitos especiais em filmes. Mas, mais recentemente, o
desenvolvimento rápido dos computadores pessoais conduziu a novas áreas como a
multimédia, jogos interactivos e realidade virtual. Para estas novas áreas a interactividade
e a animação em tempo real tornou-se fundamental.
Como método tradicional para animar personagens articuladanente temos o Keyframe.
Este método consiste, numa primeira fase, em criar a personagem num programa de
modelação (ex. 3D Studio Max) que permita criar animações. Com alguma facilidade o
8
animador5 adiciona, altera ou remove as frames que fazem parte da animação da
personagem. O animador define assim um conjunto de poses para um determinado
movimento. O movimento em tempo real é obtido através da interpolação das poses
necessárias para o estado actual da personagem.
A metodologia keyframe apresenta a vantagem de o animador ter o controlo total sobre o
modelo e a implementação do sistema não requer dificuldade. Por sua vez esta técnica
apresenta alguns problemas, nomeadamente: dificuldade em especificar interacções mais
realistas, dificuldade para especificar cenários muito dinâmicos e o resultado final da
animação está muito dependente do algoritmo de interpolação das poses. Para maior
delhate sobre a técnica de animação pode-se consultar: [Bruderlin e Calvert, 89], [Chung e
Hahn, 99], [Marselas, 00], [Watt, 93], [Witkin et al., 90] e [Witkin e Popovic, 95].
A simulação física é outra técnica de animação que produz movimentos mais naturais que
a técnica de keyframe. Os movimentos são implementados em tempo real através de
fórmulas físicas que definem o comportamento da personagem. Este modelo foi usado
para a simulação de movimento de câmaras utilizando massa, atrito e viscosidade [Turner
et al., 91]. Um problema com sistemas de simulação dinâmicos é a dificuldade de
implementar o modelo físico para que se comporte como desejado.
2.1.6 Parâmetros da câmara virtual em 3-Dimensões
O posicionamento de uma câmara no mundo virtual a 3-Dimensões é definido por um
conjunto de parâmetros que são descritos de seguida e ilustrados na figura 2.2 [Foley et
al., 00]. Para um posicionamento da câmara no ambiente virtual é sempre necessário
utilizar os seguintes parâmetros da câmara [Bares et al., 00a]:
5

Posição da câmara P(x,y,z): Ponto no qual a câmara virtual é colocada no sistema
de coordenadas a três dimensões.

Vector de direcção At(dx, dy, dz).

Campo de visão (Field of View): O campo horizontal e vertical dos ângulos de
visão, denominado o “ângulo da lente”. Na computação gráfica, este ângulo é
determinado através de dois parâmetros, o campo horizontal de ângulo de visão
(ӨH) e no campo vertical de ângulo de visão (ӨV).

Vector Up de orientação Up(dx, dy, dz): Vector que controla o ângulo do tilt ou
rotação roll da câmara sobre o seu vector de direcção.
Animador – pessoa que implementa a animação do modelo num software especifico.
(Perspectiva da visão)
9
(Visão de cima)
Figura 2.2: Parâmetros de câmara virtual a 3D
2.1.7 Pipeline de visualização tridimensional
O Pipiline de visualização tridimensional é o processo básico de gerar imagens
tridimensionais por computador para aplicações em tempo real ou interactivas,
encontrando-se o conceito perfeitamente normalizado. Trata-se assim de uma estratégia
de compromisso de visualização entre o realismo e a velocidade de processamento do
desenho. O objectivo desta técnica é criar uma projecção a duas dimensões da cena
tridimensional, tendo em conta a iluminação da cena e a perspectiva de visualização para
que possa ser visualizada no ecrã [Foley et al., 00]. O processo assume como entrada de
dados de uma cena tridimensional um conjunto de objectos descritos por polígonos6,
fontes de luz e parâmetros de visualização. O cálculo do processamento é o seguinte
[Madeiras, 03]:
1. “Leitura” da base de dados que contém o modelo matemático da cena;
2. Aplicação do modelo de reflexão local de acordo com o algoritmo de
sombreamento;
3. Aplicação das transformações geométricas tendo em conta a posição e direcção do
ponto de vista;
4. Eliminação das faces escondidas (back-faces culling);
5. Execução do recorte e opcionalmente a transformação da perspectiva;
6. Calculo dos pixels7 que irão ser activados (scan-conversion);
7. Calculo da cor de cada um dos pixel (algoritmo incremental de sombreamento);
8. Remoção das superfícies ocultas;
6
Polígonos - Na maioria das aplicações gráficas que possibilitam a modelação de cenas utilizam-se
primitivas gráficas de alto nível (exemplo: sólidos 3D) o que implica a existência de um camada de préprocessamento responsável pela sua decomposição em polígonos.
7
Pixel – É a menor unidade gráfica a partir da qual se forma uma imagem.
10
9. Implementação de eventuais efeitos visuais (ex: mapeamento de texturas, sombras
e transparências);
10. Filtragem dos ruídos da imagem (anti-aliasing);
11. Escrita da informação respeitante aos pixéis na memória da imagem para
visualização e implementação da projecção a duas dimensões.
2.1.8 Bibliotecas gráficas
Actualmente existem vários sistemas de visualização comerciais que utilizam a técnica de
imagem baseadas no pipeline 3D. As mais conhecidas são: OpenGL [Wright e Sweet, 00],
Direct3D [Root e Boer, 99] e Renderware [Criterion, 95], sendo esta última a utilizada no
trabalho experimental descrito nesta tese.
De um modo geral, os sistemas de visualização gráfica, frequentemente apelidados de
APIs (Application Progamming Interface), disponibilizam uma biblioteca gráfica que
constitui um ambiente bastante versátil para a modelação e visualização de objectos
complexos. Geralmente as bases de dados das cenas para os programas de visualização
em tempo reais ou interactivos contêm a especificação dos parâmetros de visualização,
das fontes de luz, dos atributos físicos das superfícies (cor, índices de reflexão, etc.) e da
informação geométrica dos polígonos. O processo final de cada cena será sempre o envio
de toda a cena para o pipeline de visualização. A biblioteca gráfica tem também como
missão assegurar a compatibilidade com todo o hardware gráfico.
2.2 CINEMATOGRAFIA
Cinematografia é a arte de fazer filmes. O problema central do realizador cinematográfico
é como capturar para a filmagem um conjunto de eventos que ocorrem no mundo em
simultâneo de modo a que o espectador os consiga perceber com toda a clareza, dando a
continuidade pretendida.
Vários trabalhos de investigação foram extremamente úteis para a comunidade
cinematografa perceber como elaborar um filme. Notavelmente, Arijon tem um papel
muito construtivo em que nomeia um conjunto de descrições técnicas para filmar
correctamente qualquer tipo de situação cinematográfica [Arijon, 76]. Alguns autores
consideram que as descrições dele são simplistas, mas no entanto elas são a base perfeita
de como derivar uma classe de grandes primitivas para filmar qualquer tipo de situação
[Drucker, 94]. Esta classe de primitivas, que se designam neste trabalho de restrições de
projecção, envolve a colocação e orientação da câmara baseada na projecção do objecto
sobre o ecrã.
11
2.2.1 Princípios da cinematografia
Na generalidade, os eventos são filmados por várias câmaras em diferentes pontos de
vista, sendo o resultado do filme a junção de todas as cenas filmadas. A este processo
chama-se edição [Mascelli, 98]. Na terminologia cinematográfica um pedaço de filme
ininterrupto, filmado por uma única câmara, é designado de shot ou take. Os shots
editados em conjunto formam uma cena, logo um filme é formado por um conjunto de
shots [Mascelli, 98].
O problema que se coloca a um realizador é saber como dispor as câmaras e o
equipamento de iluminação para que quando o filme seja editado, tudo junto descreva
coerentemente os eventos exigidos.
O problema pode ser dividido em duas partes. A primeira parte pode ser designada por
problema semântico, consiste em assegurar que são incluídas todas as acções do shot na
sequência correcta. A segunda parte do problema é pragmática. Relaciona assuntos de
percepção humana, e consiste em decidir que propriedades visuais devem estar
invariavelmente do outro lado de cortes para assegurar que o espectador perceba a
continuidade.
Linha de interesse
A3
A1
B
B3
B1
A
internas
paralela
paralela
E
B2
externa
A2
externa
ápice
Figura 2.3:Posicionar câmaras pela “ Linha de interesse” [Arijon, 76]
Uma aproximação à resolução destes problemas é o desenvolvimento de um conjunto de
planos de câmara standards por cenas típicas, que facilitem a edição da cena. Estes planos
são chamados de idiomas. Um conjunto de idiomas ou descrições foi publicado por
Arijon, como foi salientado anteriormente [Arijon, 76].
O objectivo básico do idioma é evitar confundir o sentido de visualização da imagem.
Para isso ser alcançado é desenhada uma linha de interesse entre os vários actores
proibindo qualquer câmara de cruzar essa mesma linha, como se pode analisar na figura
2.3. O problema com um idioma é que resolve só parcialmente o problema de achar o
melhor ângulo de câmara, pois não descreve a altura de posição da câmara em relação aos
12
actores ou se os shots são para ser close-up8 ou não. Outro problema é que foram
desenvolvidos idiomas principalmente para a indústria de filme teatral onde o actor pode
ser colocado pelo Realizador (Director) e o cenário pode ser mudado à vontade. Os
idiomas são muito menos úteis em trabalhos de documentários onde o realizador tem de
dar o melhor uso do assunto a ser debatido do qual ele não tem nenhum controle.
2.2.2 A diferença entre câmaras reais e virtuais
A câmara virtual é um conceito importante na computação gráfica, pois representa o
ponto de vista sobre o qual os objectos do mundo são projectados no ecrã. Uma câmara
virtual pode ser colocada em qualquer parte do mundo gráfico, incluindo dentro de
objectos sólidos. No mundo virtual as câmaras não têm qualquer limite de movimentação
de um ponto para outro ou de rotação em torno de qualquer eixo, podendo ocorrer esta
movimentação a uma velocidade instantânea.
Já uma câmara real, por outro lado, apresenta um conjunto de limitações físicas. Não pode
penetrar dentro de objectos sólidos e não pode contornar um objecto, voando, com a
mesma facilidade. Devido ao modo como se movem e giram, as câmaras reais, levantam
também problemas de velocidade para realizar as operações pretendidas.
Apesar das limitações das câmaras reais é importante impor algumas restrições nas
câmaras virtuais para que estas se assemelhem a realidade. Uma das vantagens de usar
uma câmara virtual no mundo gráfico é que permite saber, com alguma facilidade, as
posições dos objectos no seu ambiente. Nas câmaras reais não se tem a informação de
onde os objectos estão localizados concretamente [Drucker, 94].
2.2.3 Restrições físicas da câmara
As restrições físicas também podem ser aplicadas na câmara virtual para que esta se torne
o mais similar possível com uma câmara real nas suas limitações. As limitações a
estabelecer numa câmara virtual são:
8

Velocidade de rotação da câmara: limitar a velocidade da rotação da câmara
virtual.

Velocidade de movimento da câmara: limitar o intervalo de movimento da câmara
virtual. Por exemplo, num cenário com várias câmaras deve-se assegurar que a
deslocação para novas posições seja possível com uma câmara real.

Velocidade do zoom: A restrição na velocidade do zoom limita a velocidade da
câmara de mudar o nível de zoom, limitando-se também os níveis máximos e
mínimos do zoom.
Close-up – Redução de ângulo de um grande plano para um plano mais fechado de um determinado
pormenor a filmar, dando a sensação de transportar o espectador para dentro da cena [Mascelli, 98].
13
A inclusão destas três restrições físicas, cobre assim os 7 graus de liberdade de uma
câmara virtual no seu mundo tridimensional.
2.3 Conclusões
O desenvolvimento das tecnologias gráficas permitiu novos métodos de visualização que
vão de encontro aos conceitos cinematográficos. É neste contexto que surge a necessidade
de utilizar conceitos gráficos e cinematográficos, para que se possa criar um sistema de
controlo de câmara que se assemelhe com a da realidade. O visualizador tridimensional,
Virtual3D, desenvolvido no âmbito desta tese, utiliza os conceitos atrás referenciados de
forma a dar ao espectador o ambiente real desejado, como de uma filmagem televisiva se
tratasse.
14
CAPÍTULO 3: CONTROLO CÂMARAS INTELIGENTES
3 CONTROLO CÂMARAS INTELIGENTES
Este capítulo pretende descrever, no domínio do controlo inteligente de câmara, as
diversas abordagens metodológicas apresentadas pelos diferentes autores. O objectivo
central dos autores é desenvolver um conjunto de soluções para o problema de procurar a
melhor solução de posicionar ou orientar a câmara de filmagem para um determinado
cenário a filmar.
3.1 Introdução
Os movimentos das câmaras têm sido estudados em diferentes contextos da Computação
Gráfica, nomeadamente: animação, exploração, manipulação e apresentações. As câmaras
virtuais são normalmente descritas através de transformações de visualização [Foley et
al., 00]. Usando a relação geométrica entre o espaço virtual e o plano de visão, Blinn
desenvolveu uma técnica de controlo da câmara que automaticamente calcula a posição,
orientação e o factor zoom da câmara, através da especificação de dois objectos
posicionados no plano de visão [Blinn, 88].
Um outro método para controlar uma câmara foi sugerido por [Phillips et al., 92], para ser
utilizando na manipulação do sistema “Jack”9. A câmara é posicionada num local visível
e num ângulo apropriado para uma manipulação da câmara, utilizando os vários
controlos.
Karp e Feiner descrevem um sistema para gerar apresentações automáticas, mas não
consideram o controlo interactivo da câmara [Karp e Feiner, 90].
Seligmann e Feiner usam as restrições de visibilidade não para controlar o
posicionamento da câmara, mas para melhorar a renderização10 da imagem final
[Seligmann, 93] [Seligmann e Feiner, 91].
Gleicher e Witkin criaram um sistema chamado de “Throughthe-lens camera control”,
para controlar o movimento da câmara baseado no sistema de projecção do objecto do
mundo para o ecrã [Gleicher e Witkin, 92].
O sistema CINEMA era uma tentativa inicial a unificar estas várias noções de controlo de
câmara. Era um método procedimental para especificar o movimento da câmara baseado
nos objectos que fazem parte do mundo virtual [Ducker et al., 92].
Outros sistemas concentraram-se em achar o melhor posicionamento para a câmara
quando são executadas tarefas interactivas, como as que serão abordados nesta tese.
Drucker em particular mostrou como posicionar de uma forma óptima uma câmara para
9
Sistema Jack – Ferramenta de trabalho desenvolvida por Phillips e Badler para articular modelos
anatómicos [Phillips e Badler, 98].
10
Renderização - Termo aplicado para as diversas formas e metodologias de cálculo de textura, sombra e
cores em um conjunto de objectos vectoriais.
15
shots individuais resolvendo o problema através da optimização das restrições, apesar do
seu modelo ser pouco generalista e reutilizável [Ducker e Zeltzer, 95].
3.2 Sistemas de Câmaras Inteligentes
Nos pontos seguintes são apresentados os trabalhos mais relevantes para o problema no
planeamento de controlo de câmaras de filmagem. A intenção é identificar características
comuns que significam aproximações gerais ao problema no âmbito das várias técnicas de
filmagem em mundos reais ou virtuais a três dimensões.
3.2.1 Jim Blinn – Sistema espacial
A primeira tentativa para o controlo automático de câmaras num cenário virtual foi
desenvolvida por Jim Blinn [Blinn, 88]. O sistema foi projectado para colocar diferentes
câmaras numa sucessão de efeitos especiais de forma a colocarem a câmara posicionada e
na direcção do ponto de interesse11.
O problema consistia em, dada uma nave em órbita e um planeta em fundo, definir onde
se deve a câmara posicionar e como deve estar orientada de forma que a que a nave
apareça nas coordenadas (x_ship, y_ship) do ecrã a d metros de distância, estando o
planeta nas coordenadas (x_planet, y_planet) do ecrã mantendo o eixo de rotação do
planeta paralelo ao eixo y e desejar que o campo de visão seja φ graus.
3.2.2 Gleicher - Assistente para controlo automático de câmara
Gleicher e Witkin descrevem o controlo de câmara através de resolução de restrições de
projecção no artigo “Through the Lens Camera Control” [Gleicher e Witkin, 92]. Os
autores não tentam generalizar o sistema fora do contexto do posicionamento da câmara.
Além disso, o sistema apresenta várias limitações. O sistema assume que o
posicionamento apropriado para a câmara no sistema gráfico pode ser possível para
alguns exemplos de manipulação mas pode ser geralmente falso na maioria das operações
cinemáticas. Na realidade, foi declarado que quase 70% de todos os shots na maioria dos
filmes não envolvem nenhum movimento da câmara.
O Assistente para controlo automático de câmara12 baseia-se na noção que a mudança de
projecção de um ponto nas coordenadas do mundo pode ser a base para a mudança de
parâmetros da câmara. Para resolver o posicionamento da câmara, o assistente resolve
então um conjunto de equações diferenciais que dão o movimento de controlo
(posicionamento) na limitação dos pontos das coordenadas do mundo para pontos das
coordenadas de ecrã. O sistema deve ter cuidado na resolução das equações de forma a
garantir controle estável dos parâmetros da câmara (por exemplo: pontos que têm
11
12
Ponto de interesse – ponto para onde se deve olhar no ecrã no qual apresenta mais interesse na cena.
Automatic camera control assistant
16
pequenas oscilações nos parâmetros da câmara poderão ter um enorme efeito no resultado
da mudança de projecção).
3.2.3 CamDroid – Sistema para controlo inteligente de câmara
Uma generalização da versão de Blinn foi desenvolvida por Ducker et al [Ducker et al.,
92] [Ducker e Zeltzer, 95] [Ducker e Zeltzer, 96]. No sistema de Ducker a imagem
desejada é definida por dois conjuntos de funções. O primeiro, são as restrições que
devem ser conhecidas. O segundo, são os objectivos que têm que ser minimizados. O
resultado da optimização das diferentes restrições passa por uma bibilioteca de
optimização chamada de CFSQP (C code for Feasible Sequential Quadratic
Programming), que permite saber qual a solução satisfatoriamente encontrada para as
restrições da câmara.
A noção central deste sistema é que o posicionamento e movimentação da câmara são
normalmente efectuadas por um conjunto particular de razões, que podem ser expressas
formalmente como um número de primitivas ou limitações nos parâmetros de uma
câmara. A identificação das limitações da câmara é baseada sobre uma análise de tarefas
específicas para cada domínio. Analisando uma ampla variedade de tarefas, uma larga
base de primitivas podem ser facilmente incorporadas dentro de uma tarefa específica.
O sistema proposto inclui um conjunto de módulos para controlo da câmara.
Essencialmente esses módulos representam o encapsulamento dos comportamentos da
câmara para diferentes domínios de filmagem. O conceito geral de um módulo de câmara
é similar ao conceito de shot na cinematografia.
Processos de
aplicações
especificas /
Interface de
Objectos
Interfaces da
câmara para
aplicação
especifica
Interpretador
Base de dados
dos objectos
Módulos de
câmara
o
tad
es ara
m
â
c
Renderização
Figura 3.1: Arquitectura do modelo CamDroid de Ducker
A arquitectura do sistema proposto na figura 3.1 é estruturada de forma a realçar a divisão
entre uma base de dados do mundo virtual, a estrutura de câmara e um interface que faz a
ligação entre ambos. A estrutura é constituída pelos seguintes módulos:




17
Um interpretador: permite executar módulos ou gerir a entrada de informação do
utilizador. O interpretador que utilizada a linguagem TCL13 é uma parte
importante no sistema, pois inclui um conjunto de bibliotecas que permite tratar da
computação de matrizes, base de dados, cálculos de visibilidade e dinâmica de
simulação.
Sistema de renderização: sistema que permite o uso que qualquer hardware
gráfico ou software para renderização.
Base de dados do ambiente: contem a informação referente a todos os objectos
que existem no ambiente virtual.
Módulo da câmara: Essencialmente permite encapsular os comportamentos das
câmaras para os diferentes estilos de interacção com o ambiente.
Entrada de
dados utilizador
Lista de restrições
Controlador
Inicializador
Estado
Parametros
da câmara
Figura 3.2: Módulo genérico de uma câmara de Ducker
O módulo de câmara, representando na figura 3.2, é a base do sistema CamDroid. Permite
que várias interfaces possam ser rapidamente construídas para as várias tarefas de
filmagem a realizar. O módulo de câmara é constituído pelos seguintes componentes:




13
Estado – Contem a informação referente ao estado da câmara: posição, matriz de
visualização, vector “up” e o campo de visão. O estado pode conter também
alguns valores derivados dos parâmetros da câmara, valores de tempo ou outro
tipo de informação específica ao módulo. Sempre que o módulo está activo a
câmara está a ser renderizada para ser visualizada;
Inicializador – Esta rotina é iniciada quando o módulo está activo, inicializando o
estado da câmara do componente anterior;
Controlador – Este componente passa a entrada de dados do utilizador
directamente para o estado da câmara.
Lista de restrições – Contêm as restrições a satisfazer pela câmara sempre que o
módulo está activo.
TCL – Linguagem de programação a base de scripts.
18
3.2.4
ConstraintCam - Controlo da câmara através de restrições
William Bares, conjuntamente com James Lester [Bares e Lester, 99], desenvolveu um
sistema chamado de ConstraintCam (Controlo da câmara através de restrições). O sistema
permite, através de uma interface de visualização cinemática flexível, aos utilizadores
seleccionarem, em tempo real, quais os objectos a serem vistos, especificarem quais as
restrições aplicadas a cada objecto, seleccionar qual o tipo de estilo cinemático,
escolherem os efeitos de destaque e controlarem a informação a ser exibida no ecrã.
Descrição do
Mundo Virtual 3D
Pedidos de visualizção
Estruturas de
Multi-shot
Interface inteligente de visualização 3D
Analise de restrições
Resolução de restrições
Composição Multi-shot
Plano de visualização
Figura 3.3: Arquitectura ConstraintCam de Bares
Os pedidos de visualização são resolvidos pelo sistema ConstraintCam cujos módulos
principais estão ilustrados na figura 3.3. As bases de conhecimento incluem a descrição
do mundo virtual 3D e as estruturas de Multi-shot para composição das cenas. Os
módulos principais da arquitectura são os seguintes:

Análise de restrições: módulo que identifica as regiões no espaço dimensional
para posicionar a câmara satisfazendo as restrições;

Resolução de restrições: se uma solução for possível, é determinado, calculando
uma região comum no espaço, onde colocar a câmara para que todas as restrições
sejam satisfeitas. Se não se encontrar um único shot que satisfaça as restrições, o
módulo identifica quais pares de restrições que são incompatíveis. As restrições
incompatíveis e mais fracas entram então em relaxação para permitir uma solução
mais rápida por parte do sistema.

Composição de Multi-Shot – módulo que explora na base de dados de
conhecimento a estrutura multi-shot para criar, sucessivamente ou
compostamente, as soluções múltiplas de visualização dos shots.
19
Após o processamento sequencial pelos diferentes módulos temos como resultado um
plano de visualização hierárquico de shots. O plano é então processado em tempo real
pela componente gráfica. Posteriormente o processo é repetido desde o início tendo em
conta os novos desenvolvimentos no ambiente virtual.
No sistema desenvolvido os objectos são sujeitos a quatro tipos de restrição:
1. Melhor ângulo (vantage angle): indica o intervalo permissível de orientações
relativas da câmara com o objecto (por exemplo: quais as faces de um objecto que
a câmara é capaz de visualizar e destas quais são as óptimas);
2. Distância de filmagem (shot distance): especifica a distância mínima e máxima
permitida entre a câmara e o objecto;
3. Inclusão de objecto (object inclusion): requer que um objecto seja visualizado;
4. Área de inclusão (room enclosure): Limitar a posição da câmara para permanecer
dentro de uma região rectangular inclusa opcional.
A importância de cada restrição é determinada pelo produto da prioridade do objecto pela
prioridade de cada restrição. Durante a relaxação, as restrições de menor importância
serão desligadas ao invés das maiores.
Usando o trabalho anterior, Bares desenvolveu, conjuntamente com Thainimit e
McDermott, um novo conjunto de restrições mais complexo para controlo da câmara. O
sistema desenvolvido suporta onze restrições referentes aos atributos da câmara ou como
os objectos aparecem para o shot [Bares et al., 00a] [Bares et al., 00b] [Bares et al., 00c].
As novas restrições são:
1. Look At Point: restringe a focagem da câmara para um determinado ponto
(objecto);
2. Object in Field of View: restringe que um objecto esteja no campo de visão;
3. Object Occlusion Minimize: restrição dos objectos com um determinado valor
mínimo de oclusão. Os valores de oclusão variam no intervalo de [0.0 a 1.0];
4. Object View Angle: restrição do ângulo de orientação da câmara referente ao
objecto. A orientação é expressa em coordenadas esféricas;
5. Object Distance: restrição da distância da câmara ao centro do objecto;
6. Object Projection Size: restringe a distância da câmara para com o objecto e o
ângulo do campo de visão determina o tamanho no qual o objecto é visualizado,
utilizando por exemplo para um close-up;
20
7. Object Projection Absolute: Exigir que a projecção de um objecto principal fique
completamente dentro de uma determinada região rectangular da imagem a duas
dimensões.
8. Object Projection Relative: A projecção do objecto principal estipula uma relação
para a projecção do objecto secundário na imagem.
9. Object Depth Order: restrição para especificar que a câmara seja posicionada de
forma que o objecto pivot apareça o mais próximo ou distante da câmara do que
um objecto secundário.
10. Camera Position Region: restringe a região de acção da câmara no espaço
tridimensional;
11. Camera Field of View: restringe o ângulo do campo de visão da câmara na vertical
e na horizontal para definir o formato da imagem a ser visualizada.
Estas novas restrições descritas por Bares, apesar de terem provado ser bastante
satisfatórias para codificar os cenários de filmagem matematicamente, apresentam o
problema no módulo de resolução de restrições para achar os melhores posicionamentos
em tempo real, algo que o sistema anterior fazia. Isto deve-se ao facto do novo número de
restrições e da sua complexidade. Não funcionando o modelo em tempo real, torna-se
difícil achar uma nova posição da câmara quando esta acompanha um objecto que se
move na cena. Porém, resolver as restrições em tempo real não é uma exigência para um
sistema de posicionamento de câmaras automatizado que acha as melhores soluções de
filmagem em cenários reais. O novo modelo produz bons resultados para cenas que
envolvam vários objectos a serem filmados, como provam os resultados apresentados
pelos autores.
A medição do grau de satisfação das restrições avaliadas ou resolvidas é importante para
determinar se um determinado posicionamento da câmara satisfaz cada uma das
restrições. O grau de satisfação para cada restrição é calculado através de um valor
fraccionário compreendido entre [0.0 a 1.0], especificando quais os valores mais
satisfatórios para o posicionamento da câmara. O valor total acumulativo do grau de
satisfação é a soma dos pesos de satisfação de todas as restrições individuais expressas na
equação abaixo, onde Pi significa a prioridade da i-ésima restrição, Si a taxa de satisfação
da mesma restrição e N é o número total de restrições.
N
Grau Satisfação =
∑ (Pi * Si)
1
21
O protótipo inicial para resolução das restrições utiliza um algoritmo de gerar e testar de
forma a determinar a colocação da câmara tendo em conta o grau de satisfação
acumulativo mais elevado. Os posicionamentos candidatos da câmara são gerados
repetidamente em passos discretos sobre todas as possibilidades da câmara (posição,
objectivo, direcção, campo de visão). O protótipo analisa assim um conjunto vasto de
hipóteses tornando-se bastante lento, implicando sérios problemas para ser implementado
em tempo real.
3.2.5 DCCL – Linguagem declarativa para controlo de câmara
O sistema desenvolvido por He e Christianson em 1996 [Christianson et al., 96] [He et al.,
96] chamado de Linguagem Declarativa de Controlo de Câmara (DCCL14) baseia-se
numa base de dados de idiomas cinematográficos predeterminados. O sistema foi
implementado para ser utilizado nas áreas da indústria e entretenimento para resolver o
problema do controle da câmara em cenários interactivos e com animações dos actores
muito diversificada (ver figura 3.4).
A DCCL é uma linguagem usada para codificar os idiomas cinematográficos, sendo
constituída por quatro primitivas, que são as seguintes:
1. Fragmentos (Fragments): um fragmento especifica o intervalo de tempo durante o
qual uma câmara estática está numa determinada posição e orientada ou a câmara
está em movimento;
2. Visão: especificação da animação tal como um close-up;
3. Posicionamento: definição da posição da câmara em relação aos actores;
4. Movimento final: usado para indicar a extensão de movimento a ser coberta pela
câmara junto ao actor relativamente ao fragmento.
A entrada de dados para o sistema é a simulação traçada com a informação da actividade
executada por cada actor em cada tempo de ciclo. O primeiro módulo é o sequenciador,
em que a sua função é dividir a simulação traçada em cenas, especificando o actor
principal da cena.
Para cada cena o conjunto de idiomas a instanciar é introduzido no compilador DCCL,
que produz para cada imagem da animação as referências de configuração da câmara. As
especificações da imagem são fornecidadas ao avaliador de heurísticas, que analisa o
idioma e calcula o desempenho comparando com as várias heurísticas cinemáticas do
sistema. As heurísticas tipicamente usadas são:

14
Suavização na transição de shots;
DCCL - Declarative Camera Control Language.
22

A câmara não deve “cruzar” a linha de interesse;

Os shots de filmagem não podem ser muito perto ou longe dos actores;

A câmara não pode rodar para trás.
Dados para
simulação
Gestor de
sequencias
Idiomas
Compilador
DCCL
Imagens
candidatas
Analisador de
Heuristicas
Imagem
final
Figura 3.4: Arquitectura do modelo DCCL de He e Christianson, 1996.
O processo acaba quando o melhor resultado do idioma for encontrado, começando de
seguida o processo de renderização. No sistema, o compilador DCCL, a base de dados de
idiomas e o analisador de heurísticas são domínios completamente independentes,
enquanto o gestor de sequências é dependente.
3.2.6
FILM - O Cinematógrafo virtual
Um modelo alternativo de idiomas cinematográficos para ser executado em tempo real,
nomeadamente em jogos ou simulações foi desenvolvido por Amerson e Kime com o
nome de FILM (Film Idiom Language and Model) [Amerson e Kime, 01].
O sistema DCCL descrito anteriormente, onde o controlo de câmara é realizado por
idiomas que obedecem às restrições, é a grande base conceptual do sistema FILM, apesar
do sistema DCCL não ter sido desenhado para trabalhar em tempo real. O modelo de
Bares e Lester [Bares e Lester, 99] dá o seu contributo na selecção e composição dos
shots em tempo real. Para representar a cena através de uma árvore foi usada a noção do
sistema Virtual Cinematographer de He, Cohen e Salesien, que explora a cena
hierarquicamente para o modelo cinematográfico em tempo real [He et al., 96].
Em contraste com os sistemas anteriores, foi proposto assim um sistema híbrido que usa a
abstracção definindo os idiomas cinematográficos como restrições para seleccionar o
melhor posicionamento da câmara para qualquer shot, em qualquer momento, a qualquer
elemento geométrico.
A estrutura do controlo da câmara proposto pelos autores é baseada nas noções práticas
da realização cinematográfica. No sistema FILM as decisões de filmagem individuais do
realizador e operador de câmara são representadas por módulos de software, como se
pode observar na figura 3.5. É o realizador quem selecciona os shots baseando-se na
composição e natureza da cena a filmar. Como exemplo, no cinema real é o realizador
que controla e sabe os movimentos dos actores.
Longbow
Comunicar
intenções
Tradutor
Comunicar
intenções
Realizador
Especificação Shot
na linguagen FILM
Figura 3.5: Arquitectura do modelo FILM de Amerson e Kime
"Cameraman"
23
Para simular o modelo real cinematográfico, o sistema FILM é constituído por um
pipeline, como pode ser visto na imagem acima. O módulo Longbow15 é quem faz a o
planeamento da narração, pois é ele que define o que deve ser visto na visualização. Esta
informação é de seguida comunicada para o módulo de Tradução para que as intenções de
visualização do módulo Longbow possam ser convertidos em termos que o Realizador
possa entender.
O módulo Realizador utiliza a informação proveniente do Tradutor (o tipo de cena, o
número de participantes, o estado emocional ou afectivo da cena) para efectuar a pesquisa
em profundidade (depth-first), com backtracking de forma a seleccionar a melhor cena na
árvore de pesquisa das cenas. Após a selecção, o Realizador comunica a informação
(restrições de tempo, localizações, rotações, actores e propriedades do mundo) para
realização da cena ao “cameraman”16.
Uma vez que o Realizador definiu as especificações da cena e as restrições da filmagem
da cena, o trabalho do “cameraman” é escolher a melhor posição e configurar as câmaras,
tentando ao mesmo tempo satisfazer os idiomas do Realizador e os problemas de oclusão
dos objectos. Toda a responsabilidade de comunicação com o motor gráfico é da
responsabilidade do “cameraman”.
Um desenvolvimento ao modelo FILM foi efectuado por Charles [Charles et al., 02], que
desenvolveu um sistema chamado de “Realizador Virtual e Operador Virtual”. O
Realizador virtual recebe a comunicação das intenções do módulo de reconhecimento,
seleccionando na base de dados os melhores shots para instanciar satisfatoriamente as
intenções. O “cameraman” virtual por sua vez é o responsável pelas configurações das
câmaras. O sistema é mais satisfatório em tempo real que o FILM, pois pode responder a
mudanças do mundo pela acção do módulo de reconhecimento que gera novos shots.
3.3 Conclusões
Ao longo deste capítulo foram apresentados os modelos de maior interesse para esta tese
no domínio do controlo de câmara inteligente. Os modelos descritos pretendem identificar
as funcionalidades básicas de controlo de câmara respeitando os conceitos
cinematográficos. Através dos modelos apresentados pretende-se identificar caractristicas
de controlo para que se possa criar um modelo genérico utilizando agentes. Um sistema
de agentes é uma arquitectura que permite construir uma interface que pode ajudar a
executar várias tarefas de filmagem. Os agentes podem aprender observando as acções de
15
Longbow - é um sistema baseado no domínio da planificação da Inteligência Artificial que combina a
decomposição de raciocínio (planeamento para executar uma acção abstracta executando a acção através
de sub passos de acção) e o raciocínio causal (planificar para executar uma acção assegurando que as
condições prévias da acção são consideradas antes da sua execução) na mesma representação.
16
“Cameraman” – operador de uma câmara de filmar que executa uma filmagem.
24
um utilizador, ou podem encapsular conhecimento em como executar uma tarefa
correctamente e convenientemente. O controlo de uma câmara virtual é um bom exemplo
de como podem ser usados os agentes para ajudar o utilizador interagir com uma tarefa
complicada. A unificação de metodologias através de uma arquitectura de agentes têm
como objectivo criar um conjunto de tarefas acções identificáveis que possa levar a
resolução de como se filmar num sistema distribuído em que os agentes (realizador e
operadores) são os responsáveis pela coordenação da filmagem.
CAPÍTULO 4: SISTEMAS MULTI-AGENTE
25
4 SISTEMAS MULTI-AGENTE
A resolução distribuída e cooperativa de problemas faz apelo a arquitecturas de sistemas
apropriados os quais apontam para a noção de Agente e Sistema Multi-Agente (SMA). As
noções de Agente e SMA são aplicadas cada vez mais nas diferentes áreas
computacionais. É nestes dois conceitos que assenta esta tese, como base para modelação
e resolução dos diferentes problemas associados ao controlo de câmaras inteligentes.
Neste capitulo pretende-se apresentar com detalhe o conceito de agente, abordando as
várias características fundamentais e requisitos próprios que o caracterizam. Serão
apresentados os mais importantes modelos de cognição fundamentados em três principais
atitudes mentais, que são: as crenças, os desejos e as intenções (abreviadas por BDI, do
inglês beliefs, desires e intentions, respectivamente).
Outra noção não menos importante que se vai abordar é a de SMA, focando as suas
características e modelos organizacionais de agentes.
4.1 Agentes
A crescente relevância e utilizacção do paradigma de agentes no domínio informático tem
suscitado bastante discussão sobre as características em comum e os aspectos que os
distinguem dos demais programas. O paradigma trouxe às entidades computacionais dos
sistemas de software comportamentos próprios quando inseridas em um determinado
ambiente coordenando as suas próprias acções com base no seu conhecimento sobre as
acções possíveis e as suas consequências sobre os outros agentes e o meio ambiente que
as rodeia.
4.1.1 Conceito de agente
O conceito de agente é baseado em inúmeras áreas do conhecimento, desde a Psicologia,
Sociologia, até as Ciências de Computação. Foi a comunidade de Inteligência Artificial,
pelo facto de basear-se em metáforas psicológicas e sociais como forma de inspiração e
de motivação, quer como forma de modelação do processamento (complexo) da
informação, que optou por este conceito. Esta primazia está associada a Carl Hewitt pela
sua proposta do sistema actor [Hewitt, 77].
“Um actor é um agente computacional que têm um endereço de correio electrónico e um
comportamento. Os actores comunicam por troca de mensagens e executam as suas
mensagens concorrentemente” [Hewitt, 77].
No entanto, o conceito de agente é bastante genérico, não existindo uma definição
comum. Contudo, a maior parte das definições são tudo menos uniformes, como ser vê no
trabalho de Franklin e Graesser [Franklin e Graesser, 96]:
26
MudBot de Sankar Virdhagriswaram [www.mudbot.org]: “… o termo agente é usado
para representar dois conceitos ortogonais. O primeiro é a capacidade computacional de
um agente executar autonomamente. O segundo é a capacidade de um agente raciocinar
perante um domínio específico “.
AIMA de Russel e Norvig [Russel e Norvig, 95]: “Um agente é qualquer objecto que
possa ser visto como percepcionando o seu ambiente através de sensores e actuar sobre
esse ambiente através de actuadores”.
Maes de Pattie Mães [Maes, 96]: “Agentes autónomos são sistemas computacionais
que habitam em ambientes dinâmicos e complexos, e actuam autonomamente no seu
ambiente e ao efectuar isso realizam um conjunto de objectivos ou tarefas para as quais
foram designados”.
KidSim de Smith, Cypher e Spohrer [Smith, Cypher e Spohrer, 94]: “Define-se um
agente como uma entidade persistente de software dedicada a um determinado objectivo.
Ser persistente distingue os agentes das sub rotinas; os agentes têm as suas próprias ideias
sobre como completar as suas tarefas, a sua própria agenda. Ter um objectivo específico
distingue-os das aplicações com múltiplas funções; os agentes são tipicamente mais
simples”.
Hayes-Roth de Hayes [Hayes-Roth, 95]: “Agentes inteligentes executam
continuamente três funções: percepcionam as condições dinâmicas do ambiente, actuam
para afectar as condições do ambiente e raciocinam para interpretar as suas percepções,
resolver problemas e determinar as suas acções”.
IBM [IBM, 97]: “Agentes inteligentes são entidades em software que executam
algum conjunto de operações em nome de um utilizador ou outro programa com algum
grau de independência ou autonomia, e ao fazê-lo, utilizam conhecimentos ou
representações dos objectivos ou desejos do utilizador”.
Wooldridge e Jennings [Wooldridge e Jennings, 94]: “ (Um agente é) um sistema
computorizado em hardware ou (mais frequentemente) em software que goza das
seguintes propriedades: autonomia, capacidade social, reactividade e pró – actividade”.
SodaBot de Michael Coen [Coen, 94]: “Agentes de software são programas que
dialogam entre si e negoceiam e coordenam transferências de informação”.
Brustoloni de Brustoloni e Franklin [Brustoloni, 96] [Franklin, 95]: “Agentes
autónomos são sistemas capazes de acções autónomas, com objectivos próprios no mundo
real”.
No entanto, na maior parte das definições é aceite como ponto fulcral o facto de um
agente ser uma entidade computacional com capacidade de raciocínio.
27
Uma das mais compreensíveis definições de agentes e na qual os nossos agentes se
enquadram neste trabalho é a de Wooldridge e Jennings [Wooldridge e Jennings, 95], na
qual se define um agente segundo uma visão “forte” e uma visão “fraca”.
A noção fraca de agente, que deriva das áreas da computação distribuída e inteligência
artificial distribuída, baseia-se no conjunto mínimo de características que um agente
deverá possuir em geral, tais como:

Autonomia: Os agentes operam sem intervenção directa humana ou outra, e
possuem controlo sobre as suas acções e o seu estado interno.

Sociabilidade: Os agentes interactuam com outros agentes ou humanos no sentido
de resolver um problema ou ajudar outros nas suas actividades. A comunicação é
efectuada através de algum tipo de linguagem.

Reactividade: Os agentes observam e analisam o seu ambiente de forma a
responderem em tempo útil às alterações nele ocorridas. Estes agentes são
designados de reactivos e são de fácil concepção, baseando-se em três
componentes (percepção, acção e comunicação).

Pró-actividade (ou orientação por objectivos): Os agentes não actuam apenas em
resposta às alterações do seu ambiente, mas também apresentam comportamentos
conduzidos pelos seus objectivos sendo capazes de tomar iniciativa na realização
de determinadas acções.

Persistência: Os agentes mantêm consistentemente o seu estado interno ao longo
da sua existência.
A noção forte de agente, que deriva essencialmente da área da inteligência artificial onde
o agente é visto como uma entidade cognitiva com consciência e com capacidade de
aprendizagem, sendo capaz, à semelhança dos humanos, de exibir sentimentos,
percepções e emoções. Os atributos associados à determinação do agente são:

Conhecimento: Possuir conhecimento é muito mais do que possuir informação,
não sendo apenas a recolha de informação dinamicamente, mas também o
raciocínio sobre essa mesma informação.

Crenças: É a noção que o agente possui sobre um determinado facto, sendo esta
dinâmica, pois o seu valor de verdade pode ser alterado no tempo. De entre as
teorias desenvolvidas destacam-se os trabalhos de Rao e Georgeff baseado em
agentes BDI (agentes com crenças, desejos e intenções) [Rao e Georgeff, 95] e o
de Wooldridge e Jennings de com agentes baseados em atitudes e pró-atitudes
[Wooldridge e Jennings, 95].
28

Intenções: Capacidade de representação dos objectivos de um agente, objectivos
esses que o agente possui ao longo do tempo e resultam de padrões de
comportamento, levando a execução de acções individuais.

Obrigações: Compromissos que o agente assumiu a partir do momento que o
agente expressou a sua disponibilidade para executar uma determinada tarefa.

Veracidade: Assunção que um agente não comunica (deliberadamente)
informação falsa, devendo ser sempre verdadeiro.

Benevolência: Significa que um agente não deve assumir um comportamento
contra-produtivo, adoptando os objectivos dos outros agentes, desde que estes não
sejam incompatíveis com os seus objectivos.
4.1.2 Contexto de um agente
Um agente está situado num determinado contexto quando se encontra exposto a
interacções com ele próprio e com o ambiente do qual faz parte. Por exemplo: um agente
de software que analisa uma rede eléctrica ou negoceia na Internet entre outros. Esta
assumpção é essencial pois é determinante na definição e na actuação de um agente (se a
sua existência fosse autónoma até em relação aos seus objectivos, um agente poderia ser
visto como uma caixa preta, sem qualquer utilidade).
As interacções com o ambiente são essenciais ao agente pois permitem alterar o ambiente
através de acções ou obter através dos sensores informações úteis para cumprimento dos
seus objectivos (incluindo a avaliação do seu próprio desempenho).
Tantos os sensores como os mecanismos de acção dependem do contexto e natureza do
agente. Podemos considerar como sendo um agente, desde um robô com sensores ópticos
e rodas até agentes de software que negoceiam na Internet ou recolhem informações de
bases de dados. Existe uma enorme variedade de tipos de agentes sendo impossível referilos todos. No contexto desta tese, a atenção centra-se nos agentes que tem a sua existência
ao nível do software.
4.1.3 Arquitecturas de agentes
Segundo Pattie Maes, as arquitecturas são especificações de como se pode construir
agentes através de módulos e como estes interagem ente si. Os módulos e interacções
existentes entre os mesmos devem especificar como, a partir dos dados dos sensores e do
estado actual do agente, são obtidas as acções e o novo estado interno [Maes, 96].
Um aspecto importante num agente é a sua arquitectura interna. A arquitectura interna de
um agente está associada à sua própria definição e mecanismos de decisão do agente que
determina a influência de actuação individualmente e na própria arquitectura do Sistema
Multi-Agente. As arquitecturas de agentes definem assim o comportamento interno de
29
cada agente mas, também o próprio Sistema Multi-Agente onde os agentes estão
inseridos.
Wooldridge e Jennings afirmam que a arquitectura de um agente pode ser estruturada
através de uma metodologia específica para definir agentes, abrangendo técnicas e
algoritmos para suportar essa mesma metodologia [Wooldridge e Jennings, 94].
A Inteligência Artificial classifica os agentes computacionais em três grandes categorias:
agentes deliberativos, reactivos e híbridos [Wooldridge, 98]:

Agentes deliberativos: Abordagem clássica onde os agentes actuam com pouca
autonomia, com uma visão “top-down” e possuindo modelos simbólicos explícitos
para verificar informação e gerar acções no seu ambiente através de raciocínio
lógico (figura 4.1). Este tipo de agente permite com alguma facilidade que se
análise a qualidade do desempenho do agente. Normalmente, este tipo de agente
tem: um objectivo, crenças acerca do seu contexto e mecanismo de raciocínio. Na
construção destes agentes levantam-se dois problemas concretos: como traduzir o
mundo para uma descrição simbólica em tempo real e como raciocinar utilizando
essa informação simbólica de forma a decidir as acções a executar em cada
instante.
Raciocínio
Conhecimento
Actualização do
Estado do
Mundo
Acções
Possiveis
Decisão
Objectivos
Execução da
Acção
Interpretação da
Percepção
Comunicação
AMBIENTE
percepção
Figura 4.1: Representação de um agente deliberativo genérico
Acção
30
 Agentes reactivos: Abordagem que procura não utilizar um modelo ou raciocínio
simbólico complexo, comportando-se autonomamente no ambiente inserido em
que os comportamentos inteligentes emergem da dinâmica das interacções com o
contexto [Brooks, 91]. O agente toma as suas decisões em “tempo real”,
geralmente com base em um conjunto de informação muito limitada. A
informação proveniente dos sensores é normalmente utilizada directamente no
processo de decisão não sendo criada qualquer representação simbólica do mundo
(ver figura 4.2).
Regras simples
situação/acção
(comportamentos)
Interpretação da
Percepção
percepção
Decisão
AMBIENTE
Execução da
Acção
Acção
Figura 4.2: Representação de um agente reactivo genérico
 Agentes híbridos: Combinam as características das duas abordagens anteriores,
“retirando” os seus pontos fracos. Os agentes reactivos são limitados em
implementar comportamentos orientados aos objectivos. Por sua vez, os
deliberativos são baseados em mecanismos de raciocínio complexo, tendo por
vezes algumas dificuldades em reagir a estímulos exteriores. Modelos híbridos
estruturam-se hierarquicamente por níveis ou camadas, possibilitando uma melhor
estruturação das funcionalidades e controlo do agente. Normalmente a camada
reactiva tem prioridade em relação à deliberativa de forma a permitir um estímulo
mais rápido aos eventos do ambiente (ver figura 4.3).
31
componente deliberativa
Acções
Possiveis
Raciocínio
Conhecimento
Actualização do
Estado do
Mundo
Decisão
Deliberativa
Objectivos
componente reactiva
Regras simples
situação/acção
(comportamentos)
Interpretação da
Percepção
Decisão
reactiva
Fusão das
decisões
Comunicação
AMBIENTE
Acção
Execução da
Acção
percepção
Figura 4.3: Representação de um agente híbrido
Como exemplo desta solução híbrida Neves e Oliveira apresentam um robô móvel
movimentando-se em ambientes com um grau de incerteza respeitante à sua
previsibilidade [Neves e Oliveira, 97]. A componente deliberativa tem a função de
guiar o comportamento da reactiva, através de sugestões de planos a realizar. No
entanto, em situações de emergência (iminência de uma colisão), a componente
reactiva sobrepõe-se à componente deliberativa, assumindo o controlo do robô
móvel.
4.1.4 Agentes emocionais
É cada vez mais óbvio que existe potencial para “casar” a tecnologia de agentes com as
áreas do cinema, jogos e realidade virtual [Wooldridge e Jennings, 95]. Para construir tais
mundos simulados, é necessário desenvolver agentes com propriedades de ser credível ou
parecer real, semelhante aos seres humanos [Bates, 94] [Reilly, 92]. O conceito de
emoção é natural em humanos, mas é bastante difícil de implementar no domínio dos
robôs, incluindo os agentes de software. A ideia geral é construir agentes que possam
sentir, pensar, desejar, ter “reacções emocionais”. J. Bates critica o facto dos
investigadores da Inteligência Artificial procurarem apenas construir agentes que
raciocinem, que resolvam problemas e aprendam, sendo realizado pouco investimento nas
habilidades emocionais do agente [Bates, 94]. As habilidades emocionais num agente de
software tem como objectivo:
32

Realizar uma avaliação interna do agente para medir se os objetivos do agente
estão a ser cumpridos;
 Ser utilizadas de forma a criar um planeamento para as futuras acções;
 Ser utilizadas como uma forma de comunicação entre agentes;
 Ser exteriorizadas por meio de actuações no próprio estado interno do agente que
se exterioriza na aparência do agente diante do mundo.
Vários projectos têm utilizado arquitecturas emocionais de agentes, no qual se destaca o
projecto OZ da Universidade de Carnegie Mellon, Pittsburgh, que consiste na criação de
mundos virtuais que contêm um conjunto de expressões que fornecem ao utilizador a
oportunidade de sentir e interagir dentro dos vários mundos. O projecto fornece um
conjunto de ferramentas para criar tipos de dramas interactivos utilizando expressões
interactivas, em tempo real e animadas [Bates et al., 92a]. Um mundo OZ é composto por
[Reilly, 92]:

Simulação de um ambiente físico;

Agentes que reagem as mudanças no ambiente, comportamentos direccionados
aos objectivos, emoções e personalidade;

Habilidade social e habilidades de linguagem;

Interface;

Teorias do drama.
No entanto, para Cañamero [Cañamero, 97], as emoções corporais e suas várias
expressões são uma parte essencial da aparência, apresentação e surgimento de cocomportamentos a longo prazo. O agente de software também é dotado de motivação
relacionada à sobrevivência que leva o agente a agir com autonomia, disposição e
temperamento que contribuem de uma forma importante para definir a personalidade do
agente. Para o reconhecimento de emoções, o autor propõe o uso de padrões para
caracterizar as diferentes emoções.
4.2 Arquitecturas BDI (“Belief-Desire-Intention”)
A arquitectura BDI é uma arquitectura essencialmente deliberativa [Rao e Georgeff, 91],
na medida em que se baseia em modelos simbólicos explícitos e num raciocínio lógico. O
modelo de cognição do agente é descrito através de um conjunto de “estados mentais”:
crenças (“Belief”), desejos (“Desire”) e intenção (“Intention”), denominada de
arquitectura BDI. A fundamentação filosófica para esta concepção de agentes vem do
trabalho de Dennett [Dennett, 87] sobre sistemas intencionais e de Bratman sobre
raciocínio prático [Bratman, 87]. A primeira implementação de um sistema baseado
nestas idéias foi o IRMA (Intelligent Resource-bounded Machine Architecture) [Bratman
33
et al., 88]. Com base nesta experiência, foi criado outro sistema que usa uma arquitectura
BDI, chamado PRS (Procedural Reasoning System) [Georgeff, 87] e o seu sucessor
dMARS [d’Inverno, 98]. Foi com base nestas experiências que Rao criou a linguagem de
programação AgentSpeak(L)17. Georgeff e Rao foram os principais autores a elaborarem
arquitecturas abstractas de agentes baseadas no modelo BDI, bem como na concepção de
lógicas BDI [Rao e Georgeff, 92, 95] [Rao, 96].
De seguida serão definidos os vários conceitos de “estados metais”, e serão apresentadas
as diferentes arquitecturas BDI de maior interesse para esta tese.
4.2.1 Estados mentais (crenças, desejos e intenções)
A ideia básica de uma arquitectura BDI baseia-se na descrição do processamento interno
do agente utilizando para isso um conjunto de “estados mentais” e na definição da
arquitectura de controlo, através do qual o agente selecciona racionalmente o seu curso
das acções a executar. Os “estados mentais” diferem ligeiramente de autor para autor, no
entanto as noções de crença, desejo e intenção são aceites unanimemente, até porque
estão na origem do nome atribuído à classe de arquitecturas de agentes.

Crenças: as crenças são basicamente as informações em que o agente acredita
referentes ao mundo e a si mesmo em cada instante, mas podem incluir
informações a respeito do resultado da execução de acções ou sequências de
acções pré-especificadas para atingir determinados objectivos. Por outro lado, o
conceito relacionado com crença é o de conhecimento, sendo geralmente o
conhecimento definido como uma crença verdadeira.

Desejos: são as motivações do agente [Rao e Georgeff, 95] correspondendo a
tarefas estabelecidas pelo próprio agente. Assim, como os agentes humanos, não
se exige que os desejos sejam logicamente consistentes. O desejo é um estado
emocional e com potencial motivador para atingir os vários objectivos que
resultam do processo de raciocínio. Desejos apresentam assim as seguintes
características:

Representam um conjunto de situações em que o agente gostaria que o
mundo estivesse.
 Podem estar em conflito com as crenças do próprio agente.
 Podem ser, simultaneamente, conflitosos com outros desejos do agente.
 As acções não são directamente executadas pelos desejos, mas
potencialmente pelas várias intenções criadas pelos desejos.
17
AgentSpeak(L) – Linguagem de programação para Agentes BDI [Rao, 96].
34

Intenções: As intenções são as tarefas ou acções que o agente seleccionou para
realizar, resultantes da escolha dos desejos que sejam consistentes com as crenças
do agente, com as intenções já seleccionadas e do comprometimento do agente
com a sua realização dos seus objectivos. Como exemplo temos um agente que
pode ter como intenção comprar algo, mas não decidiu onde. As intenções devem
ser consistentes internamente e representam o resultado do processo de
deliberação.
4.2.2 Arquitectura IRMA de Bratman
A arquitectura IRMA (Intelligent Resource-Bounded Machine Architecture), foi
desenvolvida tendo por definição duas características fundamentais para agentes racionais
[Bratman, 87]:

Inclusões de capacidades para realizar raciocínio de “meios-fins”, forma de como
avaliar cursos alternativos de acção e especificar como essas capacidades se
relacionam.

Limitação dos recursos do agente.
A arquitectura representada na figura 4.3 é constituída por um vários módulos, que são:

Estrutura de intenção: conjunto de intenções ordenadas no tempo;
 Planos estruturados em árvore: conjunto de sub-planos;
 Raciocinador ”meios-fins”: que raciocina sobre as crenças proveniente da
percepção do ambiente procurando sub-planos para completar os planos já
adoptados pelo agente que pertencem à estrutura de intenção do agente;
 Um analisador de “meios-fins”: que determina quais os planos que podem ser
usados para alcançar as intenções do agente;
 Processo de filtragem: módulo que recebe as opções do analisador e raciocinador
de “meios-fins”, testando a compatibilidade das opções com as intenções actuais
do agente;
 Analisador de oportunidades: que analisa o ambiente para determinar opções
adicionais para o agente;
 Deliberação: a escolha final das opções é efectuada pelo processo de deliberação
sendo adoptada como intenção do agente.
35
Acção
Planos
Intenções
Analisador de
oportunidades
opções
Raciocinador
Meios-Fins
opções
Filtro de
Compatibilidade
Filtro de
Sobreescrita
opções
seleccionadas
Percepção
Deliberação
Crenças
Desejos
Raciocinador
Figura 4.3: Arquitectura IRMA, segundo [Bratman, 87]
As crenças do agente são actualizadas pelas suas percepções que resultam do ambiente. O
analisador de oportunidades sugere opções de acções a executar baseadas nas próprias
crenças e desejos do agente. As opções que são sugeridas pelo raciocinador pertencem à
estrutura de intenção do agente. As opções disponíveis são executadas através do
processo de filtragem, onde são testadas para verificar a estrutura de intenção actual do
agente. As opções que passaram no processo de filtragem com sucesso são enviadas para
o processo de deliberação de forma a modificar a estrutura de intenção do agente,
adoptando assim o agente uma nova intenção. Estas intenções podem ser planos parciais,
forçando o raciocinador de “meios-fins” a propor novas opções, ao mesmo tempo que o
analisador de oportunidades propõe novas opções em função da alteração das crenças.
É importante referir que as intenções nesta abordagem são planos que o agente adoptou
para a execução, estando comprometido com eles futuramente. Os planos adoptados
podem ser parcialmente estruturados, representado que o agente está comprometido com
um objectivo sem ter executado a deliberação sobre todos os meios para atingir esse fim.
Desta parcialidade estrutural surge a necessidade de raciocínios de “meios-fins” que
invocarão sub-planos para complementar o plano parcial.
4.2.3 Arquitectura PRS de Georgeff e Lansky
O Sistema de Raciocínio Processual, PRS (Procedural Reasoning System) desenvolvido
pela Stanford Research Institute Internacional, é uma arquitectura BDI genérica para
representar raciocínio de acções e procedimentos em ambientes dinâmicos, implicando
36
uma grande reactividade por parte do agente [Georgeff 1986, Georgeff 1989]. Esta
arquitectura foi utilizada no domínio espacial pela NASA18 para controlo reactivo dos
propulsores que controlam a posição da nave na sua trajectória.
As características da arquitectura PRS que contribuíram para o seu sucesso foram:




Estratégia parcial de planeamento;
Reactividade;
Uso processual do conhecimento;
Capacidades reflexivas de metanível;
Base de Dados
( Factos, Crenças )
Biblioteca de Planos
( Área conhecimento )
INTERPRETADOR
Raciocínador
Objectivos
( Desejos )
Estrutura de Intenção
Monitor
Gerador de Comando
Sensores
Actuadores
Caminho principal de controle
AMBIENTE
Caminho principal de dados
Figura 4.4: Arquitectura PRS, segundo [Rao e Georgeff, 92]
A arquitectura PRS, como ilustra a figura 4.4, é subdividida em componentes periféricos
e de raciocínio. Os componentes periféricos são:




18
Sensores;
Um monitor para traduzir as informações em crenças do agente;
Actuadores para gerar eventos no ambiente;
Gerador de comandos.
NASA – National Aeronautics Space Administration (Agência Espacial dos Estados Unidos da América).
37
Os componentes de raciocínio são:
 A Base de dados de um agente PRS contem os factos (expressos em lógica de
primeira ordem) que o agente conhece a respeito do seu mundo dinâmico, ou
também a respeito do seu próprio estado interno de crenças;
 Conjunto de objectivos (substituem os desejos na teoria BDI) do agente que são
descritos como condições sobre um intervalo de tempo, e não na forma de estados
estáticos a serem atingidos. Existem objectivos em relação ao comportamento
interno do próprio agente, que são designados de objectivos metanível;
 Biblioteca de planos ou área de conhecimento (KA-Knowledge Área), usada para
executar / atingir objectivos (desejos) ou reagir a determinadas situações;
 Estrutura de intenção, contem todos os planos para execução imediata ou futura
(pilhas de área de conhecimento) seleccionados e ordenados por tempo de
execução. Normalmente, cada intenção é formada por um plano em conjunto com
outros sub-planos. As intenções podem estar em três estados distintos: activas
(quando estão aptas para ser executada assim que a sua posição na estrutura o
permita); suspensas (quando foram seleccionadas para execução, mas nenhuma
decisão foi tomada sobre quando devem ser executadas); suspensas
condicionalmente (quando aguardam por uma condição de activação que seja
satisfeita). Existe uma relação de precedência entre as intenções assegurada pelo
tempo de ordenação na estrutura que evita assim conflitos no momento da
execução.
 Interpretador (ou mecanismo de inferência) controla o funcionamento do agente
baseado no conteúdo da base de dados e dos objectivos da seguinte forma: (i)
seleccionar os planos da área de conhecimento em resposta aos objectivos e
crenças do sistema sem nenhuma forma de raciocínio, possibilitando uma grande
rapidez no processo; (ii) confirmar os planos seleccionados na estrutura de
intenção e executá-los.
4.2.4 Arquitectrua COSY de Burmeister e Sundermeyer
A arquitectura COSY (COperating SYstem) foi apresentada por Burmeister e
Sundermeyer em 1992 [Haddadi e Sundermeyer, 95] e segundo [Wooldridge e Jennings,
95], “inclui elementos tanto de PRS quanto de IRMA”. A arquitectura COSY adiciona
mecanismos de comportamento social aos agentes oferecendo mecanismos de
planeamentos simples, algo que as arquitecturas anteriores não contemplam. Esta
abordagem descreve um agente através dos seus comportamentos, recursos e intenções.
Os comportamentos de um agente são classificados pela sua percepção, cognição e
38
execução, cada qual simulado por uma componente específica da arquitectura. Os
recursos incluem recursos cognitivos (conhecimento e crença), recursos de comunicação
(protocolos de baixo nível e comunicação de hardware e recursos físicos). O termo
intenção é utilizado para definir dois estados mentais:
 Intenções estratégicas, modelam um agente em termos de objectivos, preferências
e responsabilidades;
 Intenções tácticas, comprometem o agente com um conjunto de planos de acções
escolhidas.
A arquitectura do agente é composta por cinco módulos, que são: sensores, actuadores,
comunicação, motivação e cognição. A disposição de cada módulo pode ser observada na
figura 4.5.
Raciocínio e Decisão
Execução
de Scripts
Execução
de
Protocolos
Comunicação
Actuadores
Sensores
Motivações
Base de Conhecimento
COGNIÇÃO
Figura 4.5: Arquitectura COSY, segundo [Haddadi, 96]
Os três primeiros módulos são específicos no campo da actuação em que a sua
implementação fica fora do agente. As funções de cada um destes módulos são: o módulo
actuadores é responsável pelas acções físicas no ambiente; o módulo sensores por
fornecer ao agente a informação actualizada sobre o estado e eventos ocorridos no
ambiente; o de comunicação pela troca de informação através de mensagens entre os
outros agentes. O módulo de motivações (desejos) implementa a intenção estratégica de
um agente. O módulo cognição é o responsável pela avaliação da situação, pela escolha e
execução das acções e pela análise dos resultados. Este módulo está subdividido da
seguinte forma:

Base de conhecimento (BC): contem as estruturas para o processo de raciocínio,
na qual se encontram informações referentes ao ambiente e sobre os objectivos e
intenções dos agentes. Na mesma BC existe um conjunto de planos que são as
directrizes que um agente possui para resolver as soluções específicas de um
determinado problema;
39

Componente de execução de scripts (CES): é responsável pela execução dos
scripts (planos), enviando os comportamentos da execução para os módulos de
actuadores;

Componente Execução de protocolos (CEP): é responsável por assegurar os
protocolos de comunicação para enviar as mensagens entre os agentes;

Componente de raciocínio e decisão (CRD): é o módulo responsável pelo
raciocínio sobre o ambiente e pela “melhor” escolha dos objectivos a atingir ou a
executar as intenções tendo em conta a situação actual. Os processos do CRD
envolvem três níveis que ocorrem sequencialmente: nível estratégico (os
objectivos seleccionados ou existentes são analisados em função de uma situação),
táctico (as intenções são analisadas ou novas formadas a partir da escolha de
planos para realizar os objectivos) e execução (onde as acções são escalonadas e
preparadas para execução).
4.2.5 Arquitectura genérica de Wooldridge
A arquitectura genérica de um agente BDI é, na abordagem de Wooldridge, constituída
por sete componentes principais: conjunto de crenças, função de revisão de crenças,
função de geração de opções, conjunto de opções, função de filtragem, conjunto de
intenções e função de selecção de acção (ver figura 4.6) [Wooldridge, 99].
Função geração
opções possiveis
Crenças
Desejos
Função Revisão
de Crenças
Função Filtro
Intenções
Interpretação da
Percepção
Função de
Selecção Acção
Execução da
Acção
Comunicação
AMBIENTE
Acção
Percepção
Figura 4.6: Arquitectura BDI genérica, segundo [Wooldridge, 99]
Resumidamente, esta arquitectura de agente está estruturada da seguinte forma:
40

As crenças: representam a informação que o agente possui sobre o estado do
ambiente e dos vários agentes inseridos no ambiente (inclusive sobre si mesmo).

Os desejos: representam os possíveis cursos de acção que o agente quer atingir.
Em tese, os desejos podem ser contraditórios, ou seja, pode-se desejar coisas que
são mutuamente exclusivas do ponto de vista prático. Normalmente referem-se a
objectivos como um subconjunto dos desejos que são todos compatíveis entre si.

As intenções: representam as sequências de acções que um agente se compromete
a obter para atingir um determinado objectivo.

A função de revisão de crenças (FRC): recebe a informação através das
percepções (percebe alterações no ambiente) e, consultando as crenças anteriores
do agente, actualiza as próprias crenças para que elas reflictam o novo estado do
ambiente. Com esta nova representação do estado do ambiente, é possível que
existam novas opções disponíveis (opções de estados a serem atingidos).

A função de geração de opções: função que analisa quais as novas acções
(desejos) a serem realizadas (consultando quais as intenções com que o agente já
está comprometido), uma deliberação deve ocorrer para a escolha de algumas
destas novas opções com as quais o agente se comprometerá (actualizando então
os desejos do agente). Definido o conhecimento e a motivação do agente, é
preciso em seguida decidir que curso de acções específico será usado para
alcançar os objectivos actuais do agente (para isto é preciso levar em conta os
outros cursos de acções com os quais o agente já se comprometeu, para evitar
acções incoerentes).

A função filtro: processo que representa a deliberação do agente que actualiza as
intenções deste com base nas suas crenças e desejos actuais, nas suas intenções
prévias. Esta actualização implica, por vezes, a desistência de intenções que
deixam de ser atingíveis, ou apresentam um custo elevado, e a adopção de novas
intenções que resultam das novas opções geradas.

A função de selecção de acção: determina qual a acção a realizar em cada
momento com base nas intenções actuais do agente.
41
4.3 Sistemas Multi-Agente (SMA)
Os Sistemas Multi-Agente formam uma sub-área da Inteligência Artificial Distribuída
(IAD), em que se pretende definir mecanismos para a criação de sistemas computacionais
a partir de entidades autónomas, denominadas de Agentes, que interagem através de um
ambiente comum, sobre o qual os agentes actuam, alterado o seu estado interno. Os SMA
constituem uma nova área nas ciências da computação, tendo início nos anos 80,
alcançando a notoriedade nos anos 90 [Wooldridge, 02].
Os SMA são a evolução natural do conceito de um agente isolado para um sistema
composto por múltiplos agentes num mesmo grupo de trabalho, exibindo cada agente um
comportamento autónomo mas que, em simultâneo, interage uns com os outros agentes
do sistema. Um SMA apresenta as seguintes características fundamentais:

Interacção – os agentes interagem com o ambiente e entre si num SMA;

Objectivo global – o SMA têm um objectivo global, independentemente dos
objectivos de cada agente não serem coincidentes com o objectivo global;

Topologia do SMA – a topologia permite estabelecer relações hierárquicas entre
agentes, o que é importante na descrição dos fluxos de interacção no SMA;

Relacionamentos – para os agentes poderem interagir entre si é necessário que os
interlocutores se conheçam;

Assunção de um mundo dos agentes – o SMA assume à priori um ambiente e os
tipos de agentes que o constituem. Esta assunção condiciona a flexibilidade dos
agentes, mas é necessária para restringir as variáveis no SMA.
Os requisitos para desenvolvimento de um controlo de câmara inteligente onde existe
operadores e um realizador implicam, necessariamente, o uso de capacidades distribuídas,
coordenação, cooperação e negociação. Tais capacidades podem ser realizadas com
sucesso através de uma aproximação às metodologias de agente e Sistemas Multi-Agente.
4.3.1 O conceito de Sistema Multi-Agente
Um Sistema Multi-Agente é um sistema computacional no qual dois ou mais agentes
interagem ou trabalham em conjunto num conjunto de tarefas ou satisfazem um conjunto
de objectivos a que são propostos. [Lesser, 99].
Os Sistemas Multi-Agente incluem diversos agentes que interagem ou trabalham em
conjunto, podendo compreender agentes homogéneos ou heterogéneos. Um agente no
sistema é considerado uma parte da resolução do problema, operando assincronamente
com uma certa autonomia respeitando sempre os outros agentes do sistema.
42
Interacção
Relação
organizacional
Organização
Agente
Esfera de
Influência
Ambiente
Figura 4.7: Estrutura de um Sistema Multi-Agente
A estrutura do SMA representado na figura 4.7 inclui uma infra-estrutura hierárquica
onde os agentes operam, sistema esse que permite a comunicação e/ou a interacção entre
os vários agentes. O SMA contêm vários agentes, cada qual com diferentes capacidades
de percepção e acção no mundo, tendo uma esfera de influência distinta sobre o ambiente,
sendo capaz de influenciar outras organizações ou partes do ambiente [Jennings, 99].
A investigação em Sistemas Multi-Agente derivou da Inteligência Artificial Distribuída,
constituíndo actualmente o núcleo deste campo. Inclui a investigação em diversas áreas
científicas, sendo extremamente abrangente. A investigação está focada para o
desenvolvimento de princípios computacionais, construção de modelos para descrever,
implementar e analisar as formas de interacção e coordenação de agentes em sociedades
de reduzida ou elevada dimensão [Lesser, 99].
4.3.2 Interacção e comunicação entre agentes
A comunicação entre entidades computacionais foi desde sempre considerada um dos
problemas mais importantes das ciências da computação. No entanto, na área dos
Sistemas Multi-Agente, a comunicação é tratada a um nível muito mais elevado do que
nas outras áreas das ciências da computação. A comunicação tem dois fins principais:
partilha do conhecimento, informação, crenças ou planos com outros agentes; e
coordenação de actividades entre agentes. [Reis, 03]
Como já foi dito anteriormente, o SMA tem inerente a interacção entre os agentes,
possuidores de capacidades de percepção, processamento e actuadores num dado
ambiente. A comunicação está normalmente associada a pelo menos dois interlocutores
43
(agentes) [Lesser, 99] com capacidades de comunicar e habilidade social, para que possa
interagir com os outros agentes e/ou humanos presentes no seu ambiente.
AGENTE
Módulo
Inteligente
Recepção
de
Mensagens
Percepção
Módulo de
Comunicação
Percepção da
comunicação
Envio
de
Mensagens
Acção da
comunicação
Acção
AMBIENTE
Figura 4.8: Agente com capacidades de comunicação
Na figura 4.8 é representado um agente genérico com capacidades de comunicação. Os
agentes com capacidade de comunicação incluem normalmente um módulo de
comunicação na sua arquitectura que se subdivide nas componentes de percepção
(recepção de mensagens) e de acção (envio de mensagens). O módulo de comunicação
está ligado directamente ao módulo central (módulo inteligente) para que possa ter acesso
às mensagens recebidas/envidas.
Huhns e Stephens descrevem que a comunicação entre os agentes pode assumir duas
arquitecturas básicas, que são: [Huhns e Stephens, 99]

Comunicação directa – Quando dois ou mais agentes trocam informação por
mecanismos dedicados sem intervenção de outros agentes. Os agentes tratam da
sua própria coordenação, partilham especificações, enviando aos outros agentes as
suas capacidades e/ou necessidades para que cada agente possa tomar
individualmente as suas decisões relativas à comunicação.

Comunicação assistida – Os agentes apoiam-se noutros agentes, chamados
“facilitadores”, para comunicarem entre si, organizando-se num sistema federado.
Nestes casos, se um agente i deseja enviar uma mensagem ao agente j, terá
primeiro de a enviar para o “agente facilitador”, que se encarregará de a
reencaminhar ao seu destinatário.
Na arquitectura de comunicação directa é colocado o problema da falta de coordenação da
comunicação, pois não existe um agente coordenador, o que pode originar bloqueios nos
sistemas de comunicação. Como exemplo temos o caso de existir um número razoável de
agentes que decidiram enviar mensagens ao mesmo tempo. Por sua vez, na comunicação
44
assistida, o problema da coordenação não existe derivado a presença do “agente
facilitador”, diminuindo consideravelmente a complexidade necessária aos agentes
individuais na realização da comunicação. No entanto o “agente facilitador” pode trazer
uma certa centralização no sistema e estrangulamento (bottleneck). É de realçar ainda que
se o agente deixar de funcionar toda a comunicação pára.
A comunicação entre agentes pode ser implementada de duas formas distintas,
dependendo do nível de implementação das comunicações. Assim temos:

Memória partilhada (“quadro-negro”) por todos os agentes da comunidade;

Passagem de mensagens entre agentes ou módulos destes.
A passagem de mensagens entre agentes é o modo de comunicação mais utilizado,
assegurando a privacidade e rapidez da mensagem que é transmitida sem comprometer a
eficácia do sistema. As soluções de memória partilhadas são mais difíceis de distribuir
obrigando a metodologias adicionais para sincronização dos agentes.
4.3.3 Protocolos e níveis de comunicação
Os protocolos de comunicação são definidos por vários níveis [Huhns e Stephens, 99]. Os
níveis inferiores definem o método de interligação, o formato (sintaxe) diz respeito aos
níveis intermédios. Por último, os níveis superiores dizem respeito ao sentido (semântica).
A semântica refere-se tanto ao conteúdo como ao tipo da mensagem.
Existem associados aos protocolos a aridade que pode ser binária ou de ordem n.
Enquanto um protocolo binário envolve apenas um emissor e um receptor, um protocolo
de aridade n implica a existência de um emissor e múltiplos receptores. Genericamente
podemos definir que um protocolo contém a seguinte estrutura de dados [Huhns e
Stephens, 99]:





Emissor;
Receptor ou Receptores;
Linguagem utilizada;
Funções de codificação/descodificação da linguagem;
Acções que o receptor deve executar.
4.3.4 Linguagens de comunicação
Existem várias linguagens definidas no âmbito da comunicação em Sistemas MultiAgente que permitem uma comunicação ao mais alto nível. Estas linguagens
normalmente aparecem associadas a projectos específicos. Entre as mais utilizadas,
podem-se referir as seguintes:
45

A linguagem KQML (Knowledge and Query Manipulation Language) O KQML é uma linguagem externa para troca de informação e conhecimento
entre agentes, baseada nos actos de discussão (“speech acts”). O KQML, na sua
definição, assume certas condições de base a nível do transporte e ligações entre
agentes, fornecendo uma série de construtores que permitem acomodar e
classificar na mensagem grande parte das “semânticas” existentes numa
comunicação (ask, reply, tell, subscribe, discard, etc), para além de permitir
acomodar informação acerca do próprio processo de comunicação (content,
language, ontology, sender, receiver, etc). Para um estudo mais alargado
recomenda-se [Finin et al., 93] ou [Labrou e Finin 1994].

Formato KIF (Knowledge Interchange Format) - A ideia base do KIF
[Genesereth e Fikes, 92] é ser um formato que permite descrever informação simples a
suportar a definição de modelos lógicos (lógica de primeira ordem: operadores
booleanos e lógicos (and, or, not, etc.), quantificadores universal e existencial, de
raciocínio não monótono associados a entidades em sistemas periciais, bases de
dados, agentes inteligentes, etc. No entanto, outras linguagens têm sido também usadas
como veículos das mensagens, como é o caso do Prolog [Bratko, 86] e do Lisp [Steele,
90]. O KIF é proposto como linguagem de expressão do conteúdo da mensagem
KQML.

A linguagem ACL (Agent Comunication Language) - A linguagem ACL é
semelhante no formato à linguagem KQML. Define essencialmente a estrutura
exterior da mensagem. No entanto, o número de performativas é bastante inferior
ao número de performativas KQML. A linguagem ACL define unicamente 20
performativas para definir a interpretação desejada para cada tipo de mensagem.
A importância das linguagens de comunicação é tentar definir modelos que providenciem
conceitos e sintaxes que possam ser comuns entre as várias abordagens existentes que
permitam a existência de Sistemas Multi-Agente realmente heterogéneos em que a
comunicação possa existir entre dois agentes independente da sua natureza.
4.3.5 Ontologias
Como analisado anteriormente, para que seja possível que os agentes interajam num
sistema é necessário todos os agentes falar a mesma linguagem com o mesmo significado
(ontologia), pois só assim serão capazes de entender e serem entendidos pelos outros
agentes. Uma ontologia não é mais do que: “a representação do conhecimento de um dado
domínio, disponibilizada a todos os outros componentes de um sistema de informação”
[Huhns e Singh, 97].
46
Num contexto de SMA, uma ontologia é uma representação formal de conceitos,
características e relacionamentos num dado domínio específico, permitindo o
entendimento entre os diversos agentes [Reis, 03].
Diversas áreas de investigação aplicam ontologias, nomeadamente: no desenvolvimento
de bases de dados, na componente da sua especificação, com a utilização de modelos
como o Relacional ou Entidade-Associação ou ainda o UML (Unified Modeling
Language) [Bergenti e Poggi, 00] [Odell et al., 00] [Cranefield et al., 01].
4.3.6 Metodologias de concepção de um SMA
Um aspecto fundamental para a concepção de um SMA é ter em conta o objectivo global
a atingir. Já sabemos que os vários agentes do SMA também possuem objectivos na sua
definição. A dúvida que se coloca agora é saber como conjugar um objectivo global de
um SMA com os vários objectivos dos agentes que o compõem. Na realidade essa dúvida
não existe, se os agentes fazem parte de um SMA, logo, de alguma forma, os seus
objectivos se esquadrão no esquema de obtenção do objectivo global. Assim, tanto na fase
de implementação e definição de um SMA, (descrição, escolha dos agentes, interacções e
objectivos dos agentes) o objectivo global está sempre implícito.
Na concepção de um SMA podemos considerar duas abordagens distintas: a deliberativa
e a comportamental, as quais são descritas da seguinte forma:
A abordagem deliberativa, ao assumir um objectivo ao nível do SMA, tenta modelar e
condicionar vários aspectos do próprio sistema SMA (morfologia e topologia) e dos
agentes (modelos) que reflectem os objectivos do SMA. Tenta-se “garantir” o sucesso
desta abordagem através de:

Esquemas de interacção entre agentes, para “controlar” as interacções a nível local
do SMA;

Objectivos dos agentes em particular, reflectindo papéis mais ou menos precisos
no âmbito do SMA: os próprios agentes terem uma noção de que estão integrados
num SMA, com outros agentes, e que de alguma forma existe um objectivo global
comum atingir.
A abordagem comportamental cai num outro extremo. A concepção deste modelo é
obtida através do ”comportamento” das interacções entre os agentes para que se possa
alcançar o objectivo global do sistema. Esta abordagem baseia-se bastante na Etologia,
ciência que estuda os comportamentos [Brooks, 91] [Drogoul e Ferber, 92] [Mataric, 94].
Assim, a concepção de um SMA é considerada como um processo interativo que implica
a experimentação de configurações e a avaliação e estudo do comportamento global
emergente do SMA. O processo de experimentação pode implicar o estudo de
47
combinações que podem envolver parâmetros desde os modelos dos agentes, número de
agentes no SMA, tipos de agentes e sua distribuição no SMA, etc.
Estas duas abordagens tentam atingir o seu objectivo global com duas estratégias
completamente diferentes. Enquanto a abordagem deliberativa tem uma lógica “top to
bottom”, tentado definir os objectivos globais do SMA até às funções dos seus agentes, a
abordagem comportamental tem uma abordagem inversa, “bottom up”, que a partir das
combinações dos agentes do SMA tenta alcançar o objectivo global.
4.3.7 Avaliação de um sistema multi-Agente
Para avaliarmos um SMA é necessário um processo de avaliação para que se tenha como
alvo o objectivo global a cumprir por parte dos agentes que o compõem. A avaliação é
fundamental na definição de um SMA, pois as avaliações incluem um grau de satisfação
inerente e custos associados respeitante aos objectivos a atingir. A avaliação é necessária
quando se aborda um SMA no ponto de vista comportamental.
4.4 Conclusões
No domínio do controlo de câmaras inteligentes não existe modelos utilizando Sistemas
Multi-Agente. Este trabalho torna-se pioneiro pela utilização de um paradigma original
para resolver o problema. Uma parte do problema passa pela optimização e cálculo
matemático, mas a outra parte passa pela coordenação dos vários intervenientes
(realizador, operadores de câmaras, actores). A integração do conceito de Agentes e SMA
no MAICC traz a este um nível extremamente poderoso. Os agentes introduzem:

Controlo descentralizado;

Diversas arquitecturas de organização interna;

Facilidade de implementação de comportamentos inteligentes;

Flexibilidade através da pró-actividade e autonomia;
Para além de ser uma noção naturalmente distribuída, o conceito de SMA permite
introduzir e modelar as interacções num sistema distribuído de uma forma mais
harmoniosa e conceptual introduzindo as seguintes características ao modelo:

Distribuição do conhecimento;

Melhoramento do desempenho em relação a sistemas centralizados nas vertentes
de eficiência computacional, fiabilidade, escalabilidade, facilidade de manutenção,
flexibilidade ou reutilização;

Relações de cooperação, competição, etc.

Uniformização do processo de comunicação, incluindo a própria linguagem de
comunicação entre agentes;

Coordenação do sistema.
48
CAPÍTULO 5: FUTEBOL ROBÓTICO
5 FUTEBOL ROBÓTICO
O Futebol Robótico (RoboCup) é um campeonato do mundo de futebol para robôs que se
realiza todos os anos e que tem como objectivo promover a investigação e integração das
áreas da Inteligência Artificial e Robótica nas suas tarefas comuns, nomeadamente na
evolução de algumas teorias, algoritmos, aprendizagem e arquitecturas de Sistemas MultiAgente [Kitano et al., 95] [Kitano et al., 97] [Asada et al., 00].
O primeiro RoboCup-97 decorreu em 1997, organizado em conjunto com o IJCAI-9719
em Nagoya, Japão, participando trinta e nove equipas [Noda e Frank, 00]. O RoboCup-98
aconteceu em Paris em Julho de 1998 sendo os jogos vistos por 15,000 pessoas, sendo a
cobertura da competição assegurada por 120 representantes da comunicação social
internacional, nomeadamente estações de televisão20 e revistas científicas [Asada et al.,
00]. O RoboCup-99 realizou-se em Estocolmo, Suécia, tendo um crescimento notável,
com a participação de noventa equipas [Noda e Frank, 00]. As edições seguintes do
RoboCup disputaram-se, Melbourne 2000 e Seattle 2001. As últimas edições do RoboCup
transformaram-se em grandes eventos científicos com centenas de participantes e
milhares de espectadores. No RoboCup 2002 em Fukuoka participaram 288 equipas, com
mais de 1000 investigadores envolvidos e assistiram ao certame um total de mais de 110
mil espectadores. O RoboCup 2003 foi realizado em Itália apresentando o mesmo sucesso
que os anteriores.
O campeonato do Futebol Robótico é dividido em várias categorias, sendo que destas
todas, excepto uma, envolvem o uso de robots reais. A excepção consiste na liga de
simulação que utiliza numa plataforma cliente – servidor onde os jogadores são
programas (agentes de software) que se conectam a um servidor central, o soccerserver
[Cheny et al., 02], onde toda a partida é simulada. É na categoria simulada que se baseia
esta tese.
5.1 Descrição geral do futebol robótico simulado
O Futebol Robótico simulado é um jogo de futebol, específico e muito atractivo, pois é
jogado num ambiente distribuído e em tempo real, sendo suportado por uma arquitectura
multi-agente, uma das áreas da inteligência artificial. Incluindo assim um conjunto de
problemas científicos, que passa pelo processamento em tempo real, robustez de
comunicação com ruído, cooperação de agentes numa arquitectura multi-agente e
processamento incompleto de informação. A simulação é assegurada por uma arquitectura
cliente – servidor em que o servidor central é designado de soccerserver no qual se
modela uma campo de futebol virtual composto por duas equipas de agentes. Cada equipa
19
The Internacional Joint Conference on Artificial Intelligence.
20
A cobertura televisiva foi efectuada, nomeadamente pela CNN, ABC, NHK e TV-Aich.
49
é constituída por onze jogadores (e um treinador) [Noda e Frank, 00], tendo como
objectivo marcar o maior número de golos para ganhar o jogo à equipa adversária.
Os jogadores do Futebol Robótico21 são programas que representam os jogadores, que se
conectam ao servidor soccerserver. As percepções e acções dos jogadores são mapeadas
em mensagens enviadas e recebidas através do protocolo de comunicação, num ambiente
de rede. Esta arquitectura permite assim que os vários clientes possam ser desenvolvidos
em qualquer linguagem de programação, desde que suporte este tipo de comunicação
[Noda e Stone, 00].
5.2 Servidor soccerserver
A primeira versão preliminar do servidor foi desenvolvida em 1993 por Itsuki Noda para
demonstrar as capacidades de uma linguagem de programação chamada MWP, um tipo
Prolog com multi-tarefa, sendo a sua visualização efectuada num terminal VT100.
A primeira versão a apresentar a actual arquitectura cliente - servidor foi a versão zero,
escrita em 1994, em Lisp. Essa versão utilizava TCP/IP para comunicação com os
clientes, e a sua saída de visualização era exibida em um terminal X11, mas ainda com
uma representação utilizando caracteres [Corten et al., 99].
A versão 1 surgiu na reescrita da versão em Lisp para C++ em 1995. A versão 2 foi
iniciada em 1996, para a realização da pré-RoboCup-96, que se realizou em Osaka, Japão.
Essa versão foi a primeira a dividir a funcionalidade do servidor (soccerserver) e do
visualizador (soccer monitor). Além disso, o visualizador exibia os jogos utilizando agora
não mais caracteres mas sim gráficos, e um jogo poderia ser assistido de vários terminais
X11 conectando-se assim vários visualizadores a um mesmo servidor.
A versão 3 do servidor, que seria utilizado na primeira RoboCup-97 oficial [Cheny et al.,
02], apresentava recursos adicionais, como:

Logplayer, módulo para gerar ficheiro das partidas para futura análise;

Informações sobre a movimentação dos objectos, no campo de visão do agente;

Capacidade de comunicação entre os agentes, ouvir/enviar mensagens.
A versão 4 surgiu após a RoboCup-97 e foi usada no Japão, com os seguintes novos
recursos:
21

Modelo de cansaço dos jogadores mais realístico;

Implementação de jogadores do tipo guarda-redes;

Implementação de foras de jogo;
Os termos “cliente” e “agente” do Futebol Robótico serão utilizados indiferentemente, uma vez que os
programas clientes jogadores do simulador são tipicamente agentes autónomos.
50

Informação visual do cliente tendo em conta a sua direcção;

Introdução da componente física do jogador.
Nas versões seguintes foram poucas as alterações efectuadas. A versão 5 foi usada em
Estocolmo 1999, Suécia, a versão 6 em Melbourne 2000, Austrália. As versões 7.0 e 8.0
foram implementadas em 2001, sendo a última versão a 9.1.4.
5.2.1 Descrição funcional do servidor
O soccerserver é um servidor que controla um jogo de futebol num campo virtual de
acordo com um conjunto de regras do jogo, simulando os movimentos da bola e dos
jogadores, e é responsável pela comunicação entre os diferentes agentes do jogo, numa
arquitectura de cliente - servidor (figura 5.1) [Kitano et al., 95].
Soccer Server
Socket
Cliente
Gestor de
mensagens
Socket
Cliente
Visualizador
Arbitro
X Window
Simulador de campo
Socket
Cliente
UDP/IP
Figura 5.1: Arquitectura cliente - servidor do soccerserver
Cada cliente controla apenas um jogador que está conectado ao servidor pela rede, usando
para isso uma conexão via socket UDP/IP. Todas as acções do agente são tomadas no
cliente, sendo a informação enviada por comandos para o servidor. Por sua vez o agente
recebe do servidor informação visual, auditiva e física através dos seus sensores de
informação [Noda e Stone, 00].
O servidor é constituído por três grandes módulos que permite assim a comunicação
perfeita com os clientes [Noda et al., 97]. Os módulos são:

Simulador de campo: módulo que permite calcular o movimento dos vários
agentes e analisar as colisões entre os vários intervenientes no campo;

Gestor de mensagens: módulo que controla a comunicação de mensagens entre o
servidor e os clientes;

Árbitro: módulo que assegura que as regras do jogo são cumpridas.
51
5.2.2 Domínios do simulador
5.2.2.1 O campo de jogo e os agentes
O campo de jogo e os agentes são representados no servidor por um sistema de
coordenadas a duas dimensões. As medidas do campo de futebol virtual são definidas de
acordo com as medidas oficiais estabelecidas pela FIFA22 (105m por 68m) e a única
excepção é a largura das balizas, que é o dobro, porque a duas dimensões, é mais difícil
marcar golos. Os agentes que se movem no campo são os jogadores e a bola. Estes
agentes são representados por um círculo, e têm um raio de 0.3m e 0.085m
respectivamente (figura 5.2) [Cheny et al., 02].
Jogador 0.6 m
6
Bola
0.17 m
Figura 5.2: Representação do jogador e bola no soccerserver
Os agentes jogadores e bola apresentam os seguintes parâmetros no servidor:
Tabela 1: Parâmetros dos agentes no soccerserver
Parâmetro
Tamanho
Posição
Velocidade
Aceleração
Direcção
Decadência
Ruído
Descrição
Dimensão do raio do objecto. As dimensões por defeito do jogador
e da bola são 0.3 e 0.085 respectivamente.
Coordenadas X, Y em 2-Dimensões do centro do objecto.
Velocidade de deslocação do objecto em 2-Dimensões
Aceleração do objecto.
Direcção de deslocação do objecto
Parâmetro da decadência da velocidade. Se parâmetro for um
então o objecto continua a mover-se, se zero então o objecto pára
imediatamente.
Taxa de incerteza do movimento de um objecto. Se valor zero
então o objecto move-se de acordo com a velocidade. Se positivo
então o ruído é adicionado ao movimento. A magnitude do ruído é
proporcional ao valor do parâmetro como ao da velocidade do obj.
O campo de jogo também é constituído por objectos estáticos que são visíveis e não se
movem. Os objectos são balizas, linhas de jogo e bandeiras. Os clientes do servidor não
sabem as posições absolutas dos jogadores mas sim as posições relativas dos objectos
22
Federation Internationale de Football Association com site em http://www.fifa.com
52
estáticos [Noda et al., 96]. Estes objectos estáticos são principalmente utilizados para os
agentes poderem calcular as suas posições relativas [Akiyama, 01].
5.2.2.2 Movimento e colisão de agentes
O soccerserver pode também ser visto como um servidor físico no qual permite simular o
movimento dos agentes (bola e jogadores) e as eventuais colisões entre eles. Esta
simulação de movimento e colisão pretende ser simplificada de forma a ser fácil calcular
as alterações em tempo real [Kitano et al., 95].
Em cada passo da simulação o movimento dos objectos é calculado da seguinte forma
[Cheny et al., 02]:
(uxt+1, uyt+1)
= (vxt, vyt) + (axt, ayt) - aceleração
(pxt+1, pyt+1)
= (pxt, pyt ) + (uxt+1, uyt+1) - movimento
(vxt+1, vyt+1)
= decad * (uxt+1, uyt+1) - velocidade decadência
(axt+1, ayt+1)
= (0,0) - iniciar aceleração
Onde, (pxt, pyt) é a posição e (vxt, vyt) a velocidade do objecto no espaço de tempo t.
decad é o parâmetro de decadência para a bola ou jogador. A aceleração (axt, ayt) do
objecto é derivada do parâmetro força (power):
(axt, ayt)
=
power * power_rate * (cos (ө t), sin (ө t))
Se um agente sobrepõe outro, então dá-se uma colisão entre os objectos. Após o
movimento o agente é forçado a ser movido para trás, até que não sobreponha nenhum
outro agente [Noda, 00].
5.2.2.3 Protocolo de comunicação
Como já foi dito, a conexão dos agentes ao servidor é efectuada via socket UPD/IP,
quando o cliente se conecta ao servidor abrindo um conexão este associa o agente ao
campo de jogo, podendo assim o cliente controlar o seu jogador [Kitano et al., 95].
Por sua vez a conexão via socket permite com que o cliente possa ser desenvolvido em
qualquer tipo de arquitectura ou ambiente de programação [Noda e Stone, 00].
Toda a comunicação entre o cliente e o servidor é efectuada através de cadeias de
caracteres em ASCII. O protocolo de comunicação consiste no envio de mensagens do
cliente com os comandos das acções do agentes e no envio de mensagens pelo servidor
com a informação referente aos sensores dos agentes. As acções básicas de uma agente
são mover, voltar, chutar, dizer, acelerar [Noda et al., 96]. Os sensores de informação são
as mensagens enviadas pelo servidor para os agentes de forma a informar o estado do
campo a partir do ponto de vista do agente. Existem três tipos de informação sensorial a
receber pelo agente através dos seus sensores: a informação visual, auditiva e a física.
53
5.2.3 Acções dos agentes no servidor
O agente está limitado a um conjunto de acções que são enviadas por mensagem para o
servidor para este as executar [Noda, 00] [Cheny et al., 02]. As acções possíveis são:
23

Acção mover (“Move (posx, posy)”): Coloca o agente numa posição desejada no
campo. Esta acção só é valida para iniciar a sua posição do agente e não funciona
quando o jogo está a decorrer.

Acção apanhar (“Catch (direcção) ”): O agente guarda-redes é o único que pode
apanhar a bola quando o jogo está a decorrer e se encontra na grande área.

Acção andar (“Dash (potência)”): Incrementa a velocidade de aceleração do
agente mantendo a sua direcção actual.

Acção chutar (“Kick (potência,direcção)”): Acção para o agente chutar a bola. O
chuto depende da força aplicada e da direcção do chuto.

Acção dizer (“Say (mensagem)”): Envia uma mensagem instantaneamente para
todos os agentes. A mensagem consiste numa cadeia de caracteres.

Acção voltar (“Turn (ângulo)”): Muda a direcção do agente no mundo.

Acção voltar cabeça (“TurnNeck (ângulo)”): Permite virar o pescoço do agente
independente da direcção do seu corpo, para o agente com o ângulo da cabeça
visualizar o ambiente.

Acção Tackle (“Tackle(potência)”): Acção introduzida em 200223, que tem como
principal objectivo aumentar o realismo providenciando uma forma realista de
desarmar jogadores adversários que se encontram na posse de bola.

Acção mudar de visão (“Change_View(abertura,qualidade)”): A configuração da
percepção visual de um agente pode ser alterada. A acção toma dois argumentos:
abertura do cone de visão (narrow, normal ou wide) e a qualidade da informação
visual (high ou low).

Acção dar atenção (“AttentionTo(equipa,núm)”): Permite seleccionar quais os
agentes que são prioritários a ouvir em cada instante. A introdução desta acção em
2002 traz novos desafios no controle da percepção dos agentes da liga de
simulação.

Acção apontar (“PointTo(distância,direcção)”): Capacidade de comunicar
visualmente com os restantes jogadores apontando para pontos específicos do
campo de jogo.
O comando tackle encontra-se disponível a partir do servidor 8.x
54
5.2.4 Percepções dos agentes
Os agentes do Futebol Robótico recebem a informação através de três tipos distintos de
sensores: auditivo, visual e físico. Esta secção descreve de uma forma sucinta as
características da informação recebida pelos diferentes sensores [Corten et al., 99] [Noda,
00] [Cheny et al., 02].
5.2.4.1 Informação auditiva
A informação auditiva é enviada através dos outros agentes (todos os jogadores de) ou do
treinador. As mensagens do árbitro também são recebidas pelo sensor auditivo. As
mensagens do árbitro são recebidas instantaneamente sem qualquer tipo de atraso. As
mensagens são transmitidas no seguinte formato:

Tempo: é o tempo de ciclo do servidor;

Direcção: é a direcção relativa à qual o som (mensagem) é proveniente24;

Mensagem: conteúdo da mensagem (limitado a 10 Bytes).
Os agentes têm uma capacidade limitada de ouvir as mensagens, pois só conseguem ouvir
uma única mensagem durante dois ciclos do servidor e ouvir as mensagens dos agentes
que estão num determinado raio de acção. Estas limitações não são válidas para as
mensagens do árbitro.
5.2.4.2 Informação visual
A informação visual enviada pelo servidor descreve o que o agente está a visualizar
naquele instante a duas dimensões. Esta informação é enviada ciclicamente do servidor
para o agente de uma forma automática. A informação recebida pelo agente num formato
básico é a seguinte:
24

Nome do objecto: descrição do objecto a ser visualizado, que pode ser um jogador
(indicando o número e a equipa), a bola e informação do campo do jogo.

Distância: distância do objecto ao agente.

Direcção: direcção do objecto em relação ao agente.

Direcção do corpo: no caso de o objecto ser um jogador, será passada a
informação referente à direcção do seu corpo.

Direcção da cabeça: no caso de o objecto ser um jogador, será passada a
informação referente à direcção da cabeça.
Actualmente o emissor é identificado.
55
5.2.4.3 Informação física
O sensor físico recolhe a actual informação física do jogador. Esta informação é
ciclicamente enviada pelo servidor ao jogador de uma forma automática. As mensagens
são transmitidas num formato específico do servidor o qual inclui a seguinte informação:

Valores para a energia, esforço e capacidade de recuperação do agente;

Velocidade do agente;

Valores para a qualidade de visão e formato de visão do agente;

Acções efectuadas correctamente pelo agente.
5.2.5 Estados de um jogo no servidor
Um jogo de futebol no servidor tem sempre associado um estado em que se encontra o
jogo. Este mesmo estado é actualizado permanentemente pelo árbitro, pois o ambiente
está em permanente mudança. Todos os estados de jogo possíveis para a última versão do
servidor estão devidamente documentados no anexo B.
5.2.6 Regras do jogo
O árbitro (módulo do servidor) controla o jogo de futebol através de um conjunto de
decisões baseadas nas regras gerais do futebol. As regras a serem respeitadas são as
seguintes: primeiro, quando a posição de bola estiver na linha de golo (dentro da baliza),
o árbitro anunciará uma mensagem de golo para todos os clientes que estão conectados ao
servidor, actualizando o resultado, move a bola para o centro do campo e muda o estado
do jogo para “kickoff”. Segundo, se a bola sair dos limites do campo, o árbitro parará o
jogo e anuncia a decisão tomada (lançamento, canto, pontapé de baliza), e coloca a bola
na posição correcta. Terceiro, quando o tempo de alguma parte do jogo chega ao fim, o
árbitro pára o jogo e os respectivos jogadores, ficando à espera de uma mensagem de
“kick” para começar uma parte ou iniciar o jogo [Noda et al., 97].
Por defeito cada parte do jogo tem 3000 ciclos do servidor (cada qual com 100
milissegundos, correspondendo a 5 minutos).
56
5.3 Descrição do Soccer Monitor
Figura 5.3: Visualização no soccer monitor
5.3.1 Descrição geral
O soccer monitor é uma ferramenta de visualização sendo constituída por uma interface
simples que permite visualizar a duas dimensões de uma forma virtual o jogo que está a
ser processado pelo soccerserver. A informação que nos é apresentada inclui o resultado
do jogo, o nome das equipas e a posição de todos os jogadores e também da bola ( figura
5.3). É possível que vários programas soccer monitor se possam conectar ao servidor,
podendo assim vários utilizadores visualizarem o mesmo jogo em simultâneo.
5.3.2 Comunicação
Para que o monitor possa visualizar e sincronizar o servidor é necessário existirem dois
sentidos de comunicação: informação proveniente do servidor e comandos para o
servidor. Normalmente o soccermonitor e o soccerserver são conectados via UDP/IP na
porta 6000.
5.3.2.1 Informação proveniente do servidor
Quando o soccer monitor é conectado ao servidor soccerserver, este último envia
ciclicamente informação (100 milissegundos) para o visualizador, para que este reproduza
o mais realisticamente possível o jogo que o servidor está a processar. No anexo D
podemos analisar as diferentes estruturas de dados enviadas do servidor soccerserver para
os visualizadores.
57
5.3.2.2 Comandos para o servidor
Para que o jogo possa ser controlado o visualizador pode enviar, através de mensagens,
alguns comandos para o servidor [Corten et al., 99] [Cheny et al., 02]. Os comandos
possíveis são:

(dispinit) | (dispinit version 2): Esta é a primeira mensagem a enviar para o
servidor pelo monitor para se registar. A ligação ao servidor é efectuada na porta
6000.

(dispstart): Mensagem enviada ao servidor para começar o jogo, dar início à
segunda parte ou iniciar os tempos extras de jogo. Quando o jogo está a decorrer a
mensagem é ignorada pelo servidor.

(dispfoult x y lado): Mensagem utilizada para indicar uma falta no jogo. As
coordenadas da falta são x e y, respeitante a equipa do lado esquerdo (1) ou lado
direito (-1), o lado neutro é assumido pelo valor 0.

(dispdiscard lado núm): Esta mensagem serve para tirar um jogador do jogo,
mostrando-lhe o cartão vermelho. O jogador pode ser da equipa do lado esquerdo
(1) ou direito (-1) sendo designado pelo seu número núm [1-11].

(dispplayer lado núm posx posy âng): Mensagem enviada para posicionar um
jogador nas coordenadas (posx, posy) com uma determinada direcção do corpo
(âng). O lado da equipa no campo pode ser do esquerdo (1) ou direito (-1). O
(num) é o número do jogador (1-11). O novo ângulo (âng) de direcção do corpo é
referenciado em graus.
5.3.3 O Vídeo – LogPlayer
O LogPlayer é uma aplicação que permite a visualização de jogos pré-gravados à
semelhança do que acontece com um gravador de vídeo. Para gravar os jogos em disco o
servidor disponibiliza um conjunto de ferramentas com esse intuito. Depois de efectuada
a gravação para o disco do ficheiro gerado (ficheiro de log – anexo C) por parte do
servidor, pode-se analisar e reproduzir o jogo gravado através da utilização de um
visualizador, pois este normalmente disponibiliza um conjunto de ferramentas para
visualização e análise do jogo. Para visualizar os ficheiros gerados os visualizadores estão
equipados com botões de avanço, recuo rápido e paragem, dispondo também da
possibilidade de avançar directamente para um dado ciclo do jogo. À semelhança do que
se passa com um gravador de vídeo.
58
5.4 Arquitecturas de visualização do Futebol Robótico
Como já foi dito anteriormente, o soccer monitor é uma ferramenta de visualização sendo
constituída por uma interface simples que permite visualizar em 2-Dimensões de uma
forma virtual o jogo que está a ser processado pelo soccerserver. Vários monitores podem
ser conectados ao mesmo servidor no decurso de um jogo. Esta possibilidade permite
visualizar em diversos terminais o mesmo jogo ao mesmo tempo, utilizando para tal,
diferentes ferramentas de visualização com potencialidades distintas (por exemplo um
monitor 3D e um sistema de análise de jogo).
Vários grupos de investigação têm criado monitores com capacidade de visualização
gráfica dos jogos através da conexão ao servidor. Actualmente têm-se trabalhado nos
monitores tridimensionais que permitem a visualização a 3-Dimensões e a análise de
jogos e cálculo estatístico do jogo. Após esta breve descrição serão apresentados os mais
importantes e agrupados a duas e três dimensões.
5.5 Arquitecturas de visualização 2D
5.5.1 Monitor Tradicional – Soccer Monitor
O monitor tradicional do soccerserver (ver figura 5.4) implementado em Linux25 permite
configurar as cores e dimensões com que são visualizados todos os objectos (jogadores e
bola). Permite ainda configurar os tipos de mensagens visualizadas, os respectivos textos
e as dimensões das fontes. Desde a criação da liga de simulação até 2001, o monitor
utilizado em jogos oficiais foi o Soccer Monitor tradicional. Actualmente é o FrameView
[Merke, 03].
Figura 5.4: Visualizador tradicional para Linux do Soccer Server
25 Linux – Sistema operativo originalmente desenvolvido por Linus Torvalds o qual é baseado no Unix mas
para estações tipo PC - Personal Computer.
59
A arquitectura modular do simulador permite a separação entre o módulo de simulação e
o módulo de visualização. Isto permite não só a utilização de diferentes monitores
associados ao mesmo simulador, mas ainda a construção de monitores em sistemas
operativos distintos.
5.5.2 Soccer Monitor - Klaus Dorer ( Univ. de Freiburg, Alemanha )
Um dos primeiros monitores a ser implementado em sistema operativo Windows foi o de
Klaus Dorer, na Universidade de Freiburg [Dorer, 00]. O monitor apresenta as mesmas
características do monitor tradicional em Linux (ver figura 5.5).
Figura 5.5: Visualizador Soccer Monitor de Klaus Dorer
Este mesmo simulador de visualização foi continuado por diferentes Universidades entre
quais se destacam a Universidade de Tsinghua [Cai et al., 02], China e o grupo de
investigação WrightEagle, da Universidade Science and Technology [WrightEagle, 03],
também da China.
5.5.3 FrameView - Arthur Merke ( Univ. de Karlsruhe, Alemanha )
O monitor oficial do futebol simulado é actualmente, desde Outubro de 2001, o
FrameView [Merke, 03], desenvolvido pela Universidade de Karlsruhe na Alemanha (ver
figura 5.6). Para além das funções do monitor tradicional, permite ainda analisar diversas
características do jogo, úteis para a sua análise. Entre estas incluem-se a visualização de:
ampliações de regiões do campo, energia dos jogadores, visão dos jogadores e
características dos jogadores heterogéneos26 presentes no campo.
26
Os jogadores heterogéneos foram introduzidos na liga de simulação em 2001. Consistem em jogadores
com capacidades físicas distintas dos jogadores tradicionais. Por exemplo, um jogador pode ter uma maior
velocidade máxima mas cansar-se mais rapidamente ou então ter uma maior potência de chuto mas uma
menor precisão.
60
(vista normal do visualizador)
(Zoom na grande área)
Figura 5.6: Visualizador FrameView de Arthur Merke
5.5.4 SoccerScope – YowAI (Univ. Electro-Communications, Japão)
O SoccerScope [Miyazawa e al., 02] [Ako e al., 03] é mais uma ferramenta de
visualização e monitorização que é suportada por um agente aplicacional, sendo capaz de
analisar logs do servidor e, em simultâneo, visualizar o jogo através de uma reprodução
fiel (ver figura 5.7). Quando um agente do servidor faz uma acção estranha ou inesperada
o agente de suporte investiga o detalhe da acção e o estado interno do agente. Os agentes
de suporte podem assim compreender as causas da estranha acção do agente. Estas causas
podem ser erros de concepção nos agentes, existência de ruído na comunicação por parte
do servidor, problemas na rede, etc.
Figura 5.7: Visualizador SoccerScope, Japão
SoccerScope visualiza a informação relacionada com as acções do agente e as várias
condições de jogo. Além disso, o SoccerScope contém um treinador off-line. Com a ajuda
do treinador, pode-se conectar ao servidor em modo de treinador e pode mudar a posição
de agentes e da bola, podendo-se também mudar o modo de jogo. O visualizador é assim
composto pelas seguintes quatro funções:
1. Visualizar a informação proveniente do servidor de futebol;
61
2. Visualizar a informação proveniente dos agentes do servidor através do protocolo
de comunicação;
3. Capacidade de análise e visualização das diferentes condições do jogo;
4. O agente de suporte pode mudar as situações do jogo sempre que deseje.
5.5.5 SoccerDoctor - WrightEagle (Univ. Ciência e Tecnologia, China)
O monitor Soccer Doctor desenvolvido pelo laboratório Multi-Agent Systems Lab da
Universidade da Ciência e Tecnologia da China (ver figura 5.8), é composto por um
visualizador em 2D que permite realizar uma visualização fiel do ficheiro de log
carregado, ou do que se passa no servidor [WrightEagle, 03].
O monitor é composto por uma barra de ferramentas que é distinta da janela de
visualização do jogo a duas dimensões. Na barra de ferramentas encontramos um
conjunto diverso de opções para controlo da visualização que permite mostrar o seguinte:
destacar o jogador activo, número dos jogadores, ângulo de visão do jogador activo,
trajectória da bola, linhas de fora de jogo.
Figura 5.8: Visualizador Soccer Doctor dos WrightEagle, China.
As estatísticas do jogo são efectuadas na globalidade da equipa ou individualmente a cada
jogador. A representação estatística é efectuada através de gráficos ou tabelas. Os itens
que compõem as estatísticas são chutos a baliza, cantos, livres, lançamentos, passes
correctos, passas interceptados, dribles e a percentagem do controlo da bola.
Para análise do jogo o monitor disponibiliza uma ferramenta de visualização que permite
desenhar no campo as diferentes posições de linhas de passe, drible, chuto, intercepção de
bola e zona de acção dos jogadores.
62
5.5.6 TeamDesigner - FC Portugal (Univ. do Porto/Aveiro)
O TeamDesigner [Reis, 03] [Reis e Lau, 03] [Teixeira e Santos, 03] é um analisador de
jogo que calcula diversas estatísticas do jogo que podem depois ser utilizadas pelo
treinador. O TeamDesigner é desenvolvido numa plataforma gráfica que integra, na
mesma aplicação, a possibilidade de configurar estratégias de equipa (incluindo tácticas,
formações e tipos de jogadores), visualizar jogos online ou offline e ainda permite testar
jogadores com um treinador offline (FCPTrainer) para definir a melhor táctica a utilizar
(ver figura 5.9). Entre as várias estatísticas destacam-se a localização da bola por região
do campo, número de remates às balizas e número de oportunidades de golo de cada
equipa.
(visualizador FCPMonitor)
(treinador FCPTrainer)
Figura 5.9: Visualizador TeamDesigner, das Univ. Porto/Aveiro
Como já foi dito, foram criados dois visualizadores de jogo: o FCPMonitor para funcionar
em tempo real (online), ligando-se ao servidor soccerserver e o FCPLogMonitor para
funcionar em diferido (offline) através dos logs criados pelo servidor. Os visualizadores
incluem ambos uma barra de tarefas que permite aos utilizadores ligarem-se aos
servidores ou abrir um ficheiro de log. O visualizador offline permite ainda configurar a
velocidade e sentido do jogo, determinar distâncias entre pontos, verificar as propriedades
de um determinado jogador ou da bola, efectuar zoom sobre um região do campo e
verificar o ângulo de visão de um dado jogador.
5.5.7 RoboBase - John Sear (Univ. de Manchester, Inglaterra)
O RoboBase de John Sear combina um repositório central de ficheiros log do RoboCup,
com uma arquitectura aberta de visualização [Sear, 03]. O sistema é implementado em
Java permitindo assim, com alguma facilidade, a extensão do visualizador (compressão
de dados, estatísticas, visualização) por parte dos utilizadores e a execução do
visualizador em qualquer sistema (ver figura 5.10).
63
Figura 5.10: Visualizador RoboBase de John Sear, Univ. Manchester.
Uma base de dados central dos ficheiros log utilizando métodos específicos de
compressão permite assim uma conexão remota e mais rápida aos jogos da liga simulada.
O monitor permite o acesso total ou parcial (sem a necessidade de carregar
completamente o ficheiro) das competições usando dois modos diferentes de
visualização: um com imagem gráficas e outro sem. O sistema disponibiliza um conjunto
de estatísticas de futebol em tempo real ou estatísticas globais que podem ser visualizadas
mesmo antes do jogo ser realizado. O repositório permite também a comparação de
estatísticas de diferentes partidas.
5.5.8 Team Assistant – SBC (Univ. Shahid Beheshti, Irão )
O Team Assistant (TA) é uma ferramenta de monitorização multi-função. O seu
desenvolvimento deu ênfase às necessidades gerais da visualização, desenvolvimento e
análise de uma equipa da liga simulada [Nazemi et al., 03]. O monitor inclui um
logplayer, um debugger gráfico e um analisador de jogo (ver figura 5.11). O logplayer
melhorado permite o utilizador ver os diferentes atributos de um jogador, a visão e os
movimentos de um jogador graficamente representados.
Figura 5.11: Visualizador Team Assistant, Univ. Shahid Beheshti, Irão.
O Debugger Gráfico permite representar graficamente as manifestações de cada jogador.
Uma gramática genérica é proposta estudando as exigências de uma equipa. Esta
gramática é constituída por declarações que definem o ambiente (jogador/bola
64
posição/velocidade), o comportamento dos jogadores (posse, remates, etc.) e também
comentários. Por último o analisador, através da informação recolhida do servidor,
permite definir os seguintes eventos: posse de bola, passe, perca de bola, dribles e
remates. O analisador, sempre que reconhece um destes eventos, representa-o
graficamente no campo.
5.6 Arquitecturas de visualização 3D
O desenvolvimento de visualizadores 3D para as diversas competições do futebol
robótico tem sido um desafio de investigação estimulado ao longo dos últimos anos. O
domínio preferencial da aplicação dos visualizadores tem sido a liga de simulação. No
entanto, nos últimos anos, após o aparecimento do RoboCup Rescue27, visualizadores 3D
para este domínio de simulação têm também sido desenvolvidos. De seguida serão
analisados os visualizadores tridimensionais que se enquadram mais no tema desta tese.
5.6.1 Virtual RoboCup – Universidade de Bielefeld, Alemanha
O visualizador Virtual RoboCup foi realizado por Bernhard Jung, Markus Oesker, Heiko
Hecht [Jung et al., 99], da faculdade de Bielefeld, Alemanha. Foi dos primeiros
visualizadores tridimensionais a ser implementado para o futebol robótico simulado,
funcionando em estações gráficas SGI e sobre o sistema operativo Irix6 (ver figura 5.12).
Figura 5.12: Visualizador Virtual RoboCup da Univ. Bielefed, Alemanha.
O principal desafio científico e técnico para os autores foi criar uma animação
tridimensional a partir dos dados bidimensionais do servidor soccerserver, para que as
animações dos jogadores apresentem uma movimentação realística quando correm ou
chutam a bola. A ideia básica da animação é criar vários estados intermédios de animação
para as acções do jogador. Para isso utilizaram a técnica de animação keyframe.
27 RoboCup Rescue – Campeonato de salvamento que tem como objectivo estimular a aplicação da
investigação realizada no futebol robótico, a domínios socialmente mais úteis, no caso, missões de
salvamento e resgate em grandes catástrofes.
65
5.6.2 Magic Box - Wright Eagle (Univ. Ciência e Tecnologia), China
O visualizador MagicBox [Xing et al., 02] [Li et al., 03] foi desenvolvido em OpenGL, e
funcionam em Windows e Linux (ver figura 5.13). O sistema apresenta uma animação
baseada nas acções dos jogadores. Ao comportamento da bola foi dada a noção de altura
de forma a dar um maior realismo. O visualizador apresenta também a análise estatística
do jogo e características do mesmo baseado nas diferentes distribuições estatísticas.
Foi implementado pelos autores um sistema automático para controlo da câmara com o
objectivo de visualizar a melhor cena do jogo. O posicionamento da câmara apresenta
vários tipos de posicionamento que são: no centro do campo, de lado do campo, de cima,
por cima do jogador, nas grandes áreas e câmara que sobrevoa o campo.
(vista câmara de lado)
(vista câmara aérea)
Figura 5.13: Visualizador MagicBox dos Wright Eagle, China.
O visualizador apresenta um comentador “inteligente” que faz automaticamente o relato
do jogo e os efeitos sonoros quando algumas acções acontecem durante o decorrer do
jogo, podendo-se assim ouvir e ver o que está a acontecer no servidor em simultâneo.
5.6.3 Robolog - Oliver Obst ( Universidade of Koblenz), Alemanha
A equipa do Robolog participa na liga de simulação do futebol robótico desde 1999. O
seu visualizador 3D funciona em ambiente Windows e usa como biblioteca gráfica o
OpenGL (ver figura 5.14). Para gerar a cena foi implementada uma ferramenta de
simulação tridimensional genérica, Tool.In, de forma a representar simulações a três
dimensões que usam tipicamente uma arquitectura gráfica de cena, modelando os
aspectos de objectos no mundo virtual e as suas interacções com o ambiente directamente
[Obst e Ringelstein, 02].
66
Figura 5.14: Visualizador RoboLog de Oliver Obst, Alemanha.
O controlo da câmara pode ser efectuado automaticamente ou interactivamente pelo
utilizador. No controlo interactivo o utilizador pode movimentar a câmara via teclado de
forma a visualizar as áreas de interesse do jogo que mais lhe interessem. Adicionalmente,
o controlo automático tem como foco principal a simulação da visualização real de uma
partida de futebol, apesar de utilizar apenas uma única câmara para visualização [Kogler e
Ringelstein, 03].
5.6.4 The Venue (The Cave) – Univ. Vrije de Amesterdão, Holanda
O sistema de monitorização CAVE tem como objectivo a construção de um ambiente no
qual os utilizadores podem interagir numa simulação do RoboCup da forma mais natural
possível (ver figura 5.15). O Virtual RoboCup não usa apenas ambientes imersivos como
o CAVE28, mas integra também outros dispositivos de visualização. O sistema permite
visualizar o RoboCup em três modos diferentes: monitor, Workbench29 e modo CAVE
[Spoelder et al., 00] [Spoelder et al., 99b] [Spoelder et al., 99a].
O modo de monitor permite uma visualização tridimensional aproximada de uma
cobertura televisiva dos jogos de futebol. A visualização pode ser realizada em diferentes
locais de uma forma passiva (sem interacção no jogo). O modo utiliza várias câmaras
posicionadas no campo de jogo sendo a selecção da câmara de visualização através de um
algoritmo. A câmara seleccionada limita-se depois a seguir apenas a bola.
O modo Workbench permite dar uma cobertura ampla do jogo simulado através de uma
perspectiva 3D com apenas uma única câmara fixa. A característica principal deste modo
é dar uma visualização de todo o cenário (campo, jogadores) miniaturizada para permitir
ao humano uma avaliação total sem ser necessário mudar de perspectivas para
28
CAVE (CAmeras in Virtual Environment) ou caverna (do português) - permite em projectar imagens no
“interior de um cubo” dando a noção ao utilizador estar imerso num ambiente virtual .
29
Workbench – Método de visualização tipo bancada que usa um projector para gerar uma imagem 3D
numa tela de projecção ligeiramente inclinada. Os utilizadores vêem a cena 3D como se saí-se de uma
mesa.
67
acompanhar o jogo, permitindo assim que os treinadores possam gerir o jogo com mais
clareza.
Figura 5.15: Visualizador “The Venue”
O modo CAVE permite que o utilizador possa ser imergido (câmara associada a um
jogador) no jogo e interagir com ele. Este modo utiliza a mesma informação e
comunicação que o original monitor 2D de visualização, mas agora visualiza o estado do
jogo em CAVE num cenário completamente virtual. A animação dos jogadores é baseada
num utilitário do OpenGL em que os seus movimentos são realizados através de um
conjunto de pontos básicos que são interpolados através de splines30 de forma a suavizar a
animação. Os movimentos possíveis dos jogadores são: parado, andar e correr, que são
ajustados interpolando linearmente entre os três modos.
O modo CAVE apresenta uma característica interessante, pois pode-se interagir com o
servidor soccerserver através de comportamentos humanos. Para isso são integrados três
periféricos de realidade virtual, através de um software específico. O periférico óculos
permite monitorizar as mudanças posicionais dentro do sistema. O segundo periférico
conectado é um joystick ou rato que é usado para movimentos globais sobre o campo de
futebol. O último periférico é um dispositivo colocado no pé do jogador humano e é
usado para reconhecer um pontapé. Os comandos dos periféricos são convertidos em
comandos (correr, virar, chutar) que são enviados para o servidor do futebol robótico
[Renambot et al., 00]. Apesar do sistema apresentar conceptualmente interesse, na
realidade funcional deixa muito a desejar.
5.6.5 Caspian - (IUST Computer Engineering), Irão
O sistema de apresentação Caspian [Sedaghat et al., 03] é dividido por três módulos
principais: monitor 3D, comentador e ferramenta de análise que pode funcionar a duas ou
30
Splines - É uma curva suave definida matematicamente por dois ou mais pontos de controle.
68
três dimensões (ver imagem 5.16). O objectivo do visualizador tridimensional foi
desenvolver um sistema que se assemelha à realidade na visualização de um jogo de
futebol.
Figura 5.16: Visualizador Caspian, IUST, Irão.
O visualizador utiliza um conjunto de câmaras fixas em diferentes locais do estádio para
dar a melhor visão do jogo. As câmaras podem ser controladas de duas formas:
automaticamente ou manualmente. No modo automático a melhor perspectiva é
determinada em dois passos. Primeiro, o agente director selecciona a melhor câmara
através de uma heurística que é baseada no modo de jogo e na posição da bola e jogadores
dentro do campo. No segundo passo o agente câmara decide qual o status da câmara
considerando para isso a posse de bola, posição e velocidade.
O modo manual é usado para analisar algumas situações do jogo pelo utilizador,
seleccionando a câmara desejada e ajustando os parâmetros de pan, zoom como se deseje.
5.6.6 RA3DM - Isteam (Instituto Superior Técnico), Portugal
O RoboCup Advanced 3D Monitor, RA3DM é uma aplicação tridimensional que permite
visualizar e analisar os jogos de futebol robótico da liga de Simulação. O monitor é
implementado em OpenGL (ver imagem 5.17). A aplicação tem como objectivo dar aos
utilizadores uma experiência realística de uma partida de futebol a três dimensões,
mantendo um equilibro saudável através de uma animação realística e efeitos especiais
[Penedo et al., 03].
O RA3DM usa um sistema de animação composto por três animações principais a serem
executadas pelo jogador: andar, corrida e pontapé. O processo de animação é simplificado
através de técnicas de interpolação de keyframe.
69
Figura 5.17: Visualizador RA3DM do IST, Portugal.
Existem três tipos distintos de visualização do jogo que o utilizador pode seleccionar:
estático, manual e controlo automático de câmaras. A visualização automática consiste
em colocar cuidadosamente uma série de câmaras em alguns pontos estratégicos do
campo. A decisão de qual a câmara a seleccionar e o por quanto tempo para a
visualização é efectuada pelo realizador e um agente editor, que são assim os
responsáveis pelas cenas que aparecem no ecrã.
5.6.7 Avan – Universidade de Qazvin Islamic Azad, Irão
Avan, desenvolvido pela faculdade Qazvin Islamic Azad University do irão [Rahmani,
03], é um sistema integrado composto em três partes: SoccerPlayer, Treinador e
Visualização. Na visualização o sistema é composto por dois módulos: Ferramentas de
análise / depuração e visualização tridimensional (ver imagem 5.18).
(debuger 2D)
(visualização a 3D)
Figura 5.18: Imagens do visualizador AVAN, Irão.
O sistema gráfico foi desenvolvido em OpenGL e os seus modelos gráficos foram
desenvolvido em 3D Studio Max. O visualizador, quando funciona em modo a duas
dimensões, apresenta de uma forma geral os mesmo atributos do que os visualizadores do
70
género já descritos anteriormente. O visualizador em modo 3D apresenta um sistema de
câmara composto por diferentes tipos de visão do jogo, que são: topo, esquerda, direita,
traseira, frente, centrar bola. A animação dos jogadores é efectuada de uma forma simples
e repetitiva.
5.7 Conclusões
O RoboCup veio estimular consideravelmente a investigação realizada na Inteligência
Artificial Distribuída, chamando a atenção da comunicação social e público em geral. As
ligas de competição colocam problemas de investigação distintos mas ao mesmo tempo se
relacionam umas com as outras. A liga de simulação, sendo jogada num ambiente
distribuído e em tempo real, suportada por uma arquitectura multi-agente coloca um vasto
conjunto de desafios aos investigadores da área da Inteligência Artificial e Sistemas
Multi-Agente. As características do domínio e desafios associados mais importantes
colocados pelo simulador incluem [Reis, 01]: simulação em tempo-real; diversas fontes
de Informação Sensorial e disponibilidade de sensores configuráveis; modelo energético
realista; comunicação; Percepção e acção assíncronas; ambiente multi-objectivo mas
parcialmente cooperativo e adverso; vasto conjunto de acções de baixo-nível disponíveis;
necessidade de criar acções colectivas complexas.
Ao longo do capítulo foram apresentados os diferentes visualizadores de maior
importância a duas e três dimensões para visualizar os desafios da liga simulada do
RoboCup. Nos visualizadores a duas dimensões pretendeu-se adquirir conhecimento
sobre as seguintes funcionalidades:

Capacidades de ligação ao servidor ou ler ficheiro de log para partidas em diferido
(off-line);

Arquitectura funcional dos visualizadores a duas dimensões;

Tipo de Informação estatísticas;

Ferramentas de análise do jogo (ampliações de regiões do campo, energia dos
jogadores, visão dos jogadores e características);

Funcionalidades de comunicação entre o monitor e o servidor.
Nos visualizadores a três dimensões pretendeu-se adquirir um conhecimento mais sobre
capacidades gráficas da visualização, incluindo sistemas de câmara. As características
analisadas foram:

Plataforma gráfica utilizada no desenvolvimento;

Modelos gráficos do estádio e jogadores;

Sistemas de animação utilizado nos jogadores e bola;
71

Conversão dos movimentos dos jogadores e bola de duas para três dimensões;

Tipos de câmara para visualizar os jogos;

Posicionamento das câmaras no cenário;

Disposição da informação (resultado, mensagens, estatísticas, etc);

Sistema de som utilizado e suas funcionalidades;
O modelo a desenvolver pretende integrar as funcionalidades mais relevantes dos
visualizadores a duas e três dimensões. O sistema a implementar diverge em algumas
funcionalidades destes sistemas devido ao acentuado realismo das animações, dos sons e
ainda do Sistema Multi-agente para controlo de câmara inteligente. O sistema de controlo
de câmara pretende dar ao utilizador uma visualização mais real, simulando a filmagem
de um jogo televisivo onde interagem operadores de câmara com o realizador para
executarem a filmagem televisiva.
72
CAPÍTULO 6: PROJECTO - MAICC
6 PROJECTO - MAICC
O sistema MAICC Muti Agent Inteligent Camera Control – é um Sistema Multi-Agente
que permite o controlo automático e inteligente de um conjunto de câmaras (previamente
posicionadas no cenário) e de um realizador para dar ao utilizador a melhor imagem de
visualização do cenário, como se de uma filmagem televisiva se tratasse.
O Futebol Robótico simulado através do seu servidor soccerserver é uma plataforma ideal
para estudar Sistemas Multi-Agente, tradicionalmente usada como uma ferramenta para
estudar SMA no âmbito da coordenação e comunicação no desenvolvimento de agentes
para controlar os jogadores. A aproximação desta tese é baseada na comunicação e
cooperação entre os vários agentes intervenientes de um cenário de futebol para exibir de
uma forma automática e inteligente a melhor imagem da região de interesse do jogo,
cumprindo um conjunto de regras cinematográficas que são executadas pelos operadores
de câmara e o realizador.
O sistema tem por objectivo básico o controlo automático da visualização pelos diferentes
operadores de câmara e realizador da filmagem com capacidades de comunicação entre
todos os intervenientes da filmagem (realizador, operadores, analisador, jogadores, bola,
arbitro e público). Simultaneamente pretende-se explorar as vantagens resultantes da
noção de Agente com vista à apresentação de uma alternativa fiável para a resolução do
problema. Para implementar o modelo MAICC foi implementado o Virtua3D, um
visualizador tridimensional com as capacidades desejadas para o problema. Toda a
componente de comunicação entre os agentes é realizada também numa plataforma
desenvolvida (MAS – Multi Agent System) para responder as exigências de desempenho
de uma aplicação gráfica.
6.1 O Visualizador 3D – Virtual3D
O visualizador desenvolvido no âmbito desta tese é um sistema que permite a
visualização de jogos bidimensionais de futebol robótico simulado num ambiente
tridimensional incluindo animação e som. O sistema é, em si próprio, um Sistema MultiAgente em que cada câmara é modelizada como um agente inteligente autónomo. O
sistema inclui ainda agentes para o realizador, analisador e público. Dado as percepções
(posições e velocidades dos jogadores e da bola), os agentes operadores de câmara
(camaraman) estão aptos a decidir qual a melhor perspectiva em cada momento do jogo,
enviando a informação de alto nível para o agente realizador que é o responsável pela
decisão de escolher qual é a melhor a imagem a exibir aos espectadores. O Virtual3D
utiliza as funcionalidades genéricas do SoccerDoctor [WrightEagle, 03]. As animações
dos jogadores são baseadas nas acções dos jogadores como no MagicBox [Xing et al.,
02], que utilizam o sistema keyframe para animação dos jogadores, sistema já utilizado no
pioneiro visualizador Virtual RoboCup [Jung et al., 99]. O sistema de câmara utilizado
73
segue o modelo funcional do visualizador RA3DM sendo possível o modo automático e o
manual [Penedo et al., 03]. No entanto, o visualizador desenvolvido diverge destes
sistemas devido ao acentuado realismo das animações e dos sons e ainda ao SMA para
controlo de câmara inteligente.
6.1.1 Descrição
A liga simulada do Futebol Robótico é jogada num ambiente distribuído e em tempo real,
suportada por uma arquitectura multi-agente [Kitano et al., 95] [Kitano et al., 97]. Esta
tese é também baseada no conceito de SMA utilizado no soccerserver da liga de futebol
simulado do RoboCup [Noda et al., 97]. O simulador do futebol robótico simula um
campo de jogo a duas dimensões em que é composto por duas equipas para realizarem
uma partida de futebol. O estado do jogo no servidor inclui as posições, velocidades e
direcções de todos os objectos num sistema de coordenadas bidimensional (duas
dimensões), que serão convertidas para um sistema tridimensional para que o jogo se
torne o mais realístico possível. Com os avanços recentes no desenvolvimento da
tecnologia gráfica, é agora possível desenvolver aplicações para mostrar uma visualização
tridimensional realística destas partidas de futebol simuladas.
A aproximação do sistema MAICC concentra-se no estudo de um Sistema Multi-Agente
utilizando o servidor soccerserver da liga simulada do RoboCup [Kitano et al., 95]
[Kitano et al., 97], como plataforma de testes. No entanto, a maior contribuição do
sistema é baseada no desenvolvimento de um visualizador 3D associado a um SMA para
controlo inteligente de câmaras para a visualização de jogos em tempo real ou em diferido
(off-line).
O sistema inclui como principais potencialidades:

Ambiente 3D incluindo um estádio e animações realistas;

Controle de câmara inteligente através de um Sistema Multi-Agente;

Repetições em câmara lenta dos melhores momentos do jogo;

Geração de sons 3D baseado em agentes emocionais que representam os
espectadores de cada equipa, através de um motor de som 3D posicional;

Capacidade de conexão em tempo-real com o soccerserver e de leitura de logfiles
(versão 2 e 3), incluindo as versões gerada para o sistema operativo NT;

Visualização de estatísticas de jogo fornecidas por um agente analisador de jogo;

Modelos 3D (Studio Max) para os jogadores com animação real;

Suporte DirectX7+ para o sistema operativo Windows 2000 e XP;

Paradigma de programação, linguagem orientada por objectos, C++.
74
6.1.2 Ambiente virtual
O ambiente virtual é o responsável de dar a noção de imersão ao espectador de como de
um cenário real se tratasse, como se pode ver na figura 6.1.
Figura 6.1: Imagens do visualizador 3D
O sistema virtual tridimensional é composto por: um cenário tridimensional que inclui um
estádio, uma estrutura multi-agente para controlo inteligente das câmaras, sistema de
repetição, geração de som 3D baseado no estado emocional dos espectadores, modelos
3D (Studio Max) dos jogadores com animações reais, suporte de DirectX [Root e Boer,
99] e sistema de som posicional 3D.
6.1.3 Arquitectura do sistema
Como já foi salientado, o sistema foi desenvolvido numa arquitectura Multi-Agente. Para
implementar esta arquitectura foi desenvolvida uma ferramenta designada de MAS
(Multi-Agent System), utilizando o paradigma de object oriented.
Monitor
Colunas
RoboCup
Logs
10 frames/sec
Pipeline Gráfico
30 frames/sec
Motor de Som 3D
Log 3D
2D
via Sc
str ene
ea
m
Comunicação
e
en
Sc P
D
D
2
U
via
RoboCup Soccer Server
10 frames/sec
Agente
Realizador
Agentes
Operadores
Agente
Analisador
Agentes
Cenário
System Architecture - Toolkit MAS
Figura 6.2: Arquitectura do sistema do visualizador
Movimento
de
Animações
3D
75
A arquitectura é suportada por cinco componentes, que são: renderização gráfica 3D
utilizando a biblioteca gráfica RenderWare [Criterion, 95], motor de som 3D para
público, árbitro e jogadores, comunicação, animação 3D e agentes. Esta arquitectura é
apresentada na figura 6.2.
6.1.3.1 Componente gráfica 3D
É a componente gráfica que permite criar ambientes virtuais 3D cada vez mais realistas.
Para responder à necessidade da visualização utilizou-se uma biblioteca gráfica
RenderWare [Criterion, 95], que permite criar cenários em tempo real com alguma
qualidade e com um desempenho muito bom, acima das 30 imagens por segundo. A
componente gráfica tem a responsabilidade de gerar o output 3D do cenário a partir dos
vários estados dos agentes envolvidos e objectos estáticos do mundo virtual.
6.1.3.2 Componente de agentes
A componente de agentes tem os modelos de três tipos de agentes: reactivos,
deliberativos e emocionais. Nos agentes deliberativos temos os operadores de câmara
(cameraman), que utilizam uma arquitectura BDI. O cameraman tem como função tentar
focar o jogo na melhor perspectiva de visualização, através de primitivas de focalização
da câmara. Cada cameraman calcula as várias medidas de qualidade da visualização,
sendo enviada a medida da qualidade para o agente reactivo realizador, que é o
responsável por escolher qual a melhor câmara para visualizar o cenário num determinado
momento do jogo. É o agente realizador que envia as coordenadas de posicionamento das
câmaras como as regiões do campo de maior prioridade para a filmagem no decorrer do
jogo.
Os agentes do cenário são compostos por jogadores, público, árbitro e bola. Os jogadores
são modelados como agentes emocionais, pois são emocionalmente afectados pelo seu
comportamento no campo (durante o jogo). Eles também são agentes reactivos simples
porque são guiados pelas coordenadas bidimensionais enviadas pelo servidor
soccerserver que são convertidas em coordenadas tridimensionais. O público também é
modelado como agente emocional. Isto permite implementar a satisfação emocional por
equipa, sendo a satisfação expressa através do som. A bola é um agente reactivo simples
que converte o seu sistema de coordenadas bidimensionais para tridimensionais. O árbitro
é também um agente reactivo simples pois limita-se analisar as percepções do ambiente,
nomeadamente o estado do jogo, para depois seleccionar as faltas existentes. O sistema
utiliza um agente analisador de jogo que é responsável por calcular as estatísticas de jogo,
que serão visualizadas no ecrã sempre que o realizador entenda. As mesmas estatísticas
são utilizadas para ajudar a seleccionar a região de interesse pelo realizador da filmagem.
76
6.1.3.3 Motor de som tridimensional
A geração de sons do jogo depende dos agentes jogadores, público e árbitro. O sistema
emocional dos vários agentes permite assim criar um ambiente sonoro o mais realista
possível tendo em conta o desenvolvimento do próprio jogo. O motor de som posicional
tridimensional é suportado pela tecnologia DirectX [Root e Boer, 99].
6.1.3.4 Componente de comunicação
Actualmente o tempo de ciclo do servidor do futebol simulado, soccerserver, é de 100
milissegundos [Cheny et al., 02]. Para melhorar o tempo de comunicação entre os agentes
existe a necessidade de criar uma componente de comunicação, independente do servidor
soccerserver, que permita aos agentes trocarem mensagens entre si e que não dependam
do tempo de amostragem dos movimentos referentes ao servidor. A componente serve
assim para a troca de mensagens entre os vários agentes, como também para as diferentes
mensagens da aplicação.
6.1.3.5 Movimento das animações 3D
O sistema de animação 3D é criado tendo por base a posição, velocidades, direcção,
energia e orientação do pescoço de todos os jogadores que estão a correr no mundo virtual
a duas dimensões do servidor soccerserver em tempo real ou diferido. O sistema de
animação dos jogadores utiliza a aproximação keyframe que já foi explicada
anteriormente [Marselas, 00]. Várias animações foram previamente criadas para cada
situação do jogador: parado, andar, correr, chutar com pé esquerdo, etc. É de salientar que
também foram criados os estados intermédios entre os diferentes movimentos para que a
animação não apresente “saltos” nas transições de movimentos. A sequência de animação
a executar depende da acção do jogador e da sua envolvente e percepção do jogo (ver
figura 6.3).
Figura 6.3: Animação do jogador utilizando KeyFrame no Virtual3D
Várias animações foram previamente criadas para cada situação do jogador: parado,
andar, correr, chutar com pé esquerdo, de parado para andar, de parado para correr, de
77
parado para andar, correr, andar, chutar com os dois pés, defender, celebrar, aquecimento,
relaxar, mexer perna, mexer pescoço e mexer braço.
6.1.4 Posicionamento e descrição das câmaras utilizadas
O posicionamento das câmaras é fundamental para um bom visionamento de uma partida
de futebol. No âmbito desta tese não é importante criar um modelo para posicionar as
câmaras automaticamente no cenário, como tal, recorre-se a exemplos reais de
posicionamento de câmaras.
O
I
L
M
H
G
E
N
D
A
B
C
F
J
Figura 6.4: Posicionamento das câmaras no Estádio José de Alvalade
A SportTV31 assegurou em 2002 a transmissão televisiva do jogo Sporting – Benfica
[Record, 02]. Foram utilizadas quinze câmaras de quatro tipos diferentes, o
posicionamento foi efectuado da seguinte forma (ver figura 6.4):

Câmaras de jogo: A, B, D, F, G, I, J, L, N, O

Câmaras junto ao relvado: C, E;

Câmara em grua por trás da baliza: M;

Beauty-shot32: H;
O modelo gráfico do estádio de futebol utilizado no visualizador Virtual3D apresenta as
mesmas características estruturais do antigo estádio José de Alvalade, facilitando assim o
posicionamento das câmaras no cenário virtual.
No Virtual3D utiliza-se dois tipos de câmaras, as reais e as virtuais. As câmaras reais são
colocadas no cenário seguindo a disposição das câmaras do modelo de posicionamento
apresentado pela SportTV, sendo utilizadas sete câmaras de jogo [1 a 7] em que a sua
disposição assemalha-se as câmaras A, B, F, G, J, L (ver figura 6.5).
31
32
SportTV – Televisão privada de desporto em Portugal.
Beauty-shot – Câmara utilizada para apresentar imagens de beleza impar, normalmente uma
perspectiva panorâmica do estádio.
78
Figura 6.5: Imagens das câmaras reais no Virtual3D
As câmaras virtuais utilizadas neste cenário são do tipo fly (flutuante) em que as câmaras
não têm qualquer limite de movimentação de um ponto para outro no cenário. As câmaras
fly implementadas no visualizador apresentam as seguintes características:

Câmara 8 – Câmara que se desloca num carril virtual na cobertura superior do
estádio acompanhando sempre a posição da bola.

Câmara 9 – Câmara estática no centro do campo estando a altura da cobertura do
estádio, acompanhando também a posição da bola.

Câmara 10 – Câmara de topo que se encontra sempre nas coordenadas 2D da bola
sendo a sua elevação ao nível da cobertura do estádio.
Figura 6.6: Imagens das câmaras virtuais no Virtual3D
As câmaras virtuais não são seleccionadas automaticamente pelo agente realizador, mas
apenas pelo utilizador (ver figura 6.6). Para uma descrição mais completa sobre
implementação de câmaras virtuais consultar os variados textos, dos quais se destacam
[Foley et al., 00] [Harrison, 03] [Paull, 00]
6.1.5 Menu principal do visualizador Virtual3D
Para facilitar a interface entre o utilizador e o visualizador criou-se um menu principal
que está sempre disponível no ecrã. No menu principal o utilizador pode aceder a um
conjunto de funcionalidades, tais como: ler ficheiros de jogos (logs), ligar/desligar a
comunicação ao servidor soccerserver, visualizar estatísticas, configurar câmaras,
activar/desactivar efeitos, etc. O menu principal é composto por um conjunto de opções
79
que por sua vez estão subdivididas em outras opções. As opções principais do menu geral
são:

File: Opção geral que inclui sub-opções para carregar ficheiros de log e
estabelecer ligação de comunicação entre o visualizador e o servidor soccerserver
para visualizar um jogo em directo (tempo real).

Edit: É constituída por um conjunto de opções standard das aplicações Windows
para manuseamento de dados (copiar, colar, etc.);

LogPlayer: A utilização principal do LogPlayer situa-se ao nível da análise da
estratégia das várias equipas e dos seus pontos fracos e fortes. À semelhança do
que se passa com um gravador de vídeo, a opção LogPlayer é constituída por um
conjunto de opções para avanço, recuo rápido e paragem do jogo, dispondo
também da possibilidade de avançar directamente para um dado ciclo do jogo.
Disponibiliza também uma opção para ler ficheiros do formato log como na opção
principal File.

View: Esta opção é constituída por um conjunto de opções que permite
activar/desactivar funcionalidades relacionadas com a visualização, tais como:
resultado e mensagens do jogo, estatísticas, mensagens de debug33 e
funcionalidades de rendering do visualizador;

Cameras: A configuração das câmaras e o seu funcionamento são efectuadas
nesta opção. As funcionalidades possíveis referentes a esta opção são: definir
detalhe do zoom das câmaras (fraco, médio, alto); definir distância do zoom
(perto, longe); seleccionar algoritmo do auto zoom (melhor valor, melhor média);
iniciar a posição das câmaras ou valores de cálculo, modo de funcionamento da
câmara (auto zoom, lookat); seleccionar se as câmaras funcionam com
sincronização das imagens e se o realizador define regiões prioritárias a focar.

Effects: Engloba um conjunto de opções que estão associadas aos efeitos visuais
da simulação do jogo, podendo-se seleccionar o tipo de relva, animação de
jogadores, céu, público, etc.

Sound: Inclui opções relacionadas com o som do visualizador;

Help: Informação sobre o visualizador.
Para uma análise mais detalhada do funcionamento do visualizador Virtual3D pode-se
consultar o anexo O.
33
Debug – componente de um programa que ajuda o programador a encontrar erros de programação no
código.
80
6.2 Controlo de câmara inteligente
O controlo de câmara é o sistema responsável pela visualização do jogo de futebol. É
nesta secção que se define o modelo de focagem e enquadramento para visualização dos
diferentes objectos do cenário (jogador, bola). O controlo da câmara é efectuado por um
conjunto de comandos como se de uma câmara real se tratasse. Para os comandos
funcionarem é necessário definir um conjunto de métodos de apoio aos comandos e um
conjunto de restrições aplicar na visualização do cenário, sendo também necessário
definir um conjunto de intenções de filmagem que são expressas pelo realizador aos
diferentes operadores.
6.2.1 Descrição do modelo utilizado
O controlo da câmara baseia-se no modelo matemático de Blinn em que as câmaras estão
automaticamente a focar o ponto de interesse (bola) no centro do ecrã [Blinn, 88]. Para
posicionar e orientar as câmaras através dos comandos (set, roll, pan, tilt e zoom) de
forma a focar o ponto de interesse da cena no mundo virtual é utilizado um conjunto de
métodos de câmara procedimentais sugeridos por Ducker [Ducker et al., 92]. O sistema
desenvolvido utiliza um conjunto de restrições sugeridas por William Bares que permite
especificar as restrições aplicadas aos objectos e a projecção em tempo real [Bares e
Lester, 99]. O modelo de percepção e intenções da filmagem segue o modelo de Amerson
e Kime [Amerson e Kime, 01] em que o realizador tenta que sejam cumpridas as
intenções da filmagem, que serão enviadas para os operadores de câmara via mensagem
utilizando a linguagem CAMERA LANGUAGE34. O realizador é o responsável pelas
configurações das câmaras no cenário e pela coordenação da filmagem. Os seus
procedimentos do realizador na filmagem resumem-se a:
1. Seleccionar o shot a executar e seleccionar as restrições aplicáveis no cenário;
2. Configurar as câmaras para o shot a filmar;
3. Definir as regiões importantes na visualização;
4. Especificar o ponto de focagem atribuído factores de prioridade na visualização
dos actores (jogadores e bola);
5. Enviar as intenções (regiões e restrições) de filmagem para os operadores de
câmara;
6. Seleccionar a melhor câmara para a colocar no “ar”.
Por sua vez o operador de câmara com a informação proveniente do realizador e outros
operadores tenta focar o ponto de interesse de forma a dar a melhor perspectiva dos
34
CAMERA LANGUAGE – Linguagem cinematográfica desenvolvida no âmbito deste trabalho com o
objectivo de facilitar a comunicação entre os vários interveniente numa filmagem (Actores, Operadores e
Realizadores).
81
actores. A focagem do operador consiste em seguir o ponto de interesse e enquadrar os
actores no ecrã sem “cortes” respeitando as distâncias de focagem das outras câmaras e as
intenções do realizador. Os procedimentos do operador para realizar a filmagem são:
1. Verificar as restrições impostas pelo realizador e outros operadores, referente ao
plano desejado;
2. Analisar os actores que fazem parte do volume de visualização;
3. Calcular a qualidade de visualização dos diferentes actores;
4. Fazer várias aproximações da câmara na tentativa de melhorar a qualidade de
filmagem;
5. Enviar a informação da filmagem para os outros operadores de câmara;
6. Enviar a qualidade da imagem filmada para o realizador;
Para medir o grau da qualidade da imagem projectada por cada câmara foi criada uma
fórmula que tem por base o princípio da medição do grau de satisfação das restrições
sugerida no trabalho de William. Esta fórmula permite integrar a prioridade do objecto a
ser visualizado (Pi), o factor (Di) que quantifica a distância do objecto ao ponto de
focagem (normalmente a bola) e a qualidade de visualização (Qv) do objecto no ecrã. As
métricas utilizadas têm por base a janela de visualização do volume de visualização. A
qualidade da imagem para valores mais altos implica uma melhor qualidade de
visualização da imagem.
N
Qualidade da imagem = ∑ Pi*Di*Qv
i=1
N: número de objectos do cenário a analisar;
Pi: prioridade de visualização do objecto [0.0 até 1.0] na visualização. Os objectos com
maior relevância têm prioridade mais alta para que sejam contemplados na cena a
visualizar (valor atribuído pelo realizador);
Di: distância do objecto ao ponto de focagem. Este parâmetro permite dar importância aos
objectos que se encontrem na proximidade do ponto de focagem. Quando o objecto está
perto do centro de focagem então Di toma o valor mais alto. Para calcular este parâmetro
recorre-se ao volume de visualização, utilizando a seguinte fórmula:
Di = (DiTotal - DiFocus/DiTotal)
DiTotal é a distância total na diagonal do volume de visualização e DiFocus traduz a
distância do objecto ao centro do ecrã dentro do volume. As variáveis dPlanoDir,
82
dPlanoEsq, dPlanoTop, dPlanoBot traduzem as distâncias do objecto ao plano respectivo
(direito, esquerdo, topo ou base).
DiTotal = sqrt( DiTotH 2+DiTotV 2 );
DiFocus = sqrt( (dPlanoDir- dPlanoEsq)2 + (dPlanoTopo- dPlanoBase)2 )
DiTotH(distância total do volume de visão na horizontal) = (dPlanoDir + dPlanoEsq)
DiTotV(distância total do volume de visão na vertical) = (dPlanoTopo + dPlanoBase)
Qv: qualidade de visualização do objecto (dimensão do objecto no ecrã). O objecto pode
estar descentrado, mas o que interessa neste caso é se o objecto está a ser visualizado com
qualidade. A fórmula é o resultado do produto das seguintes variáveis: QWi (qualidade da
imagem na horizontal [0..1]); QHi( qualidade da imagem na vertical [0..1] ) e KQ(factor
de amplificação do valor da qualidade de imagem para ajustar modelo).
Qv = QWi*QHi*KQ
QWi = (DiTotW- dPlanoEsq - dPlanoDir) / DiTotH
QHi = (DiTotH - dPlanoTop - dPlanoBase) / DiTotW;
6.2.2 Transformação da visualização
A operação fundamental de uma câmara virtual é transformar os objectos de uma
perspectiva de visão do mundo gráfico num novo espaço de visualização associado ao
periférico de visualização, que neste caso é o ecrã. A transformação implica então o
mapeamento de um sistema de coordenadas tridimensionais para um sistema de
coordenadas a duas dimensões para que seja mais fácil trabalhar os objectos. Esta secção
apresenta assim as técnicas matemáticas básicas utilizadas nas transformações das
câmaras para converter os pontos do espaço para um sistema de coordenadas que possa
ser visualizado no ecrã a duas dimensões. O volume de visualização (View Frustum)
representado na figura 6.7 demonstra graficamente os conceitos necessários para a
realização da transformação para a janela de visualização [Lengyel, 02]. Como já foi dito
anteriormente, o volume de visualização delimita o espaço em que um objecto é
visualizado dentro do volume, representando assim o espaço de coordenadas em que os
objectos foram transformados, relacionando as técnicas de projecção com o plano de
visualização. Para definir o volume de visualização é necessário primeiro posicionar a
câmara no mundo tridimensional no ponto P (x, y, z) com uma direcção de visualização
At e um vector Up que controla o ângulo do tilt ou rotação roll da câmara.
83
janela de visualização
Plano esquerdo
B
D
Plano topo
H
2h
F
Up
ângulos de abertura
FOVs
At
V
2v
P(x,y,z)
Plano anterior
Plano base
Plano direito
Plano posterior
Figura 6.7: Volume de visualização
A área rectangular, no plano de visualização, aonde irá ser projectada a cena, é designada
de Janela de Visualização e no modelo de câmara virtual simples está centrada
simetricamente relativamente ao ponto P (x, y, z). Introduz-se deste modo as dimensões
2v (altura) e 2h (largura) da Janela de Visualização.
A execução de um algoritmo de recorte passa, em primeiro lugar, pela definição do
volume de visualização que contém a parte da cena que está visível na direcção da
câmara, ou seja, tudo aquilo que a câmara “vê”. O volume é constituído por seis planos
(anterior, posterior, base, topo, esquerdo e direito). Os planos de topo (base e topo) e
laterais (esquerdo e direito) do volume de visualização explicam o significado geométrico
e analítico do conceito de Field of View (FOV), ou campo de visão. Desta forma pode-se
especificar a altura e largura da Janela de Visualização através da abertura do ângulo
horizontal (ӨH) ou vertical (ӨV).
Existem consequências negativas na utilização de volumes de visualização infinitos. Os
objectos muito afastados, depois de transformados, podem reduzir-se a um pequeno ponto
no ecrã, o que corresponde a um desperdício de tempo de computação. Por outro lado,
projecções de objectos demasiado próximos, podem gerar resultados caóticos. A solução
passa por definir então os planos de recorte paralelos ao plano de projecção, através da
distância do ponto da posição da câmara ao longo da direcção At. Especifica-se, assim,
um plano de recorte anterior através de uma distância F (near plane) e um plano de
recorte posterior através de uma distância B (far plane), sendo D a distância à Janela de
Visualização [Foley et al., 00] [Madeiras, 03].
Os passos necessários para criar um volume de visualização tendo em conta os conceitos
explicados anteriormente são os seguintes [Lengyel, 02]:
1. Criar a matriz de visualização (ViewMatrix);
84
Para criar a matriz primeiro é necessário calcular o vector Z (vView), que aponta
para a frente. O resultado é a diferença entre o ponto alvo a focar (LookAtPoint) e
o ponto de visão da câmara, designado por P:
vView = LookAtPoint – P
De seguida é necessário calcular o vector Y (vUp) da projecção que é calculado
pela projecção em Z sobre o vector Up, normalmente (0,1,0).
vUp = Up - vView.Dot35( Up ) * vView
Por fim, para construir a matriz é necessário calcular o vector X (vRight), que é o
produto (Cross36) entre o vector Y pelo Z da projecção. Após o cálculo dos
vectores X, Y, Z e da respectiva normalização, a matriz da visualização é
preenchida da seguinte forma:
vRight.x vUp.x vView.x 0
vRight.y vUp.y vView.y 0
vRight.z vUp.z vView.z
0
P.Dot P.Dot P.Dot
(vRight) (vUp) (vView)
1
2. Criar a matriz de projecção (ProjMatrix);
A matriz de projecção pretende expressar as dimensões da janela de visualização
através dos ângulos do campo de visão e as distâncias de recorte. É de salientar
que o ângulo de focagem de uma câmara é expresso por 1/tan(Ө*0,5). O
preenchimento da matriz de projecção é o seguinte:
w
0
0
0
0
h
0
0
0
0
-Q
-Q*F
0
0
-1
0
w = 1/tan(ӨH*0.5) h = 1/tan(ӨV*0.5) Q = B/(B - F)
3. Calcular o produto da matriz de visualização pela matriz de projecção, resultando
a matriz ViewProj;
ViewProj = ViewMatrix * ProjMatrix
35
36
A operação Dot consiste no produto escalar entre dois vectores (P e Q): P.Q = Px*Qx+Py*Qy+Pz*Qz.
A operação Cross em dois vectores (P e Q) é conhecida pelo produto de vectores, sendo o resultando um
vector prependicular aos dois anteriores: PxQ = (Py*Qz-Pz*Qy, Pz*Qx-Px*Qz, Px*Qz-Py*Qx).
85
4. Por fim calcula-se o volume de visualização utilizando como argumento a matriz
ViewProj. No anexo L será explicado o algoritmo para criar um volume de
visualização utilizando como referência o trabalho de Eric Lengyel [Lengyel, 00].
O volume de visualização têm uma grande importância no controlo de câmara inteligente,
pois é através dele que se consegue saber se um objecto está dentro da janela de
visualização da câmara. Esta informação tem como função optimizar o cálculo ignorando
os objectos não visíveis no ecrã. Para testar os objectos que estão dentro do volume existe
um conjunto de métodos disponíveis:

PointInFrustum – Verificar se um ponto está dentro do volume.

CubeInFrustum – Verificar se um cubo está dentro do volume.

SphereInFrustum – Verificar se uma esfera está dentro do volume.
A partir do volume de visualização é possível saber a que distância está um determinado
ponto aos planos laterais e de topo do volume. Esta informação tem uma importância
relevante, pois é a base para saber se um objecto está centrado na janela de visualização
ou se ocupa uma determinada área do ecrã, informação útil para se poder enquadrar e
avaliar um conjunto de actores (jogadores e bola) no ecrã.
Para uma análise mais detalhada de como se procede a verificação se um ponto está
dentro do volume ou saber a distância de um ponto aos planos pode-se consultar o anexo
M.
6.2.3 Modelo de Blinn
Blinn no seu artigo “Where am I? What am I Looking At?” discute métodos alternados de
derivar a matriz de transformação da visão [Blinn, 88]. Este trabalho apresenta alguma
importância nesta tese devido ao facto de serem formuladas matematicamente as
transformações matriciais de quatro modos diferentes de especificar a visualização de
objectos no espaço. Os quatro modos possíveis de especificar para visualizar os objectos
são:
1. Especificar um ponto e direcção de visualização. Esta é a transformação genérica
de lookat de uma câmara sobre um objecto.
2. Especificar as coordenadas do ecrã sobre o qual um objecto de primeiro plano
deve ser projectado e especificar a direcção de visualização. Procurar nas
coordenadas do mundo a posição que satisfaz a situação de verdadeira.
3. Especificar a posição de visualização e a posição onde se deve encontrar o objecto
de segundo plano a ser projectado no ecrã. Achar a direcção de visualização que
satisfaça a condição.
86
4. Especificar a posição nas coordenadas de ecrã do objecto de primeiro plano e um
objecto de segundo plano. Calcular a posição e direcção de visualização de ambos
os objectos que satisfaça a situação.
No contexto desta tese é importante as câmaras visualizam o ponto de interesse
(normalmente a bola) no centro do ecrã para que os espectadores não percam o ponto de
interesse a ser visualizado, evitando o “desnorte” de procurar a referência de visualização.
Este método faz com que nas mudanças de câmara o ponto de interesse esteja sempre
posicionado no centro do ecrã. Para se posicionar o ponto de interesse no centro do ecrã
utilizou-se o primeiro modo sugerido por Blinn no seu trabalho (ver anexo E).
6.2.4 Representação dos objectos
Os objectos do cenário para uma maior facilidade de tratamento da sua informação
volumétrica na cena são tratados como “caixas”. Na figura 6.8 pode-se ver uma caixa
amarela a envolver o jogador e bola.
Figura 6.8: Caixa de colisão (BoundingBox) do jogador e bola
Este método que permite representar os objectos através de uma caixa é designado por
BoundingBox. O sistema boundingbox permite assim representar um objecto de uma
forma simplista abstraindo-se dos detalhes do mesmo. Esta abstracção permite facilitar o
cálculo e acelerar o processamento das colisões do objecto com o cenário, permitindo
assim facilitar o enquadramento do objecto na janela de visualização. A simplicidade do
método deve-se ao facto de a caixa de colisão ser apenas composta por 4 pontos
tridimensionais (x, y, z) de controlo, que se encontram nas extremidades da mesma. Este
sistema é bastante utilizando na computação gráfica nomeadamente no controlo de
colisões entre objectos. Para mais detalhe sobre BoundingBox pode-se consultar as
seguintes referências: [Assarsson e Tomas, 99] [Kaiser, 00] [Lengyel, 02].
6.2.5 Comandos de câmara e metódos sobre objectos
Este capítulo permite dar uma noção total do controlo de uma câmara num mundo virtual
a 3D através de um conjunto de comandos e métodos. Os comandos de uma câmara são
derivados dos sete graus de liberdade já descritos anteriormente (ver tabela 2)
[Nieuwenhuisen e Overmars, 02]. Os comandos são módulos de alto nível que surgem
com a necessidade de permitir o manuseamento simples pelos agentes operadores para
87
realizar a filmagem de acordo com as especificações do realizador e percepções próprias
do agente operador, ver tabela 2.
Tabela 2: Comandos de uma câmara
Comandos
Set
Pan
Tilt
Roll
Zoom
Definição dos comandos
Posicionamento da câmara.
Rotação da câmara na horizontal.
Rotação da câmara na vertical.
Rotação no seu próprio eixo.
Permite aumentar ou diminuir o campo de visão
Para enquadar os diferentes objectos do cenário no ecrã através dos comandos de câmara
para que a disposição dos objectos seja perfeita, e assim se possa avaliar a qualidade de
visualização dos mesmos objectos foi necessário definir um conjunto de métodos
genéricos que possam ser utilizadas num objectivo proposto de visualização num
determinado momento.
Tabela 3: Métodos sobre um Objecto
Métodos
Points(O)
Bbox(O)
Centr(O)
Topcentr(O)
Botcentr(O)
Centr(O1,O2,..,On)
Gaze(O)
Up(O)
Definição (em coordenadas mundo)
Retorna uma lista dos pontos de controlo para o objecto O
Bounding box (xmin, ymin, zmin, xmax, ymax, zmax )
Centroid ((xmin+xmax)/2, (ymin+ymax)/2, (zmin+zmax)/2)
( (xmin+xmax)/2, (ymin+ymax)/2, zmax )
( (xmin+xmax)/2, (ymin+ymax)/2, zmin )
Retorna a média de Centroid de todos os objectos
Retorna o vector de orientação para o objecto O
Retorna o vector up para o objecto O
Os métodos implementados podem ser utilizados em outros domínios de filmagem,
podendo ser combinados entre eles para realizar as sequências desejadas pelo operador.
Ducker sugere um conjunto de métodos para enquadrar os objectos no domínio das
câmaras que permita de uma forma simples enquadrar o objecto O no cenário [Drucker,
94]. Na tabela 3 são descritos os métodos a utilizar para manuseamento dos objectos
compostos pela sua informação através de uma boundingbox.
6.2.6 Formalização de restrições de câmara
O sistema MAICC utiliza um conjunto de restrições sugeridas principalmente por Bares
para atingir os objectivos referentes à filmagem do cenário. Os resultados dos objectivos
dependem assim do cumprimento das restrições aplicar por cada câmara na filmagem.
88
O modelo de Bares apresenta alguns problemas no posicionamento das câmaras
utilizando as restrições, este problema não se coloca no sistema MAICC pois as câmaras
estão posicionadas estaticamente no cenário. Para formalizar as restrições estas foram
agrupadas de três formas distintas: restrições relativas ao ambiente/câmaras; restrições
relativas ao objecto e restrições da projecção.
6.2.6.1 Restrições relativas ao ambiente
As restrições referentes ao ambiente pretendem assegurar restrições físicas das câmaras e
configurações genéricas para a execução de uma boa filmagem. Estas restrições são
descritas na tabela 4.
Tabela 4: Restrições directas relativas ao ambiente
Restrição
Limitar fov
(Camera Field of View)
Limitar x, y, z
Propósito
Limitar o ângulo do campo de visão da câmara na vertical e
na horizontal para definir o formato da imagem.
Limitar a região de acção da câmara no espaço 3D.
(Camera Position Region)
Limitar Pan, Tilt
Limitar a velocidade da rotação da câmara virtual.
(Camera Speed Rotate)
Limitar Zoom( speed, Restringir a velocidade do zoom, limitando também os níveis
min, max)
máximos e mínimos do zoom.
(Camera Zoom)
Limitar Swap
Limitar tempo mínimo da permanência da câmara activa.
(Camera Swap)
6.2.6.2 Restrições relativas ao objecto
As restrições relativas ao objecto têm como objectivo assegurar as limitações a impor na
filmagem de um determinado objecto. As restrições aplicar são de diversa ordem,
incluindo: focagem, distância à câmara, ângulo de orientação do objecto, campo de visão,
ordem na visualização, oclusão e projecção. Na tabela 5 serão analisadas as restrições
aplicar a cada objecto mais detalhadamente.
Tabela 5: Restrições relativas a um objecto
Restrição
LookAt(O)
Propósito
Utilizar o ponto de visão no centro do objecto.
(LookAtPoint)
Distance(O,dist)
Restrição da distância da câmara ao centro do objecto.
(Object Distance)
Angle(O,ang)
(Object View Angle)
Fov(O,fov).
Restringir ângulo de orientação da câmara referente ao
objecto.
Restringir que um objecto esteja no campo de visão.
89
(Object Field of View)
DepthOrder(O,ord)
(Object Depth Order)
Occlusion(O,occ)
(Object Occlusion
Minimize)
Restrição para especificar que a câmara seja posicionada de
forma que o objecto pivot apareça o mais próximo ou distante
da câmara do que um objecto secundário.
Restrição dos objectos com um determinado valor mínimo de
oclusão. Os valores de oclusão variam no intervalo de [0.0 a
1.0] .
6.2.6.3 Restrições da projecção
As restrições de projecção estão relacionadas com a forma de como os objectos aparecem
posicionados no ecrã. Estas restrições pretendem assim limitar o posicionamento do
aparecimento dos objectos a duas dimensões (ver tabela 6). Estas restrições utilizam
alguns métodos aplicáveis aos objectos.
Tabela 6:Restrições directas de projecção
Restrição
(xmin, ymin) < Proj(centr(0)) <
(xmax, ymax)
Propósito
Restringir o centro de um objecto para estar em
alguma região do ecrã.
(Object Projection Size)
(xmin, ymin) < Proj(points(O)) < Assegurar que todos os pontos de um objecto
estão em alguma região do ecrã.
(xmax, ymax)
(Object Projection Absolute)
6.2.7 Tarefas de visualização num jogo de futebol
Para realizar a filmagem de um jogo de futebol é necessário definir um conjunto de
procedimentos de filmagem que são genéricos para o cenário. Após uma entrevista com
um realizador da RTP (ver anexo A) foi possível definir um conjunto de procedimentos a
executar pelo operador e realizador para que a filmagem de jogo de futebol seja o mais
real possível. Já Ducker no seu trabalho [Drucker e Zeltzer, 95] recorreu a um realizador
desportivo da WBZ-TV em Bostom, para recolher informação sobre como filmar um jogo
de futebol. Após a recolha da informação definiram-se tarefas básicas de visualização
numa partida de futebol que são descritas na tabela 7:
Tabela 7: Tarefas de visualização num jogo de futebol
Futebol
1. Posicionar as câmaras nas posições respectivas do cenário
2. Localizar a bola com uma das câmaras
3. Isolar jogador (significando, mostrar o jogador e um ou dois jogadores na
proximidade do jogador isolado)
4. Visualizar as repetições em outras câmaras não utilizadas no jogo.
90
5. Manter a visualização de dois jogadores ao mesmo tempo.
6. Posicionar a câmara por cima do ombro de jogador a jogador
7. Visualizar o campo a partir de um ponto de vista de qualquer jogador ou
da própria bola.
8. Movimentar a câmara acompanhando a bola durante o jogo
As cinco primeiras tarefas de visualização são os comandos típicos dados pelo realizador
para os operadores de câmara. As últimas três tarefas não podem ser implementadas num
jogo de futebol real, pois a câmara não pode sobrevoar pelo ar, logo são aplicadas a
câmara virtuais em que não existem limites a aplicar nas mesmas.
6.3 Toolkit MAS – Multi Agent System
No contexto desta tese existiu a necessidade de criar um plataforma multi-agente, com o
nome de MAS (Multi Agent System), desenvolvida em C++ e utilizando o paradigma de
object oriented. A plataforma MAS foi desenvolvida com o objectivo de responder as
exigências do alto desempenho aplicacional (nomeadamente em jogos e simulações) e
facilitar a interacção entre os agentes pertencentes ao mundo inseridos. A plataforma é
constituída por um conjunto de ferramentas e classes de baixo nível que permitem a
criação de agentes de software inteligentes. A plataforma permite dois tipos de interacção
a que os agentes estão sujeitos:

Interacção com o mundo físico (movimentação e orientação dos agentes);

Interacção com outros agentes através da comunicação via mensagem.
A comunicação entre os agentes é efectuada através de mensagens, sendo o
processamento da mesma realizado automaticamente pela plataforma, assegurando assim
que a mensagens chegam sempre ao agente ou agentes destinatários.
MAS - Multi Agent System
CMAS_Communication
CMAS_Scene3D
CMAS_World
CMAS_Sound3D
CMAS_Agent
CMAS_Agent
CMAS_Agent
CMAS_Agent
Agente
Realizador
Agente
Operador
Agente
Analisador
Outros
.....
Agentes do visualizador
Figura 6.9: Arquitectura Multi Agent System (MAS)
91
Na figura 6.9 é visível o esquema genérico da plataforma MAS e a sua extensibilidade
com o Virtual3D. A plataforma é constituída pelos seguintes módulos:

CMAS_World: A classe World define o ambiente onde os agentes estão inseridos.
A comunicação entre os agentes é estabelecida por esta classe através de um
conjunto de métodos próprios de comunicação entre agentes. O ambiente tem
associado a si uma cena tridimensional e uma saída de som tridimensional.

CMAS_Agent: Classe genérica do agente de software que permite a extensão para
outros tipos de agentes, tal como: realizador, operador, analisador, utilizador, etc.
A generalização permite inclusive a alteração e adição de novos métodos de
comportamento aos agentes de software através da herança de métodos. Cada
agente é constituído por um conjunto de atributos genéricos que passam pelo:
nome do agente, tipo de coordenadas tridimensionais, ângulo de orientação e
estado. Para um agente fazer parte do mundo necessita obrigatoriamente ser
registado, podendo ser removido do mundo através de uma operação inversa.

CMAS_Communication: Módulo que assegura a comunicação entre agentes
através de um thread. As mensagens quando são enviadas para um agente são
colocadas numa fila circular para que futuramente o módulo de comunicação a
envie para o respectivo destinatário. A comunicação é efectuada através de uma
mensagem em formato genérico para que todos os agentes a possam ler.
Fila circular
Recepção mensagens
M3
Mn
M2
M1
Tratamento mensagens
Mensagens
Entrada
Mensagens
Saída
Thread processamento de mensagens
Figura 6.10: Estrutura do processamento de mensagens
Os agentes implementados partilham a mesma estrutura e processos de
comunicação, estando a representação da estrutura de comunicação na figura (ver
figura 6.10).

CMAS_Scene3D: Módulo que
tridimensional no mundo virtual.

CMAS_Sound3D: Módulo que é o responsável pela integração do som.
é
responsável
pela
intergração
gráfica
Como já foi dito anteriormente, a conunicação é efectuada através de mensagem. A
mensagem é constituída pelo agente, origem e destino, tipo de mensagem e conteúdo da
mensagem.
92
6.4 Descrição dos agentes
O sistema MIACC através da sua arquitectura multi-agente para realizar uma filmagem
inteligente identifica dois grupos distintos de agentes pelas suas características próprias de
coordenação. O primeiro grupo é constituído pelos agentes cinematográficos, o segundo
grupo inclui os agentes do cenário alvo a filmar. Os agentes cinematográficos incluem os
agentes necessários para a realização de uma filmagem televisiva, que inclui, um
realizador para coordenação e operadores para manuseamento das câmaras de filmagem.
No que diz respeito aos agentes do cenário futebol estes são constituídos por árbitro,
público, analisador de jogo e os actores37.
Os agentes têm um papel fundamental para a coordenação de todo o cenário virtual. Uma
das características mais relevantes de um Sistema Multi-Agente reside na interacção
estabelecida entre os seus componentes. Podem ser estabelecidas relações de cooperação,
competição ou antagonismo, com o objectivo de facilitar a resolução de um problema. No
sistema MAICC os agentes operadores de câmara estabelecem processos cooperativos
que consistem no envio aos agentes vizinhos da informação sobre o seu estado de
filmagem do ponto de interesse. Esta informação é de utilidade no controlo da
visualização, permitindo uma visão mais global no processo de afectação do
enquadramento dos planos através do factor de zoom. De seguida passamos a descrição
dos vários intervenientes do SMA.
6.4.1 Agente realizador (CAgentDirector)
A coordenação entre os agentes operadores é fundamental para uma boa visualização. O
agente realizador tem a responsabilidade de coordenar os agentes que operam as câmaras
virtuais (operador ou cameraman) para que estes estejam sincronizados de acordo com os
seus planos para uma boa realização do jogo. O agente realizador tem o papel principal
numa filmagem, pois é ele quem selecciona qual a câmara a colocar no “ar” (selecção da
câmara para visualização).
37
Os actores no modelo do futebol são os jogadores de ambas as equipas e a bola.
93
Agente Realizador
Configuração
do shot
Ecrã
Prioridades / Restrição 1
Prioridades / Restrição 2
Prioridades / Restrição ...
Ev
en
Mundo
tos
Agente
Actor
parâmetros
(re Int
str enç
içõ
es ões
, re
giã
o
Biblioteca
de shot
Configuração da
câmara
Cenário shot 1
Cenário shot 2
Cenário shot ...
Agente
Utilizador
Prioridade de
visualização
)
Agente
Operador
de
ica o
íst zaçã
r
u i
He sual
vi
selecção
Selector
(shot, output)
Informação
estatística
Agente
Analisador
Regras simples
situação/acção
(comportamentos)
Figura 6.11: Arquitectura do agente realizador
Como se pode analisar na imagem 6.11, a arquitectura do agente realizador é constituída
por três módulos principais, que são:

Selector (analisar dados, seleccionar câmara, seleccionar shot): - Módulo
responsável pelo raciocínio do agente. O agente através de uma arquitectura
reactiva analisa os factos provenientes do: mundo, utilizador, analisador e
operadores de câmara (heurística de visualização), de seguida selecciona a melhor
câmara que se enquadra no shot a e coloca-a no “ar”. A heurística enviada pelos
operadores de câmara quantifica a qualidade da imagem que está a filmar num
determinado momento do jogo. A arquitectura do agente reactivo pretende
satisfazer a necessidade de seleccionar a melhor câmara com a maior rapidez
necessária. Este módulo é também o responsável por seleccionar qual o shot a
utilizar na visualização e quais as suas configurações (prioridades dos actores e
restrições).

Biblioteca de shots: Módulo que contêm os vários tipos de shot para um
determinado cenário a filmar, em que neste caso é o futebol;

Configuração do shot: Parametrização das restrições e prioridades de visualização
dos actores (jogadores).
O agente tem a responsabilidade de enviar para os agentes operadores de câmara as
intenções da filmagem [Amerson e Kime, 01] e a configuração das câmaras dependente
do tipo de shot a realizar. As intenções são traduzidas na região de visualização e nos
valores das restrições aplicadas a cada operador [Bares e Lester, 99]. No domínio do
94
futebol a região a filmar é seleccionada pelo realizador através de um conjunto de regras
simples situação/acção (comportamentos do agente) que estão associadas ao estado do
jogo, disposição dos agentes no cenário e estatísticas do jogo. As regiões possíveis do
campo para filmar pelos operadores são as descritas na tabela 8.
Tabela 8: Regiões definidas pelo Agente Realizador
Região
Descrição
REGION_CENTER
Região central do campo delimitada pela circulo do
meio campo.
REGION_AREA_LEFT
Região da grande área do lado esquerdo do campo.
REGION_AREA_RIGHT
Região da grande área do lado direito do campo.
REGION_MIDDLE
Região central do campo.
REGION_MIDDLE_RIGHT Região direita entre a região central do campo e a
região da área do lado direito.
REGION_MIDDLE_LEFT
Região esquerda entre a região central do campo e a
região da área do lado esquerdo.
É de realçar que cada região tem associado um valor de prioridade de visualização para
que o operador possa escolher os diferentes enquadramentos de imagens segundo
prioridades de outros elementos do cenário.
A atribuição de prioridade aos agentes actores tem como objectivo quantificar a
importância de visualização dos mesmos. Esta importância é preponderante para o agente
operador poder decidir quem fica fora ou dentro da imagem a filmar. Através desta
prioridade o realizador pode definir a inclusão do mesmo, atribuindo o valor de 0. A
prioridade máxima possível é de 1.
É o realizador que deve exibir a informação estatística proveniente pelo agente analisador
para que os espectadores possam analisar as mesmas no decorrer no jogo. O agente deve
assegurar a comunicação entre o utilizador e o funcionamento do aplicacional do
visualizador Virtual3D. Os eventos aplicacionais a executar pelo realizador provenientes
do utilizador são:

Seleccionar a câmara para visualização;

Enviar comandos para a câmara (tilt, pan, zoom);

Seleccionar o modo estatístico a visualizar (posse bola, localização de bola,
automático ou ignorar)

Activar/desactivar a malha de renderização dos objectos;

Activar /desactivar a área rectangular de colisão dos objectos;

Activar /desactivar as repetições dos golos;

Seleccionar o modo de autozoom;

Seleccionar o modo de lookat;

Seleccionar se existe controlo de regiões pelo realizador;

Definir o detalhe do zoom;

Definir o Algoritmo de zoom;

Definir o tipo de focagem: distante ou próxima;

Iniciar parâmetros das câmaras;

Iniciar valores de cálculo;
95
A manipulação das câmaras pelo utilizador via teclado só é possível através do realizador,
pois é ele que recebe as ordens e as envia para o respectivo agente operador. Assim
pretende-se assegurar que o agente realizador tem o controlo total sobre os operadores de
câmaras.
6.4.2 Agente operador (CAgentCameraman)
O agente operador ou cameraman é o responsável por realizar a filmagem no modelo
MAICC, enquanto o realizador tem o papel da coordenação. O agente operador é
subordinado do realizador, executando as tarefas de filmagem de acordo com as intenções
do realizador [Amerson e Kime, 01]. Como já foi dito anteriormente, as intenções são
expressas pela região a filmar e pelos novos valores atribuir as restrições da câmara
descritas na secção 6.2.5. O agente operador de câmara não têm como missão apenas
enquadrar a imagem, mas também tem como missão efectuar a sincronização da imagem.
A sincronização da imagem consiste em que o ponto de interesse da filmagem ocupe a
mesma área de ecrã nas várias câmaras, evitando assim as mudanças bruscas de imagem
na selecção da nova câmara. Para realizar o sincronismo é necessário que exista
cooperação entre os diversos operadores do modelo. A sincronização actua directamente
no comando de zoom da câmara. Na secção 6.5.2 a sincronização será analisada mais
detalhadamente. Por fim, após o enquadramento da imagem respeitando as intenções do
realizador e a sincronização da imagem, cada operador de câmara envia a heurística da
qualidade da imagem filmada para o realizador, para que este possa seleccionar a melhor
câmara convenientemente a realização da filmagem.
A comunicação entre os vários agentes operadores e o realizador é estabelecida
directamente. Na figura 6.12 é apresentada a arquitectura comunicativa do agente.
Podemos analisar que a arquitectura é composta pelo módulo de recepção de mensagens
dos agentes realizador, operadores e actores. O módulo de envio de mensagens como o
próprio nome diz é o responsável pelo envio das mensagens.
96
Ac
çã
o
Câmara
Percepção
Recepção
de
Mensagens
Percepção da
comunicação
Módulo
Inteligente
Módulo de
Comunicação
Envio
de
Mensagens
Agente
Operador
Acção da
comunicação
Figura 6.12: Arquitectura de comunicação do agente operador
O módulo central de comunicação é o responsável por coordenar toda a comunicação do
agente. Este mesmo módulo está ligado ao módulo inteligente do agente, para que sejam
reportadas as mensagens ao sistema central de raciocínio. O módulo inteligente define a
arquitectura racional do agente. No modelo actual o agente operador usa uma arquitectura
BDI (“Belief-Desire-Intention”). Das arquitecturas anteriormente analisadas na secção
4.2, optou-se pela arquitectura de Raciocínio Processual, PRS (Procedural Reasoning
System) [Georgeff 1986, Georgeff 1989], enquadrando-se esta no modelo de controlo de
câmara inteligente e respondendo satisfatoriamente as exigências do cenário dinâmico em
que estão envolvidos os agentes operadores.
A arquitectura do agente apresenta então características dos modelos analisados de
controlo de câmara inteligente associadas a uma arquitectura de agente BDI. O
funcionamento do agente é caracterizado da seguinte forma: o módulo de Sensores é
responsável por captar a informação do ambiente e dos outros agentes. A informação a
recolher é a seguinte:

Estado e posição dos actores (jogadores, bola) no ambiente virtual;

Parâmetros das outras câmaras (posição e orientação e factor de zoom);

Conteúdo das mensagens dos outros agentes.
Por sua vez o módulo Monitor, que estabelece a ligação entre os Sensores e a Base de
Dados de conhecimento, tem como missão traduzir a informação captada pelos sensores
para a base de dados de conhecimento (factos/crenças), que é constituída por:

Estado interno do agente operador de câmara;

Posição tridimensional dos actores (jogadores, bola) no ambiente virtual;

Parâmetros de sincronização das outras câmaras;

Mensagens dos outros agentes.
97
A biblioteca de planos do agente contem os comandos possíveis para o operador de
câmara conseguir executar os objectivos que levam ao sucesso da filmagem (que neste
caso é o jogo de futebol). Os comandos possíveis são os descritos na secção 6.2.5. Os
objectivos necessários para atingir uma boa filmagem são as restrições da filmagem
descritas na secção 6.2.6. Estas mesmas restrições são afectadas permanentemente pelas
intenções do realizador e pelo sincronismo necessário a efectuar com os outros
operadores de câmara. Os módulos descritos anteriormente comunicam directamente com
o módulo Interpretador de Raciocínio, módulo que é composto pelos seguintes
procedimentos:
1.Analisar as crenças (posição e estado dos actores, estado interno);
2.Saber qual o plano a implementar por ordem do realizador;
3.Enquadrar os planos nos objectivos a realizar pelo agente operador de câmara
através de um algoritmo de gerar e testar (ver anexo H);
4.Colocar na estrutura de intenção os planos de filmagem para execução;
5.Actualização das estruturas do agente;
Seguidamente os planos que satisfazem os objectivos são colocados na estrutura de
intenções para que se possa futuramente gerar os comandos necessários para movimentar
a câmara através os actuadores.
Com o modelo adoptado pretende-se dar ao agente capacidades inteligentes associadas ao
controlo de câmara inteligente em cenários dinâmicos para que ele possa realizar uma
filmagem correctamente executando procedimentos cinematográficos necessários para
uma boa realização.
6.4.3 Agentes jogador (CAgentPlayer)
Os jogadores são os agentes mais importantes do cenário, pois é sobre eles que se efectua
o enquadramento da imagem pelo operador de câmara. Os jogadores são modelados como
agentes emocionais, pois são emocionalmente afectados pelo seu comportamento no
campo (durante o jogo). Eles também são agentes reactivos simples porque são guiados
pelas coordenadas bidimensionais enviadas pelo servidor soccerserver (ambiente) que são
convertidas em coordenadas tridimensionais. O agente tem ainda a capacidade de criar a
sua caixa de colisão (BoundingBox) que é utilizada para os diferentes operadores de
câmara enquadrarem o objecto no plano. A selecção da sequência de animação a
processar é efectuada através do seu estado emocional.
98
16,66 ms (fps=60)
6
6
X0 inicio = 0
X1 fim = 60
100 ms ( fps=10 ) - tempo de ciclo do servidor soccerserver
Figura 6.13: Diagrama do modelo de movimento do jogador
A movimentação do agente jogador no campo de futebol sofre uma pequena alteração ao
sistema imposto pelo servidor soccerserver. O tempo de amostragem da nova posição
proveniente do ambiente (afectado pelo servidor) é de 100 milissegundos (tempo de
ciclo), o que acontece é que a aplicação funciona nos novos processadores e placas
gráficas actuais uma velocidade muito superior, cerca de 50 a 60 imagens por segundo o
que dá um tempo de ciclo compreendido entre 16,66 a 20 milissegundos. Sendo o tempo
de ciclo muito superior ao do ambiente surgiu por natureza a necessidade de o agente
jogador poder suavizar a movimentação no campo 5 a 6 vezes respectivamente. A
imagem 6.13 demonstra a suavização do movimento pelo agente, onde para um tempo de
ciclo médio de 16,66 milissegundos (60 imagens por segundo) é possível posicionar o
jogador muitas mais vezes, implicando uma melhoria substancial na qualidade de
movimento do jogador. A suavização do movimento do jogador implica também uma
melhoria na focagem dos jogadores pelos agentes operadores, isto acontece porque
existem um maior detalhe de posicionamento nos objectos a focar. A suavização da
orientação do agente segue o mesmo modelo anterior, para uma análise mais detalhada
sobre a suavização do movimento e orientação do agente pode-se consultar o algoritmo
em anexo G.
6.4.4 Agente bola (CAgentBall)
O agente bola representa o estado da bola no servidor soccerserver ou no ficheiro de log
que está a ser processado pelo visualizador. Este agente reactivo apresenta características
muito básicas limitando-se a converter as coordenadas de visualização do servidor para
coordenadas tridimensionais no visualizador Virtual3D. As novas coordenadas são
enviadas pelo ambiente para o agente, sendo convertidas de bidimensionais para
tridimensionais pelo próprio agente, criando posteriormente o rectângulo de colisão
(boundingbox) para enquadramento com as câmaras. O algoritmo de deslocação do
agente no cenário é o mesmo que utiliza o agente jogador na sua movimentação (ver
anexo G). O agente bola é responsável de através das novas coordenadas de
posicionamento simular a rotação do esférico, a rotação é efectuada tendo em conta pela
seguinte fórmulas:
99
deltaRot = (Dist/2*Raio*PI)*fScale
A fórmula que traduz a rotação do esférico num determinado momento de ciclo (deltaRot)
é efectuada pela divisão da distância percorrida (Dist) pelo perímetro do esférico. O Raio
da bola toma o valor de 0.10 por defeito. No final o resultado final será multiplicado por
fScale para ajustar a rotação real ao mundo virtual. O parâmetro fScale assume o valor 3.5
como defeito. A orientação da rotação é efectuada pelos vectores de direcção da
deslocação da bola pelo servidor.
6.4.5 Agente analisador (CAgentStats)
O agente analisador tem como missão estar permanentemente a observar o estado do
ambiente alterado dinamicamente pelo desenrolar do desafio, com o objectivo de
processar as respectivas análises estatísticas do jogo. Após o cálculo das estatísticas o
analisador envia as mesmas para o realizador da visualização e público, para que ambos
disponham informação sobre o jogo para definir o seu estado interno.
Existem dois tipos de estatísticas que estão a ser calculadas neste momento pelo
analisador, que são a percentagem de posse e localização de bola por região.
(estatística posse de bola)
(estatística localização de bola)
Figura 6.14: Estatísticas do agente analisador
A percentagem da posse de bola por região indica o tempo que uma determinada equipa
esteve com a posse de bola numa região previamente definida pelo analisador de
estatísticas. Por sua vez a localização de bola por região contabiliza a percentagem da
ocorrência da posição da bola numa determinada região do campo também previamente
definida pelo analisador. Na imagem 6.14 são visíveis os dois tipos de estatísticas que vão
para o “ar” por ordem do realizador num jogo que está decorrendo.
6.4.6 Agente público (CAgentPublic)
O agente público pretende dar um maior realismo ao cenário através da expressão de
satisfação do estado do jogo. O realismo do público é conseguido através da agitação nas
bancadas e pelo ruído efectuado. O agente para expressar a sua satisfação utiliza uma
arquitectura emocional que é constituída pelo sistema de valores descrito na tabela 9. Para
100
calcular o grau de satisfação o agente utiliza as suas percepções sobre o ambiente (estado
do jogo) associadas a informação estatística proveniente do analisador de jogo.
Tabela 9: Sistema de valores do agente público
Sistema de valores
Descrição
Muito satisfeito
Golo de uma das equipas
Satisfeito a 90%
Resultado com muitos golos e posse de bola diversificada.
Satisfeito a 70%
Resultado com golos e posse de bola diversificada.
Satisfeito a 50%
Resultado com golos e posse de bola central.
Satisfeito a 30%
Resultado com poucos golos e posse de bola central.
Satisfeito a 10%
Resultado sem golos e posse de bola central.
Espanto
Bola ao lado da baliza
Insatisfeito
Resultado sem golos e posse de bola no meio campo
A reprodução de sons é efectuada da seguinte forma, tendo em conta o estado emocional
do agente, este envia para o sistema sonoro a mensagem de som que expressa o seu
estado. O efeito de agitação nas bancadas é conseguido através da animação do público
(troca de imagens). Assim quanto maior for o seu grau de satisfação maior é a agitação
nas bancadas, implicando assim uma maior velocidade na troca das texturas.
6.4.7 Agente árbitro (CAgentRefree)
O agente árbitro é o responsável por apitar as faltas existentes no decorrer do jogo. Este
agente puramente reactivo através da sua percepção analisa o estado do jogo (ocorrência
de faltas), posteriormente toma a decisão de apitar dependo da gravidade da falta, se a
falta é menos grave apita com menos intensidade se a falta é mais grave, então apita com
maior intensidade.
Tabela 10: Comportado do agente árbitro (situação/acção)
Estado Jogo
Início de jogo (PM_BeforeKickOff)
Intensidade
Muito Alta
Colocação da bola em jogo (PM_KickIn_Left, PM_KickIn_Right)
Baixa
Pontapé de baliza (PM_GoalKick_Left, PM_GoalKick_Right)
Baixa
Pontapé de canto (PM_FreeKick_Left, PM_FreeKick_Right)
Média
Fora de jogo (PM_OffSide_Left, PM_OffSide_Right)
Média
Reposição da bola no meio campo por golo ou início da partida
(PM_KickOff_Left, PM_KickOff_Right)
Alta
Faltas cometidas no decorrer do jogo (PM_Foul_Charge_Left,
PM_Foul_Charge_Right, PM_Foul_Push_Left,
Alta
101
PM_Foul_Push_Right … )
Fim do jogo (PM_TimeOver)
Muito Alta
Na tabela 10 são visíveis as diferentes intensidades de apito pelo árbitro dependente do
estado do jogo. Para uma consulta mais detalhada dos estados do jogo no servidor
soccerserver ver tabela 14.
6.5 A Comunicação dos agentes do sistema MAICC
De uma forma geral, a passagem de mensagens entre agentes é o modo de comunicação
mais utilizado entre agentes. A privacidade e rapidez com que a mensagem é transmitida,
asseguram ao sistema uma eficácia, que de outra forma poderia ser comprometida. A
arquitectura de comunicação utilizada no modelo é a directa, devido ao facto de os
agentes trocarem a informação por mecanismos dedicados sem intervenção de outros
agentes. Os agentes utilizam a plataforma de comunicação MAS para comunicarem uns
com os outros. Os agentes tratam da sua própria coordenação enviando aos outros agentes
as suas capacidades e/ou necessidades para que cada agente possa tomar individualmente
as suas decisões relativas à comunicação.
A comunicação entre os agentes tenta assegurar a coordenação de todo o sistema para
controlo inteligente das câmaras de forma a realizar a filmagem o mais real possível. Na
figura 6.13 pode-se ver as comunicações entre os principais intervenientes do cenário:
utilizador, realizador, operadores, analisador. A comunicação é efectuada através de um
conjunto de mensagens de baixo nível descritas no anexo I.
Agente
Operador
3
Agente
Operador
2
Agente
Utilizador
Agente
Realizador
Agente
Operador
n
Agente
Operador
1
Agente
Analisador
Agente
Público
Ambiente
Figura 6.15: Troca de mensagens entre os principais agentes
102
6.5.1 Descrição da comunicação
Na comunicação existente entre os diferentes agentes do sistema, o agente utilizador
recebe as ordens via o periférico teclado, as ordens são de seguida enviadas para o
realizador para que este as possa executar ou mandar executar. No caso da ordem do
utilizador envolver uma câmara o realizador é utilizado como intermediário, assegurando
assim o controlo total sobre as câmaras. O agente analisador tem o papel de através do
seus sensores de percepção recolher informação do jogo para de seguida se efectuar a sua
análise, com o objectivo de enviar a informação para o realizador e público. A informação
proveniente do analisador para o realizador é utilizada com dois objectivos concretos, que
são:

Ajudar a seleccionar a região de filmagem do jogo;

Exibir a informação estatística no ecrã para que o utilizador tenha a percepção do
que se esta a passar no decorrer jogo no âmbito da posse ou localização de bola no
campo por região.
Por sua vez, a comunicação entre o analisador e o público tem como intuito disponibilizar
ao agente público a informação estatística necessária para este criar um sistema de valores
referentes ao grau de satisfação do jogo.
A comunicação mais importante do modelo é a que é efectuada entre o realizador e os
operadores de câmara. A importância deve-se ao facto de envolver toda a coordenação de
filmagem dos agentes operadores num determinado momento do jogo. A comunicação é
efectuada nos dois sentidos. No sentido do realizador para o operador a comunicação
envolve a seguinte informação:

Configuração do posicionamento e restrições das câmaras;

Definir os métodos de utilizar o zoom das câmaras pelos operadores;

Manuseamento assistido da câmara através dos comandos (tilt, pan, zoom). Esta
comunicação pretende realizar as operações solicitadas pelo utilizador à câmara
que está activa para visualização;

Definir o idioma da filmagem da cena através da especificação da região a filmar.
Já a troca de mensagens entre o operador e o realizador têm como objectivo o envio da
heurística da qualidade da imagem da câmara, para que ajude o realizador a seleccionar a
câmara que deve colocar no ecrã.
A comunicação entre agentes operadores não é menos importante que a anterior. Esta
comunicação envolve a troca de mensagens permanentemente entre eles com o objectivo
de sincronizar as câmaras na sua distância de filmagem ao ponto de interesse. Esta
103
sincronização tem como objectivo evitar mudanças bruscas de imagem na selecção de
outra câmara pelo realizador para que mantenha o mesmo plano de filmagem.
Os agentes actores são todos os agentes que fazem parte do cenário para a filmagem, que
neste caso são os jogadores e a bola. Na figura 6.16 pode-se analisar a comunicação dos
principais agentes (realizadores e operadores) com os agentes actores. A comunicação
tem como objectivo estabelecer prioridades de visualização. As prioridades são definidas
pelo realizador para indicar a importância de o operador o integrar na imagem a filmar.
Agente
Operador
1
Agente
Actor 1
Agente
Actor 2
Agente
Realizador
Agente
Operador
2
Agente
Actor n
Ambiente
Figura 6.16: Troca de mensagens entre os agentes (actores)
Sempre que um operador desejar saber a prioridade de um actor é estabelecida uma
comunicação com dois sentidos, primeiro o agente operador faz o pedido ao agente para
saber a sua prioridades de seguinte está é enviada ao operador de câmara. Este sistema de
prioridades de visualização poderá ser útil para outros cenários que envolve a inclusão de
objectos. Os agentes actores também recebem mensagens do ambiente para que estes se
possam posicionar no campo de acordo com o jogo que se está a desenrolar no servidor
ou está a ser processado no ficheiro de log. Para um maior detalhe de comunicação entre
os diferentes agentes pode-se consultar o anexo J em que descreve todas as comunicações
possíveis entre os agentes do modelo de controlo inteligente de câmara através de um
Sistema Multi-Agente.
6.5.2 Sincronização das câmaras
A sincronização da imagem entre câmaras é o processo pelo qual o operador de câmara
tenta ajustar o factor de enquadramento zoom em relação às outras câmaras existentes no
cenário. A sincronização permite de uma forma directa melhor a percepção da imagem do
ponto de interesse (zona da bola) pelo espectador quando existe uma mudança de câmara.
A sincronização da imagem afecta directamente o factor de zoom que é utilizado pelo
operador para enquadrar a imagem final no ecrã. A comunicação entre os agentes
operadores tem assim como objectivo sincronizar as áreas de enquadramento do ponto de
interesse pelas diferentes câmaras do cenário. As câmaras implementadas como virtuais
104
(as que não apresentam características reais) não são utilizadas no algoritmo, pois
apresentam comportamentos instáveis à filmagem. O processo de comunicação entre os
agentes operadores é estabelecido de forma a sincronizar a qualidade de visualização do
ponto de interesse, para estabelecer a comunicação o agente deve incluir no módulo de
envio de mensagens as seguintes tarefas a executar:

Calcular a qualidade de visualização do ponto de interesse (zona da bola);

Enviar para todos os agentes operadores via broadcast38 a qualidade de
visualização do ponto de interesse focado pelo do agente;

Afectação do valor de sincronização da imagem com a qualidade de visualização
do ponto de interesse.
No módulo de recepção de mensagens o agente deve executar os seguintes
procedimentos:

Filtrar as mensagens de sincronização dos outros agentes;

Recolher o valor actual da qualidade de visualização do ponto de interesse do
agente operador que envia a qualidade de visualização;

Actualização do último valor enviado pelo agente para actualizar o estado interno;
Para o agente sincronizar a imagem é necessário calcular a média da qualidade de
visualização do ponto de interesse das várias câmaras do modelo. Após o cálculo da
média o agente operador tenta ajustar a sua imagem à média global da qualidade do ponto
de interesse das várias câmaras. O ajuste da câmara é efectuado no comando zoom,
implicando assim um aumento ou diminuição do factor tendo em conta as necessidades de
sincronização com os outros agentes operadores.
6.5.3 A Linguagem CAMERA LANGUAGE
A linguagem CAMERA LANGUAGE permite a comunicação cinematográfica entre os
vários intervenientes (realizador, operadores e actores) no cenário. A linguagem introduz
ainda um agente analisador que tem a capacidade de recolher informação do cenário. Este
agente é usado para fornecer ao realizador informação de alto-nível que possa ser
utilizada para decidir qual a melhor imagem a seleccionar em cada instante da filmagem.
A linguagem CAMERA LANGUAGE é baseada em diversos conceitos, tais como: regiões
do cenário, períodos de tempo, intervenientes na filmagem, configuração de câmaras,
intenções de filmagem e prioridades de visualização. A arquitectura da linguagem utiliza
o mesmo conjunto de mensagens apresentadas no anexo I.
38
Broadcast - Método de transmitir informação, que consistem em enviar a informação de um ponto de
emissor para n receptores que fazem parte de um grande grupo. Este grupo pode ser em geral o público
ou até mesmo um conjunto de agentes de software.
105
6.5.3.1 Requisitos e especificação formal da linguagem
A linguagem respeita um conjunto de requisitos necessários para permitir inserir um
compromisso entre a generalidade e simplicidade. A linguagem deve ser suficientemente
geral de forma a permitir a representação das variantes mais comuns associados aos
conceitos cinematográficos a utilizar pelos intervenientes do modelo MIACC. Os
requisitos principais na definição da linguagem são:

Simplicidade de expansão para novos conceitos e restrições de filmagem;

O formato deverá ser de simples leitura pelos agentes do sistema mas também por
humanos;

Todos os conceitos e associações devem ser claros para pessoas com
conhecimentos básicos em cinematografia;

Conceitos cinematográficos devem ser facilmente exportados para o formato da
linguagem;

Possibilitar representar regiões, períodos de tempo, configurações de câmara,
intenções de filmagem, prioridades de visualização e tipos de intervenientes;

A linguagem deve ser o mais simples e compacta possível, sendo ao mesmo
tempo robusta permitindo uma validação constante;
Estes requisitos são a base para uma análise mais detalhada para encontrar uma
linguagem que permita a representação de uma forma genérica. As mensagens de
definição de conceitos impostos pelos requisitos devem permitir definir novos conceitos
de forma a serem utilizados como parte da linguagem no decurso de uma filmagem. Os
conceitos definidos são identificados por um nome para que possam ser referenciados em
futuras mensagens pelos intervenientes. A linguagem CAMERA LANGUAGE possui
quatro tipos de mensagens:

Configuração: Permite ao realizador configurar as câmaras no cenário, incluindo
a posição e factores iniciais da câmara;

Estatística: Permitir ao realizador dispor de informação estatísticas de alto-nível
do cenário para facilitar a selecção do ponto de focagem do cenário. Este tipo de
mensagem é bastante útil em ambientes dinâmicos, onde os actores estão em
permanente movimento;

Intenções, qualidade e sincronismo da filmagem: Mensagens utilizadas entre os
vários intervenientes do cenário para permitir uma coordenação total na realização
da filmagem para que esta se torne o mais real possível;

Prioridade de visualização: Permitem atribuir aos diferentes actores prioridades
de visualização. Como exemplo, no cenário do futebol os jogadores que estão
106
mais próximos do ponto de focagem apresentam uma prioridade mais elevada.
Podendo-se fazer distinção entre actor principal e secundário.
A linguagem CAMERA LANGUAGE foi definida utilizando BNF – BakusNaur form
[Naur, 60]. A definição dos tipos de mensagens utilizadas é a seguinte:
<MESSAGE> ::= (<TIME> <ID> <SENDER> <RECEIVER> <MESSAGE_PART>
{<MESSAGE_PART>})
<MESSAGE_PART> ::= <FILM_MSG> | <SATISFACTION_MSG> | <PRIORITY_VIEW_MSG> |
<STATISTICS_MSG> | <SYNC_CAMERA_MSG> | <CAMERA_CFG_MSG> |
<SENDER> ::= <AGENT>
<RECEIVER> ::= <AGENT>
<FILM_MSG> ::= (film_intention <ID> <FILM_INTENTION>)
<SATISFACTION_MSG> ::= (satisfaction <ID> < SATISFACTION>)
<PRIORITY_VIEW_MSG> ::= (priority_view <ID> <PRIORITY_VIEW>)
<STATISTICS_MSG> ::= (statistics <ID> <STATISTICS>)
<CAMERA_CFG_MSG> ::= (camera_cfg <ID> <CAMERA_CFG>)
<SYNC_CAMERA_MSG> ::= ( sync_camera <ID> <SYNC_CAMERA>)
6.5.3.2 Regiões do cenário
Para executar uma filmagem é necessário definir termos sobre as regiões do cenário a
filmar. As regiões do cenário são específicas para cada contexto da filmagem. No caso do
futebol, onde se insere este trabalho, o conceito de região é bastante comum aos
profissionais de futebol (jogadores, treinadores, jornalistas, realizadores e operadores). A
partilha de uma definição dos termos de região para todos os elementos do cenário tornase fundamental para uma boa coordenação da filmagem. Neste contexto serão definidos
os termos de região associados ao futebol. Para os cenários genéricos serão definidos
termos gerais para definir qualquer tipo de região.
<REGION> ::= <SIMPLE_REGION> | (<SIMPLE_REGION> {<SIMPLE_REGION>})
<SIMPLE_REGION> ::= <REGION_NAME> | ( <REGION_FOOTBALL> | … ) |
<REGION_DEFINITION>
<REGION_FOOTBALL>::= center | left_area | right_area | middle | left middle |
right_middle | …
<REGION_DEFINITION> ::= <POINT> | NULL
(rect <POINT> <POINT>) |
(tri <POINT> <POINT> <POINT>) |
(quad <POINT> <POINT> <POINT> <POINT>) |
(circle <POINT> [real])
<POINT> ::= (point [real] [real] [real])
107
6.5.3.3 Períodos de tempo
O tempo é importante num cenário cinematográfico para sincronizar algumas acções. A
linguagem providencia assim um mecanismo simples de definição de períodos de tempo.
Existem diversos períodos de tempo que são conceitos pré-definidos na linguagem,
nomeadamente para ambientes específicos. Para além disso pode-se definir períodos de
tempo para utilizar posteriormente nas mensagens.
<PERIOD>::= <PREDEFINED_PERIOD> | <PERIOD_NAME> | <PERIOD_DEFINITION>
<PREDEFINED_PERIOD>::= game | first_half | second_half | extra_time
<PERIOD_DEFINITION>::= (<TIME> <TIME>) | <LENGTH>
<TIME>::=[integer] | now
<LENGTH>::= [integer]
6.5.3.4 Intervenientes do cenário
Um cenário é constituído por diferentes intervenientes como já foi salientado
anteriormente. Nesta secção pretende-se definir uma estrutura genérica que possa integrar
os diferentes intervenientes do modelo MAICC que já foram mencionados anteriormente.
<AGENT> ::= analyser | public | <DIRECTOR> | <CAMERAMAN> | <ACTOR>
<ACTOR> ::= actor | <PLAYER> | <BALL> | …
<CAMERAMAN> ::= cameraman <NUMBER>
<DIRECTOR> ::= director <NAME>
<PLAYER> ::= (<TEAM> <NUMBER> <PLAYER_PARAMETERS>)
<PLAYER PARAMETERS> ::= (<POSITION> <VELOCITY> <DIRECTION> <NECK_DIRECTION>)
<BALL> ::= (<POSITION> <VELOCITY> <DIRECTION>)
<NAME>::= "[string]"
<NUMBER> ::= [integer]
<POSITION> ::= <VECTOR3D>
<VELOCITY> ::= <VECTOR3D>
<VECTOR3D> ::= ([float] [float] [float])
<DIRECTION> ::= [float]
<NECK_DIRECTION> ::= [float]
6.5.3.5 Estatísticas do cenário
A informação estatística do cenário é muito importante para o modelo MIACC, porque o
agente público e realizador a utilizam como base de apoio ao seu comportamento interno.
Não menos importante é a utilidade da informação estatística para o utilizador, porque
disponibiliza um conjunto de resultados sobre o desafio interessante para análise do
domínio. Tendo em conta estes dois aspectos a estatística deve contemplar o
posicionamento dos actores no cenário e informação detalhada sobre o ambiente em que
os actores estão inseridos, que neste caso é o futebol.
<STATISTICS> ::= <STATS_FILM> | <STATS_FOOTBALL> | …
<STATS_FILM> ::= (localization <ACTOR> <REGION> <PERIOD> <COUNT>)
108
<STATS_FOOTBALL> ::= (clear) | (game_time <TIME>) |
(game_result <PERIOD> [integer] [integer]) |
(ball_possession <REGION> <TEAM> <PERIOD> <COUNT>) |
(ball_localization <REGION> <PERIOD> <COUNT>) | ….
<TEAM>::= left | right
<COUNT> ::= [float]
6.5.3.6 Configuração da câmara
O primeiro procedimento a efectuar pelo realizador é comunicar a posição das câmaras
aos operadores respeitando o modelo do cenário a filmar. A comunicação é efectuada via
mensagem apresentando a seguinte configuração:
<CAMERA_CFG>::= <POSITION> <PAN> <TILT> <ROLL> <ZOOM>
<PAN>::= <POS> <VEL>
<TILT>::= <POS> <VEL>
<ROLL>::= <POS> <VEL>
<ZOOM> ::= <FACTOR> <VEL> <MIN> <MAX>
<FACTOR>::= [float]
<MIN>::= [float]
<MAX>::= [float]
<POS>::= [float]
<VEL>::= [float]
6.5.3.7 Intenções, qualidade e sincronismo da filmagem
As intenções da filmagem que são comunicadas pelo realizador ao operador de câmara
também são definidas através da linguagem CAMERA LANGUAGE de forma a
uniformizar a comunicação entre os principais agentes. Como já foi dito anteriormente as
intenções são expressas pelas região de focagem e pelas restrições aplicar a filmagem. Na
descrição da linguagem faz-se então a distinção entre estes dois tipos de intenção, assim
temos:
<FILM_INTENTION> ::= <FILM_REGION> | <FILM_CONSTRAINT>
<FILM_REGION> ::= <REGION_DEFINITION> <PRIORITY>
<PRIORITY> ::= [float]
<FILM_CONSTRAINT> ::= <CAMERA_FOV> | <CAMERA_POS_REGION> |
<CAMERA_SPEED_ROTATE> | <CAMERA_ZOOM> | <CAMERA_SWAP> | <LOOKAT> |
<OBJ_DISTANCE> | <OBJ_VIEW_ANGLE> | <OBJ_FOV> | <OBJ_DEPTH_ORDER> |
<OBJ_OCCLUSION>
<CAMERA_FOV>::= <CAMERAMAN> <FOV>
<CAMERA_POS_REGION>::= <CAMERAMAN> <REGION>
<CAMERA_SPEED_ROTATE>::= <CAMERAMAN> <VEL> <VEL> <VEL>
<CAMERA_ZOOM>::= <CAMERAMAN> <ZOOM> <MIN> <MAX>
<CAMERA_SWAP>::= <REALIZADOR> <TIME>
<LOOKAT>::= <CAMERAMAN> <ACTOR>
<OBJ_DISTANCE>::= <CAMERAMAN> <ACTOR> <DISTANCE>
<OBJ_VIEW_ANGLE>::= <CAMERAMAN> <ACTOR> <ANGLE>
109
<OBJ_FOV>::= <CAMERAMAN> <ACTOR> <FOV>
<OBJ_DEPTH_ORDER>::= <CAMERAMAN> <ACTOR> <ORDER>
<OBJ_OCCLUSION>::= <CAMERAMAN> <ACTOR> [float]
<OBJ_PRJ_SIZE>::= <CAMERAMAN> <ACTOR> <RECTANGLE>
<OBJ_PRJ_ABSOLUTE>::= <CAMERAMAN> <ACTOR> <RECTANGLE>
<FOV> ::= [float][float]
<TIME>::= [float]
<DISTANCE>::= [float]
<ANGLE>::= [float]
<ANGLE>::= [integer]
<RECTANGLE>::= <MIN> <MAX> <MIN> <MAX>
A sincronização da imagem pelos diferentes operadores obriga a que cada operador envie
a informação respeitante à qualidade de visualização do ponto de interesse para os outros
operadores. Assim a mensagem necessária a enviar inclui o agente emissor o receptor e o
valor de sincronização.
<SYNC_CAMERA> ::= <SENDER> <RECEIVER> <SYNC_VALUE>
<SYNC_VALUE> ::= [float]
Após a recepção das intenções de filmagem e das mensagens dos outros operadores com
o objectivo de sincronizar as imagens para minimizar a mudança brusca de planos o
operador de câmara envia uma mensagem para o realizador indicando a qualidade da
imagem a filmar.
<SATISFACTION> ::= <CAMERAMAN> <SATISFACTION_VALUE>
<SATISFACTION_VALUE> := [float]
6.5.3.8 Prioridade de visualização
A prioridade de visualização é importante para definir a importância do aparecimento do
actor no ecrã. Existe a necessidade de definir uma mensagem genérica para o realizador
indicar a prioridade de visualização dos actores.
<PRIORITY_VIEW> ::= <ACTOR> <PRIORITY_VALUE>
<PRIORITY_VALUE> ::= [float]
6.5.3.9 Instruções do utilizador para o realizador
No modelo desenvolvido para este trabalho é possível o utilizador controlar alguns
parâmetros da realização da filmagem. Derivado a esta necessidade surge um conjunto de
opções possíveis de seleccionar pelo utilizador.
<USER_OPTION>
<ZOOM_METHOD>
<CAMERA_TILT>
render_wire |
::= stats_reset | <STATS_MODE> | <SET_CAMERA> | auto_zoom |
| <ZOOM_DETAIL> | <ZOOM_DISTANCE> | auto_lookat | <CAMERA_PAN> |
| <CAMERA_ZOOM> | region_decision | replay_mode | render_bbox |
heuristics_reset
<STATS_MODE> ::= possession | localization | auto_view
<SET_CAMERA> ::= <ID> <CAMERAMAN>
110
<ZOOM_METHOD> ::= best_value | best_average
<ZOOM_DETAIL> ::= low | medium | high
<ZOOM_DISTANCE> ::= near | far
<CAMERA_PAN> ::= left | right
<CAMERA_TILT> ::= up | down
<CAMERA_ZOOM> ::= in | out
6.5.3.10 Conclusões
A linguagem CAMERA LANGUAGE foi uma primeira tentativa para criar uma linguagem
cinematográfica de alto-nível inserida numa arquitectura muti-agente. É claro que ainda
existem diversos pontos em abertos e a sintaxe não permite representar tudo o que é
necessário para definir todos os procedimentos de filmagem. Apesar das suas limitações
iniciais a linguagem resolve os problemas impostos pelo trabalho no âmbito de uma
filmagem futebolística. A linguagem está actualmente em extensão de forma a incluir
novas intenções e mecanismos de filmagem.
6.6 Implementação
Neste capítulo apresentam-se os aspectos relativos à implementação do sistema de
controlo de câmara inteligente. O ambiente de desenvolvimento, a plataforma gráfica
utilizada na estrutura dos agentes, mensagens implementadas, classes e estruturas criadas
para o visualizador.
6.6.1 Ambiente de desenvolvimento
Esta aplicação foi desenvolvida para o sistema operativo Windows, nomeadamente o
windows XP, funcionando a aplicação nos sistemas mais antigos: Windows 95/98,
Millenium e 2000. Este sistema operativo apresenta-se estável e permite utilizar
tecnologia DirectX e a biblioteca gráfica RenderWare que os outros não permitem
(Linux).
Como ambiente de desenvolvimento para o sistema utilizou-se o ”Microsoft Visual C++
6.0” usando MFC (Microsoft Foundation Classe). MFC não é mais do que uma biblioteca
do Visual C++ que inclui um conjunto de primitivas para construção de aplicações de
uma forma rápida. O Visual C++ e a classe MFC permitem a utilização do paradigma
Object Oriented para desenolver o Sistema Multi-Agente. O ambiente de
desenvolvimento demonstrou ser fiável e robusto, não tendo, durante o processo de
implementação, apresentado qualquer problema. O elevado volume de documentação e
manuais disponíveis, o sistema de debug, a possibilidade de implementação de aplicações
genéricas e a interacção agradável e intuitiva com o utilizador foram alguns dos factores
que motivaram a sua escolha:

Manuais: Juntamente com o ambiente de desenvolvimento pode ser instalado um
elevado de manuais que funcionam como suporte à execução das tarefas a realizar
(MSDN- Microsoft Developer Network). Paralelamente existe disponível na
111
Internet um conjunto de grupos de discusão, manuais e exemplos onde a maioria
dos problemas surgidos no decorrer da implementação podem ser resolvidos.

Visualização de métodos e classes dinâmica: Possui uma área onde os métodos,
classes ou variáveis implementadas são dinamicamente actualizados, característica
relevante para a análise do sistema.

Auto-compleição: O sistema apresenta ao programador automaticamente a
informação sobre as acções permitidas para cada classe no ambiente de trabalho.
Sendo assim possível dirigir a concentração para o que é verdadeiramente
importante, deixando de se preocupar com a memorização dos métodos e
parâmetros para os diferentes componentes do programa.

Edição durante o processo de debug (”Edit and Continue”): É possível realizar
alterações no código durante o debug, evitando que por cada falha detectada seja
necessário parar o debug e reiniciá-lo posteriormente.

Suporte do ANSI C++: Suporta as mais recentes especificações ANSI/ISO, pelo
que qualquer aplicação desenvolvida (desde que não inclua componentes ou
classes específicas da Microsoft) será passível de compilação e execução noutro
ambiente de desenvolvimento.
6.6.2 Biblioteca gráfica
Para permitir um bom desempenho gráfico e com alguma qualidade, e que permitisse com
alguma facilidade a integração de novos dispositivos gráficos sem ser necessário alterar o
código do programa, permitindo assim ter-se mais tempo para o desenvolvimento da
aplicação do que trabalhando nas várias configurações do hardware, surgiu a necessidade
de utilizar uma biblioteca gráfica que preenchesse os requisitos exigidos. Para cumprir os
requisitos gráficos impostos utilizou-se a biblioteca gráfica RenderWare que apresenta
todas as características das bibliotecas genéricas, incluindo mais as seguintes:

Permite um alto desempenho da aplicação;

Permite integrar modelos gráficos desenhados em 3D Studio Max v2.5;

Multi plataforma 3D (Pc, XBOX, Nintendo, PlayStation);

Facilidade de debug da biblioteca gráfica;

Integra animações de personagens;

Integração de ambiente de luz nos objectos;

Ferramenta para desenhar a 2D no ambiente 3D;

Arquitectura extensível a novos módulos integrados.
112
6.7 Conclusões
Neste capítulo apresentou-se o visualizador desenvolvido Virtual3D, onde assenta o
sistema MAICC. Na descrição do visualizador foi analisada em detalhe a arquitectura
funcional do sistema. As metodologias de controlo de câmara inteligente foram analisadas
na perspectiva do sistema MAICC relacionando-se com as abordagens dos diferentes
autores. Foram explicadas as novas metodologias de coordenação da filmagem aplicadas
no sistema MAICC no âmbito da visualização de jogos de futebol robótico simulado do
RoboCup. Para integrar as novas metodologias de coordenação foi desenvolvido uma
plataforma de comunicação, designada de MAS, com o objectivo de facilitar e acelerar a
comunicação entre os agentes do sistema. Após a descrição dos vários agentes foi
apresentado o sistema de comunicação, realçando-se as interacções existentes entre os
vários intervenientes do sistema. A comunicação assenta na linguagem CAMERA
LANGUAGE, linguagem desenvolvida especificamente para o domínio da filmagem.
Resumindo, neste capítulo apresentou-se o modelo de controlo inteligente de câmara para
a implementação de um sistema automatizado para realização de uma filmagem real no
domínio do futebol. Este modelo foi desenvolvido numa estrutura onde se integram várias
abordagens: computação gráfica, cinematografia, controlo de câmara, agentes, Sistemas
Multi-Agente, comunicação e coordenação.
No próximo capítulo ilustram-se os cenários onde as características descritas neste
capítulo são analisadas na realização da filmagem em cenários de futebol específicos.
CAPÍTULO 7: ANÁLISE DE RESULTADOS
113
7 ANÁLISE DE RESULTADOS
Neste capítulo apresentam-se os resultados obtidos para a avaliação do sistema MAICC
no controlo de câmaras inteligentes inseridas num SMA. Em primeiro são estabelecidos
os cenários da simulação, os parâmetros considerados e por fim os critérios de avaliação.
Segue-se a discussão dos resultados da simulação e posteriormente algumas
considerações acerca dos resultados.
7.1 Cenários
Para avaliação do SMA foram seleccionados cinco cenários de jogos de futebol distintos.
Para a análise dos dados foram utilizados cenários em formato de logfile (jogo em
diferido) de forma a manter a consistência dos dados, algo que uma ligação ao servidor
soccerserver não permitirá. Os cenários de jogo seleccionados foram de dois tipos: jogos
reais dos campeonatos do RoboCup e jogos gerados com as melhores equipas da época.
Estes cenários estão longe de poderem representar todas as situações possíveis num
cenário dinâmico como é o futebol, mas julga-se terem interesse sobe o ponto de vista de
seleccionar um conjunto de particularidades inerentes aos cenários do jogo, das quais se
destaca o tempo de jogo, resultado e localização da bola. Estas particularidades
apresentam ter interesse do ponto de vista da independência dos cenários para a realização
da filmagem utilizando os vários agentes operadores, actores e realizador. Os cenários da
simulação são descritos na tabela 11, sendo apresentadas as diferentes particularidades.
Tabela 11: Cenários para análise dos resultados
Nº
1
2
3
4
5
Equipas
FCPortugal2001 – UvaTrilearn
(Jogo do Mundial 2001)
TsinghuAeolus – FCPortugal
(Jogo gerado)
Brainstormers2K – FCPortugal
(Final do Europeu 2000)
FCPortugal – LuckyLuebeck
(Fase inicial do Europeu 2000)
TsinghuAeolus – CMUnited
( Jogo gerado)
Tempo Resultado
% Localização
6000
4-1
28 – 61 – 11
6000
0–3
7 – 73 – 20
6000
0-2
22 – 44 – 34
6000
13 - 0
1 – 51 – 48
6000
2–0
20 – 69 – 11
Como se pode constatar os cenários apresentam vários resultados de jogo e localizações
de bola (lado esquerdo, centro e direito). O tempo é expresso em ciclos, em que cada ciclo
corresponde a 100 milissegundos.
114
7.2 Critérios de avaliação
Antes de apresentar os resultados foi importante ressalvar alguns aspectos. Uma das
dificuldades que se apresentou foi tentar encontrar quais os parâmetros que são essenciais
para uma avaliação do sistema com características particulares a cada humano como é
analisar a qualidade de uma filmagem ou se o sincronismo entre câmaras é o mais
correcto. Após uma reflexão mais profunda e estudo das diversas alternativas foi decidido
tomar como medidas: a qualidade de visualização da imagem global e a suavização de
plano na mudança de câmara. A qualidade de visualização permite assim analisar se a
imagem está bem enquadrada pelo operador e se cumpre as intenções da filmagem
impostas pelo realizador. Esta medida, que foi explicada na secção 6.2.1, pretende
quantificar a qualidade da imagem através de um conjunto de prioridades de visualização
sobre os actores, regiões de filmagem, posição central da bola, etc. Já a medida de
suavização da câmara permite analisar até que ponto é que a coordenação entre os agentes
permite manter o mesmo plano para evitar mudanças bruscas de câmara para câmara.
Outro aspecto não menos importante para avaliar o sistema é sabermos que estamos a
lidar com valores expressos em função de simulações. Assim, a comparação será restrita à
comparação de valores entre os vários cenários a testar, que neste caso são cinco
possíveis.
7.3 Resultados observados
Tendo em conta os objectivos assumidos inicialmente, a nível do sistema de controlo
inteligente das câmaras utilizando um SMA, é necessário avaliar o sistema e perceber o
seu funcionamento, para que se possa tirar conclusões até que ponto o sistema de
visualização corresponde às exigências cinematográficas. Para realizar a avalização foi
necessário realizar várias simulações nos cenários anteriormente definidos. Os resultados
podem ser visualizados na globalidade no anexo N. As simulações pretendem analisar os
seguintes factores de filmagem e são apresentados seguidamente.
7.3.1 Cooperação entre agentes para suavizar planos
A cooperação entre os agentes foi fundamental para suavizar os planos de forma a
permitir uma visualização mais estável na mudança de câmara. Nos gráficos apresentados
na figura 7.1 são apresentados os resultados obtidos da sincronização entre os vários
operadores de câmara, assim sendo foram analisados os jogos nos cinco cenários
anteriormente descritos para realização da filmagem com e sem sincronização.
A sincronização entre agentes operadores tem implicações na qualidade da imagem e nos
valores médios de sincronização das câmaras. Assim sendo, são apresentados dois
gráficos distintos que expressam as duas grandezas referidas.
115
Figura 7.1: Resultados da cooperação entre agentes para suavizar planos
Nos gráficos pode-se constatar que a utilização da sincronização entre agentes operadores
de câmara melhora os níveis de sincronização globais das câmaras, melhoria que pode
atingir quase o dobro (44%). Consta-se também que a sincronização tem como
implicações uma pequena perca da qualidade da imagem a filmar. Este facto explica-se
pela obrigatoriedade dos agentes operadores tentarem sincronizar os seus planos,
implicando consequentemente limitações de realização no enquadramento dos actores na
imagem.
Algo que também tem interesse analisar é saber até que ponto um maior número de
câmaras permite melhorar ou piorar os valores de sincronização e a qualidade de imagem.
Esta análise é expressa nos gráficos da figura 7.2.
Figura 7.2: Resultados de uma filmagem com menos câmaras
Para realizar a análise foram efectuadas dois tipos de filmagem, uma com seis câmaras
centrais e outra com apenas quatro câmaras centrais. Após a execução das várias
filmagens para os cincos cenários de simulação os resultados demonstram que numa
filmagem com um menor número de câmaras, o valor médio de sincronização melhora
tendo como contrapartida uma pequena perca na qualidade da imagem. Os valores mais
elevados de sincronização devem-se ao facto de existirem menos câmaras no cenário,
sendo assim mais fácil realizar a sincronização entre os operadores. Já a perca na
qualidade de imagem está directamente relacionada com a existência de um menor
116
número de câmaras no cenário, o que implica um menor número de alternativas para
seleccionar a melhor câmara.
7.3.2 Utilização de regiões de focagem definidas pelo realizador
Outro ponto de vista interessante para análise são as implicações que a definição de
regiões de filmagem impostas pelo realizador (através de intenções de filmagem aos
operadores de câmara) têm sobre a qualidade de imagem e consequentemente sobre a
sincronização entre os operadores câmaras. Nos gráficos da figura 7.3 são apresentados os
resultados para os cinco cenários de simulação com utilização de regiões e sem utilização.
A realização das simulações utilizou sempre o sincronismo de planos pelos operadores de
câmara.
Figura 7.3: Resultados de uma filmagem com e sem regiões
Nos resultados apresentados pode-se analisar que a filmagem com regiões aumenta a
qualidade da imagem a visualização pelas câmaras. Este aumento está relacionado
directamente com o facto de a região definida pelo realizador indicar ao operador de
câmara qual a melhor região de filmagem. É certo que a região de filmagem já foi
previamente analisada pelo realizador da filmagem, apresentado assim uma direcção a
seguir para conseguir uma boa imagem. A utilização das regiões de filmagem tem como
contrapartida uma perca na qualidade de sincronização das câmaras, como se pode
analisar no gráfico à esquerda.
7.3.3 Qualidade de imagem versus sincronização
Nas duas secções anteriores foram analisadas as implicações da sincronização entre
agentes e a importância das regiões de filmagem. Após a sua análise é fácil concluir que a
qualidade da imagem está sempre relacionada com a sincronização das câmaras.
Resumindo, quando se ganha na sincronização perde-se na qualidade da imagem e
quando se ganha na qualidade de imagem perde-se na sincronização.
117
Figura 7.4: Qualidade de Imagem Verus Sincronização de Câmaras
Assim sendo é importante apresentar dois gráficos onde se possa expressar esta mesma
relação entre as duas grandezas anteriormente abordadas (ver figura 7.4). A simulação foi
efectuada nos primeiros três cenários e utilizou sempre as regiões activas. Os gráficos
apresentam a evolução das duas grandezas utilizando diferentes factores de relevância ao
longo das simulações. No início a qualidade da imagem é 1 (representa 100%) e a
sincronização 0 (representando 0%), dando-se por fim o inverso. O ponto central situa-se
nos valores 0,5/0,5, o que equivale a 50% para cada. No gráfico da qualidade de imagem
pode-se observar que a qualidade da imagem inícia com o valor mais alto, não existindo
sincronização, de seguida tem uma caída suave até ao ponto central, apresentando depois
um pequeno acréscimo até ao fim. No entanto a sincronização apresenta um
comportamento contrário, começando a subir até ao ponto central, seguindo-se uma queda
ligeira, por fim, já no limite apresenta uma pequena subida. O ponto óptimo entre as duas
grandezas situa-se então no ponto central e é óbvio que um melhor valor da qualidade da
imagem implica uma pior sincronização e vice-versa.
7.4 Conclusões
Após apresentação dos resultados pode-se concluir que a sincronização entre os agentes
operadores de câmara tem um papel importante na qualidade de visualização de uma
filmagem. Quando a sincronização entre os agentes operadores ocorre, existe uma
melhoria substancial na sincronização de planos entre as câmaras. Por outro lado implica
uma perca na qualidade da visualização da imagem final. Já a utilização de regiões de
filmagem pelo realizador (intenções) para “guiar” os operadores apresenta um
comportamento contrário, levando ao ganho da qualidade de imagem em detrimento da
sincronização de planos. Após a análise destas duas grandezas chegou-se a conclusão que
a variação das mesmas depende uma da outra: quando uma atinge melhores valores a
outra tem um comportamento contrário. É de salientar ainda que cada cenário apresenta
valores diferentes para a sincronização e qualidade de imagem dependentes do próprio
jogo. Apesar da diferença entre os valores apresentados, as grandezas analisadas
(qualidade de imagem e sincronização) apresentam sempre as mesmas tendências de
comportamento perante os diferentes cenários.
118
CAPÍTULO 8: CONCLUSÃO E TRABALHOS FUTUROS
8 CONCLUSÃO E TRABALHOS FUTUROS
8.1 Conclusões
Para além das conclusões específicas retiradas da análise da aplicação prática do sistema
no capítulo 6, é também possível extrair conclusões mais gerais, das quais destacamos de
seguida as mais interessantes no âmbito do controlo de câmara.
O sistema MAICC tem como objectivo, para o seu sucesso, a unificação de três grandes
áreas: Computação Gráfica, Cinematografia e a Inteligência Artificial Distribuída. A
definição da MAICC torna-se essencial para a unificação destas áreas em que
normalmente actuam individualmente. Da unificação destas áreas pretende-se obter
vantagens através do aproveitamento das melhores características das respectivas áreas,
características que já foram analisadas anteriormente, ao longo dos vários capítulos deste
trabalho. O sistema implementado nesta tese diverge dos outros sistemas, devido ao
Sistema Multi-Agente para controlo de câmara inteligente. O sistema de controlo de
câmara pretende dar ao utilizador uma visualização mais real, simulando a filmagem de
um jogo televisivo onde interagem actores, operadores de câmara e o realizador para
executarem uma filmagem televisiva.
No desenvolvimento do sistema foram aplicadas estratégias de coordenação nos domínios
distribuídos e descentralizados em que os agentes executam tarefas cooperativas e
complexas. O sistema implementado contém características que podem constituir-se, mais
do que alternativas, como complementos viáveis aos sistemas existentes de controlo de
câmara em diferentes cenários. A análise do domínio de controlo de câmaras inteligentes
revelou uma complexidade de coordenação entre os vários intervenientes para realização
de uma filmagem e os problemas que lhe estão associados (enquadramento de imagem,
posicionamento de câmaras, definição de competências, comunicação).
O facto do sistema ser baseado em agentes propicia uma implementação de
comportamentos de adaptabilidade, autonomia e relacionamento. Torna-se assim
perfeitamente satisfatória a adopção por parte de alguns sistemas actuais no domínio do
controlo de câmara de algumas das características apresentadas pelo MAICC,
nomeadamente na integração de um SMA para controlo da filmagem. Além destas
características vantajosas, os agentes podem simultaneamente modelar os
comportamentos actualmente implementados nos componentes dos sistemas de controlo.
Relativamente ao papel dos agentes no sistema, pensa-se que as conclusões mais
relevantes se prendem com os potenciais benefícios resultantes da cooperação entre o
realizador, operadores e os actores. Partindo dos problemas de comunicação entre os
agentes foi necessário formalizar uma linguagem cinematográfica – CAMERA
LANGUAGE – que permite, de uma forma simples, efectuar a coordenação para os
119
problemas conhecidos à priori. Através da utilização da linguagem torna-se mais fácil
coordenar os agentes operadores de câmara, realizadores e actores para resolver o
problema do controlo de câmara.
Do estudo realizado relativamente a possíveis domínios de aplicação, foi concluído que o
RoboCup, e em particular a liga de simulação, constituíam o domínio ideal para a
aplicação das metodologias de coordenação desenvolvidas. As características da
simulação tornam este cenário particularmente adequado às metodologias de coordenação
desenvolvidas. O visualizador desenvolvido como plataforma de testes utilizando o
sistema MAICC comprova isso mesmo.
As metodologias de coordenação, nomeadamente dos agentes operadores de câmara e
realizador para realizarem uma filmagem, são, no entanto, generalizáveis de forma a
serem aplicadas em outros domínios cinematográficos. A aplicação das novas
metodologias de coordenação desenvolvidas na implementação do visualizador Virtual3D
no âmbito do RoboCup, levou este visualizador a ficar em 3º lugar na competição de
visualizadores do campeonato do mundo de Futebol Robótico disputado em Fukuoka Japão em 2002. Apesar da versão que concorreu ainda não contemplar metodologias de
controlo inteligente da câmara permitiu, mesmo assim, concluir que a coordenação apenas
de focagem da bola foi a arma principal do visualizador associada as suas características
gráficas e sonoras.
Pensa-se assim que as premissas e requisitos apresentados para este trabalho foram
globalmente atingidos com sucesso, apresentando-se assim como resultado final do
trabalho, um Sistema Multi-Agente de controlo inteligente de câmara, totalmente
funcional, incluindo características inovadoras e que responde ao desafio proposto como
tema desta tese.
8.2 Trabalhos Futuros
Após a implementação do sistema (gráfico, comunicação e agentes), existem algumas
vertentes susceptíveis de complemento ou optimização e objecto de trabalho futuro. O
requisito principal do sistema, que consistia na implementação de um Sistema MultiAgente para controlo de câmaras, permite pelas suas características de modularidade a
evolução do sistema para níveis de maior sofisticação e aproximação à realidade. As
perspectivas de desenvolvimento incluem:

Integração do sistema com ligação a câmaras reais e sensores de reconhecimento
de padrões para filmar jogos de futebol reais;

Criação de novas regras de selecção da região de interesse pelo realizador
dependentes do estado do jogo, cenário e estatísticas;

Aprofundamento de alguns conceitos de cinematografia no sistema;
120

Integração de um novo agente operador para “manuseamento” da câmara sobre
um carril ou em cima de uma grua;

Implementação de novos cenários tridimensionais para analisar o comportamento
dos vários agentes na coordenação da visualização;

Posicionamento automático das câmaras no cenário pelo realizador consoante o
tipo de estádio;

Integração e análise de novas restrições no controlo da câmara efectuado pelo
agente operador;

Melhoria da coordenação entre os agentes operadores de câmara para
sincronizarem as câmaras, especificando os limites da filmagem para que a
mudança de câmara pareça contínua ao utilizador;

Implementação de novos tipos de câmara virtual e suavização com splines dos
movimentos das câmaras e agentes no espaço tridimensional;

Implementação de estatísticas mais detalhadas do jogo e por jogador. O
melhoramento das estatísticas poderá ser útil para analisar jogos reais que já são
convertidos para formato de ficheiro;

Melhoria da animação dos jogadores e da bola, incluindo sombras animadas no
cenário. A animação da bola inclui elevação da mesma dependente do chuto
efectuado pelo jogador;

Adicão ao visualizador um comentador inteligente que faça o relato do jogo a ser
processado pelo servidor ou ficheiro de log;

Generalização do sistema de controlo inteligente de câmara a outros cenários
(entrevistas, medicina, robótica, estúdios);
Tendo em conta as novas perspectivas de desenvolvimento e as potencialidades actuais do
sistema MAICC, utilizando as metodologias anteriormente referidas ao longo do trabalho,
é possível implementar um sistema mais evoluído que permita assim a visualização
automática em cenários reais (entrevistas, jogos, concursos, etc.). Esta evolução passa
pela integração de mecanismos para manuseamento e reconhecimento de padrões
utilizando câmaras reais. A mesma ferramenta de visualização (Virtual3D) poderá ser
utilizada para visualizar os mesmos jogos captados pela realização para uma análise mais
detalhada das equipas e dos jogadores.
CAPÍTULO 9: REFERÊNCIAS BIBLIOGRÁFICAS
121
9 REFERÊNCIAS BIBLIOGRÁFICAS
[Angel, 02] – Angel, Edward, “Interactive Computer Graphics: A Top-Down Approach
with OpenGL”, 2nd Edition, Addison Wesley, 2002. [Amerson e Kime, 01] – Amerson,
Dan; Kime, Shaun, “Real-time Cinematic Camera Control for Interactive Narratives”,
Notas de trabalho para: AAAI Spring Symposium on Artificial Intelligence e
Interactive Entertainment, Stanford, Californania, 2001.
http://liquidnarrative.csc.ncsu.edu/pubs/DAmerson01.pdf
[Assarsson e Tomas, 99] - Ulf, Assarsson e Moller, Tomas, “Optimized View Frustum
Culling Algorithms for Bounding Boxes”, Chalmers University of Technology, Suécia,
1999.
http://fibbla.ce.chalmers.se/staff/uffe/Vfc_Bbox.pdf
[Akiyama, 01] - Akiyama, Jun – “Adapting the Multi Agent Planning System For
RoboCup Simulation League”, Department of Information Technology and Electrical
Engineering University of Queensland, 2001.
[Ako e al., 03] – Ako, Takuya; Nakayama, Koji; Takahashi, Shinichi ; Takeuchi, Ikuo,
“SoccerScope 2003”, Universidade Electro-Communications, Japão, Descrição da
equipa para o RoboCup-03, 2003.
[Arijon, 76] – Arijon, Daniel, “Grammar of the Film Language”, Silman James Press,
1976.
[Asada et al., 00] – Asada, M.; Veloso, M.; Tambe, M.; Noda, I.; Kitano, H.,
Kraetzschmar, G.K., “Overview of RoboCup-98 (2000)”, notas de leitura na Computer
Science, 2000.
http:/www.isi.edu/teamcore/tambe/papers/2000/robocup-aimag.ps
[Bares e Lester, 99] - Bares, William.; Lester, J., “Intelligent Multi-Shot Visualization
Interfaces for Dynamic 3D Worlds”, Proceedings of International Conference on
Intelligent User Interfaces, 1999.
http://www.iuiconf.org/99pdf/1999-001-0021.pdf
[Bares et al., 00a] - Bares, William H.; Thainimit, Somying; McDermott, Scott, “A Model
for Constraint-Based Camera Planning”, Center for Advanced Computer Studies,
University of Louisiana at Lafayette, Paper presented at Spring Symposium Smart
Graphics, Stanford, CA, 2000.
http://www.cacs.louisiana.edu/~sdm1718/A_Model_for_ConstraintBased_Camera_Planning.pdf
[Bares et al., 00b] - Bares, William; McDermott, Scott; Boudreaux, Christina; Thainimit,
Somying, “Virtual 3D Camera Composition from Frame Constraints”, Center for
Advanced Computer Studies, University of Lousiana at Lafayette, Paper presented at
the ACM Multimedia conference, Los Angeles, CA, 2000.
122
http://www.cacs.louisiana.edu/~sdm1718/Virtual_3D_Camera_Composition_from_Fra
me_Constraints.pdf
[Bares et al., 00c] - Bares, William.; Thainimit, S.; McDermott, S., “A Model for
Constraint-Based Camera Planning”, Proceedings of AAAI Spring Symposium on
Smart Graphics, March 2000.
http://w5.cs.uni-sb.de/~butz/AAAI-SSS2000/cameready/WBares00.pdf
[Bates, 94] – Bates, Joseph, “The role of emotion in believable agents”, Communications
of the ACM, 37(7):122-125, School of Computer Science, Carnegie-Mellon
University, Pittsburgh,1994.
www-2.cs.cmu.edu/afs/cs.cmu.edu/ project/oz/web/papers/ba-and-emotion.ps
[Bates et al., 92] – Bates, Joseph.; Bryan Loyall, A.; Scott Reilly, “An architecture for
action, emotion, and social behaviour”. Technical Report CMU-CS-92-144, School of
Computer Science, Carnegie-Mellon University, Pittsburgh, 1992.
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers/CMU-CS-92-144.ps
[Bergenti e Poggi, 00] - Bergenti, Federico e Poggi, Agostino, “Exploiting UML in the
Design of Multi-Agent Systems”, Dipartimento di Ingegneria dell’Informazione,
Università degli Studi di Parma, ESAW Worshop at ECAI 2000.
http://lia.deis.unibo.it/confs/ESAW00/pdf/ESAW13.pdf
[Blinn, 88] – Blinn, Jim, “A Trip Down the Graphics Pipeline”, Morgan Kaufmann, pp.
69-82 – Capitulo 8 -“Where am I? What am I looking at?”, 1988.
[Bratman et al., 88] - Bratman, Michael E.; Israel, David J.; Pollack, M. E., “Plans and
resource-bounded practical reasoning”. Computational Intelligence,349-355, 1988.
http://www.cs.mu.oz.au/~eas/subjects/aconcepts/IRMA.ps
[Bratko, 86] - Bratko, Ivan, “Prolog – Programming for Artificial Intelligence”, 3nd
Edition” , Addison Wesley, 1986
[Brooks, 91] - Brooks, Rodney A., “Intelligence Without Reason” , Proceedings of the
12th International Joint Conference on Artificial Intelligence (IJCAI-91), 1991.
http://www.cs.mu.oz.au/isa/brooks91.ps
[Bruderlin e Calvert, 89] - Bruderlin, A. e Calvert, T. W., “Goal-Directed, Dynamic
Animation of Human Walking”. Proc. ACM, SIGGRAPH 89, Boston, 1989.
[Brustoloni, 96] - Brustoloni, Jose C., "Autonomous Agents: Characterization and
Requirements" Carnegie Mellon Technical Report CMU-CS-91-204, Pittsburgh:
Carnegie Mellon University, 1991.
[Cai et al.., 02] – Cai, Yunpeng; Chen, J.; Yao, J.; Li, S. ,“Global Planning from Local
Eyeshot: An Implementation of Observation-Based Plan Coordination in RoboCup
Simulation Games”, Universidade Tsinghua, China, 2002.
http://robocup.lits.tsinghua.edu.cn/download/document/tsinghuaeolus_defense.zip
123
[Cañamero, 97] - Cañamero, Dolores, “Modeling Motivations and Emotions as a Basis
for Intelligent Behavior”, Proceedings of the First International Symposium on
Autonomous Agents, AA'97, Marina del Rey, CA, Fevereiro 5-8, 1997.
http://www.ai.mit.edu/people/lola/aa97-online.ps
[Cheny et al., 02] - Cheny, Mao; Foroughi, Ehsan; Heintz, Fredrik; Huangy, ZhanXiang;
Kapetanakis, Spiros; Kostiadis, Kostas; Kummeneje, Johan; Noda, Itsuki; Obst,
Oliver; Riley, Pat; Steens, Timo; Wangy, Yi e Yiny, Xiang, “RoboCup Soccer Server for Soccer Server Version 7.07 and later”
http://sserver.sf.net/docs/manual.pdf
[Christianson et al., 96] - Christianson, D.; Anderson, Sean; He, Li-wei, Salesin, D.;
Weld, D.; Cohen, M., “Declarative Camera Control for Automatic Cinematography”,
Proceedings of the AAAI-96, August 1996.
http://grail.cs.washington.edu/pub/papers/dccl-aaai96.pdf
[Chung e Hahn, 99] - Chung, Shih-kai; Hahn,James K., “Animation of Human Walking in
Virtual Environments”, 1999.
http://www.seas.gwu.edu/~graphics/papers/ca99.pdf
[Coen, 94] - Coen, Michael. “SodaBot: A Software Agent Environment and Construction
System”, MIT AI Lab Technical Report 1493, June, 1994.
ftp://ftp.ai.mit.edu/pub/users/mhcoen/aitr-1493.ps.Z
[Corten et al., 99] - Corten, Emiel; Dorer, Klaus; Noda, Itsuki; Stone, Peter, “RoboCup
Soccer Server - for Soccer Server Version 5.1 and later”, 1999.
www.robocup.org/resource
[Cranefield et al., 01] - Cranefield, Stephen; Haustein, Stefan; Purvis, Martin, “UMLBased Ontology Modelling for Software Agents”.
http://www-ai.cs.uni-dortmund.de/DOKUMENTE/cranefield_etal_2001a.pdf
[Criterion, 95] – Criterion, “Renderware – Real-time 3D graphics library”, API
Reference Manual, Canon Company, 1995.
[Dorer, 00] – Dorer, Klaus, “The Magma Freiburg Soccer Team”, Universidade de
Freiburg, Alemanha, 2000.
http://jmvidal.ece.sc.edu/822/papers/magmaFreiburg99.ps
[Drogoul e Ferber, 92] - Drogoul, Alexis; Ferber, Jacques, “Multi-Agent Simulation as a
Tool for Modeling Societies: Application to Social Differentiation in Ant Colonies” ,
MAAMAW’92, Pre-Proceedings of the 4th European Workshop of MAAMAW, Ed.
Amadeo Cesta, Rosaria Conte, Maria Miceli, National Research Council, Institute of
Psychology, Rome, Italy, Julho, 1992
www-poleia.lip6.fr/~drogoul/ papers/Drogoul.Maamaw92.pdf
[Dennett, 87] - Dennett, Daniel C., “The Intentional Stance”, The MIT Press, Cambridge,
MA,1987.
124
[Drucker et al., 92] - Drucker, Steven M.; Galyean, Tinsley A.; Zeltzer, David,
“CINEMA: A System for Procedural Camera Movements”, Computer Graphics and
Animation Group, MIT Media Lab, SIGGRAPH Symposium on 3D Interaction.
Cambridge, MA. 1992
http://www.research.microsoft.com/users/sdrucker/papers/SIG92symp.pdf
[Drucker, 94] - Drucker, Steven M., “Intelligent Camera Control for Graphical
Environments”, Tese de Doutoramento, MIT - Massachusetts Institute of Technology,
USA, 1994.
[Drucker e Zeltzer, 95] - Drucker, Steven M.; Zeltzer, David, “CamDroid: A System for
Implementing Intelligent Camera Control”, Computer Graphics and Animation Group,
MIT Media Lab, SIGGRAPH Symposium on Interactive 3D Graphics, 1995.
http://www.research.microsoft.com/users/sdrucker/papers/SIG95symp.pdf
[Drucker e Zeltzer, 96] - Drucker, Steven M.; Zeltzer, David, “Intelligent Camera
Control in a Virtual Environment”, Computer Graphics and Animation Group, MIT
Media Lab.
http://www.research.microsoft.com/users/sdrucker/papers/GImuseum_wfigs.pdf
[Foley et al., 00] – Foley, James D.; Dam, Andries Van; Feiner, Steve; Hughes, Jonh F.,
“Computer Graphics Principles and Pratice”, Second Edition in C, Addison Wesley,
2000.
[Franklin e Graesser, 96] - Stan Franklin and Art Graesser, “Is it an Agent, or just a
Program?: A Taxonomy for Autonomous Agents” , Proceedings of the Third
International Workshop on Agent Theories, Architectures, and Languages, SpringerVerlag, 1996.
[Finin et al., 93] - Finin, T. et al., “Specification of the KQML Agent Communication
Language”, DARPA Knowledge Sharing Initiative External Interfaces Working
Group, 1993
http://logic.stanford.edu/sharing/papers/kqml.ps
[Franklin, 95] - Franklin, Stan, “Artificial Minds”, Cambridge, MA: MIT Press, 1995.
[Genesereth e Fikes, 92] - Genesereth, M. R. e Fikes, R. E., “Knowledge Interchange
Format, Version 3.0 Reference Manual, Technical Report, Computer Science
Department, Stanford University, 1992
http://www-ksl.stanford.edu/knowledge-sharing/papers/kif.ps
[Georgeff, 87] – Georgeff, Michael P. e Lansky, A. L., “Reactive reasoning and
planning”, In Proceedings of the Sixth National Conference on Artificial Intelligence
(AAAI’87), 13–17, Julho, 1987.
http://agent.aitia.ai/download.php?ctag=download&docID=147
[Gibson, 76] Gibson, J. J., “The Ecological Approach To Visual Perception”, Lawrence
Erlbaum Associates, 1976.
125
[Gleicher e Witkin, 92] - Gleicher, M.; Witkin, A., “Through-the-Lens Camera Control”,
Processdings of SIGGRAPH 92. July 1992.
http://www.cs.wisc.edu/graphics/Papers/Gleicher/CMU/camera.pdf
[Haddadi e Sundermeyer, 95] - Haddadi, Afsaneh; Sundermeyer, Kurt, “Belief-DesireIntention AgentAArchitectures”. In: O’Hare, G. M. P.; Jennings, N. R.
(Eds.)AFoundations of Distributed Artificial Intelligence. Wiley Inter-Science, 1995.
[Haddadi, 96] - Haddadi, Afsaneh, “Comunications and Cooperation in Agent Systems: A
Pragmatic Theory”. Notas in Artificial Intelligence, Heidelberg, 1996.
[Harrison, 03] – Lynn T. Harrison, “Introduction to 3D Game Engine Design Using
DirectX 9 and C#”, Apress, pp.197-212, 2003.
[Hayes-Roth, 95] - Hayes-Roth, B., "An Architecture for Adaptive Intelligent Systems”,
Artificial Intelligence: Special Issue on Agents and Interactivity, 72, 329-365, 1995.
[He et al., 96] - He, Li-Wei; Cohen, Michael F.; Salesin, David H., “The virtual
cinematographer: a paradigm for automatic real-time camera control and directing”,
Proceedings of SIGGRAPH 96, in Computer Graphics Proceedings, Annual
Conference Series.
http://grail.cs.washington.edu/pub/papers/virtcine.pdf
[Hewitt, 77] - Carl Hewitt, “Viewing Control Structures as Patterns os Passing
Messages”. Artificial Intelligence. 1997.
[Hubbold et al., 98] - Hubbold, Roger; Murta, Alan; West, Adrian; Howard, Toby
“Design Issues for Virtual Reality Systems”, Proceedings of the First Eurographics
Workshop on Virtual Environments, 1993.
http://www.cs.man.ac.uk/aig/publications/barcelona.ps.Z
[Huhns e Singh, 97] - Huhns, M. N., e Singh, M. P., “Ontologies for Agents”, IEEE
Internet Computing, pp. 81-83, 1997
http://www.csc.ncsu.edu/faculty/mpsingh/papers/columns/aow-1-6-97.pdf
[Huhns e Stephens, 99] - Huhns, Michael e Stephens, Larry M., “Multiagent Systems and
Societies of Agents”, em Multiagent Systems: A Modern Approach to Distributed
Artificial Intelligence, editado por Gerhard Weiss, The MIT Press, Cap 2, pp. 121-164,
1999.
[IBM, 97] – “IBM's Intelligent Agent Strategy White Paper”, Intelligent Business
Machines Inc., 1997
[d’Inverno, 98] - d’Inverno, Mark; Kinny, David; Luck, Michael; and Wooldridge,
Michael,“A formal specification of dMARS”, Notas de leitura em Artificial
Intelligence, pages 155–176. Springer-Verlag, Berlin, 1998.
www.aaii.com.auzSzpubzSzaaii-technoteszSztechnote72.pdf/dinverno97formal.pdf
126
[Jennings, 99] - Jennings, Nick R., “Agent-Base Software Engineering”, Proceedings of
the 9th European Workshop on Modelling Autonomous Multi-Agent System
Engineering, 1999.
http://www.ecs.soton.ac.uk/~nrj/download-files/oopsla.pdf
[Jung et al., 99] – Jung, Bernhard; Oesker , Markus; Hecht, Heiko, “Virtual RoboCup:
Real-Time Visualization of 2D Soccer Games”, Universidade de Bielefeld, Alemanha,
1999.
[Kaiser, 00] – Kaiser, Kevin, “3D Collision Detection”, In Game Programming Gems,
Editado por Mark DeLoura, Charles River Media, pp.390-402, 2000.
[Karp e Feiner, 90] – Karp, P., Feiner, S., “Issues in the Automated Generation of
Animated Presentations”, In Proceedings of Graphics Interface '90, pp.39-48, 1990.
[Kay et al., 98] - Stanney, Kay M.; Mourant Ronald R.; Kennedy, Robert S., “Human
Factors Issues in Virtual Environments”, Universidade de Central Florida Department
of Industrial, EUA, 1998.
http://www1.coe.neu.edu/~mourant/pubs/presence98.pdf
[Kitano et al., 95] - Kitano, Hiroaki; Asada, Minoru; Kuniyoshi, Yasuo; Noda, Itsuki;
Osawa, Eiichi, “RoboCup: The Robot World Cup Initiative”, Proceedings of the First
International Conference on Autonomous Agents (Agents'97).
http://citeseer.nj.nec.com/cache/papers/cs/6203/http:zSzzSzwww.robocup.orgzSzgame
szSzAI-Symp.RoboCup.pdf/kitano95robocup.pdf
[Kitano et al., 97] - Kitano, Hiroaki, Tambe, Milind, Stone, Peter, “The RoboCup
Synthetic Agent Challenge 97“, International Joint Conference on Artificial
Intelligence (IJCAI97).
www.robocup.org/overview/RoboCup-Challenge97.ps
[Kogler e Ringelstein, 03] – Kogler, Marco e Obst, Oliver, “RoboLog Koblenz 2003 - 3D
Simulator Presentation”, Universisade Koblenz-Landau, Alemanha, Descrição da
[Labrou e Finin, 94] - Labrou, Yannis e Finin, Tim, “A Semantics Approach for KQML –
A General Purpose Communication Language for Software Agents”, em Proceedings
of International Conference on Information and Knowledge Management, 1994.
ftp://archive.cs.umbc.edu/pub/DARPA/kqml/papers/kqml-semantics.ps
[Lengyel, 00] – Lengyel, Eric, “A Fast Cylinder-Frustum Intersection Test”, In Game
Programming Gems, Editado por Mark DeLoura, Charles River Media, pp.380-389,
2000.
[Lengyel, 02] - Lengyel, Eric, “Mathematics for 3D Game Programming & Computer
Graphics”, Charles River Media, pp. 79-105, 2002.
127
[Lesser, 99] - Lesser, Victor, “Cooperative Multi-Agent Systems: A Personal View of the
State of the Art”, IEEE Transactions on Knowledge and Data Engineering, Vol. 11, Nº
1, Janeiro/Fevereiro de 1999.
http://www.ktsi.com/carlos/papers/99/k0133.pdf
[Leston, 96] - Leston, J., “Virtual reality: the it perspective”, Computer Bulletin, pp. 1213, Junho, 1996.
http://www1.coe.neu.edu/~mourant/pubs/presence98.pdf
[Li et al., 03] –Li, Qingrui; Huang, Zhanxiang; Sun, Pen ; Chen, Xiaopinp, “WrightEagle
2003 Presentation Description: 3D Monitor with Automatic Commentary and
Graphical Debugging System”, AI Center, University of Science and Technology of
China, Descrição da equipa para o RoboCup-03, 2003.
[Macedo, 01] – Macedo, Ana Paula Cunha da Rocha, “Metodologias de Negociação em
Sistemas Multi-Agente para Empresas Virtuais”, Tese Doutoramento, Faculdade de
Engenharia da Universidade do Porto, 2001.
[Maes, 96] - Maes, Pattie, “Intelligent Software: Programs That Can Act Independently
Will Ease the Burdens that Computers Put on People”, IEEE Expert Systems, Vol. 11,
No. 6, pp. 62-63, 1996.
[Madeiras, 03] – “João Madeiras – Computação Gráfica [Em Linha]”, Docente no
Instituto Superior Técnico de Lisboa / INESC [Consultado em 11/09/2003].
http://hogan.ist.utl.pt/~teles/index.html
[Marselas, 00] – Marselas, Herbert, “Interpolated 3D Keyframe Animation”, Game
Programming Gems, Charles River Media, pp. 465-470, 2000.
http://www.cs.wisc.edu/graphics/Papers/CMU/interactive.pdf
[Mascelli, 98] Mascelli, Joseph V. – “The five C’s of cinematography” Motion picture
filming techniques, Silman-James Press, 1998.
[Mataric, 94] - Mataric, Maja J., “Interaction and Intelligent Behavior”, MIT EECS PhD
Thesis, Maio 1994
www.upl.cs.wisc.edu/~creed/AITR-1495.pdf
[May, 00] - May, J., “Perceptual principles and computer graphics”, submetido ao forum
da Computer Graphics, em Maio de 2000.
www.shef.ac.uk/jonmay/papers/PPCG.EG.pdf
[Merke, 03] – Merke, Arthur, “FrameView HomePage [Em Linha]”, Universidade de
Dortmund, Alemanha. [Consultado em 11/08/2003].
http://ls1-www.cs.unidortmund.de/~merke/software/frameview/index.html
[Miyazawa e al., 02] – Miyazawa, Shinichi; Nakayama, Koji ; Takeuchi, Ikuo,
“SoccerScope3”, Universidade Electro-Communications, Japão, Descrição da equipa
para o RoboCup-02, 2002.
128
[Myin, 00] – Myin, Erik, “Two Sciences of Perception and Visual Art”, Editorial
Introduction to the Brussels Papers, 2000.
http://www.maurer.demon.co.uk/jcs_pdf/Myin.pdf
[Naur, 60] NAUR, Peter editor, “Revised Report on the Algorithmic Language ALGOL
60”, Communications of the ACM, Vol. 3 No.5, pp. 299-314, Maio 1960.
[Nazemi et al., 03] – Nazemi, Eslam; Zareian, AmirReza; Samimi, Reza; Shiva, Foruhar
Ali, “Team Assistant”, Universidade Shahid Beheshti University, Irão, Descrição da
[Neves e Oliveira, 97] - Neves, Maria C. e Oliveira, Eugénio, “A Control Architecture for
an Autonomous Mobile Robot”, Proceedings of First International Conference on
Autonomous Agents (AA'97) in Marina d'el Rey -California- USA - Fevereiro, 1997.
[Nieuwenhuisen e Overmars, 02] – Nieuwenhuisen, Dennis ; Overmars, Mark H. ,
“Motion Planning for Camera Movements in Virtual Environments”, Institute of
Information and Computing Sciences, Utrecht University, 2003.
http://archive.cs.uu.nl/pub/RUU/CS/techreps/CS-2003/2003-004.pdf
[Noda et al., 96] – Noda, Itsuki; Matsubara, Hitoshi; Hiraki, Kazuo; Frank, Ian , “Soccer
Server and Researches on Multi-Agent Systems”, Electrotecnhical Laboratory Umezono, Tsukuba, Japan, 1996.
ftp://ci.etl.go.jp/pub/noda/Papers/1996/iros96.ps.gz
[Noda et al., 97] – Noda, Itsuki; Matsubara, Hitoshi; Hiraki, Kazuo; Frank, Ian , “Soccer
Server: a tool for research on multi-agent systems”, Electrotecnhical Laboratory Umezono, Tsukuba, Japan, 1997.
htpp://www.etl.go.jp/etl/suiron/~ianf/Publications/ETLTR9711.ps.gz
[Noda, 00] – Noda, Itsuki , “Soccer Server : a simulator of RoboCup”, Electrotecnhical
Laboratory - Umezono, Tsukuba, Japan, 2000.
www.robocup.org/games/sserver.ps
[Noda e Stone, 00] – Noda, Itsuki; Stone, Peter, "The RoboCup Soccer Server and
CMUnited Clients: Implemented Infrastructure for MAS Research", Nota no
Workshop 13 on Infrastructure for Scalable Multi-agent Systems, 2000.
http://www.carc.aist.go.jp/~noda/Paper/2000/aa00ws.pdf
[Noda e Frank, 00] – Noda, Itsuki; Frank, Ian, "Review: RoboCup Through 2000",
Segunda conferência internaional de computação gráfica (CG2000), 2000.
http://www.carc.aist.go.jp/~noda/Paper/2000/cg2000.pdf
[Obst e Ringelstein, 02] - Obst, Oliver e Ringelstein, Christoph, “RoboLog Koblenz 2002
– Visualization Description”, Universidade Koblenz-Landau, Alemanha, Descrição da
[Odell et al., 00] - Odell, James; Parunak, H. Van Dyke e Bauer, Bernhard, “Extending
UML for Agents”, AOIS Worshop at AAAI 2000.
129
http://www.jamesodell.com/ExtendingUML.pdf
[Penedo et al., 03] - Penedo, Carla; Pavão , João; Nunes, Pedro, “ISTeam RoboCup
Advanced 3D Monitor”, Institute for Systems and Robotics, Instituto Superior Técnico,
Descrição da equipa para o RoboCup-03, 2003.
http://islab.isr.ist.utl.pt/papers/Custodio-ra3D-final.pdf
[Paull, 00] – David Paull, “The Vector Camera”, Game Programming Gems, Charles
River Media, pp. 366-379, 2000.
[Phillips et al., 92] – Phillips, C. B.; Badler, N. I.; Granieri, J., “Automatic viewing
control for 3D direct manipulation”, 1992 Symposium on Interactive 3D Graphics,
ACM Press, 1992.
[Phillips e Badler, 98] – Phillips, C. B.; Badler, N. I.. , “Jack: A Toolkit for Manipulating
Articulated Figures” ACM Siggraph Symposium on user Interface Software and
Technology, Banff, Canada, New York: ACM Press, p.221-229, 1998.
[Rao, 96] – Rao, A. S., “AgentSpeak(L): BDI agents speak out in a logical computable
language”, In W. van der Velde and J. Perram, editors, Agents Breaking Away (LNAI
1038), pp. 42-55. Springer-Verlag, 1996.
http://www.cs.drexel.edu/~shulman/bdib.pdf
[Rao e Georgeff, 95] - Rao, A. S. e Georgeff, M. P., “Bdi Agents: From theory to
practice” in Proceedings of the First Intl. Conference on Multiagent Systems, San
Francisco,1995.
http://www.cs.umbc.edu/agents/introduction/rao.ps
[Rao e Georgeff, 92] – Rao, A. S. e Georgeff, M.P., “An abstract architecture for rational
agents” In C. Rich, W. Swartout, and B. Nebel, editors, Proceedings of Knowledge
Representation and Reasoning (KR&R-92), pp. 439-449, 1992.
[Rao e Georgeff, 91] – Rao, A. S. e Georgeff, M. P., “Modeling rational agents within a
BDI-architecture”, In Proceedings of the Second International Conference on
Principles of Knowledge Representation and Reasoning (KR'91).
http://www.cs.nott.ac.uk/~mhl/archive/Rao+Georgeff:91a.pdf
[Rahmani, 03] – Rahmani, Mahmood, “Avan Analysis/Debug Tool and 3D
Presentation”, Universidade Qazvin Islamic Azad University, Irão, Descrição da
[Record, 02] – “Jornal Record”, edição 7 de Dezembro de 2002, Portugal.
[Reilly, 92] - Reilly Scott, W. e Bates, Joseph, “Building Emotional Agents“, Technical
Report CMU-CS-92-143, School of Computer Science, Carnegie Mellon University,
Pittsburgh, PA, Maio 1992.
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/papers/CMU-CS-92-143.ps
[Reis, 01] RoboCup Tutorial – The RoboCup International Initiative: AI Meets Robotics
to Create RoboSoccer Teams, editado por Reis, Luís Paulo, integrado no EPIA2001 –
130
10th Portuguese Conference on Artificial Intelligence, Seminário de Vilar, Porto, 20 de
Dezembro de 2001.
[Reis, 03] - Reis, Luis Paulo, “Coordenação em Sistemas Multi-Agente: Aplicações na
Gestão Universitária e Futebol Robótico”, Tese de Doutoramento, Faculdade de
Engenharia da Universidade do Porto, Portugal, 2003.
[Reis e Lau, 03] - Reis, Luís Paulo e Lau, Nuno, “FC Portugal Approach Overview, [Em
Linha]”, Universidade de Aveiro/Porto, Portugal. [Consultado em 11/08/2003].
http://www.ieeta.pt/robocup/overview.htm
[Renambot et al., 00] - Renambot, Luc; Bal, Henri E.; Germans, Desmond; Spoelder,
Hans J.W., “CAVEStudy: an Infrastructure for Computational Steering and Measuring
in Virtual Reality Environments”, Vrije Universidade de Amesterdão, Holanda, 2000.
http://www.cs.vu.nl/~renambot/vr/papers/hpdc_final.pdf
[Root e Boer, 99] – Root, Michael e Boer, James, “DirectX Complete”, McGraw-Hill,
1999.
[Russel e Norvig, 95] - Russell, Stuart J. e Peter Norvig, “Artificial Intelligence: A
Modern Approach”, Englewood Cliffs, NJ: Prentice Hall, pp. 33, 1995.
[Sear, 03] – Sear, John, “RoboBase – Jonh Sear HomePage [Em Linha]”, Universidade
de Manchester, Inglaterra. [Consultado em 11/08/2003].
http://www.cs.man.ac.uk/~searj6/
[Sedaghat et al., 03] – Sedaghat, M. N.; Gholami, N.; Mirbagheri, B.; Afkanpour, A.;
Vaisipour, S.; Saffar, H. H.; Montaghami, V.; Shahbazi, M.; Tourzan, O. M.; Jeddi,
M.; Valinejad, A.; Motamedi, A.; Kangavari, M. ,“Caspian 2003 Presentation
Description”, 2003.
[Seligmann, 93] – Seligmann, D. D., “Interactive Intent-Based Illustration: Language for
3D Worlds”, Tese de Douturamento. Graduate School of Arts and Sciences,
Universidade de Columbia, Estados Unidos da América, 1993.
www1.cs.columbia.edu/~doree/IBIS/thesis.html
[Seligmann e Feiner, 91] – Seligmann, D. D. ; Feiner, S., “Automated of intent based 3D
illustrations”, Computer Graphics, 25, pp.123-132. 1991.
[Smith, Cypher e Spohrer, 94] - Smith, D. C.; A. Cypher ; J. Spohrer, "KidSim:
Programming Agents Without a Programming Language,", Communications of the
ACM, pp. 37, 7, 55-67, 1994.
[Spoelder et al., 00] - Spoelder, Hans J.W.; Renambot, Luc; Germans, Desmond; Bal,
Henri E.; Groen, Frans C.A., "Real-time Interaction in VR with a Distributed MultiAgent System", Vrije Universidade de Amesterdão, Holanda, 2000.
http://www.cs.vu.nl/~renambot/vr/papers/dist.ps.gz
131
[Spoelder et al., 99b] - Spoelder, Hans J.W.; Renambot, Luc; Germans, Desmond; Bal,
Henri E.; Groen, Frans C.A., "Man Multi-Agent Interaction in VR: a Case Study with
RoboCup", Vrije Universidade de Amesterdão, Holanda, 1999.
http://www.cs.vu.nl/~renambot/vr/papers/robocup99b.ps.gz
[Spoelder et al., 99a] - Spoelder, Hans J.W.; Renambot, Luc; Germans, Desmond; Bal,
Henri E.; Groen, Frans C.A., "Interactive and Collaborative Visualization of Robot
Soccer", Vrije Universidade de Amesterdão, Holanda, 1999.
http://www.cs.vu.nl/~renambot/vr/papers/robocup99.ps.gz
[Steele, 90] - Steele, Jr.and G. L, “Common Lisp the Language, Second Edition” , Digital
Press, 1990
[Teixeira e Santos, 03] - Teixeira, Cláudio e Santos, Johnny , “FC Portugal - Uma Equipa
da Liga de Simulação do Robocup”, Universidade de Aveiro, 2003.
[Turner et al., 91] - Turner, Russell; F.Balaguer; Gobbetti, Enrico; Thalmann, Daniel.
“Physically-Based Interactive Camera Motion Control Using 3D Input Devices”.
Computer Graphics International.pp. 135-145, 1991.
http://ligwww.epfl.ch/~thalmann/papers.dir/CGI91.pdf
[Watt, 93] - Watt, A., “3D Computer Graphics” Addison Wesley, 2nd Edição, 1993.
[Witkin et al.,90] - Witkin, Andrew; Gleicher, Michael; Welch, William, “Interactive
Dynamics”, Computer Graphics (Symposium on Interactive 3D Graphics), 1990.
http://www.cs.wisc.edu/graphics/Papers/CMU/interactive.pdf
[Witkin e Popovic, 95] - Witkin, Andrew; Popovic, Zoran, “Motion Warping”,
SIGGRAPH 95, Los Angeles, COMPUTER GRAPHICS Proceedings,August, 1995.
http://www.cs.berkeley.edu/~daf/games/webpage/motionpapers/warpage.pdf
[Wooldridge e Jennings, 95] - Michael J. Wooldridge and Nicholas R. Jennings.,
“Intelligent Agents: Theory and Practice”, Knowledge Engineering Review Vol. 10
Nº2, Cambridge University Press, 1995.
[Wooldridge e Jennings, 94] - Michael J. Wooldridge and Nicholas R. Jennings., “Agent
Theories, Architectures, and Languages: A Survey”, Workshop on Agent Theories,
Architectures and Languages, 11th European Conference on Artificial Intelligence,
Amsterdam, the Netherlands, 1994.
[Wooldridge, 98] - Michael Wooldridge. “Agent-based computing”. Interoperable
Communication Networks, 1(1):71–97, January 1998.
[Wooldridge, 99] - Wooldridge, Michael, “Intelligent Agents”, em Multiagent Systems:
A Modern Approach to Distributed Artificial Intelligence, editado por Gerhard Wei,
MIT Press, pp.27-77, 1999.
[Wooldridge, 02] - Michael Wooldridge. “Introduction to Multi-Agent Systems”, John
Wiley & Sons, Ltd, 2002.
132
[Wright e Sweet, 00] – Wright, Richard S. e Sweet, Jr. Michael, “OpenGL Super Bible”,
Waite Group Press, 2nd Edition, 2000.
[WrightEagle, 03] – “Wright Eagle - HomePage [Em Linha]” , Laboratório Multi-Agent
Systems Lab da Universidade da Ciência e Tecnologia da China. [Consultado em
11/09/2003].
http://wrighteagle.org/en/robocup/index.php
[Xing et al., 02] – Xing, Xuan; Li, Qingrui; Liu, Chang; Yang, Bin; Chen, Xiaopinp, “An
Intuitive 3D Monitor System with Automatic Commentary for RoboCup 2002”, AI
Center, University of Science and Technology of China, Descrição da equipa para o
RoboCup-02, 2002.
[Young e Malcolm, 98] - Young, Peter e Munro, Malcolm, “Visualising Software in
Virtual Reality”, International Workshop on Program Comprehension, 1998.
http://www.dur.ac.uk/~dcs1elb/youngiwpc98.ps
CAPÍTULO 10: ANEXOS
133
10 ANEXOS
Anexo A – Entrevista com José Paulo Valente
Realizador de programas da RTP
Qual o critério do realizador para filmar um jogo de futebol?
O realizador define todos os planos para os operadores. Estes, por sua vez, apenas executam as
suas tarefas com pouca autonomia. Ou seja, apenas se limitam a ajustar a visualização para que a
bola fique ligeiramente centrada e não apareçam jogadores “cortados” na visualização.
Num campo de futebol quais são os tipos de câmara existentes e suas finalidades?
Existem as câmaras de grandes planos que têm como objectivo acompanhar os jogadores. No
entanto, as câmaras por trás das balizas ou de lado pretendem filmar sempre as grandes áreas. Em
algumas filmagens também existe uma câmara fixa sem operador que dá uma imagem “bonita”,
designada de Beautyshot. Como exemplo temos a visualização em perspectiva do estádio.
Como se procede à filmagem de um jogo em câmaras de grande plano?
Filma-se sempre a bola (exceptuando-se alguns lances) centrando esta no ecrã com um pequeno
desvio tendo em conta a deslocação da mesma, de forma a proteger o operador de mudanças
bruscas na direcção da mesma.
Quais são as ordens enviadas pelo realizador ao operador?
São ordens previamente definidas para os planos a filmar que têm como informação a região do
cenário, a importância a dar a cada actor e a indicação da abertura do plano.
Que comunicação existe entre os diferentes operadores?
Os operadores recebem apenas ordens e têm pouca comunicação com os outros operadores. A
única comunicação existente entre os operadores é no sentido de ajustar os planos. Esta
sincronização depende das características do cenário a filmar.
Como é efectuada a escolha da melhor imagem a visualizar pelo telespectador?
Normalmente os planos estão definidos, logo não é difícil escolher o plano. Dos planos que
apresentam várias câmaras escolhe-se a que apresenta melhor visualização.
Como se sabe se uma imagem está boa ou não no cenário do futebol?
Uma boa imagem é definida pela posição da bola no ecrã (normalmente centrada) e tentar que os
jogadores com mais importância na jogada e jogo estejam sempre enquadrados na imagem,
evitando que os jogadores fiquem com o corpo cortado.
É importante que o plano de filmagem na mudança de câmara seja sempre o mesmo
(sincronização das câmaras)?
Em alguns cenários é importante em outros não. No caso do futebol faz sentido dois tipos de
filmagem. Um é criar uma alternância de planos (mais próximo e mais distante para dar
dinamismo à filmagem), o outro é manter sempre o mesmo plano.
Quais os comandos efectuado pelos operadores para manusearem a câmara?
134
Os comandos básicos são: os horizontais (pan), verticais (tilt), rotação (roll) e abertura/fecho do
zoom.
As repetições são efectuadas com as mesmas câmaras de filmagem do jogo?
Normalmente estão associadas câmaras específicas para as repetições, mas recorre-se muitas
vezes as câmaras de filmagem do jogo também para visualizar as repetições.
Cada cenário apresenta termos de regiões próprios para a filmagem?
Sim, é verdade, cada cenário tem as suas próprias regiões previamente definidas para que o
realizador e operadores se entendam nas áreas do cenário a filmar.
Na possibilidade de existirem câmaras virtuais num cenário de futebol, quais são os planos
de maior interesse?
Os planos de maior interesse são vários. Um deles é o acompanhamento da bola com uma
pequena elevação. Outro plano é fixar a câmara no meio campo, a uma determinada altura, e
acompanhar sempre a bola. Outro plano interessante é colocar uma câmara que segue por trás o
acompanhamento de um jogador. Para finalizar, a utilização de uma câmara sobre um carril para
acompanhar superiormente o estádio, já que dá sempre um plano panorâmico bastante
interessante.
135
Anexo B – Soccerserver estados do jogo
Um jogo de futebol quando esta a decorrer no servidor soccerserver (versão 7.0)
encontra-se sempre num determinado estado de jogo, os estados possíveis são:
Versão 1: Estado gerais de um jogo no servidor
PM_Null
PM_BeforeKickOff
PM_TimeOver
PM_PlayOn
PM_KickOff_Left
PM_KickOff_Right
PM_KickIn_Left
PM_KickIn_Right
PM_FreeKick_Left
PM_FreeKick_Right
PM_CornerKick_Left
PM_CornerKick_Right
PM_GoalKick_Left
PM_GoalKick_Right
PM_AfterGoal_Left
PM_AfterGoal_Right
PM_Drop_Ball
PM_OffSide_Left
PM_OffSide_Right
// Comando não existente
// Colocação de bola em jogo
// Jogo terminado
// Jogo decorrendo
// Reposição bola ao centro, início de jogo ou golo
// Reposição bola ao centro, início jogo ou golo
// Colocação bola em jogo pela equipa da esq.
// Colocação bola em jogo pela equipa da direita.
// Falta a favor da equipa da esquerda
// Falta a favor da equipa da direita
// Pontapé de canto a favor da equipa esquerda
// Pontapé de canto a favor da equipa direita
// Pontapé de baliza para a equipa da esquerda
// Pontapé de baliza para a equipa da direita
// (não utilizado no Virtual3D)
// Fora de jogo a favor da equipa da esquerda
// Fora de jogo a favor da equipa da direita
Versão 2: Estados adicionados para visualizador 3D e para comentadores.
PM_PK_Left
PM_PK_Right
PM_FirstHalfOver
PM_Pause
PM_Human
PM_Foul_Charge_Left
PM_Foul_Charge_Right
PM_Foul_Push_Left
PM_Foul_Push_Right
PM_Foul_MultipleAttacker_Left
PM_Foul_MultipleAttacker_Right
PM_Foul_BallOut_Left
PM_Foul_BallOut_Right
PM_MAX
// Pausa no jogo.
// Falta carga em jogador (esquerda)
// Falta carga em jogador (direita)
// Falta empurrão em jogador (esquerda)
// Falta empurrão em jogador (direita)
// Último elemento da estrutura
Tabela 12: Soccerserver estados do jogo
136
Anexo C – Estrutura dos ficheiros Log do Servidor
VERSÃO 1
Logfile da versão 1 (versões de servidor até 4.16) apresenta no ficheiro a informação
consecutivamente da estrutura dispinfo_t. Devido à estrutura dispinfo_t conter uma união
(C++) de várias estruturas de dados, muitos bytes ficam por excesso, conduzindo a uma
dimensão enorme do ficheiro. Devido a este problema surgiu a versão 2.
VERSÃO 2
O formato da versão 2 tenta evitar a redundância de dados, assim o formato apresenta a
seguinte descrição:
CABEÇA DO FICHEIRO - A cabeça do ficheiro é utilizada para saber qual a versão do ficheiro de
log. Os três caracteres iniciais do ficheiro ‘ULG’ indicam que o ficheiro foi gerado em
Unix, caso contrario assume-se que a versão é a 1.
VERSÃO DO FICHEIRO – Versão do formato do ficheiro de log, exemplo 2.
CORPO DO FICHEIRO - O corpo do ficheiro contem sempre antes da estrutura um byte de controlo
que indica que parte da estrutura dispinfo_t se segue. Os bytes possíveis e a respectiva
estrutura são os seguintes:
● SHOW_MODE – Estrutura seguinte é a showinfo_t.
● MSG_MODE – Os próximos bytes são, byte especificando o tipo de mensagem, byte com a
dimensão da mensagem e por fim a mensagem em formato de cadeia de caracteres.
VERSÃO 3
A versão 3 contém informação dos parâmetros dos jogadores e optimiza espaço. O formato
apresenta assim a seguinte descrição:
CABEÇA DO FICHEIRO – Igual a versão 2, o início do ficheiro começa com ‘ULG’.
VERSÃO DO FICHEIRO – Versão do formato do ficheiro de log, exemplo 3.
CORPOS DO FICHEIRO – O corpo contêm um byte de referência que indicam sempre a estrutura de
dados que se segue, isto sucessivamente. A codificação para os diferentes bytes de
controlo possíveis com a respectiva estrutura é a seguinte:
● PM_MODE – Seguido de carácter que indica o modo de jogo, o carácter só é escrito
quando o modo de jogo muda.
● TEAM_MODE – Duas estruturas de equipa (team_t) da esquerda e direita.
● SHOW_MODE – Estrutura short_showinfo_t2 que especifica a bola e as posições e estados
dos jogadores.
● MSG_MODE – Byte especificando o tipo de mensagem de seguida vem novo byte com a
dimensão da mensagem e por fim a mensagem em formato de cadeia de caracteres.
● PARAM_MODE - Estrutura server_params_t com os parâmetros do servidor. Esta estrutura
só é escrita uma vez no início do ficheiro de log.
● PPARAM_MODE – Estrutura player_params_t com os parâmetros dos jogadores. Esta
estrutura só é escrita uma vez no início do ficheiro de log.
● PT_MODE – Estrutura player_type_t com os parâmetros dos tipos de jogadores. Esta
estrutura só é escrita uma vez no início do ficheiro de log.
* Os valores das coordenadas tais como x e y são em metros multiplicados por
SHOWINFO_SCALE2.
* Os valores de deltax e deltay são em metros/ciclo multiplicados por SHOWINFO_SCALE2.
* Outros valores como staminia, effort e recovery são também multiplicados por
SHOWINFO_SCALE2.
137
Anexo D – Informação do Servidor para Visualizador
Quando o visualizador é conectado ao servidor, este envia informação ciclicamente para o
visualizador. O servidor pode enviar informação em dois formatos distintos (versão 1 e
versão 2), o formato é especificado nos argumentos de inicialização do servidor.
VERSÃO 1
O servidor envia ciclicamente (100 ms) uma estrutura de dados dispinfo_t do tipo união
(C++) na qual é composta por três tipos diferente de informação:
● showinfo_t - Informação necessária para desenhar o cenário;
● msginfo_t - Contem as mensagens dos jogadores e do árbitro;
● drawinfo_t - Informação para o visualizador desenhar círculos, linhas ou pontos.
typedef struct {
short board;
char message[2048];
} msginfo_t;
// Estrutura de mensagens.
// Indica o tipo de mensagem (*).
// Mensagem.
// Fim da estrutura.
(*) msginfo_t.board – A mensagem cujo o tipo é MSG_BOARD (1), indica que é uma mensagem do
árbitro do jogo, se a mensagem for LOG_BOARD (2) então é uma mensagem para jogadores de
outro jogador.
typedef struct {
// Estrutura para desenhar cenário (não utilizada).
short mode;
// Determina que estrutura union está a utilizar.
union {
pointinfo_t pinfo;
// Início da estrutura union.
// Estrutura para desenhar um ponto.
circleinfo_tcinfo;
Lineinfo_t linfo;
// Estrutura para desenhar um círculo.
// Estrutura para desenhar uma linha.
} object;
} drawinfo_t;
// Fim da estrutura union.
typedef struct {
// Estrutura genérica de visualização.
short mode ;
union {
showinfo_t show;
msginfo_t msg;
drawinfo_t draw;
} body;
} dispinfo_t;
// Determina qual a estrutura union que está a utilizar.
// Início da estrutura union.
// Informação da estrutura para desenhar cenário.
// Estrutura para desenhar cenário (não utilizada).
VERSÃO 2
O Servidor e o logplayer enviam a nova estrutura de dados dispinfo_t2 para o visualizador
em vez da estrutura dispinfo t da versão 1. Esta nova estrutura inclui agora 5 tipos de
dados, que são:
● showinfo_t2 - Informação necessária para desenhar o cenário;
● msginfo_t - Contem as mensagens dos jogadores e do árbitro;
● player_type_t - Informação que descreve as diferentes capacidades do jogador;
● server_params_t – Parâmetros da configuração do servidor;
● player_params_t – Parâmetros do jogador.
138
typedef struct {
// Estrutura da bola.
long x;
// Coordenada x da posição da bola.
long y;
long deltax;
// Coordenada y da posição da bola.
// Deslocação da bola no sentido x.
long deltay;
} ball_t;
// Deslocação da bola no sentido y.
typedef struct {
// Estrutura que define o novo jogador.
short modo;
// Estado do objecto
short type;
long x;
// Tipo de jogador
// Posição x no campo.
long y;
long delayx;
// Posição y no campo.
//
long delayy;
long body_angle;
//
// Ângulo do corpo do jogador.
long head_angle;
long view_width;
// Ângulo da cabeça do jogador.
// Abertura do ângulo de visão do jogador.
short view_quality;
long stamina;
// Qualidade de visão do jogador.
// Energia.
long effort;
long recovery;
// Esforço.
// Recuperação.
short kick_count;
short dash_count;
// Contador utilizado no chuto.
// Contador utilizado na potência de deslocação.
short turn_count;
short say_count;
// Contador utilizado na mudança de orientação.
// Contador utilizado no envio de mensagem.
short tneck_count;
short catch_count;
// Contador utilizado na orientação da cabeça
// Contador utilizado na acção de apanhar a bola.
short move_count;
// Contador utilizado no movimento.
short chg_view_count;
} player_t;
// Contador utilizado na mudança de visão.
typedef struct {
// Estrutura que contém informação para desenhar cenário.
char pmode;
team_t team[2];
// Modo em que se encontra o jogo, (Anexo B).
// Informação das equipas a esquerda e direita.
ball_t ball;
player_t pos[22];
// Posição e informação da bola (ver abaixo).
// Posição de todos os jogadores.
short time;
} showinfo_t2;
// Tempo de jogo.
A estrutura msginfo_t mantêm os mesmos dados que na versão anterior. As estruturas
server_params_t e player_params_t não são utilizadas nesta tese, logo não são explicadas.
typedef struct {
// Determina o objecto da estrutura
union a utilizar.
short mode;
// (NO_INFO, SHOW_MODE,MSG_MODE,BLANK_MODE,
union {
showinfo_t2 show;
// PT_MODE, PARAM_MODE, PPARAM_MODE )
// Estrutura de informação para desenhar cenário.
msginfo_t msg;
player_type_t pinfo;
// Estrutura do tipo de jogador.
server_params_t params;
player_params_t params;
// Parâmetros do servidor.
// Parâmetros dos jogadores.
} body;
} dispinfo_t2;
typedef struct {
139
// Estrutura que define as capacidades do jogador.
short id;
// Código de identificação do jogador.
long player_speed_max;
long stamina_max;
// Velocidade máxima do jogador.
// Máximo de energia possível num jogador.
long stamina_inc_max;
// Valor de energia a incrementar em cada ciclo.
long player_decay;
long inertia_moment;
// Decadência da velocidade do jogador.
// Momento de inércia aplicar em cada jogador.
long dash_power_rate;
long player_size;
// Factor que multiplica pela potência de aceleração.
// Dimensão do raio que define o tamanho do jogador.
long kickable_margin;
long kick_rand;
// Margem da área na qual a bola pode ser chutada.
// Valor de ruído adiciona ao chuto.
long extra_stamina;
long effort_max;
// Energia extra.
// Esforço máximo.
long effort_min;
long sparelong1;
// Esforço mínimo.
// Variável para ser utilizada no futuro.
long sparelong2;
long sparelong3;
long sparelong4;
long sparelong5;
long sparelong6;
long sparelong7;
long sparelong8;
long sparelong9;
} player_type_t;
140
Anexo E – Algoritmo LookAt segundo Jimm Blinn
ALGORITMO LookAt( camPos, Target, camUp )
RETORNA projectionMatix – Matriz de projecção
PARÂMETROS
CVector3D camPos – Posição actual (x, y, z) da câmara
CVector3D Target – Posição (x, y, z) do alvo (normalmente a bola)
CVector3D camUp – Vector de orientação da câmara. Valor defeito (0,1,0)
{
// Calcular o Vector At designado de F e normalizar
CVector3D F = target - camPos;
F.Normalize();
// Calcular o Vector Right designado S e normalizar
camUp.Normalize();
S.Cross(F, camUp);
S.Normalize();
// Calcular o Vector Up designado U e normalizar
CVector3D U;
U.Cross(S, F);
U.Normalize();
// Construção da matriz de projecção (4x4)
projectionMatix.m4x4[0][0] = S.x
projectionMatix.m4x4[1][0] = S.y
projectionMatix.m4x4[2][0] = S.z
projectionMatix.m4x4[3][0] = 0.0
projectionMatix.m4x4[0][1] = U.x
projectionMatix.m4x4[1][1] = U.y
projectionMatix.m4x4[2][1] = U.z
projectionMatix.m4x4[0][2] = F.x
projectionMatix.m4x4[1][2] = F.y
projectionMatix.m4x4[2][2] = F.z
// Retornar a matriz de projecção que colocar o objecto no centro do ecrã.
RETORNA projectionMatix
}
Algoritmo 1: Calcular matiz de projecção LookAt
141
Anexo F – Estrutura de decisão do agente realizador
ALGORITMO ComportamentoRealizador(Estado_Jogo,PosBola,Stats)
RETORNA VarRegiao – Retorna a região a filmar.
PARÂMETROS
Estado_Jogo – Estado em que se encontra o jogo.
PosBola – Posição 3D do agente bola no cenário.
Stats – Estatísticas do jogo (enviada pelo agente analisador).
{
// A variável VarRegião define o local para onde o operador deve focar a câmara.
VarRegiao = REGION_NONE
// Definir as diferentes regiões de filmagem dependendo do estado do jogo.
SE Estado_Jogo = PM_CornerKick_Left ENTÃO VarRegiao = REGION_AREA_LEFT
SE Estado_Jogo = PM_CornerKick_Right ENTÃO VarRegiao = REGION_AREA_RIGHT
SE Estado_Jogo = PM_GoalKick_Left OU Estado_Jogo = PM_Penalty_Kick_Left ENTÃO
VarRegiao = REGION_AREA_LEFT
SE Estado_Jogo = PM_GoalKick_Right OU
VarRegiao = REGION_AREA_RIGHT
Estado_Jogo = PM_Penalty_Kick_Right ENTÃO
// Se alguma região seccionada pelo estado do jogo então retorna a região.
SE VarRegiao <> REGION_NONE ENTAO RETORNA VarRegiao
// Verificar a região onde se encontra a bola no campo de futebol.
// As coordenadas utilizadas são as definidas no cenário.
P = PosBola
SE P.X> 917.5 E P.X<= 982.5 E P.Z>704.5 E P.Z<769.5 ENTÃO VarRegiao =REGION_CENTER
SE P.X> 790.5 E P.X<= 841.5 E P.Z>667.0 E P.Z<807.0 ENTÃO VarRegiao =REGION_AREA_LEFT
SE P.X>1058.5 E P.X<=1109.5 E P.Z>667.0 E P.Z<807.0 ENTÃO VarRegiao =REGION_AREA_RIGHT
SE P.X> 915.0 E P.X<= 985.0 E P.Z>633.5 E P.Z<840.5 ENTÃO VarRegiao =REGION_MIDDLE
SE P.X> 985.0 E P.X<=1055.0 E P.Z>633.5 E P.Z<840.5 ENTÃO VarRegiao =REGION_MIDDLE_LEFT
SE P.X> 845.0 E P.X<= 915.0 E P.Z>633.5 E P.Z<840.5 ENTÃO VarRegiao =REGION_MIDDLE_RIGHT
// Atribuir valores percentuais das estatísticas de localização de bola no decorrer
// do jogo de futebol a variáveis.
SLLeft = Stats.GetStatsLocalBallLeft()
SLRight = Stats.GetStatsLocalBallLRight ()
SLMiddle = Stats.GetStatsLocalBallLMiddle()
// Calcular a região dependente estatística do jogo.
//
//
SE
SE
Se a bola se encontrar na zona central do campo com fraca probabilidade de se lá
manter então vamos assumir a zona com maior probabilidade.
VarRegiao = REGION_MIDDLE E SLLeft> 50 ENTAO VarRegiao = REGION_MIDDLE_LEFT
VarRegiao = REGION_MIDDLE E SLRight> 50 ENTAO VarRegiao = REGION_MIDDLE_RIGHT
SE VarRegiao = REGION_MIDDLE_RIGHT E SLMiddle> 50 ENTAO VarRegiao = REGION_MIDDLE
SE VarRegiao = REGION_MIDDLE_LEFT E SLMiddle> 50 ENTAO VarRegiao = REGION_MIDDLE
// Retornar região definda pelo realizador.
RETORNA VarRegiao
}
Algoritmo 2: Comportamento situação/acção do realizador
142
Anexo G – Suavizar movimento dos agentes no cenário
ALGORITMO MoveAgente ( fFPS, pAgent, fAnimPos, fAnimElapsed
PARÂMETROS
)
fFPS – Frame Rate, imagens geradas pela aplicação por segundo.
pAgent – Ponteiro para a referência do agente em memória.
fAnimPos – Posição intermédia da suavização, assume valor entre [0..1]
fAnimElapsed – Tempo que passou deste posicionamento do agente (ciclo soccerserver).
{
// As variáveis vLastPosAg e vTargPosAg assumem a posição alvo e a posição anterior
//
impostas pelo ambiente, já as variáveis fTargOri e fLastOri assumem a orientação do //
agente impostas também pelo ambiente.
vLastPosAg = pAgent->GetLastAnimPlayer()
vTargPosAg = pAgent->GetTargetAnimPlayer()
fTargOri = pAgent->GetOriTargetAnimPlayer()
fLastOri = pAgent->GetOriLastAnimPlayer()
// Vector de deslocação x,y,z do agente tendo em contas a posição actual e a anterior.
vDelta = ( vTargPos.x-vLastPos.x,vTargPos.y-vLastPos.y,vTargPos.z-vLastPos.z )
// Processar a suavização do movimento e orientação do agente.
// timeCycle – tempo de ciclo para o frame rate aplicacional num determinado momento.
timeCycle = (1000.0f/fFps)
fAnimPos = fAnimPos - timeCycle
SE( fAnimPos > 0.0f ) ENTÃO {
fAnim = 1.0f-(fAnimPos/fAnimElapsed)
if( fAnim > 1.0 ) fAnim = 1.0f
// Calcular a nova posição x,y,z para a animação do movimento.
AnimPos.x = vLastPosAg.x + vDelta.x*fAnim
AnimPos.y = vLastPosAg.y + vDelta.y*fAnim
AnimPos.z = vLastPosAg.z + vDelta.z*fAnim
// Calcular a nova orientação suavizada do agente pelo caminho mais curto.
fdeltaAnim = 0;
fdeltaAnim1 = fTargOri-fLastOri
fdeltaAnim2 = fLastOri-fTargOri
SE( fabs(fdeltaAnim1) > fabs(fdeltaAnim2) ) ENTÃO fdeltaAnim = fdeltaAnim2
SENÃO fdeltaAnim = fdeltaAnim1
AnimOri = m_fLastOri + fdeltaAnim*fAnim
}
SENAO {
// chegou-se ao tempo de ciclo imposto pelo servidor, vai-se posicionar no alvo.
AnimPos = vTargPosAg
AnimOri = fTargOri
}
// Afectação da nova posição e orientação do agente.
pAgent->SetPosition( AnimPos )
pAgent->SetOrientation ( AnimOri )
}
Algoritmo 3: Suavizar movimento e orientação dos agentes jogador e bola
143
Anexo H – Algoritmo de focagem do operador
ALGORITMO AutoFocus ( PosCam,PosBall,iZoomDetail,RegionField, bCamSync, fValueSyncCam,
fAvrgSyncCam )
RETORNA fZoomCam – Retorna factor de zoom aplicar na imagem.
PARÂMETROS
PosCam – Posição da câmara no mundo.
PosBall – Posição actual da bola no mundo.
iZoomDetail – Detalhe do zoom aplicar no enquadramento da imagem.
RegionField – Definição da região a filmar imposta pelo realizador.
bCamSync – Indica se sincronização de câmara com os outros operadores.
fValueSyncCam – Valor actual de sincronização de câmara.
fAvrgSyncCam – Media de sincronização das outras câmaras.
{
// Definir caractristica do volume de visualização.
Up( 0, 1, 0 )
Eye( PosCam.x, PosCam.y, PosCam.z )
At( PosBall.x, PosBall.y, PosBall.z )
fFar = DEFAULT_FAR_CLIP
fNear = DEFAULT_NEAR_CLIP
// Definir contadores os vários tipos de detalhe do zoom aplicar na visualização.
izoomBest =
-1 // guarda a melhor posição do zoom encontrado na geração de testes.
fzoomMaxQt = 0.0
iSyncBest = -1
// guarda o melhor valor do zoom encontrado na geração de testes.
// guarda a melhor posição do zoom para ajustar a sincronização.
fSyncBestValue=0
// guarda o melhor valor do zoom para ajustar a sincronização.
// Definir os vários tipos de detalhe do zoom aplicar na visualização.
fmaxZoom = this->GetMaxZoom()
fminZoom = this->GetMinZoom()
fZoomLow[6] ={-2.0f,-1.0f,0.0f,+1.0f,+2.0f,-99}
fZoomMed[10]={-2.0f,-1.5f,-1.0f,0.5f,0.0f,0.5f,1.0f,1.5f,2.0f,-99}
fZoomHi[14]={-3.0f,-2.5f,-2.0f,-1.5f,-1.0f,0.5f,0.0f, 0.5f,1.0f,1.5f,2.0f,2.5f,3.0f,
-99}
SE( iZoomDetail = 1 ) ENTÃO fZoomDetail = fZoomLow
SENÃO SE( iZoomDetail = 3 ) fZoomDetail = fZoomHi
SENÃO fZoomDetail = fZoomMed
// Analisar os factores de zoom aplicar a imagem actual para o cenário actual.
K = 0
fQtVisNew = 0
iCntVisNew = 0
fZoomCam = this->GetZoom()
ENQUANTO( fZoomDetail[K] <> -99 ) {
// Calcular factor do zoom a testar tendo em conta o zoom actual e o detalhe do zoom.
fTestZoom = fZoomCam + fZoomDetail[K]
SE( fTestZoom > fmaxZoom ) ENTAO fTestZoom = fmaxZoom
SENAO SE( fTestZoom < fminZoom ) ENTAO fTestZoom = fminZoom
144
// Calcular factor de fov do volume para os valores do zoom a testar.
// Calcular o volume de visualização utilizando a matriz de projecção.
fFOV = ConvZoomToFOV( fTestZoom, DEFAULT_WINX, DEFAULT_WINY );
ViewProj = CalcularMatrizProjeccao ( Eye, At, Up, fNear, fFar, fFov)
Frustum = CalcularFrustm( ViewProj )
// Verifica qualidade de visualização do ponto de interesse (bola) p/ sincronização.
// Resumindo, verifica qual o melhor zoom q sincroniza o plano com as outas câmaras.
bboxball = m_pMyAgBall->GetBBox()
fValSyncCamBall = CalcQualityVisualObj( bboxball, Frustum, NULL )
SE( |fValSyncCamBall-m fAvrgSyncCam| < fSyncBestValue ) ENTÃO
{ fSyncBestValue = |fValSyncCamBall-m_fAvrgTargSyncCamera|
iSyncBest = k
}
// Verificar a região imposta pelo realizador para enquadrar a imagem.
SE( RegionField <> REGION_NONE ) ENTÃO {
fPri = RegionField.GetPriority()
fQtVisNew = fQtVisNew + CalcularQualidadeImagem( RegionField,fPri )
iCntVisNew = iCntVisNew + 1
}
// analisar a qualidade de visualização dos actores do cenário. todos os actores que
// não estão no volume são afectados com uma flag para não serem processados.
J = 0
aAgentes = RetornarListaAgentes()
PARA( J < TOTAL(aAgentes) ) ENTÃO {
BBox = aAgentes[J].GetBoundingBox()
SE( Frustum.CubeInFrustum( BBox () ) ENTÃO {
fPri = aAgentes[J].GetPriority()
fQtVisNew = fQtVisNew + CalcularQualidadeImagem( BBox, fPri )
iCntVisNew = iCntVisNew + 1
aAgentes.SetVisible( TRUE )
}
SENÃO aAgentes.SetVisible( FALSE )
J = J + 1
}
// calcular o melhor zoom encontrado
SE( fQtVisNew > fzoomMaxQt ) ENTÃO {
izoomBest = K;
fzoomMaxQt = fQtVisNew;
}
SE( fZoomDetail[k] == 0 ) ENTÃO idZoomCenter = k
SENÃO if( fZoomDetail[k] < 0 ) ENTÃO fzoomMaxQtDn=(fzoomMaxQtDn+fQtVisNew)*0.5f
SENÃO fzoomMaxQtUp=(fzoomMaxQtUp+fQtVisNew)*0.5f
K = K + 1
}
145
// Analisa se o zoom é valido então processar o zoom.
SE( fzoomBest <> -1 && fZoomDetail[fzoomBest] <> 0.0 ) ENTÃO {
// Se sincronização então calcular o factor de zoom com a média ponderada da
// melhor imagem e da melhor sincronização.
fincZoom = fZoomDetail[fzoomBest];
SE( bCamSync && iSyncBest != -1 ) ENTÃO {
fPerSy = 0.1
fPerQi = 1.0f - fPerSy
// Percentagem factor syncronicação.
// Percentagem factor qualidade.
fincZoom = fZoomDetail[fzoomBest]*fPerQi+fZoomDetail[iSyncBest]*fPerSy)*0.5f
}
// Enquadrar o zoom nos limites correctos. Se o factor de zoom aplicar for muito
// pequeno então é ignorado.
setZoom = fZoomCam+fincZoom;
SE( setCam > fmaxZoom ) ENTÃO setCam = fmaxZoom
SENAO SE( setCam < fminZoom ) ENTÃO setCam = fminZoom
SE( fabs(setZoom-fZoomCam) >= 0.5f ) ENTÃO fZoomCam = setZoom
}
// Verificar se o zoom está nos limites desejados.
SE( fZoomCam > fmaxZoom ) ENTÃO fZoomCam = fmaxZoom
SENAO SE( fZoomCam < fminZoom ) ENTÃO fZoomCam = fminZoom
// Retornar valor final do zoom.
RETORNAR fZoomCam
}
Algoritmo 4: Algoritmo de focagem do operador de câmara
146
Anexo I – Mensagens de agentes no Virtual3D
Mensagem
Descrição das mensagens
MSG_NONE
Mensagem nula
MSG_AGENT_START
Iniciar um agente cameraman pelo realizador
MSG_AGENT_STOP
Parar um agente cameramam pelo realizador
MSG_AGENT_SETPOS
Especificar a posição do agente no mundo
MSG_AGENT_SEND_HEURISTIC
Envio da heurística da qualidade de imagem para o realizador
MSG_AGENT_STATS_PTR
Envio das estatísticas do agente analisador para o realizador
MSG_AGENT_STATS_RESET
Iniciar a contagem estatística do agente analisador
MSG_AGENT_STATS_MODE
Permite especificar quais as estatísticas a mostrarem no ecrã
MSG_AGENT_SET_CAMERA
Selecionar câmara a visualizar no periférico de saida
MSG_AGENT_CFG_CAMERA
Envio da configuração da câmara para o operador
MSG_AGENT_RESET_CAMERA
Inicialização dos valores da câmara
MSG_AGENT_RESET_HEURISTIC
Inicializar as médias das heurísticas utilizadas pelo cameraman
MSG_AGENT_AUTO_CAMERA
Realização das câmaras em modo inteligente
MSG_AGENT_AUTO_ZOOM
Especificar que a visualização vai utilizar zoom automático
MSG_AGENT_ZOOM_METHOD
Especificar qual o método a utilizar de zoom (melhor média ou
melhor valor)
MSG_AGENT_ZOOM_DETAIL
Especificar o detalhe do zoom (fraco, médio, alto)
MSG_AGENT_ZOOM_DISTANCE
Especificar distância de focagem da câmara ao ponto de
interesse
MSG_AGENT_AUTO_LOOKAT
Especificar que a câmara têm focar permanentemente o ponto de
interesse (bola)
MSG_AGENT_CAMERA_PTR
Indicar a posição em memória onde se encontra o agente
MSG_AGENT_CAMERA_PAN
Indicar o valor a incrementar na rotação horizontal (pan) na
câmara selecionada
MSG_AGENT_CAMERA_TILT
Indicar o valor a incrementar na rotação vertical (tilt) na câmara
selecionada
MSG_AGENT_CAMERA_ZOOM
Indicar o valor a incrementar do zoom na câmara selecionada
MSG_AGENT_REGION_DECISION
Especificar a utilização de regiões de visualização selecionadas
pelo realizador
MSG_AGENT_SET_REGION
Indicar ao camaraman qual a região a focar com a câmara
MSG_AGENT_SYNC_CAMERA
Especificar que se pretende sincronizar imagem e envio do seu
estado actual de sincronização
MSG_AGENT_REPLAY_MODE
Indicar que se utiliza o modo de repetições
MSG_AGENT_RENDER
Indicar aos agentes que vão ser renderizados.
MSG_AGENT_RENDER_ST_BBOX
Indicar que o agente deve mostrar a sua caixa de colisão
MSG_AGENT_RENDER_ST_WIRE
Indicar ao agente deve mostrar a sua malha gráfica da estrtutura
MSG_AGENT_SET_PRIORITY
Atribuir uma prioridade ao agente
MSG_AGENT_GET_PRIORITY
Pedir ao agente que ele envie a sua prioridade
MSG_AGENT_SEND_PRIORITY
Envio da prioridade
Tabela 13: Mensagens de comunicação entre agentes do Virtual3D
147
Anexo J – Troca de mensagens entre agentes
Ambiente ► Jogador/Bola:
Realizador ► Cameraman:
MSG_AGENT_SETPOS
MSG_AGENT_START
MSG_AGENT_CFG_CAMERA
Utilizador ► Realizador:
MSG_AGENT_AUTO_ZOOM
MSG_AGENT_STATS_RESET
MSG_AGENT_RESET_CAMERA
MSG_AGENT_STATS_MODE
MSG_AGENT_SET_CAMERA
MSG_AGENT_AUTO_CAMERA
MSG_AGENT_AUTO_ZOOM
MSG_AGENT_SET_REGION
Cameraman ► Cameraman:
MSG_AGENT_REGION_DECISION
MSG_AGENT_SYNC_CAMERA
MSG_AGENT_REPLAY_MODE
MSG_AGENT_RENDER_ST_BBOX
Cameraman ► Realizador:
MSG_AGENT_RENDER_ST_WIRE
MSG_AGENT_SEND_HEURISTIC
MSG_AGENT_CAMERA_PTR
Analisador ► Realizador:
Realizador ► Jogador/Bola:
MSG_AGENT_STATS_PTR
MSG_AGENT_SET_PRIORITY
MSG_AGENT_RENDER
Analisador ► Público:
MSG_AGENT_STATS_PTR
Jogador/Bola ► Cameraman:
MSG_AGENT_SEND_PRIORITY
Cameraman ► Jogador/Bola:
MSG_AGENT_GET_PRIORITY
Tabela 14: Troca de Mensagens entre os Agentes
148
Anexo L – Criar o volume de visualização
ALGORITMO CreateFrustum( ViewProj )
RETORNAR m_Plane[6] – Retornar a configuração dos seis planos.
PARÂMETROS
ViewProj – Matriz de visualização da projecção.
{
// Definir os seis planos do volume com a matriz de visualização da projecção
// Para simplificar Mtx assume os valores da matriz utilizada como argumento.
Mtx = ViewProj
// Plano esquerdo (left)
m_Plane[_Left_].SetNormal( (Mtx.14+Mtx.11),(Mtx.24+Mtx.21), (Mtx.34+Mtx.31) )
m_Plane[_Left_].SetDistance( (Mtx.44+Mtx.41) )
// Plano direito (right)
m_Plane[_Right_].SetNormal( (Mtx.14-Mtx.11),(Mtx.24-Mtx.21), (Mtx.34-Mtx.31) )
m_Plane[_Right _].SetDistance( (Mtx.44-Mtx.41) )
// Plano base (bottom)
m_Plane[_Bottom_].SetNormal( (Mtx.14+Mtx.12),(Mtx.24+Mtx.22), (Mtx.34+Mtx.32) )
m_Plane[_Bottom_].SetDistance( (Mtx.44+Mtx.42) )
// Plano topo (top)
m_Plane[_Top_].SetNormal( (Mtx.14-Mtx.12),(Mtx.24-Mtx.22), (Mtx.34-Mtx.32) )
m_Plane[_Top_].SetDistance( (Mtx.44-Mtx.42) )
// Plano anterior (near)
m_Plane[_Near_].SetNormal( (Mtx.14+Mtx.13),(Mtx.24+Mtx.23), (Mtx.34+Mtx.33) )
m_Plane[_Near_].SetDistance( (Mtx.44+Mtx.43) )
// Plano posterior (far)
m_Plane[_Far_].SetNormal( (Mtx.14-Mtx.13),(Mtx.24-Mtx.23), (Mtx.34-Mtx.33) )
m_Plane[_Far_].SetDistance( (Mtx.44-Mtx.43) )
// Normalizar os planos
PARA ii = _Left_ ATÉ _Far_ FAZER {
// Normalizar o plano
m_Plane[ii].Normalize()
// Determinar o ponto do plano através da distância e normais.
// A distância necessita ser negada.
Normal = m_Plane[ii].Normal()
Distance = m_Plane[ii].Distance()
PT = Normal * -1.0 * Distance;
m_Plane[ii].SetPoint( PT.x, PT.y, PT.z )
}
RETORNA m_Plane
}
Algoritmo 5: Criação do volume de visualização (ViewFrustum)
149
Anexo M – Métodos sobre o volume de visualização
ALGORITMO PointInFrustum ( Pt, m_Planes )
RETORNAR InFrustum – Retornar um valor lógivo de verdade se ponto dentro do volume.
PARÂMETROS
Pt – Ponto a verificar se esta dentro do volume.
M_Planes – Planos do volume de visualização.
{
// Testar a distancia do ponto Pt a todos os planos, se uma distancia negativa então o //
ponto está fora do plano.
PARA p = _Left_ ATÉ _Far_ FAZER {
SE m_Plane[p].DistanceToPlane(Pt) <= 0 ENTÃO RETORNA FALSO
}
// Se a distancia aos planos é sempre positiva então o ponto esta dentro do volume.
RETORNA VERDADE
}
ALGORITMO DistancePlanes ( Pt, m_Planes )
RETORNAR DistPlanes – Retornar a distancia aos planos no vector X,Y,Z.
PARÂMETROS
Pt – Ponto a verificar se esta dentro do volume.
M_Planes – Planos do volume de visualização.
{
// Calcular a distância do ponto Pt ao plano.
PARA p = _Left_ ATÉ _Far_ FAZER {
dist[p] = m_Plane[p].DistanceToPlane(Pt)
}
// Calcular a distância entre os planos laterais, de topo e o de aproximação.
DistPlanes.x = dist[_Right] – dist[_Left_];
DistPlanes.y
DistPlanes.z
= dist[_Top_] – dist[_Bottom_];
= dist[_Far_] – dist[_Near_];
// Retornar a distância aos planos.
RETORNA DistPlanes
}
Algoritmo 6: Métodos sobre o volume de visualização
150
Anexo N – Resultados
Tabela 15: Resultados da cooperação entre agentes para suavizar planos
Item
Cenário 1
Cenário 2
Cenário 3
Cenário 4
Cenário 5
Avg
Sync
Qi
Avg
Sync
Qi
Avg
Sync
Qi
Avg
Sync
Qi
Avg
Sync
Qi
Sem Sincronização
1,28
11,18
1,27
8,48
1,91
15,47
1,60
6,18
1,24
9,97
Com Sincronização
2,30
7,56
1,76
6,33
2,45
14,74
2,53
4,78
2,14
9,37
Tabela 16: Resultados de uma filmagem com menos câmaras
Item
Cenário 1
Avg
Sync
Cenário 2
Qi
Avg
Sync
Qi
Cenário 3
Avg
Sync
Cenário 4
Avg
Sync
Qi
Cenário 5
Avg
Sync
Qi
Qi
6 Câmaras Centrais
2,30
7,56
1,76
6,33
2,45
14,74
2,53
4,78
2,14
9,37
4 Câmaras Centrais
2,78
7,51
2,07
6,96
3,05
15,47
3,53
5,71
2,51
9,50
Tabela 17: Resultados de uma filmagem com e sem regiões
Item
Cenário 1
Avg
Sync
Cenário 2
Qi
Avg
Sync
Qi
Cenário 3
Avg
Sync
Cenário 4
Avg
Sync
Qi
Cenário 5
Avg
Sync
Qi
Qi
Com Regiões
2,30
7,56
1,76
6,33
2,45
14,74
2,53
4,78
2,14
9,37
Sem Regiões
2,29
3,03
1,94
3,26
2,85
5,58
2,64
3,80
2,13
6,99
Tabela 18: Qualidade de Imagem Versus Sincronização
Item
Cenário 1
Cenário 2
Cenário 3
Qualidade Image Versus
Sincronização
Avg
Sync
Qi
Avg
Sync
Qi
Avg
Sync
Qi
1,0 / 0,0
1,28
11,18
1,27
8,48
1,91
15,47
0,9 / 0,1
1,81
9,26
1,20
7,59
2,43
15,06
0,7 / 0,3
1,93
8,19
1,65
6,44
2,61
14,97
0,5 / 0,5
2,30
7,56
1,76
6,33
2,45
14,74
0,3 / 0,7
2,27
7,68
1,84
6,04
1,92
14,63
0,1 / 0,9
2,18
8,27
1,67
4,49
1,79
14,43
0,0 / 0,1
2,22
8,66
2,02
7,57
1,90
16,14
151
Anexo O – Manual de utilização do Virtual3D
O visualizador desenvolvido no âmbito desta tese é um sistema que permite a
visualização de jogos bidimensionais de futebol robótico simulado num ambiente
tridimensional incluindo animação e som. Como já foi dito anteriormente a coordenação
da visualização é suportada por uma arquitectura multi-agente. Na imagem 10.1 pode-se
ver mais uma vez o aspecto gráfico do Virtual3D desenvolvido.
Figura 10.1: Imagem geral do visualizador Virtual3D
Neste anexo pretende-se apresentar a melhor forma de interagir com o sistema
implementado. Indicam-se as funcionalidades composição da informação e comandos
permitidos pelo Virtual3D. Constituiu preocupação tornar a interacção do visualizador
com o utilizador o mais simples e acessível possível. Para isso criou-se um menu
principal que está permanentemente activo, foram também programadas teclas de atalho
para algumas opções mais específicas. Não menos importante é a informação a
disponibilizar sobre os agentes e o estado do jogo. Procedeu-se à colocação permanente
da informação mais relevante do visualizador, tal como o resultado, tempo e mensagens
do jogo. Como informação de visualização automática temos as estatísticas, podendo a
sua visualização ser forçada a uma permanência no ecrã. Também se teve o cuidado de
definir zonas específicas para disponibilizar informação de debug (topo) ou informação
sobre os agentes (base).
152
Para explicar o visualizador nada melhor que proceder à explicação das opções visíveis
no menu principal. Assim temos:
O.1 – File
Opção que inclui um conjunto de sub-opções referentes à ligação ao servidor
soccerserver e carregamento de ficheiros de log (ver figura 10.2). Inclui também uma
lista dos últimos documentos carregados pelo utilizador.
Figura 10.2: Menu principal com a sub-opções da opção File
As sub-opções disponíveis para a opção File são:
Open Scenario: Opção que permite carregar um ficheiro log que inclui o registo do jogo
de futebol.
Connect to Server: Opção que permite que o utilizador se ligue ao servidor soccerserver.
Kick Off: Esta opção permite iniciar uma segunda parte através do envio de um comando
de kickoff para o servidor soccerserver.
Disconnect: Após a ligação ao servidor é sempre possível desligar do servidor, bastando
apenas seleccionar esta opção.
Exit: Opção que permite ao utilizador abandonar o aplicativo.
Sempre que uma opção se encontra desactiva esta encontra-se com uma cor mais clara,
como exemplo temos a opção kickoff e disconnect. Algo que é importante realçar é que
após o carregamento de um ficheiro ou ligação ao servidor no topo da janela de
visualização constará o nome do ficheiro carregado ou a indicação de ligação ao servidor
soccerserver.
O.2 – Edit
É constituída por um conjunto de opções standard das aplicações para manuseamento de
dados (copiar, colar, etc.);
153
O.3 – Logplayer
A utilização principal do LogPlayer situa-se ao nível da análise da estratégia das várias
equipas e dos seus pontos fracos e fortes. À semelhança do que se passa com um gravador
de vídeo, a opção LogPlayer é constituída por um conjunto de opções para avanço, recuo
rápido e paragem do jogo, dispondo também da possibilidade de avançar directamente
para um dado ciclo do jogo. Disponibiliza também uma opção para ler ficheiros do
formato log como na opção principal File.
Figura 10.3: Sub-opções da opção Logplayer
As sub-opções respeitantes à opção principal LogPlayer, que são visíveis na figura 10.3,
são as seguintes:
Open logfile: Permite carregar um ficheiro de log.
Start player: Iniciar o jogo que foi previamente carregado.
Stop player: Após o iniciar do jogo é sempre possível parar o jogo.
Player backward: Permite visualizar o jogo do fim para o início.
Rewind player: Visualização do ponto actual para o início do jogo.
Single step: Permite avançar um ciclo.
Single step back: Permite recuar um ciclo.
Accelerate player: Permite acelerar gradualmente a velocidade do jogo.
Decelerate player: Opção que tem um funcionamento contrário à opção anterior.
Goto Cycle …: Opção que permite seleccionar o tempo de ciclo para o qual nos
desejamos posicionar. Para facilitar o utilizador, criou-se uma janela com uma barra de
tempo com a escala do tempo total do jogo (ver imagem 10.4).
154
Figura 10.4: Barra de tempo do jogo
Também é possível introduzir o tempo de ciclo desejado via teclado. Esta opção só está
disponível quando o jogo está parado.
Save logfile: Gravação do ficheiro actual.
Save as …: Gravação do ficheiro actual com outro nome.
O.4 – View
Esta opção é constituída por um conjunto de opções (ver imagem 10.5) que permite
activar ou desactivar funcionalidades relacionadas com a visualização, tais como:
resultado e mensagens do jogo, estatísticas, mensagens de debug e funcionalidades de
rendering do visualizador.
Figura 10.5: Sub-opções da opção principal View
A opção Score permite que o resultado do jogo seja visível no ecrã. Já a opção Msgs
permite visualizar as mensagens referentes ao jogo. A opção de estatísticas (Stats) permite
activar o modo de visualização das estatísticas, que passa pela localização da bola
(Localization), posse de bola (Possession) ou modo automático (Auto View). A sub-opção
das estatísticas AutoView permite que o realizador mostre alternadamente as estatísticas
de posse ou localização da bola no ecrã na altura mais conveniente.
Figura 10.6: Bounding Box dos agentes do cenário
A opção de renderização inclui sub-opções para activar a visualização das caixas de
colisão dos actores como se pode ver na figura 10.6. Também é possível visualizar a
155
estrutura dos objectos. Outra opção interessante referente à renderização passa por ser
possível visualizar qual a região de filmagem imposta pelo realizador aos operadores de
câmara. Na imagem 10.7 é visível, no centro do campo, um paralelepípedo amarelo que
define a região de filmagem.
Figura 10.7: Definição de uma região de filmagem
Por fim, a opção de debug é constituída por um conjunto de sub-opções que permite
debugar a aplicação para uma análise detalhada de alguns erros do sistema.
O.5 – Cameras
A configuração das câmaras e o seu funcionamento são efectuadas nesta opção, como se
pode ver pelas opções existentes na figura 10.8.
Figura 10.8: Sub-opções da opção principal Cameras
As funcionalidades possíveis referentes a esta opção permitem definir o modo de
funcionamento da câmara (auto zoom, lookat), iniciar a posição das câmaras ou valores de
cálculo (Reset …), seleccionar se as câmaras funcionam com sincronização das imagens
(Cameras Sync Image) e se o realizador define regiões prioritárias a focar (Director
Region Decision).
Existe ainda um conjunto de opções que são subdivididas. As opções são:
Detail of Auto Zoom: Permite definir detalhe do zoom das câmaras (fraco, médio, alto).
156
Zoom Distance: Permite definir distância do zoom (perto, longe) para que o jogo possa
ser acompanhado no plano maior ou mais fechado.
Auto Zoom Method: Esta sub-opção permite seleccionar algoritmo do auto zoom (melhor
valor, melhor média).
O.6 – Effects
Engloba um conjunto de opções descritas na imagem 10.9 que estão associadas aos
efeitos visuais da simulação do jogo, podendo-se seleccionar o tipo de relva (Grass Type),
animação de jogadores (Animate Players), céu (Sky animation), público (Public
animation), etc.
Figura 10.9: Sub-opções da opção principal Effects
As opções assumem por defeito os valores que expressa a imagem em cima. É de
salientar que a animação dos jogadores se encontra inicialmente desactiva. A opção que
define o tipo de relva é composta por três tipos de relvado como podemos ver na imagem
10.10.
Figura 10.10: Diferentes tipos de relvado do Virtual3D
É de realçar que a opção de Replay permite activar a repetição de golos. No caso de não
se desejar ver as repetições do jogo basta desactivar a opção.
O.7 – Sound
Inclui opções relacionadas com o som do visualizador, sendo possível desligar o som do
visualizador através da opção Sound Mute. A opção Stop All Sounds permite parar todos
os sons que estão a tocar no momento. Se desejar ouvir uma música de fundo no decorrer
do jogo basta seleccionar a opção Play Sound3D (Music).
157
O.8 – Help
Informação sobre o visualizador, nomeadamente a versão os autores e o Laboratório/
Faculdade onde foi desenvolvido.
Figura 10.11: Caixa com a informação sobre o visualizador
A informação é expressa numa caixa (dialogbox), como se poder ver na imagem 10.11.
O.9 – Teclas de atalho
Para facilitar a interacção entre o utilizador e o visualizador foram definidas um conjunto
de teclas de atalho que permitem realizar um conjunto de operações rápidas, que são
descritas na tabela 15.
Tabela 19: Teclas de atalho do visualizador Virtual3D
Teclas
Ctrl-O
R
0
1
2
3
4
5
6
7
8
9
A
Definição das teclas
Abertura de um ficheiro de log específico.
Reiniciar a posição e parâmetros de todas as câmaras.
Seleccionar câmara que acompanha sempre a bola com coordenada y
elevada.
Seleccionar câmara do lado esquerdo do estádio.
Seleccionar câmara do lado esquerdo/centro do estádio.
Seleccionar câmara central do estádio.
Seleccionar câmara do lado direito/centro do estádio.
Seleccionar câmara do lado direito.
Seleccionar câmara que se posiciona por trás da baliza esquerda.
Seleccionar câmara que se posiciona por trás da baliza direita.
Seleccionar câmara que se desloca num carril, no topo do estádio.
Seleccionar câmara posicionada no centro do campo.
Seleccionar câmara em modo automático (realizador)
158
Figura 10.12: Visualização do cenário com a câmara [1],[3] e [5]
A imagem 10.12 mostra as filmagens realizadas pela câmara 1, 3 e 5 no decorrer de um
jogo. As câmaras foram estas seleccionadas manualmente pelo utilizador.
159
Anexo P - Terminologia
AAII – Australian Artificial Intelligence Institute.
ACL - Agent Comunication Language.
BDI – Belief, Desire Intention.
Bitmap – Ficheiro ou estrutura de dados que consiste num conjunto rectangular de
pixels ou pontos com cor que formam uma imagem.
CamDroid - Sistema “Intelligent Camera Control”, implementado por Ducker.
Cameraman – Termo inglês para operador de câmara.
COSY – COperating System
DCCL - Declarative Camera Control for Automatic Cinematography.
Director – Termo inglês para realizador cinematográfico.
dMARS – distributed Multi-Agent Reasoning System
IA – Inteligência Artificial
IRMA - Intelligent Resource-Bounded Machine Architecture
KQML – Knowledge Query and Manipulation Language.
KIF - Knowledge Interchange Format
LISP – É uma das linguagem de alto nível mais antiga, em que a sua base estrutural são
as listas. Foi desenvolvida em 1958 por John MacCarthy. Mais tarde foi adoptada como
uma das primeiras linguagens pelos investigadores da Inteligência Artificial (IA).
LogPlayer - Aplicação que permite a visualização de jogos pré-gravados à semelhança do
que acontece com um gravador de vídeo.
Pixel – É a menor unidade gráfica a partir da qual se forma uma imagem.
PRS – Procedural Reasoning System
Shot – Conceito cinematográfico que representa uma porção de tempo entre o início e o
fim de uma filmagem de uma cena particular.
SMA – Sistema Multi-Agente
Socket – Módulos de software que ligam as aplicações ao protocolo da rede, facilitando
o trabalho do programador, que precisa apenas de invocar no programa a abertura de
um dos sockets disponíveis para estabelecer a comunicação.
160
SoccerMonitor – Nome dos primeiros monitor de visualização da liga simulada do
Robocup, permitindo ler ficheiro log ou ligar-se ao servidor.
SoccerServer – Nome do servidor da liga simulada do RoboCup.
UDP/IP – Protocolo de comunicação feito para transmitir dados pouco sensíveis, como
streaming de áudio e vídeo. Os dados são transmitidos apenas uma vez, incluindo apenas
um frágil sistema de CRC. Inclui vários mecanismos para iniciar e encerrar uma ligação,
negociar tamanhos de pacotes e permitir a retransmissão de pacotes corrompidos. A
idéia é transmitir dados com o maior desempenho possível.
UML – Unified Modeling Language
VT100 – Terminal de vídeo fabricado pela Digital Equipment Corporation (DEC) em
1978, que se tornou o terminal padrão para emulação de aplicações até ao ano de 1983.
O seu sucessor foi o VT200.
X11 – Sistema de janelas para computadores com visualização gráfica através de
bitmaps. É um sistema standard para o Unix, Linux e outros sistemas que têm por base o
Unix.
Anexo Q - Websites
Agents at RMIT
http://www.cs.rmit.edu.au/agents/
American Association for Artificial Intelligence (AAAI)
http://www.aaai.org
Anand Rao's Publications
http://www.cs.bham.ac.uk/~sra/People/Pqr/Rao/index.html
Federation Internationale de Football Association
http://www.fifa.com
International Symposium on Smart Graphics
http://www.smartgraphics.org/
Lin Padgham's Homepage
http://goanna.cs.rmit.edu.au/~linpa/
MIT Media Lab: Software Agents
http://agents.media.mit.edu/
RoboCup Official Site
http://www.robocup.org
SmartCams: Automatic TV Cameras
http://vismod.www.media.mit.edu/vismod/demos/smartcam/smartcam.html
Start here to learn about agents
http://agents.umbc.edu/introduction/
UML Agents
http://aot.ce.unipr.it/auml/
Intelligent Agent Researches in the world
http://zeus.eed.usv.ro/~marius/documents/mas/ia-research.html
Jack Krupansky's Software Agents Links
http://agtivity.com/agoldlinks.htm
Ralfs Homepage
http://isgwww.cs.uni-magdeburg.de/~helbing/
Publicações Itsuki Noda
http://www.carc.aist.go.jp/~noda/publistE.d.html
161
162
Visualizadores 2D:
Soccer Monitor - Klaus Dorer (Universidade de Freiburg, Alemanha)
http://www.fh-furtwangen.de/~dorer/
Soccer Monitor – WrightEagle (Universidade of Science and Technology, China)
FrameView
Brainstormers - Arthur Merke ( Universidade de Dortmund, Alemanha )
http://ls1-www.cs.uni-dortmund.de/~merke/robocup/
Soccer Scope – YowAI (The University of Electro-Communications, Japão )
http://ne.cs.uec.ac.jp/~koji/
Soccer Doctor - Wright Eagle (Universidade of Science and Technology, China)
Team Designer - FC Portugal (Universidade de Aveiro/Porto, Portugal)
http://www.ieeta.pt/robocup/
RoboBase - John Sear (Universidade de Manchester, Inglaterra)
http://www.cs.man.ac.uk/~searj6/
Team Assistant – SBC (Universidade Shahid Beheshti, Irão )
http://www.sbu.ac.ir/Robocup/Sim/sbc/
Visualizadores 3D:
Virtual Robocup, (Universidade de Bielefeld, Alemanha)
http://www.techfak.uni-bielefeld.de/ags/wbski/3Drobocup/3Drobocup.html
Magic Box - Wright Eagle (Universidade of Science and Technology of China)
http://www.wrighteagle.org/
The Venue (The cave) – (Universidade Vrije de Amesterdão, Holanda)
http://www.cs.vu.nl/~renambot/vr/html/soccer.htm
Caspian – (IUST Computer Engineering, Irão)
http://www.robocup-persepolis.com/
RA3DM - Isteam ( Instituto Superior Técnico, Portugal )
http://www.ist.utl.pt/
Robolog - Oliver Obst (University of Koblenz- Landau, Alemanha)
http://www.robolog.org/
Avan – ( Universidade Qazvin Islamic Azad, irão )
http://www.qazviniau.ac.ir

Faculdade de Engenharia do Porto

Transcrição

Documentos relacionados

Visualizar - Câmara Municipal de Angra dos Reis

Permite a configuração e monitoramento centralizados de seus

uma estratégia para visualização da informação gerada a partir de

casas pré-fabricadas

Modo de Compatibilidade no Internet Explorer 10

TG40 - PC Factory

Baixar o arquivo

BTL-6000 LymphasTim

Experimento 2: Movimento Parabólico

Informativo - 26/06/2015