Software Livre para Animação e Computação Gráfica (Tutorial)

Software Livre para Computao Grfica e Animao por Computador
Alberto B. Raposo, Adailton J. A. da Cruz; y, Alessandro L. Bicho ,

Alfredo K. Kojimaz; x, Carlos A. M. dos Santos{, Isla C. F. da Silva ,
Lo P. Magalhes , Paulo C. P. de Andradex
Resumo
Este curso aborda uma srie de tecnologias de domnio pblico nas reas de Computao Grfica, Realidade Virtual e Animao por Computador, enfocando ferramentas de programao para apoio ao desenvolvimento de sistemas grficos interativos.
A primeira parte apresenta duas tecnologias de menor nvel de abstrao para a gerao de interfaces grficas, formas geomtricas e imagens: o X Window System e o OpenGL. A segunda parte apresenta tecnologias de mais alto nvel, voltadas para a
Internet, que podem ser usadas para a criao de aplicaes sofisticadas, tais como mundos virtuais e animaes interativas.
Dentre estas tecnologias destacam-se Java 3D e VRML. Java 3D a biblioteca padro da linguagem Java para a criao de
programas com grficos tridimensionais. VRML um padro muito usado para a modelagem e transmisso de informao
3D e mundos virtuais pela Web.
Palavras-chave: Computao Grfica, Software Livre, Animao por Computador, Realidade Virtual.
Abstract
This course discusses some public domain tecnologies in the fields of Computer Graphics, Virtual Reality and Computer
Animation, focusing on programming tools to support the development of interactive graphic systems. The first part presents
two tecnologies of lower abstraction level used for the generation of graphic interfaces, geometric drawings and images:
X Window System and OpenGL. The second part presents higher abstraction level Internet technologies that can be used
for the creation of sophisticated applications, such as virtual worlds and interactive animations. Among these technologies,
Java 3D and VRML will be studied. Java 3D is the Java standard library for the creation of programs using tridimensional
graphics. VRML is a standard normally used for the modeling and transmission of 3D information and virtual worlds in the
Web.
Keywords: Computer Graphics, Free Software, Computer Animation, Virtual Reality.
1 Introduo
Software livre pode ser definido como software desenvolvido por um grupo amplo e heterogneo de pessoas, empresas
e grupos acadmicos, cuja diversidade de interesses impede que se estabelea o monoplio de um nico fornecedor ou
fabricante, como normalmente ocorre com software no-livre.
Recentemente, tem ocorrido um forte movimento por parte de empresas que desenvolvem software comercial no sentido
de abrir o cdigo de seus produtos, visando aumentar sua aceitao no mercado, facilitar sua distribuio e fazer uso dos
Departamento de Engenharia de Computao e Automao Industrial Faculdade de Engenharia Eltrica e de Computao UNICAMP. {alberto,
ajcruz, bicho, isla, leopini}@dca.fee.unicamp.br
y Centro Universitrio de Dourados UFMS
z Instituto de Informtica UFRGS. kojima@inf.ufrgs.br
x Conectiva Informtica S.A. Curitiba, PR. pcpa@conectiva.com.br
{ Centro de Pesquisas Meteorolgicas Universidade Federal de Pelotas. casantos@cpmet.ufpel.tche.br
servios da comunidade para testar o produto e port-lo para um maior nmero de plataformas. Este tipo de software
chamado de open source (cdigo aberto), embora muitos tambm os considerem como livres.
A Computao Grfica tem apresentado um crescimento significativo nos ltimos anos, devido principalmente ao avano
tecnolgico, disponibilizando recursos que propiciam o desenvolvimento de aplicaes cada vez mais complexas. Com o
crescente interesse evidenciado nesta rea, a utilizao de um padro grfico para trabalhar de forma eficiente em diversas
plataformas tornou-se uma preocupao. Desta forma, o crescimento de software livre e open source nessa rea tambm
uma realidade. Este artigo aborda algumas ferramentas livres (ou open source) de programao para o desenvolvimento de
sistemas grficos interativos.
Inicialmente, ser estudado o X Window System, um sistema de janelas com suporte construo de aplicaes grficas
distribudas e arquitetura cilente-servidor. Depois ser apresentado o OpenGL, um padro aberto para desenvolvimento de
aplicaes grficas tridimensionais que pode ser incorporado a qualquer sistema de janelas, inclusive o X. Java 3D, abordada
a seguir, a biblioteca da linguagem Java para a criao de aplicaes tridimensionais. Como toda a plataforma Java, Java
3D open source. Finalmente, ser apresentada a VRML, uma linguagem para a modelagem e transmisso de informao
3D pela Internet.
importante ressaltar que estas ferramentas se aplicam em contextos diferentes, sendo utilizadas para o desenvolvimento
de diferentes classes de aplicaes grficas. O X Window System e suas interfaces de programao (toolikts) so usados
para o desenvolvimento de componentes grficos de interfaces interativas (janelas, botes, etc.) e primitivas bsicas de
desenho. O OpenGL uma biblioteca grfica para a renderizao de imagens estticas. Java 3D e VRML, por sua vez, esto
relacionadas Web e possuem recursos sofisticados de animao, interao e navegao por mundos tridimensionais.
2 X Window System
O X Window System foi criado em 1984 no Massachusetts Institute of Technology (MIT) como parte das pesquisas do
Projeto Athena e do Sistema Argus, voltados construo de aplicaes multiprocessadas distribudas [1]. O sistema teve
grande aceitao no mercado e por isso, em 1988, o MIT formou junto com fabricantes de software o MIT X Consortium,
destinado a prover suporte tcnico e administrativo ao desenvolvimento subseqente do sistema. Em 1993 o consrcio
tornou-se uma organizao independente chamada X Consortium, Inc., qual o MIT cedeu os direitos sobre o X Window
System. No final de 1996 o X Consortium fechou suas portas e transferiu os direitos para a Open Software Foundation
(OSF). Pouco depois, em 1997, a OSF se fundiu X/Open (detentora dos direitos sobre o UNIX) formando uma organizao
chamada The Open Group.
O papel do X Consortium sempre foi o de produzir padres, ou seja, especificaes de software. O consrcio tambm
distribua o cdigo-fonte de uma implementao de amostra (SI sample implementation). possvel criar tantas variaes
quantas se queira a partir da SI, mas o X Window System continua sendo um s, definido por suas especificaes formais.
Qualquer implementao que no siga risca as especificaes deve ser considerada, no mnimo, defeituosa. A maioria dos
fabricantes de sistemas UNIX comerciais distribui implementaes do X baseadas na SI. O Projeto XFree86, por sua vez,
desenvolve e mantm a implementao usada em sistemas operacionais livres, como Linux e FreeBSD, e em alguns sistemas
comerciais, como OS/2 e QNX.
Ao anunciar a reviso 6.4, em fevereiro de 1998, o Open Group quis adotar uma poltica de licenciamento que permitia o
uso do cdigo da SI para fins no comerciais e de pesquisa, mas exigia para sua comercializao o pagamento de uma taxa,
proporcional ao nmero de cpias a distribuir. A justificativa para tal atitude era a necessidade de custear o desenvolvimento
do software. Devido aos protestos da comunidade de usurios de software livre, em especial do Projeto XFree86, em
setembro do mesmo ano o Open Group voltou atrs em sua deciso retomando a antiga poltica de licenciamento, sem
restries a cpia, modificao e distribuio do cdigo.
2.1 Arquitetura do X Window System

X possui arquitetura cliente-servidor na qual o servidor localiza-se na estao de trabalho do usurio e os clientes podem
ser executados na prpria estao ou remotamente, conectados ao servidor atravs de uma rede. Os servios oferecidos
pelo servidor incluem acesso transparente ao hardware grfico (primitivas de desenho 2D e criao/manipulao de janelas),
mecanismos de comunicao entre clientes e entrada de dados por dispositivos como mouse e teclado.
O sistema foi concebido para funcionar com quaisquer tipos de display e dispositivos de entrada, variando desde framebuffers mapeados por bit com monitor monocromtico at coprocessadores grficos com display colorido. As aplicaes
Software Livre para Computao Grfica e Animao por Computador SIBGRAPI2000 (tutorial)
deveriam ser executadas em qualquer display, colorido ou monocromtico, remoto ou local, sem que fosse necessrio alterar
o seu cdigo ou recompil-las, e sem perda sensvel de desempenho. Mais de uma aplicao deveria poder acessar o display
simultaneamente, cada uma apresentando informaes em uma janela.
Qualquer coisa que se queira apresentar na tela deve ser desenhada dentro de uma janela. Uma aplicao pode usar
muitas janelas de cada vez. Menus e outros elementos da interface podem ser construdos com janelas que se sobrepem
s demais. As janelas so organizadas em uma hierarquia, o que facilita o gerenciamento. Qualquer janela, exceto uma,
chamada de raiz, subjanela de outra, conforme mostra a Figura 1.
R
Figura 1: Relacionamento hierrquico entre janelas: A

ascendente de B se B est contido na hierarquia de A; B
irm de C se ambas possuem o mesmo ascendente imediato; se A ascendente de B, obviamente B descendente de
A; R a janela raiz, ascendente de todas as demais (h somente uma janela raiz em cada tela); C uma janela folha,
pois sua hierarquia vazia.
Baseado no princpio de que o conceito de melhor interface cultural, X permite o uso mais de uma interface grfica
com o usurio, propiciando que as aplicaes convivam com diversas culturas. Ao invs de um modelo de objetos de alto
nvel, X oferece um substrato de operaes bsicas, deixando abstrao para camadas superiores.
Um mecanismo de extenso permite s comunidades de usurios estender o sistema e mesclar essas extenses harmoniosamente. Suporte a grficos 3D no era um dos requisitos quando da concepo do sistema. Embora o X Consortium tenha
posteriormente padronizado uma extenso para modelagem 3D baseada em PHIGS (Programmers Hierarchical Interactive
Graphics System), chamada PHIGS extension for X (PEX), ela nunca se tornou popular. A extenso GLX, desenvolvida pela
Silicon Graphics (SGI) para dar suporte ao padro OpenGL (ver Seo 3), acabou se tornando a mais aceita no mercado.
2.2 Interfaces que constituem o sistema de janelas

Um sistema de janelas constitudo por vrias interfaces:
Interface de programao. Uma biblioteca de rotinas e tipos para interao com o sistema de janelas. H dois tipos de
interface de programao:
De baixo nvel. Prov funes grficas primitivas. No X, a biblioteca Xlib [2] prov essas funes primitivas, por
meio de troca de mensagens com o servidor de display.
De alto nvel. Prov funes para tratar os elementos constituintes da interface. Existem diversas bibliotecas (toolkits)
de interface. X no define uma interface de alto nvel padro, mas prov os mecanismos necessrios construo
de uma por meio de uma biblioteca chamada X Toolkit (Xt) [3]. A maioria dos toolkits, entretanto, construda
diretamente sobre a Xlib, sem usar o Xt.
Interface de aplicao. Define a interao mecnica entre a aplicao e o usurio, que especfica da aplicao. X tambm
no define regras para interao usurio/aplicao, embora o uso de um toolkit possa levar a aplicao a ter aparncia
e comportamento semelhantes s outras desenvolvidas com ele.
Interface de gerenciamento. Define a poltica de controle do posicionamento, tamanho e sobreposio das janelas sobre
a rea de trabalho. Este papel deve ser desempenhado por uma aplicao chamada gerenciador de janelas (window
manager). X no prov um gerenciador padro, mas define um conjunto de atributos para cada janela chamado
window manager hints (dicas). Gerenciadores de janelas devem fazer uso dessas dicas para determinar as alteraes
que o usurio pode fazer na geometria das janelas. Uma conseqncia desta abordagem que cada usurio pode
usar o gerenciador de janela que desejar. Se isso bom ou no, uma questo de gosto, e motivo de interminveis
controvrsias sobre qual o melhor gerenciador de janelas.
Essa classificao define uma arquitetura em camadas e sugere independncia entre mecanismo, provido pelas camadas
abaixo da interface de programao de baixo nvel, inclusive, e poltica, provida pelas camadas acima desta.
A interface com o usurio a a soma das interfaces de aplicao e de gerenciamento [1]. X foi projetado de forma a
prover mecanismos para que diferentes polticas de interface pudessem ser implementadas, ou seja, X no nem possui uma
interface com o usurio. A funo de prover tal interface delegada a clientes e bibliotecas externos ao servidor X e s
bibliotecas de funes do sistema.
2.3 Conceitos importantes e terminologia

Na terminologia do X Window System alguns termos so usados com significados diferentes daqueles a que estamos acostumados, conforme descrito a seguir:
Display. Instncia de um servidor X sendo executado em uma mquina. Geralmente um conjunto de hardware de vdeo,
teclado e mouse mais o software que gerencia esse hardware. Uma mquina dedicada que serve apenas como display,
chamada de terminal X.
Tela (screen). X possui suporte a mltiplos monitores ligados a uma mesma mquina ao mesmo tempo. Cada monitor ligado
denominado screen. Mltiplas telas podem conviver formando um display. A reviso 6.4 introduziu a extenso
Xinerama [4] que permite combinar vrias telas formando uma nica tela virtual, de modo totalmente transparente s
aplicaes.
Janela (window). Pode ter dois sentidos dependendo do contexto:
No nvel mais baixo, uma rea, normalmente retangular, em uma das telas do display, na qual um ou mais
clientes podem realizar operaes de entrada e sada (desenhos, etc.). Neste texto, o termo janela ser usado com
este significado.
Em um nvel mais alto, janela a rea ocupada na tela por uma aplicao. Esse tipo de janela conhecido como
janela de aplicao, ou shell.
A hierarquia de janelas permite ao cliente estabelecer polticas de tratamento de eventos. O servidor pode ser instrudo
a remover uma janela de dentro de outra, colocando-a dentro de uma terceira. Este recurso, de adoo (reparent)
utilizado por vrios aplicativos, especialmente pelo gerenciador de janelas.
rea de trabalho. O conjunto formado pela janela raiz de uma tela e as janelas criadas sobre ela. O gerenciamento da rea
de trabalho cabe ao gerenciador de janelas. Somente um gerente pode controlar um display de cada vez, mas no
existe a obrigatoriedade de se usar um determinado gerente.
Widget. Um elemento de interface grfica. Exemplos so botes, caixas de texto, etc. Janelas top-level tambm so consideradas widgets.
Servidor. O programa que compartilha um display com os clientes. O servidor construdo em duas camadas, uma dependente do hardware e outra independente. Portar o servidor para outro hardware implica em modificar apenas a
primeira. Drivers de vdeo fazem parte do servidor X e somente ele tem acesso ao hardware.
Cliente. Uma aplicao que usa um ou mais displays, podendo ter mais de uma conexo aberta simultaneamente com o
mesmo display, caso seja necessrio. O cliente no precisa ser executado no mesmo computador que o display.
Gerente de Display (display manager). Aplicao responsvel por fornecer autenticao de acesso a um ou mais displays.
O gerente de display padro do X o programa XDM.
Sesso (session). O perodo de tempo durante o qual um usurio tem acesso ao display. Normalmente apenas um usurio
pode usar o display de cada vez, mas ele pode dar autorizao a outros para que o usem. Uma aplicao especial,
chamada session manager (SM) pode ser usada para salvar o estado de uma sesso e restaur-lo posteriormente, mas
isso exige que as demais aplicaes reconheam algumas mensagens enviadas pelo SM.
2.4 Protocolo X
A comunicao cliente-servidor se d por troca de mensagens, usando o protocolo X [5], que por sua vez independente do
protocolo de transporte usado (TCP/IP, DECnet, etc.). Para estabelecer a conexo, o cliente deve saber o nome da mquina
onde o servidor executado, mas as funes da biblioteca Xlib permitem que se configure um servidor a ser usado por
omisso. Em UNIX, o servidor padro informado pela varivel de ambiente DISPLAY, que tem seu valor devidamente
atribudo pelo XDM durante o processo de login (ver Seo 2.5). O protocolo prov representao de dados independente
da organizao dos computadores em que so executados o cliente e o servidor. Isto negociado no estabelecimento da
conexo e o servidor trata de fazer no seu lado as converses necessrias.
Para o controle de seqncia das mensagens, ao invs de enviar uma confirmao imediatamente aps o recebimento
de cada requisio, a confirmao vai de carona na mensagem seguinte. Este recurso, chamado piggybacking [6, p.202],
permite o envio de confirmaes, embora com retardo, e economiza trfego de rede. Os pacotes transmitidos entre servidor possuem um cabealho de tamanho tambm varivel, com uma identificao nica de tipo, seguidos de outros dados,
dependentes do tipo de mensagem:
Request. Solicitao de servios do cliente ao servidor. Tm um cabealho de tamanho fixo, seguido de uma estrutura
dependente do tipo. Existem dois tipos de requisio:
Unidirecionais (one way trip). So aquelas que no necessitam esperar por uma confirmao imediata de recebimento. A confirmao enviada usando o mecanismo piggybacking, j mencionado. Esta forma de tratar as requisies contribui para o desempenho do sistema, pois vrias delas podem ser armazenadas no buffer de transmisso
e descarregadas em bloco, otimizando o trfego na rede.
De ida e volta (round trip). A maioria das requisies implementada da forma anterior, mas algumas delas exigem
uma resposta por parte do servidor. o caso tpico da criao de uma janela, em que deve ser retornado o seu
nmero ao cliente, pois ele ser usado nas operaes posteriores. Chamadas de ida e volta descarregam o buffer
de sada e so enviadas imediatamente. Como so bloqueantes, seu uso deve ser evitado tanto quanto possvel
para no degradar o desempenho do sistema.
Reply. Respostas a requisies. Tm um cabealho de tamanho fixo, seguido de uma estrutura dependente da requisio.
Teoricamente uma resposta poderia ter tamanho mximo de 16GB, mas na prtica isso no acontece.
Event. Eventos, tais como alterao da geometria de uma janela, pressionamento de uma tecla ou movimentao do mouse.
Tm tamanho fixo (32 octetos) e possuem no seu incio um identificador de tipo e de nmero de seqncia, que tem o
mesmo uso que nas respostas.
O protocolo assncrono, mas garante que as mensagens sero entregues ao servidor na mesma seqncia em que foram
geradas pelo cliente, e vice-versa. Como mostra a Figura 2, o cliente pode receber eventos de muitos tipos diferentes antes
da resposta a uma requisio. As funes de tratamento de eventos da Xlib permitem consultar a fila de entrada e retirar
eventos segundo vrios critrios, deixando os demais enfileirados.
SERVIDOR
Figura 2: Fluxo de mensagens

entre servidor e cliente. Como a
gerao de eventos assncrona,
eventos provenientes do servidor
podem chegar ao cliente antes da
resposta ltima requisio enviada.
CLIENTE
Legenda
Req. bloqueante
Req. no bloqueante
Resp. bloqueante
Evento
2.5 Autenticao de usurios

Como X um ambiente de trabalho distribudo, os mtodos normais de autenticao de usurios existentes nos sistemas
operacionais nem sempre podem ser aplicados. O controle de acesso ao display pode ser feito por diversos mtodos descritos na pgina de manual Xsecurity, que faz parte do pacote X (alguns mtodos no so disponveis em todas as
implementaes).
O programa XDM usa o X Display Manager Control Protocol (XDMCP) para prover servios similares queles oferecidos pelo login do UNIX, aguardando conexes na porta 177 com transporte UDP, ou via broadcast. A Figura 3 ilustra o
processo de autenticao.
4
5
9
10
11
12
6
APLICAO
XDM
SERVIDOR X
USUARIO
1
2
3
13
Figura 3: Autenticao via XDMCP. O servidor X configurado para, ao ser carregado, fazer uma chamada ao XDM via XDMCP (1).
XDM, por sua vez apresenta uma tela de login ao usurio (2). Aps receber o nome do usurio e a senha (3), XDM gera uma chave de
autenticao, grava-a no arquivo .Xauthority no diretrio do usurio (6) envia uma cpia ao servidor (7). Depois disso XDM executa
um programa correspondente sesso de trabalho do usurio, que normalmente ativa um gerenciador de janelas. Enquanto durar a sesso,
cada cliente que quiser usar o servidor dever ler a chave (8) e conectar-se porta de comunicao do servidor (9), recebendo um desafio
(10). O cliente usar a chave para formar a resposta ao desafio (11), qual o servidor responder, se estiver correta, com uma autorizao
de acesso (12). Quando a sesso termina, XDM reinicializa o servidor (13) e recomea todo o processo.
Durante o perodo da sesso do usurio, novas conexes ao display devero ser autenticadas usando a chave gerada
pelo XDM, cujo valor depende do protocolo escolhido. A funo XOpenDisplay da biblioteca Xlib usar o contedo do
arquivo .Xauthority, no diretrio home do usurio, para construir esta chave.
Os mtodos de autenticao suportados so descritos na pgina de manual Xsecurity1. Alguns deles tm a desvantagem de necessitar de um servidor para autenticao, mas permitem centralizar o cadastramento de usurios e aumentam a
segurana em ambiente de rede.
2.6 Recursos do servidor

Recursos (resources) so os objetos (na falta de um termo mais adequado) que residem na memria do servidor mas que so
usados pelos clientes. Eles so compartilhveis entre clientes de um mesmo display, mas no entre displays diferentes. Um
recurso sobrevive enquanto durar a conexo do servidor com o cliente que o criou, depois disso o servidor destri todos os
recursos a ela associados. Recursos podem ser dos seguintes tipos:
Janelas. reas para desenho na tela, normalmente de formato retangular. A destruio de uma janela implica na destruio
de todas as que nela estiverem contidas. A janela raiz contm todas as demais e no pode ser destruda. O gerenciador
de janelas assume o controle da janela raiz e informado pelo servidor de cada criao/remoo de novas janelas.
Mapas de pixels (pixmaps). So espcies de janelas ocultas. O cliente pode realizar sobre um pixmap qualquer operao
de desenho que seria feita em uma janela. O contedo de um pixmap pode ser copiado para uma janela e vice-versa.
Aplicaes que fazem desenhos complexos, como animaes ou imagens de alto realismo, podem acelerar a exibio
mandando o servidor copiar partes de um pixmap para a rea exposta da janela, ao invs de redesenh-la. Pixmaps e
janelas so chamados de drawables, porque se pode desenhar neles.
1 Em
sistemas UNIX, essa pgina de manual pode ser lida usando o comando man Xsecurity.
Contextos grficos (GCs graphic contexts). Um GC guarda um conjunto de atributos grficos como cores de frente e
fundo, padres para desenho de linhas, preenchimento de polgonos, fontes de caracteres, etc. Uma requisio de
desenho em uma janela tem como um dos parmetros o identificador do GC que deve ser usado. GCs so globais
para todo um display e podem ser usados por qualquer cliente em operaes sobre qualquer janela. GCs so um dos
mecanismos mais importantes do X para melhorar o desempenho das operaes.
Fontes. Descrevem o tamanho e aparncia de caracteres. X suporta o uso de alfabetos e smbolos internacionais baseados
nas especificaes ISO-8859 e ISO-10646 (Unicode). O servidor carrega para sua memria os padres de desenho dos
caracteres de uma fonte medida que os clientes solicitam. Servidores executados em mquinas sem disco (terminais
X) podem carreg-las de um servidor de fontes.
Mapas de cores (colormaps). O servidor prov um mapa de cores (paleta) global para ser usado por todos os clientes, no
qual cada cor referenciada por um ndice. Cada janela tem associado a ela um mapa de cores, que normalmente
o mesmo da janela raiz. Caso o nmero total de cores suportadas pelo servidor simultaneamente seja pequeno,
possvel que todos os elementos do mapa de cores acabem sendo usados. Aplicaes que fazem uso intenso de cores
podem criar um novo mapa de cores no servidor para seu uso privado, associando-o s janelas criadas.
Cursores. Descrevem a aparncia do cursor associado ao dispositivo apontador (normalmente o mouse). O cliente no
precisa desenhar o cursor, apenas requisitar ao servidor que use um certo padro (ou nenhum) sempre que o apontador
estiver sobre uma certa janela.
A criao de recursos feita por requisies one way trip. Para que isso seja possvel o servidor passa ao cliente, na abertura
da conexo, um bloco de identificadores no usados, que vo sendo consumidos medida que necessrio. As funes
tratamento de recursos da Xlib gerenciam automaticamente esse bloco de identificadores, de modo que o programador no
precisa se preocupar com eles.
2.7 Comunicao entre clientes

X prov mecanismos de comunicao no s entre cliente e servidor, mas tambm entre clientes. A rigor, um cliente
no pode realmente enviar eventos para outro cliente, apenas para as janelas que este possui no servidor, usando a funo
XSendEvent da Xlib. Clientes que desejam receber eventos enviados por outros devero fazer uma requisio ao servidor,
via XSelectInput, e a partir de ento o servidor os enviar. Um cliente no precisa solicitar eventos para uma janela
criada por ele, mas pode informar que no os deseja, conforme descrito na Seo 2.10.1.
As convenes para interao entre aplicaes so descritas detalhadamente no Inter-Client Conventions Manual (ICCCM) [7]. Faremos aqui apenas uma breve descrio de conceitos teis ao entendimento do resto do texto.
2.7.1 Propriedades, tomos, reas de recorte e selees
Eventos permitem envio de mensagens, mas no so adequados ao compartilhamento de dados entre clientes. Para fazer isto
existem tomos, propriedades e selees.
Propriedades (properties). So blocos de dados que um cliente pendura em uma janela, contendo quantidades arbitrrias
de informao de um tipo escolhido. Propriedades so mantidas na memria do servidor, junto com as janelas, e
podem ser criadas, destrudas, lidas e gravadas. A gravao/leitura do contedo de uma propriedade semelhante ao
que se faria em um arquivo.
Aplicaes que compartilham dados via propriedades devem solicitar ao servidor, via XSelectInput, a notificao
de alteraes nas mesmas. A partir de ento, sempre que houver alterao em uma propriedade o cliente ser notificado
por um evento do tipo PropertyNotify.
tomos (atoms). So identificadores nicos que os clientes podem usar para comunicar informao uns aos outros. Um
tomo simplesmente uma cadeia de bytes de tamanho arbitrrio. Ao invs de enviar essas cadeias pela rede o cliente
registra-as no servidor, obtendo um rtulo nico de 32 bits. tomos tambm so usados para especificar tipos de dados
e nomes de propriedades e selees. Existe um conjunto de tomos padro, pr-registrados no servidor, cujos rtulos
tm valores conhecidos por antecipao (declarados no arquivo Xatom.h).
reas de recorte (cut buffers). A janela raiz de cada tela possui um grupo de propriedades identificadas pelos tomos prdefinidos XA_CUTBUFFER0 a XA_CUTBUFFER7. A Xlib possui funes para armazenar bytes nestas reas de
recorte, permitindo s aplicaes implementar um sistema simples de recortar-e-colar. Um exemplo de aplicao das
reas de recorte o emulador de terminal xterm, que permite marcar uma parte do texto em uma janela e col-la em
outra.
Selees (selections). So mecanismos mais sofisticados do que os cut buffers para compartilhamento de dados. Uma seleo tratada como um basto em um sistema de revezamento. Apenas um cliente pode deter o basto de cada vez. O
detentor do basto deve ento atender s requisies dos outros clientes, convertendo os dados selecionados para um
formato solicitado, armazenando o resultado em uma propriedade e notificando o solicitante da disponibilidade.
Selees permitem que clientes armazenem os dados em seu prprio espao de dados e no na memria do servidor
X. Seu uso exige que a aplicao a quem os dados foram solicitados saiba como convert-los, se necessrio, para
o formato que o solicitante pede. Descries detalhadas deste mecanismo so dadas por Packard [8] e por Nye e
OReilly [9, cap. 11].
2.8 Arrastar e soltar

Arrastar e soltar, ou drag-and-drop (DnD), a tcnica interativa baseada na metfora de selecionar um objeto em uma janela
e transport-lo para outra, resultando em uma transferncia dos dados entre as duas aplicaes. X no prov explicitamente
tal recurso, pois ele est associado a uma poltica. As aplicaes devem implement-lo usando os mecanismos disponveis.
Em decorrncia disso h muitos protocolos DnD para X, dentre os quais destacam-se os trs mais populares:
Motif. O toolkit Motif [10] define um protocolo DnD baseado em mensagens entre clientes, properties e selections. Como exemplos de aplicaes que usam esse protocolo, podemos citar o Netscape Navigator (verso para UNIX) e os
programas integrantes do CDE (Common Desktop Environment).
Offix. Offix [11] foi um pacote de aplicativos desenvolvido por Csar Crusius, que mais tarde evoluiu para um toolkit grfico
completo. O pacote inclua um protocolo DnD, implementado em uma biblioteca de livre distribuio que usada por
um grande nmero de aplicaes.
Xdnd. um protocolo recente, criado por John Lindall para o toolkit JX [12] mas que est se tornando padro de fato entre
os pacotes de software livre.
Esses padres so incompatveis entre si e a falta de um padro real , provavelmente, o motivo principal da relativa
escassez de aplicaes para X Window que suportem drag-and-drop. Uma comparao entre os diversos protocolos foi feita
por Lindall [13].
2.9 Gerenciamento de janelas

O uso de um gerenciador de janelas no obrigatrio, mas muito til porque ele implementa as polticas de atribuio
do foco (a janela em foco recebe os eventos de teclado) e redimensionamento e sobreposio de janelas. O gerenciador de
janelas faz isso com base em um conjunto convenes, usando mecanismos como troca de mensagens e eventos.
H um conjunto padro de propriedades acopladas a cada janela, definido no ICCCM, que funcionam como dicas (hints)
para o gerenciador de janelas, contendo informaes relativas forma como a janela deve ser tratada. Exemplos dessas
propriedades so WM_NORMAL_HINTS, que fornece informaes sobre a geometria da janela, WM_NAME, que contm um
texto a ser mostrado ao usurio como sendo o ttulo da janela, e WM_HINTS, que fornece informaes como um pixmap a ser
usado em representaes iconizadas da janela. O utilitrio xprop pode ser usado para visualizar o conjunto de propriedades
definidas para uma janela. A Figura 4 mostra como isso ocorre.
2.10 Tcnicas de programao

2.10.1 Tratamento de eventos
Ao usar a aplicao, o usurio move o mouse, clica seus botes e digita no teclado. Essas aes so comunicadas pelo servidor aplicao por meio de eventos. Outras origens de eventos so a modificao da hierarquia de janelas, obscurecimento
CLIENTE
WM
3
Figura 4: Criao de uma janela top-level. O cliente cria a janela dentro da janela raiz e requisita o mapping (apresentao na tela de uma
janela e todas as suas subjanelas, o que as torna visveis) ao servidor X (1). O gerenciador de janelas recebe uma notificao (2), verifica
as propriedades colocadas na janela pelo cliente e cria um container cuja aparncia depende dos hints acoplados janela. Finalmente, o
gerenciador de janelas requisita o reparenting da janela para dentro da borda (3). O usurio sempre ver a janela da aplicao dentro do
container (4).
e exposio de uma janela ou de partes dela. Um cliente X consiste ento de um programa que envia requisies ao servidor
e reage a eventos. Existem trinta tipos de eventos declarados na estrutura XEvent no arquivo Xlib.h.
Nem todos os eventos podem ser interessantes para o cliente. O pressionamento de um boto do mouse sobre uma janela
usada apenas para exibio de um texto, por exemplo, no precisa ser informado se o cliente no precisa reagir a isso. Pode-se
informar ao servidor que tipos de eventos devem ser reportados para cada um dos objetos criados pelo cliente, o que ajuda a
reduzir o trfego de mensagens desnecessrias, alm de simplificar o cdigo da aplicao e consumir menos processamento.
Uma conseqncia indesejvel do sistema de eventos que, mesmo selecionando os tipos que se quer receber, muitos
deles ainda podem ser desnecessrios. Um exemplo o evento Expose: quando uma janela redimensionada o servidor
envia um evento desse tipo para cada modificao do tamanho ao cliente a quem ela pertence; clientes capazes de desenhar
apenas a parte exposta tero uso para a informao, mas aplicaes simples que reagem a exposes redesenhando toda a janela
provocaro um efeito de cintilao. A maneira correta de tratar o problema descartar todos os eventos de uma cadeia de
exposes e reagir apenas ao ltimo [14]. O trecho de programa a seguir demonstra o uso dessa tcnica, exemplificando o
uso de funes existentes na Xlib para verificar se h eventos na fila (XEventsQueued), consultar o prximo evento sem
retir-lo da fila (XPeekEvent) e retirar um evento da fila (XNextEvent). A verificao tem que ser feita antes de tentar
ler o evento porque a chamada XNextEvent bloqueante.
/* lao de tratamento de eventos */
done = 0;
while(!done) {
/* l o prximo evento */
XNextEvent(mydisplay, &myev);
switch(myev.type) {
/* redesenha a janela em eventos Expose */
case Expose:
/*
** Comprime uma seqncia de Exposes, para evitar repetidas
** repinturas, ja que para um redimensionamento da janela o
** servidor X envia varios Exposes consecutivos.
*/
while(
(XEventsQueued(myev.xexpose.display,QueuedAfterReading) > 0) &&
(XPeekEvent(myev.xexpose.display, &nextev),
(nextev.type == Expose))
) {
XNextEvent(mydisplay, &myev);
}
desenhar(mydisplay, mywindow, mygc);
break;
2.10.2 Tratamento de erros
A notificao de recebimento de requisies por piggybacking mencionada anteriormente tem um grave inconveniente: o
que fazer quando uma determinada requisio no pode ser atendida por algum motivo? Para resolver o problema existem
os eventos do tipo XErrorEvent. O servidor sempre envia os eventos de erro, numa poltica depois no diga que eu no
avisei, mas cabe ao cliente decidir que atitude tomar ao receb-los. Tratar o erro geralmente consiste em identificar o seu
cdigo e reagir condizentemente, o que pode ser bastante difcil. A maioria dos cdigos de erro diz respeito ao envio de
requisies com parmetros invlidos, o que significa que h um erro na aplicao.
A Xlib possui um tratador de erros simples, que normalmente mostra uma mensagem na sada de erro padro e encerra
a aplicao abruptamente, mas o cliente pode instalar o seu prprio tratador de erros. O X Toolkit tem um tratador mais
sofisticado que permite inclusive que mensagens de erro sejam internacionalizadas (geradas de acordo com o idioma da
aplicao).
Um dos fatores que dificulta a deteco de erros a gerao assncrona de eventos, que pode levar situao mostrada
na Figura 2. trabalhoso depurar uma cadeia de eventos desse tipo. Para facilitar o trabalho, o cliente pode estabelecer
a comunicao em modo sncrono usando a funo XSynchronize provida pela Xlib. O buffer de sada ser ento
descarregado e todas as requisies aguardaro a resposta do servidor. O modo sncrono s deve ser usado para depurao,
pois ele implica em queda de desempenho pelo aumento do nmero de pacotes que trafegam na rede e pela espera do
atendimento de cada requisio.
2.10.3 Aplicaes multithread
Desde a verso 11 reviso 6.1 do X Window System (X11R6.1) a Xlib e o X Toolkit possuem suporte reentrncia, permitindo que mltiplas threads faam chamadas concorrentemente s suas funes. Trs funes so providas com esta finalidade
pela Xlib:
XInitThreads inicializa o suporte a threads. Esta funo deve ser a primeira chamada Xlib em programas multithread e
deve ser completada antes que se faa qualquer outra. necessrio cham-la somente se mltiplas threads devem usar
a Xlib concorrentemente. Se todas chamadas so protegidas por outro mecanismo de excluso mtua a inicializao
desnecessria. importante tambm observar que a funo existe mesmo naquelas plataformas em que a Xlib no
suporta threads, mas neste caso ela sempre retorna False.
XLockDisplay bloqueia todas as outras threads no uso do display especificado. Outras threads que tentem faz-lo ficaro
bloqueadas at que ele seja liberado. Chamadas aninhadas a XLockDisplay podem ser feitas, mas o display no
ser liberado enquanto XUnlockDisplay no tiver sido chamada tantas vezes quanto XLockDisplay foi.
XUnlockDisplay permite s outras threads o acesso ao display especificado. Threads que tiverem sido bloqueadas
espera do display sero liberadas para continuar.
Chamadas Xlib que retornam ponteiros para estruturas sempre alocam dados dinamicamente, que devem ser descartados
posteriormente com a funo XFree, e nunca apontam para uma estrutura alocada estaticamente. Deste modo, diminui-se
o perigo de haver dependncia de dados entre threads. O X Toolkit tambm tem suporte a threads, por meio das funes
XtToolkitThreadInitialize, XtAppLock, XtAppUnlock, XtProcessLock e XtProcessUnlock.
Um cuidado adicional que se deve ter em aplicaes multithread com relao ao trmino: se uma thread responder a
um evento qualquer chamando a funo exit todas as outras threads terminaro tambm. Um exemplo de como tratar de
modo adequado o problema pode ser visto no programa ico, includo no pacote do XFree86.
2.10.4 Construo de aplicaes por composio
A operao de reparent e o compartilhamento de recursos entre clientes podem ser usados para construir aplicaes que se
apresentam ao usurio como um s programa, mas que na verdade so vrios programas sendo executados dentro de uma
mesma janela. Apresentaremos a seguir dois exemplos desse tipo de aplicao.
10
Ghostview. Ghostscript [15] um interpretador da linguagem de definio de pgina PostScript R , capaz apenas de apresentar um documento PS em uma janela X, sem nenhum tipo de interface visual, apenas de comandos. Tim Theisen
desenvolveu Ghostview, um front-end na qual a linguagem de comandos foi substituda por uma linguagem visual.
FvwmButtons. O gerenciador de janelas Fvwm [16] possui um mdulo FvwmButtons (barra de botes) capaz de fazer o
que o manual do programa chama de swallow (engolir). Ele pode ser configurado para executar uma aplicao e mover
a janela desta para dentro da barra de botes. FvwmButtons pode opcionalmente engolir uma aplicao cuja janela j
esteja na rea de trabalho quando do seu carregamento. A Figura 5 mostra um exemplo.
Figura 5: Um FvwmButtons dentro do qual esto, da esquerda para a direita, as janelas dos programas Xclock e Xload, um boto
contendo um pixmap e a janela do mdulo FvwmPager.
O recurso de reparent muito poderoso, mas no suficiente como mecanismo genrico de composio de aplicaes.
Para tanto seria necessrio definir um protocolo de comunicao entre componentes, o que no existe como padro no X.
Embora o X Toolkit defina um modelo de componentes baseado em widgets, ele omisso no que tange a mltiplas aplicaes
operando em conjunto. Essa uma deficincia do X [17].
As solues encontradas para o problema variam de aplicao para aplicao. Ghostview e Ghostscript definem um
protocolo baseado em propriedades e FvwmButtons engana as aplicaes passando mensagens que seriam enviadas pelo
gerenciador de janelas. O software GNOME [18], por outro lado, adota um modelo de componentes baseado em CORBA.
2.11 Bibliotecas e toolkits

As bibliotecas que implementam interfaces de programao para X so chamadas toolkits. O X Consortium nunca imps
um toolkit padro para interfaces grficas, o que resultou na grande proliferao desse tipo de software2 . H dezenas de
toolkits diferentes, que vo de simples conjuntos de widgets usadas em uma nica aplicao at pacotes sofisticados e cheios
de recursos.
2.11.1 Xlib
Xlib [2] a API (Application Programmers Interface) de mais baixo nvel disponvel para se programar aplicaes para
X. Ela um padro pelo X Consortium, implementado como uma biblioteca em linguagem C, que oferece funes com
correspondncia direta, ou quase, com o protocolo X.
Todos os toolkits conhecidos usam a Xlib na sua implementao, mas oferecem diversos nveis de abstrao e funes
de mais alto nvel que permitem, alm da construo de interfaces com o usurio, tratar de outras necessidades da aplicao,
tais como configurao, tratamento de erros e acesso a servios do sistema operacional.
Apesar da Xlib poder ser utilizada no desenvolvimento de aplicaes, isso no aconselhvel para programas complexos
ou que precisem de interface com o usurio elaboradas, pois alm de ser muito trabalhoso pode resultar em aplicaes com
interfaces inconsistentes umas com as das outras. Por outro lado, programas que realizam operaes de baixo nvel, tais
como gerenciamento de janelas, desenho e processamento de imagens, tero obrigatoriamente que usar as funes da Xlib.
Uma abordagem bastante comum em aplicaes complexas usar um toolkit para construir a interface e funes da Xlib
para operaes de baixo nvel. Neste caso deve-se tomar cuidado para que as chamadas feitas Xlib no interfiram com a
poltica implementada pelo toolkit.
2 Em
meados da dcada de 80 houve uma guerra de interfaces, com grandes fabricantes tentando estabelecer um padro para a indstria. A Open
Software Foundation venceu a guerra e Motif tornou-se a interface padro nos sistemas UNIX, mas, por ter uma implementao proprietria, no atraiu
a simpatia de muitos desenvolvedores de software livre. Em maio de 2000 o Open Group liberou o cdigo-fonte do Motif, autorizando sua utilizao
gratuitamente em sistemas operacionais open source.
11
2.11.2 X Toolkit (Xt)

Xt, ou X Toolkit Intrinsics [3] foi criado com a inteno de prover recursos bsicos para o desenvolvimento de outros toolkits.
Xt no tem widgets completos, mas fornece os mecanismos necessrios para se criar uma biblioteca que os possua. A idia
que Xt oferea o suporte bsico (os intrinsics) e que um toolkit complementar fornea os widgets. Xt define classes bsicas de
objetos e widgets que por si s no implementam nenhuma poltica de interface. Elas existem para que se criem subclasses,
estas sim, determinantes de uma poltica. O restante do Xt consiste de funes para:
inicializao do toolkit e da aplicao;

criao, manipulao e destruio de widgets;
adio e remoo de callbacks e actions (resposta a eventos) a widgets;
gerenciamento de widget resources;
tratamento de eventos, timeouts e sinais;
controle da execuo do programa.
Xt implementa um modelo de Programao Orientada a Objetos (POO), mas como implementado em C, uma linguagem
exclusivamente procedural, isso feito por meio de uma srie de convenes e tcnicas de programao. Por esse motivo
a programao para Xt difcil a princpio: necessrio que o programador tenha um bom domnio da linguagem de
programao C e desenvolva uma rigorosa disciplina de trabalho.
Como vantagem do modelo adotado, Xt e os toolkits nele baseados so extremamente flexveis e possuem recursos
nicos dentre os demais. Uma aplicao Xt pode ter no s sua aparncia mas tambm seu comportamento (at certo ponto,
pelo menos) modificados pelo usurio sem que seja necessrio alterar uma nica linha do cdigo-fonte do programa, e isso
pode ser feito com um programa que esteja sendo executado. O mecanismo por meio do qual isso feito chama-se widget
resources e uma das caractersticas mais poderosas do Xt.
2.11.3 Athena (Xaw)
O X Athena Widget Set (Xaw) [19] foi criado durante as pesquisas do Projeto Athena (da o nome) como um exemplo de
uso do Xt. Xaw nunca foi um toolkit completo, para uso profissional, mas acabou sendo muito utilizado porque era distribudo junto com a SI do X, apesar de nunca ter sido adotado como um padro pelo X Consortium. Como uma conseqncia
de sua origem como exerccio acadmico, Xaw carece de muitos recursos necessrios a um toolkit completo, tais como
documentao detalhada e uma grande coleo de widgets, mas suas duas principais deficincias so:
1. Implementa uma poltica muito simplista de atribuio do foco de entrada (input focus) para os eventos de teclado.
No h como identificar qual dos widgets receber os eventos correspondentes digitao (normalmente o widget
que est sob o cursor do mouse).
2. Como conseqncia do problema anterior, no h como percorrer a hierarquia de widgets usando exclusivamente o
teclado (recurso conhecido como keyboard traversal).
3. Os widgets no se diferenciam muito visualmente. No h como distinguir uma caixa de entrada de texto de um boto,
por exemplo, a no ser tentando digitar nela.
Como alternativa para resolver esses problemas, ou pelo menos o problema da aparncia, surgiram diversas variantes de
Xaw: Xaw3D, Xaw95, neXtaw, XawM, etc. Algumas aplicaes tambm tentam resolver os problemas por meio de truques
de programao, mas como regra geral podemos dizer que Xaw no se presta para o desenvolvimento de aplicaes com
boa usabilidade; para isso existem outros toolkits, sendo Motif considerado o mais profissional. Para os fins deste curso,
porm, Xaw ser o suficiente para evidenciar a diferena entre usar puramente Xlib e usar um toolkit (ver Seo 2.12.2).
12
2.12 Prtica de programao para X

Devido s restries existentes, apenas alguns conceitos bsicos sero tratados neste texto. Ao invs de descrever longamente
cada uma das funes aqui mencionadas, optamos por apresentar apenas uma sinopse do seu uso. Para cada uma delas existe
uma pgina de manual disponvel, cuja leitura recomendada para uma explicao detalhada de cada argumento da funo
e do seu resultado. Em sistemas UNIX, essas pginas de manual podem ser lidas com o programa man. Para ler o manual
da funo XCreateWindow, por exemplo, usa-se o comando
man XCreateWindow
2.12.1 Estrutura de um programa
Um programa para X divide-se em trs partes, em linhas gerais:
1. Inicializao
Durante a inicializao, o programa faz o tratamento de opes de linha de comando, conexo com o servidor X (seja
ela local ou remota) e alocao de estruturas internas. Tudo isto feito internamente pelo toolkit, caso seja utilizado
um.
2. Montagem da interface grfica
Aps aberta a conexo com o servidor, o programa pode criar e montar sua interface (janelas, menus, botes etc.)
utilizando os widgets oferecidos pelo toolkit, ou manualmente, usando-se as primitivas do Xlib.
3. Lao de tratamento de eventos.
Finalmente, o programa entra em um lao, onde fica esperando por eventos vindos do servidor, como pressionamento
de teclas ou botes do mouse, movimento do mouse ou requisio do servidor para redesenhar o contedo de suas
janelas.
Em toolkits, estes eventos so primeiro tratados internamente e dependendo do caso (quando o mouse clicado em
um widget boto, por exemplo) so repassados ao programa atravs de callbacks ou mecanismos similares.
2.12.2 Verso X do Hello, world!
Para ilustrar os conceitos apresentados, usamos a verso X do clssico Hello, world. Obviamente esta verso faz muito mais do que simplesmente escrever uma mensagem na tela. Para fins de ilustrao, apresentaremos duas verses do
programa, uma usando exclusivamente Xlib e outra usando Xt/Xaw.
Verso Xlib
O arquivo hello-Xlib.c, mostrado a seguir, um exemplo de programa escrito em C usando exclusivamente as funes
da Xlib.
#include
#include
#include
#include
#include
<X11/Xlib.h>
<X11/Xatom.h>
<X11/Xutil.h>
<X11/keysym.h>
<X11/cursorfont.h>
#include <stdio.h>
/* Esta funo chamada cada vez que um boto do mouse pressionado na janela */
void button_callback(XEvent ev, GC gc)
{
XDrawImageString(ev.xany.display, ev.xany.window, gc,
ev.xbutton.x, ev.xbutton.y, "Hello!", strlen("Hello!"));
13
}
/* Redesenha a janela */
void redraw_callback(XEvent ev, GC gc)
{
XWindowAttributes attr;
(void) XGetWindowAttributes(ev.xany.display, ev.xany.window, &attr);
XDrawLine(ev.xany.display, ev.xany.window, gc, 0, 0, attr.width - 1, attr.height 1);
XDrawLine(ev.xany.display, ev.xany.window, gc, 0, attr.height - 1, attr.width - 1, 0);
}
/* Funo chamada cada vez que a janela reconfigurada (tamanho, etc.) */
void configure_callback(XEvent ev, GC gc)
{ }
int main(int argc, char *argv[])
{
Display *display;
/*
int screen;
/*
Window root, win;
/*
GC gc;
/*
XEvent ev, nextev;
/*
KeySym key;
/*
XSetWindowAttributes xswa;
/*
XClassHint classhint;
/*
Atom wm_delete_window;
/*
Atom wm_protocols;
/*
unsigned long foreground,
/*
background;
/*
char text[10];
/*
int i, done;
/*
/*****************
Inicializao
identifica o display a usar */

nmero da tela do display */
a janela raiz e a da nossa aplicao */
contexto grfico (atributos de desenho ) */
eventos */
smbolo da tecla, se evento de teclado */
atributos da janela */
classe e nome da aplicao */
mensagem enviada pelo window manager */
tipo da mensagem */
cor de frente */
cor de fundo */
buffer de texto */
variveis auxiliares */
******************************/
display = XOpenDisplay(NULL);
if (display == NULL) {
fprintf(stderr, "XOpenDisplay falhou!\n");
exit(1);
}
screen = DefaultScreen(display);
root = DefaultRootWindow(display);
background = WhitePixel(display, screen);
foreground = BlackPixel(display, screen);
/* conecta-se ao servidor */
/*
/*
/*
/*
descobre a tela padro, */

a janela raiz, */
e cores de frente e fundo */
da tela */
xswa.background_pixel = background;
/* define os atributos da */
xswa.border_pixel = foreground;
/* janela da aplicao */
xswa.backing_store = WhenMapped;
/* usa backing-store */
xswa.event_mask = ButtonPressMask | KeyPressMask |
/* tipos de eventos */
ExposureMask | StructureNotifyMask; /* que interessam */
14
/* Cria a janela */
win = XCreateWindow(
display,
root,
200, 300,
350, 250, 5,
CopyFromParent,
InputOutput,
CopyFromParent,
CWBackPixel | CWBorderPixel |
CWBackingStore | CWEventMask,
&xswa);
/*
/*
/*
/*
/*
/*
/*
/*
display */
janela pai */
posio (x,y) */
largura, altura, largura da borda */
profundidade */
classe */
visual */
atributos a estabelecer */
/* "Hints" para o window manager */

classhint.res_name = "hello";
classhint.res_class = "Hello";
XmbSetWMProperties(
display, win,
/* display, janela */
"Hello, cruel world!",
/* ttulo da janela */
"Hello",
/* ttulo do cone */
argv, argc, None, None, &classhint);
/* WM_DELETE_WINDOW a mensagem do window manager, mandando terminar */
wm_delete_window = XInternAtom (display, "WM_DELETE_WINDOW", False);
wm_protocols = XInternAtom (display, "WM_PROTOCOLS", False);
(void) XSetWMProtocols (display, win, &wm_delete_window, 1);
/* Define o tormato do cursor do mouse usado na janela */
XDefineCursor(display, win, XCreateFontCursor(display, XC_man));
gc = XCreateGC(display, win, 0, 0);
XSetBackground(display, gc, background);
XSetForeground(display, gc, foreground);
XMapRaised(display, win);
/*****************
/* torna a janela visvel no display */
Lao de Tratamento de Eventos
******************************/
done = False;
while (!done) {
#ifdef TEST_PENDING
if (XPending(display) > 0)
XNextEvent(display, &ev); /* obtm o prximo evento */
else
fprintf(stderr, "Nenhum evento na fila\n");
#else
XNextEvent(display, &ev);
/* obtm o prximo evento */
#endif
switch (ev.type) {
case Expose:
/* Comprime uma seqncia de Exposes, para evitar repetidas repinturas,
* j que para um redimensionamento da janela o servidor X envia vrios
* Exposes consecutivos. Verifica o contedo da fila de eventos antes de
* ler porque XNextEvent bloqueante */
15
while (
(XEventsQueued(display, QueuedAfterReading) > 0) &&
(XPeekEvent(display, &nextev), (nextev.type == Expose))
) {
XNextEvent(display, &ev);
}
redraw_callback(ev, gc);
/* redesenha a tela */
break;
case MappingNotify:
XRefreshKeyboardMapping(&ev.xmapping);
break;
case ConfigureNotify:
/* Reconfiguraes da janela (alterao de tamanho, etc). Se
* ConfigureNotify seguido de Expose, a janela foi redimensionada,
* caso contrrio foi apenas movida. No primeiro caso necessrio
* recalcular a geometria do contedo da janela. */
if (
(XEventsQueued(display, QueuedAfterReading) > 0) &&
(XPeekEvent(display, &nextev), (nextev.type == Expose))
) {
configure_callback(ev, gc);
/* na verdade, no faz nada :-) */
}
break;
case ButtonPress:
/* boto do mouse pressionado */
button_callback(ev, gc);
break;
case KeyPress:
/* tecla pressionada, qual delas? */
XLookupString(&ev.xkey, text, 10, &key, NULL);
switch (key) {
case XK_Q:
/* Q ou q: fim */
case XK_q:
done = True;
break;
}
/* switch(ev.xkey) */
break;
/* case KeyPress */
case ClientMessage:
/* mensagem de outro cliente */
if (ev.xclient.message_type == wm_protocols &&
ev.xclient.data.l[0] == wm_delete_window)
done = True;
/* window manager mandou fechar a janela */
else
XBell (display, 0);
/* mensagem desconhecida: faz "bip" */
break;
/* case ClientMessage */
default:
fprintf(stderr, "Tipo de evento desconhecido\n");
}
/* switch(ev.type) */
}
/* while(!done) */
/*****************
Trmino
******************************/
XFreeGC(display, gc);
XDestroyWindow(display, win);
XCloseDisplay(display);
return 0;
16
}
Para compilar este programa, em Linux ou FreeBSD, so usados os seguintes comandos:
cc -c -I/usr/X11R6/include hello-Xlib.c
cc -L/usr/X11R6/lib hello-Xlib.o -o hello-Xlib -lX11
Verso Xaw
O arquivo hello-Xaw.c, mostrado a seguir, um exemplo que usa o X Toolkit e Xaw. Observe-se a simplificao das trs
etapas (inicializao, criao da interface e lao de eventos). Como Xaw no prov um tratamento padro para a mensagem
WM_DELETE_WINDOW gerada pelo gerenciador de janelas, preciso incluir o cdigo necessrio, semelhana do que foi
feito na verso Xlib.
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Xaw/Command.h>
static Atom wm_delete_window;
static Atom wm_protocols;
static void WMProtocols(Widget w, XEvent *ev, String *params, Cardinal *n)
{
if (ev->type == ClientMessage &&
ev->xclient.message_type == wm_protocols &&
ev->xclient.data.l[0] == wm_delete_window) {
XtAppSetExitFlag(XtWidgetToApplicationContext(w));
}
}
static void QuitCallback(Widget w, XtPointer cdata, XtPointer cbs)
{
XtAppSetExitFlag(XtWidgetToApplicationContext(w));
}
XtActionsRec actions[] = {
{"WMProtocols", WMProtocols}
};
String fallback[] = {
"*button.background: rgb:c0/c0/c0",
"*button.font: -b&h-lucida-bold-r-normal-*-*-240-*-*-p-*-*-*",
"*button.label: Hello, world!",
NULL
};
int main(int argc, char *argv[])
{
XtAppContext app;
Widget top, button;
XtSetLanguageProc(NULL, (XtLanguageProc)NULL, NULL);
17
top = XtVaAppInitialize(
&app,
"XHello",
NULL, 0,
&argc, argv,
fallback,
NULL);
/*
/*
/*
/*
/*
/*
contexto da aplicao */
classe da aplicao */
lista de opes da linha de comando */
argumentos da linha de comando */
para arquivo app-defaults perdido */
termina lista varargs */
XtAppAddActions(app, actions, XtNumber(actions));

XtOverrideTranslations(top,
XtParseTranslationTable ("<Message>WM_PROTOCOLS: WMProtocols()"));
button = XtVaCreateManagedWidget(
"button",
/* nome arbitrrio para o widget */
commandWidgetClass, /* classe de widget de Label.h */
top,
/* widget pai */
NULL);
/* termina lista varargs */
XtAddCallback(button, XtNcallback, QuitCallback, NULL);
XtRealizeWidget(top);
wm_delete_window = XInternAtom(XtDisplay(top), "WM_DELETE_WINDOW", False);
wm_protocols = XInternAtom(XtDisplay(top), "WM_PROTOCOLS", False);
(void) XSetWMProtocols(XtDisplay(top), XtWindow(top), &wm_delete_window, 1);
XtAppMainLoop(app);
return 0;
}
Para compilar o programa anterior:
cc -c -I/usr/X11R6/include hello-Xaw.c
cc -L/usr/X11R6/lib hello-Xaw.o -o hello-Xaw -lXaw -lXt -lX11
2.12.3 Processamento de eventos
Obteno de eventos. Como evidenciado no programa hello-Xlib, o lao de processamento de eventos comea com
XNextEvent(display, &ev). XNextEvent a funo que obtm o prximo evento recebido do display
display e o armazena da estrutura ev, do tipo XEvent. O tipo XEvent declarado como uma estrutura contendo
um campo identificador de tipo, chamado type, e uma unio (union, em C) de diversas estruturas de formatos
diferentes. Obtido o evento, preciso responder a ele de acordo com o contedo do campo type.
Se no houver nenhum evento na fila, a funo XNextEvent aguarda at que seja enviado um, o que impede a
continuao do programa. Uma forma de evitar que isso acontea, permitindo que a aplicao faa algo de til
enquanto no tem eventos a processar, usar a funo XEventsQueued. Conforme mostrado no programa, essa
funo retorna o nmero de eventos no processados na fila (o segundo parmetro determina o comportamento exato
da funo). A funo XPeekEvent, por sua vez, faz quase o mesmo que XNextEvent, com uma diferena: o
evento no retirado da fila.
Seleo de eventos. O cliente X pode se selecionar os tipos de eventos que deseja receber. No nosso exemplo, isso feito
por meio do campo event_mask da estrutura xswa, do tipo XSetWindowAttributes, passada como parmetro
para a funo XCreateWindow. Isso, porm, no evita que seqncias de eventos do mesmo tipo sejam enviadas
para o cliente.
O programa demonstra uma tcnica bastante comum, chamada compresso de eventos, que consiste em descartar
seqncias de eventos do mesmo tipo e processar apenas o ltimo deles. No caso, estamos comprimindo o tratamento
18
do evento do tipo Expose, recebido sempre que a janela exposta. A finalidade evitar que o contedo da janela
seja redesenhado mltiplas vezes medida que ela redimensionada pelo gerenciador de janelas.
2.12.4 Primitivas de desenho
X possui uma srie de mecanismos para a gerao de formas geomtricas simples.
Pontos. Pontos individuais so desenhados usando a funo XDrawPoint:
XDrawPoint(display, d, gc, x, y)
Display *display;
Drawable d;
GCgc;
int x, y;
Mltiplos pontos podem ser desenhados de uma s vez com a funo XDrawPoints:
typedef struct {
short x, y;
} XPoint;
XDrawPoints(display, d, gc, points, npoints, mode)
Display *display;
Drawable d;
GC gc;
XPoint *points;
int npoints;
int mode;
Drawable pode ser uma janela ou um pixmap. GC um contexto grfico, que determina os atributos usados para
desenho.
Linhas. Linhas so desenhadas com a funo XDrawLine:
XDrawLine(display, d, gc, x1, y1, x2, y2)
Display *display;
Drawable d;
GC gc;
int x1, y1, x2, y2;
Assim como no caso dos pontos, mltiplas linhas podem ser desenhadas de uma nica vez usando a funo XDrawLines:
XDrawLines(display, d, gc, points, npoints, mode)
Display *display;
Drawable d;
GC gc;
XPoint *points;
int npoints;
int mode;
Arcos (crculos e elipses). XDrawArc e XDrawArcs permitem desenhar um ou diversos arcos de cada vez:
19
XDrawArc(display, d, gc, x, y, width, height, angle1, angle2)

Display *display;
Drawable d;
GC gc;
int x, y;
unsigned int width, height;
int angle1, angle2;
typedef struct {
short x, y;
unsigned short width, height;
short angle1, angle2;
} XArc;
XDrawArcs(display, d, gc, arcs, narcs)
Display *display;
Drawable d;
GC gc;
XArc *arcs;
intnarcs;
1
graus. Isto pode parecer estranho, mas tem a
importante observar que os ngulos so sempre expressos em 64
vantagem de permitir que se usem valores inteiros para os ngulos.
Retngulos. XDrawRectangle e XDrawRectangle permitem desenhar um ou diversos retngulos de cada vez:

XDrawRectangle(display, d, gc, x, y, width, height)
Display *display;
Drawable d;
GC gc;
int x, y;
unsigned int width, height;
typedef struct {
short x, y;
unsigned short width, height;
} XRectangle;
XDrawRectangles(display, d, gc, rectangles, nrectangles)
Display *display;
Drawable d;
GC gc;
XRectangle rectangles[];
int nrectangles;
Observe-se que os retngulos no podem ser rotacionados em relao aos eixos x e y da tela. Caso seja necessrio
fazer isto, ser preciso calcular as coordenadas de cada vrtice do retngulo e desenh-lo usando XDrawLines.
Polgonos. Retngulos so os nicos polgonos suportados diretamente. Caso se queira desenhar outros tipos, ser necessrio calcular as coordenadas dos vrtices e desenh-los usando XDrawLines.
Preenchimento de reas. As funes XFillArc, XFillArcs, XFillPolygon, XFillRectangle e XFillRectangles permitem desenhar as mesmas formas geomtricas mencionadas anteriormente, mas preenchidas com uma
cor ou padro de pontos.
20
2.12.5 Manipulao de contextos grficos

A maioria das funes grficas usa GCs para informar ao servidor como realizar as operaes, isto , que cores de frente e
fundo, estilos de linhas, padres de preenchimento, etc. usar. O uso de GCs conveniente porque evita que esses parmetros
tenham de ser enviados ao servidor a cada operao de desenho solicitada.
Criao de GCs. A funo XCreateGC permite criar um novo GC:
GC XCreateGC(display, d, valuemask, values)
Display *display;
Drawable d;
unsigned long valuemask;
XGCValues *values;
O parmetro values o endereo de uma estrutura contendo os atributos do GC e o parmetro valuemask indica
quais desse atributos devem ser copiados para o novo GC em substituio aos valores padro.
Alterao dos atributos de um GC. XChangeGC permite alterar os atributos, de maneira semelhante:
XChangeGC(display, gc, valuemask, values)
Display *display;
GC gc;
unsigned long valuemask;
XGCValues *values;
Para facilitar a programao, existe um conjunto de funes de convenincia que permitem alterar individualmente os
atributos de um GC. Exemplos so as funes XSetBackground e XSetForeground.
2.13 Documentao/URLs
Documentao sobre a Xlib, Xt e Xaw pode ser encontrada na forma de pginas de manual normalmente instalados em
sistemas com o X. Manuais em PostScript R podem ser obtidos via FTP annimo em:
ftp://ftp.x.org/pub/R6.4/xc/docs/hardcopy/X11/
ftp://ftp.x.org/pub/R6.4/xc/docs/hardcopy/Xt/
ftp://ftp.x.org/pub/R6.4/xc/docs/hardcopy/Xaw/
Muitas referncias sobre sobre Motif podem ser encontradas a partir dos seguintes endereos:
Home-page do projeto LessTif: http://www.lesstif.org/

The Motif Zone: http://www.motifzone.net/
Motif FAQ: http://www.rahul.net/kenton/mfaq.html
Documentao sobre o toolkit Gtk, assim como as bibliotecas, podem ser encontradas na prpria home page do Gtk (h
ponteiros para tpicos relacionados, como o Glade e GNOME):
http://www.gtk.org/
Documentao sobre o toolkit Qt, assim como suas bibliotecas, podem ser encontradas no site da Troll Tech:
http://www.trolltech.com/
Christophe Tronche criou uma verso em HTML de [2], disponvel em http://www.tronche.com/gui/x/xlib/.
21
2.14 Concluso
O X Window System oferece um conjunto poderoso de mecanismos para a construo de aplicaes grficas interativas.
Graas sua arquitetura cliente-servidor e aos princpios de independncia entre aplicao e hardware grfico, torna-se
muito mais simples construir programas compatveis com diferentes arquiteturas.
Graas sua filosofia de oferecer mecanismo e no poltica, associada extensibilidade do protocolo, X tem evoludo
ao longo de mais de 15 anos de existncia, sempre se conservando estvel e confivel. A existncia de uma especificao
formal rgida para o protocolo garante tambm a interoperabilidade em ambientes heterogneos de hardware/software. O X
Window System constitui uma plataforma verstil de desenvolvimento combinado com bibliotecas de interface e ferramentas
grficas de mais alto nvel como o OpenGL, que ser visto na prxima seo.
3 OpenGL
Padres grficos, como GKS (Graphics Kernel System) e PHIGS, tiveram importante papel na dcada de 80, inclusive
ajudando a estabelecer o conceito de uso de padres mesmo fora da rea grfica, tendo sido implementados em diversas
plataformas. Nenhuma destas APIs, no entanto, conseguiu ter grande aceitao [20].
A interface destinada a aplicaes grficas 2D ou 3D deve satisfazer diversos critrios como, por exemplo, ser implementvel em plataformas com capacidades distintas sem comprometer a performance grfica do hardware e sem sacrificar o
controle sobre as operaes de hardware [21].
Atualmente, o OpenGL (GL significa Graphics Library) uma API de grande utilizao no desenvolvimento de aplicaes em Computao Grfica [22]. Este padro o sucessor da biblioteca grfica conhecida como IRIS GL, desenvolvida
pela Silicon Graphics como uma interface grfica independente de hardware [23]. A maioria das funcionalidades da IRIS GL
foi removida ou rescrita no OpenGL e as rotinas e os smbolos foram renomeados para evitar conflitos (todos os nomes comeam com gl ou GL_). Na mesma poca foi formado o OpenGL Architecture Review Board, um consrcio independente
que administra o uso do OpenGL, formado por diversas empresas da rea.
OpenGL uma interface que disponibiliza um controle simples e direto sobre um conjunto de rotinas, permitindo ao
programador especificar os objetos e as operaes necessrias para a produo de imagens grficas de alta qualidade. Por
ser um padro destinado somente renderizao [21], o OpenGL pode ser utilizado em qualquer sistema de janelas (por
exemplo, X ou Windows), aproveitando-se dos recursos disponibilizados pelos diversos hardwares grficos existentes. No
X Window System ele integrado atravs do GLX (OpenGL Extension for X), um conjunto de rotinas para criar e gerenciar
um contexto de renderizao do OpenGL no X [21], [23]. Alm do GLX, h uma biblioteca alternativa para interfaceamento
no X denominada GLUT (OpenGL Utility Toolkit) [24]. Esta biblioteca possui um conjunto de ferramentas que facilita a
construo de programas utilizando o OpenGL. Podemos citar, por exemplo, funes para gerenciamento de janelas, rotinas
para gerao de vrios objetos grficos 3D ou dispositivos de entrada de dados. Uma vantagem em se utilizar a GLUT que
esta biblioteca compatvel com quase todas as implementaes OpenGL em Windows e X. Em aplicaes que requerem
uma maior utilizao dos recursos do X, pode-se utilizar a GLUT juntamente com a GLX.
Esta seo descreve as funcionalidades do OpenGL e, quando necessrio, apresenta algumas rotinas disponveis no GLX
e na GLUT.
3.1 Objetos geomtricos

OpenGL uma interface que no possui rotinas de alto nvel de abstrao. Desta forma, as primitivas geomtricas so
construdas a partir de seus vrtices. Um vrtice representado em coordenadas homogneas (x, y, z, w). Se w for diferente
de zero, estas coordenadas correspondem a um ponto tridimensional euclidiano (x/w, y/w, z/w). Assim como as demais
coordenadas, pode-se tambm especificar o valor para a coordenada w. Mas isto raramente feito, sendo assumido o valor 1.0
como default. Alm disso, todos os clculos internos so realizados com pontos definidos no espao tridimensional. Assim
sendo, os pontos bidimensionais especificados pelo usurio (i.e., somente definidos com as coordenadas x e y) so trabalhados
no OpenGL como pontos tridimensionais, onde a coordenada z igual a zero. Os segmentos de reta so representados por
seus pontos extremos e os polgonos so reas definidas por um conjunto de segmentos. No OpenGL, alguns cuidados quanto
definio de um polgono devem ser tomados: um polgono dever ser sempre convexo e no poder ter interseo das suas
arestas (conhecido como polgono simples). A especificao de um vrtice feita atravs das funes glVertex*()3.
3 O * ser utilizado neste texto para representar variantes no nome da funo. As variaes restringem-se ao nmero e/ou ao tipo dos argumentos (por
exemplo, glVertex3i() definir um vrtice com trs coordenadas inteiras).
22
Em muitas aplicaes grficas h a necessidade de definir, por exemplo, polgonos no simples, polgonos cncavos ou
polgonos com furos [22]. Como qualquer polgono pode ser formado a partir da unio de polgonos convexos, algumas
rotinas mais complexas, derivadas das primitivas bsicas, so fornecidas na GLU (OpenGL Utility Library) [22]. Esta
biblioteca utiliza somente funes GL (funes padres do OpenGL) e est disponvel em todas as implementaes do
OpenGL.
Para traar um conjunto de pontos, um segmento ou um polgono, os vrtices necessrios para a definao destas primitivas so agrupados entre as chamadas das funes glBegin() e glEnd(). Pode-se adicionar tambm informaes a um
vrtice, como uma cor, um vetor normal ou uma coordenada para a textura, utilizando um nmero restrito de funes que
so vlidas entre o par glBegin() e glEnd() [22]. importante salientar que a restrio quanto utilizao apenas
para as rotinas do OpenGL; outras estruturas de programao podero ser utilizadas normalmente entre o par de funes. O
argumento da funo glBegin() indicar a ordem como sero associados os vrtices, conforme ilustrado na Figura 6.
Figura 6: Primitivas geomtricas do OpenGL [23].
No OpenGL, uma primitiva pode ser traada de diferentes maneiras, conforme a ordem selecionada e o conjunto de
vrtices definido. O trecho de cdigo a seguir apresenta um exemplo do traado de uma circunferncia.
#define PI 3.1415926535
int circle_points = 100;
glBegin(GL_LINE_LOOP);
for (i = 0; i < circle_points; i++)
{
angle = 2*PI*i/circle_points;
glVertex2f(cos(angle), sin(angle));
}
glEnd();
O exemplo acima no o modo mais eficiente para traar uma circunferncia, especialmente se esta primitiva for utilizada
vrias vezes. Neste caso, o desempenho ficar comprometido porque h o clculo do ngulo e a execuo das funes sin()
e cos() para cada vrtice. Alm disso, h tambm o overhead do loop. Poderamos solucionar este problema calculando as
coordenadas dos vrtices uma nica vez e armazenando-os em uma tabela, ou utilizando uma rotina GLU/GLUT, ou ainda
criando uma display list (lista de instrues).
A display list uma maneira de definir um grupo de rotinas do OpenGL que sero executadas posteriormente, respeitando a seqncia em que foram definidas. A maioria das rotinas do OpenGL pode ser armazenada em uma display list
ou executada na forma imediata (immediate mode). Pode-se utilizar ambos os artifcios no desenvolvimento de aplicaes
grficas. Entretanto, rotinas do OpenGL com passagem de parmetros por referncia ou que retornem um valor no sero
armazenadas. A restrio adotada porque uma lista poder, por exemplo, ser executada fora do escopo de onde os parme-
23
tros foram originalmente definidos. Estas rotinas, as rotinas que no pertencerem ao OpenGL e as variveis sero avaliadas
no momento da criao da lista, sendo substitudas por seus valores resultantes.
Uma display list definida agrupando as instrues entre as funes glNewList() e glEndList(), de modo similar
definio de uma primitiva geomtrica. O trecho de cdigo para traar a circunferncia pode ento ser rescrito utilizando
uma lista, como apresentado a seguir.
#define PI 3.1415926535
#define CIRC 1
int circle_points = 100;
glNewList(CIRC, GL_COMPILE);
glBegin(GL_LINE_LOOP);
for (i = 0;i < circle_points;i++)
{
angle = 2*PI*i/circle_points;
glVertex2f(cos(angle),sin(angle));
}
glEnd();
glEndList();
O argumento CIRC um nmero inteiro que identificar a lista. O atributo GL_COMPILE indicar ao sistema que a lista
ser compilada, porm o seu contedo no ser executado. Caso seja necessrio executar seu contedo, utilizado o atributo
GL_COMPILE_AND_EXECUTE. Quando for necessrio, a lista poder ser utilizada atravs da rotina glCallList().
Uma alternativa para modelar objetos que so difceis de serem definidos atravs de vrtices utilizar rotinas fornecidas
nas bibliotecas GLU e GLUT, como j mencionado anteriormente. Por exemplo, para traarmos uma esfera simplesmente
executamos a rotina glutWireSphere(), onde os argumentos definiro o raio, o nmero de linhas longitudinais e o
nmero de linhas latitudinais.
3.2 Visualizao
Em Computao Grfica, organizar as operaes necessrias para converter objetos definidos em um espao tridimensional
para um espao bidimensional (tela do computador) uma das principais dificuldades no desenvolvimento de aplicaes.
Para isso, alguns aspectos devem ser considerados:
Transformaes. So operaes descritas pela multiplicao de matrizes. Estas matrizes podem descrever uma modelagem,
uma visualizao ou uma projeo, dependendo do contexto.
Clipping. a eliminao de objetos (ou partes de objetos) que esto situados fora do volume de visualizao.
Viewport. a operao de correspondncia entre as coordenadas transformadas e os pixels da tela.
As matrizes de modelagem posicionam e orientam os objetos na cena, as matrizes de visualizao determinam o posicionamento da cmera e as matrizes de projeo determinam o volume de visualizao (anlogo escolha da lente para
uma mquina fotogrfica). No OpenGL, as operaes com estas matrizes so realizadas atravs de duas pilhas: a pilha que
manipula as matrizes de modelagem e de visualizao (modelview) e a pilha que manipula as matrizes de projeo (projection). As operaes de modelagem e de visualizao so trabalhadas na mesma pilha, pois pode-se posicionar a cmera em
relao cena ou vice-versa, onde o resultado de ambas operaes ser o mesmo. A matriz atual4 da modelview conter o
produto cumulativo das multiplicaes destas matrizes. Ou seja, cada matriz de transformao utilizada ser multiplicada
pela matriz atual, e o resultado ser colocado como a nova matriz atual, representando a transformao composta. A pilha
projection comporta-se da mesma maneira. Entretanto, na maioria das vezes esta pilha conter apenas duas matrizes: uma
matriz identidade e uma matriz de projeo, pois um volume de visualizao pode ser definido apenas por uma matriz de
transformao.
A pilha de matrizes utilizada no OpenGL para facilitar a construo de modelos hierrquicos, onde objetos complexos
so construdos a partir de objetos mais simples. Alm disso, a pilha um mecanismo ideal para organizar a seqncia de
4A
matriz atual aquela que est no topo da pilha.
24
operaes sobre matrizes. Segundo a metodologia de uma pilha de dados, a transformao especificada mais recentemente
(a ltima a ser empilhada) ser a primeira a ser aplicada [25]. OpenGL possui um conjunto de rotinas que manipulam as
pilhas e as matrizes de transformao. Abordaremos, de forma sucinta, as principais rotinas e suas utilizaes.
A definio da pilha na qual se deseja trabalhar feita atravs da rotina glMatrixMode(), indicada pelo argumento
GL_MODELVIEW ou GL_PROJECTION. Aps definida a pilha, ela pode ser ento inicializada com a matriz identidade,
atravs da rotina glLoadIdentity(). Como default, toda pilha conter apenas a matriz identidade.
Para o posicionamento da cmera ou de um objeto so utilizadas as rotinas glRotate*() e/ou glTranslate*(),
que definem respectivamente matrizes de rotao e de translao. Por default, a cmera e os objetos na cena so originalmente
situados na origem. H tambm a rotina glScale*(), que define uma matriz de escalonamento.
O controle sobre a pilha pode ser feito atravs das rotinas glPushMatrix() e glPopMatrix(). A rotina glPushMatrix() duplica a matriz atual, colocando a cpia no topo da pilha em questo. Este mtodo permite preservar o
estado da pilha em um determinado momento para posterior recuperao, realizada por meio da rotina glPopMatrix().
O exemplo a seguir demonstra a utilizao destas rotinas. O trecho de cdigo desenha um automvel, assumindo a
existncia das rotinas para desenhar o corpo do automvel, a roda e o parafuso.
desenha_roda_parafusos()
{
long i;
desenha_roda();
// desenha cinco parafusos na roda
for (i = 0; i < 5; i++)
{
glPushMatrix();
glRotatef(72.0*i,0.0,0.0,1.0);
glTranslatef(3.0,0.0,0.0);
desenha_parafuso();
glPopMatrix();
}
}
desenha_corpo_roda_parafuso()
{
desenha_corpo_carro();
// posiciona e desenha a primeira roda
glPushMatrix();
glTranslatef(40,0,30);
desenha_roda_parafusos();
glPopMatrix();
// posiciona e desenha a segunda roda
glPushMatrix();
glTranslatef(40,0,-30);
desenha_roda_parafusos();
glPopMatrix();
// desenha as outras duas rodas de forma similar,
// alterando apenas a posio
// ...
}
Quanto definio do volume de visualizao, OpenGL prov duas transformaes de projeo: a perspectiva e a
ortogonal.
25
A projeo perspectiva define um volume de visualizao onde a projeo do objeto reduzida a medida que ele
afastado da cmera. Esta projeo fornecida no OpenGL atravs da rotina glFrustum(). O volume de visualizao
calculado atravs de seis planos de corte, sendo os quatro planos que formam a janela (left, right, top e bottom), mais os
planos near e far, como ilustrado na Figura 7.
Figura 7: O volume de visualizao da projeo perspectiva.
A projeo ortogonal define um volume de visualizao onde a projeo do objeto no afetada pela sua distncia
em relao cmera. Esta projeo fornecida no OpenGL atravs da rotina glOrtho(). O volume de visualizao
calculado de modo similar projeo perspectiva, atravs dos mesmos seis planos de corte. Os planos formaro um
paraleleppedo retangular, ilustrado na Figura 8.
Figura 8: O volume de visualizao da projeo ortogonal.
Para estabelecer a rea na tela onde a imagem ser renderizada utilizada a rotina glViewport(). Esta rotina poder
distorcer a imagem, caso a relao entre a altura e a largura da janela na tela no corresponder a mesma relao utilizada
para definir a janela no volume de visualizao.
Alm das matrizes de transformao definidas pelo OpenGL, pode-se tambm atribuir ou multiplicar a matriz atual
por uma determinada matriz de transformao especificada pelo usurio, respectivamente atravs das rotinas glLoadMatrix*() ou das rotinas glMultMatrix*().
3.3 Cor
OpenGL possui dois modos diferentes para tratar cor: o modo RGBA e o modo indexado de cor [23]. A definio do
modo de cor depender da biblioteca que o programa est utilizando para interfacear com o sistema de janelas. A GLUT,
por exemplo, prov uma rotina denominada glutInitDisplayMode(), onde a seleo feita atravs dos parmetros
GLUT_RGBA ou GLUT_INDEX. O default GLUT_RGBA, caso no seja especificado nenhum dos modos.
O modo RGBA possui as componentes vermelho, verde, azul e alfa, respectivamente. Os trs primeiros representam as
cores primrias e so lineares (variando de 0.0 a 1.0), sendo muito teis para renderizar cenas realsticas. A componente alfa
utilizada, por exemplo, em operaes de blending (mistura) e transparncia. Esta componente representa a opacidade da
cor, variando de 0.0, onde a cor totalmente transparente, at 1.0, onde a cor totalmente opaca. Desta forma, o valor alfa
no visvel na tela, sendo usado apenas para determinar como o pixel ser exibido. As rotinas glColor*() so utilizadas
para definir os valores para cada componente. O trecho de cdigo a seguir define um tringulo no modo RGBA.
26
glBegin(GL_TRIANGLES);
glColor3f(1.0, 0.0, 0.0);
glVertex2f(5.0, 5.0);
glColor3f(0.0, 1.0, 0.0);
glColor3f(0.0, 0.0, 1.0);
glEnd();
Cada vrtice do polgono foi definido com uma cor e o seu interior ser preenchido conforme o modo indicado atravs da
rotina glShadeModel(). Pode-se indicar o modo GL_FLAT, onde a cor de um vrtice do polgono ser utilizada como
padro para toda a primitiva geomtrica, ou GL_SMOOTH, onde as cores para o interior do polgono so interpoladas entre
as cores definidas para os vrtices (mtodo Gouraud shading) (ver Figura 9). Este ltimo modo o default.
Figura 9: Um tringulo desenhado no modo smooth.
O modo indexado de cor utiliza um mapa de cores. Este mapa armazena em cada ndice os valores para cada componente
primria (RGB). A cor ento trabalhada pelo ndice, e no por suas componentes. OpenGL no tem rotinas especficas para
alocao de cores, sendo o sistema de janelas responsvel por esta funo. No X, por exemplo, a rotina XAllocColor()
utilizada para alocao de cores. J a biblioteca GLUT prov a rotina glutSetColor(), que define as componentes
primrias para um determinado ndice no mapa de cores. As rotinas glIndex*() so usadas para selecionar o ndice, no
mapa de cores, da cor atual.
3.4 Iluminao
OpenGL utiliza o modelo de Phong para prover uma cena com realismo [25]. Uma cena renderizada levando-se em considerao alguns aspectos como, por exemplo, o tipo de fonte de iluminao que est sendo usada na cena e as propriedades do
material para cada superfcie. Alguns efeitos complexos como a reflexo da luz e sombra no so fornecidos pelo modelo,
embora tcnicas e algoritmos estejam disponveis para simular tais efeitos.
Para implementar o modelo de iluminao, o OpenGL decompe o raio luminoso nas componentes primrias RGB.
Dessa forma, a cor para uma fonte de luz caracterizada pela porcentagem da intensidade total de cada componente emitida.
Se todas as componentes possurem o valor 1.0, a luz ser a mais branca possvel. Se todos os valores forem 0.5, ainda
ser a cor branca, mas com uma intensidade menor (aparentando a cor cinza). Para os materiais, os valores correspondem
porcentagem refletida de cada componente primria. Se a componente vermelha for 1.0, a componente verde for 0.5
e a componente azul for zero para um determinado material, este refletir toda a intensidade da luz vermelha, metade da
intensidade da luz verde e absorver a luz azul. Por exemplo, uma bola vermelha que receba a incidncia das luzes vermelha,
verde e azul refletir somente a luz vermelha, absorvendo as luzes verde e azul. Caso seja incidida uma luz branca (composta
por uma intensidade igual das componentes vermelha, verde e azul), a superfcie da bola refletir apenas a luz vermelha e,
por isso, a bola ser vista com esta cor. Mas caso seja incidida apenas uma luz verde ou azul, a bola ser vista com a cor
preta, pois no haver luz refletida.
Uma vez que um raio luminoso ser dividido nas suas componentes primrias RGB, o OpenGL considera ainda que est
diviso ser realizada para cada componente de luz do modelo de iluminao, que so:
Componente emitida. aquela componente de luz originada de um objeto, no sendo afetada por qualquer fonte de luz.
27
Componente ambiente. a componente de luz proveniente de uma fonte que no possvel determinar. Por exemplo, a
luz dispersa em uma sala tem uma grande quantidade da componente ambiente, pois esta luz resultante de vrias
reflexes nas superfcies contidas na cena.
Componente difusa. a componente de luz refletida em todas as direes quando esta incide sobre uma superfcie, proveniente de uma direo especfica. A intensidade de luz refletida ser a mesma para o observador, no importando
onde ele esteja situado. Qualquer luz proveniente de uma determinada posio ou direo provavelmente tem uma
componente difusa.
Componente especular a componente de luz refletida em uma determinada direo quando esta incide sobre uma superfcie, proveniente de uma direo especfica. Uma superfcie como um espelho de alta qualidade produz uma grande
quantidade de reflexo especular, assim como os metais brilhantes e os plsticos. Entretanto, materiais como o giz
possui uma baixa reflexo especular.
No modelo de iluminao do OpenGL, a luz na cena pode ser proveniente de vrias fontes, sendo controladas individualmente. Algumas luzes podem ser provenientes de uma determinada direo ou posio, enquanto outras podem estar
dispersas na cena. Entretanto, as fontes de luz somente tm efeito nas superfcies que definiram as suas propriedades do
material. Em relao s propriedades do material, elas podem ser definidas de modo a emitir luz prpria, a dispersar a luz
incidente em todas as direes e a refletir uma poro da luz incidente em uma determinada direo, como uma superfcie
espelhada ou reluzente.
Quanto aos tipos de fonte de iluminao, o OpenGL possui:
Fontes pontuais. uma fonte que irradia energia luminosa em todas as direes.
Fontes spots. uma fonte pontual direcional, isto , tem uma direo principal na qual ocorre a mxima concentrao de
energia luminosa; fora desta direo ocorre uma atenuao desta energia.
Alm das fontes citadas anteriormente, o OpenGL prov uma luz que no possui uma fonte especfica, denominada
luz ambiente. As rotinas glLight*() so utilizadas para especificar as propriedades da fonte de iluminao e as rotinas
glLightModel*() descrevem os parmetros do modelo de iluminao como, por exemplo, a luz ambiente.
Da mesma maneira que a luz, os materiais tm diferentes valores para as componentes especular, difusa e ambiente,
determinando assim suas reflexes na superfcie. Uma reflexo da componente ambiente do material combinada com a
componente ambiente da luz, da mesma forma a reflexo da componente difusa do material com a componente difusa da
luz e similarmente para a reflexo especular. As reflexes difusa e ambiente definem a cor do material, enquanto a reflexo
especular geralmente produz uma cor branca ou cinza. As rotinas glMaterial*() so utilizadas para determinar as
propriedades dos materiais.
Depois de definidas as caractersticas de cada fonte de luz e dos materiais, deve-se utilizar a rotina glEnable()
para habilitar cada fonte de luz previamente definida. Antes, entretanto, esta rotina deve ser utilizada com o parmetro
GL_LIGHTING, de modo a preparar o OpenGL para os clculos do modelo de iluminao.
O trecho de cdigo a seguir ilustra a definio de um modelo de iluminao no OpenGL para traar uma esfera azul com
o efeito do reflexo da luz (brilho) concentrado em um ponto. Quanto maior o valor da varivel mat_shininess, maior
ser a concentrao da luz e conseqentemente menor o ponto e maior o brilho. O resultado est demonstrado na Figura
10.
// Inicializa as propriedades do material e da fonte de luz
GLfloat mat_specular[] = {1.0, 1.0, 1.0, 1.0};
GLfloat mat_diffuse[] = {0.0, 0.0, 1.0, 1.0};
GLfloat mat_shininess[] = {50.0};
GLfloat light_position[] = {1.0, 1.0, 1.0, 0.0};
glShadeModel(GL_SMOOTH);
// Define as componentes do material
glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular);
glMaterialfv(GL_FRONT, GL_DIFFUSE, mat_diffuse);
glMaterialfv(GL_FRONT, GL_SHININESS, mat_shininess);
28
// Define somente a posio da fonte de luz - os valores das

// componentes sero os valores default
glLightfv(GL_LIGHT0, GL_POSITION, light_position);
// Habilita o modelo de iluminao
glEnable(GL_LIGHTING);
// Habilita a fonte de luz definida
glEnable(GL_LIGHT0);
Figura 10: Exemplo do modelo de

iluminao do OpenGL.
3.5 Textura
Para realizarmos um mapeamento de textura no OpenGL, o procedimento utilizado segue um padro bsico, conforme
descrito a seguir:
1. Especificar a textura.
2. Indicar como a textura ser aplicada para cada pixel.
3. Habilitar o mapeamento de textura.
4. Desenhar a cena, fornecendo as coordenadas geomtricas e as coordenadas de textura.
No OpenGL, quando um mapeamento de textura realizado, cada pixel do fragmento a ser mapeado referencia uma
imagem, gerando um texel. O texel um elemento de textura que representa a cor que ser aplicada em um determinado
fragmento, tendo entre um (uma intensidade) e quatro componentes (RGBA) [20].
Uma imagem de textura disponibilizada pelas funes glTextImage*() podendo, caso necessrio, ser especificada
em diferentes resolues, atravs de uma tcnica denominada mipmapping. O uso de uma textura com multiresoluo
recomendado em cenas que possuam objetos mveis. A medida que estes objetos se movem para longe do ponto de viso,
o mapa de textura deve ser decrementado em seu tamanho na mesma proporo do tamanho da imagem projetada. Desta
maneira, o mapeamento sempre utilizar a resoluo mais adequada para o fragmento.
Para indicar como a textura ser aplicada para cada pixel, necessrio escolher uma das trs possveis funes que
combinam a cor do fragmento a ser mapeado com a imagem da textura, de modo a calcular o valor final para cada pixel.
Pode-se utilizar os mtodos decal, modulate ou blend, de acordo com a necessidade do usurio. O controle do mapeamento
da textura na rea desejada especificado atravs das rotinas glTextEnv*() e as rotinas glTextParameter*()
determinam como a textura ser organizada no fragmento a ser mapeado e como os pixels sero filtrados quando no h
uma exata adaptao entre os pixels da textura e os pixels na tela.
Para desenhar a cena necessrio indicar como a textura estar alinhada em relao ao fragmento desejado. Ou seja,
necessrio especificar as coordenadas geomtricas e as coordenadas de textura. Para um mapeamento de textura bidimensional, o intervalo vlido para as coordenadas de textura ser de 0.0 a 1.0 em ambas direes, diferentemente das coordenadas
do fragmento a ser mapeado onde no h esta restrio. No caso mais simples, por exemplo, o mapeamento feito em
um fragmento proporcional s dimenses da imagem de textura. Nesta situao, as coordenadas de textura so (0,0), (1,0),
(1,1) e (0,1). Entretanto, em situaes onde o fragmento a ser mapeado no proporcional textura, deve-se ajustar as
coordenadas de textura de modo a no distorcer a imagem. Para definir as coordenadas de textura utilizado as rotinas
glTextCoord*().
29
Para habilitar o mapeamento de textura necessrio utilizar a rotina glEnable(), utilizando a constante GL_TEXTURE_1D
ou GL_TEXTURE_2D, respectivamente para um mapeamento unidimensional ou bidimensional.
O trecho de cdigo a seguir demonstra o uso do mapeamento de textura. No exemplo, a textura que consiste de
quadrados brancos e pretos alternados como um tabuleiro de xadrez gerada pelo programa, atravs da rotina makeCheckImage(). O programa aplica a textura em um quadrado, como ilustrado na Figura 11.
// Trecho do cdigo responsvel por toda a inicializao do
// mapeamento de textura
makeCheckImage();
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexImage2D(GL_TEXTURE_2D, 0, 3, checkImageWidth, checkImageHeight, 0, GL_RGB,
GL_UNSIGNED_BYTE, &checkImage[0][0][0]);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
glEnable(GL_TEXTURE_2D);
// Trecho do cdigo responsvel pela definio das coordenadas
// de textura e das coordenadas geomtricas
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0); glVertex3f(-1.0, -1.0, 0.0);
glTexCoord2f(0.0, 1.0); glVertex3f(-1.0, 1.0, 0.0);
glTexCoord2f(1.0, 1.0); glVertex3f(1.0, 1.0, 0.0);
glTexCoord2f(1.0, 0.0); glVertex3f(1.0, -1.0, 0.0);
glEnd();
Figura 11: Exemplo do mapeamento de

textura em um quadrado.
3.6 Framebuffer
Em uma aplicao, a rea utilizada para armazenar temporariamente os dados denominada buffer. Um conjunto de buffers
de uma determinada janela ou de um determinado contexto denominado framebuffer. No OpenGL, h um conjunto de
buffers que podem ser manipulados conforme a necessidade [22]:
Buffers de cor. So normalmente utilizados para traar a imagem. Podem conter cores indexadas ou RGBA. Dependendo
da aplicao, pode-se trabalhar com imagens estreo ou double buffering (dois buffers de imagem, um visvel e outro
no), desde que o sistema de janelas e o hardware suportem.
Buffer de profundidade. utilizado para armazenar, durante a renderizao, o pixel que possuir o menor valor da coordenada z, para as mesmas coordenadas x e y (algoritmo z-buffer).
Buffer Stencil (seleo). Serve para eliminar ou manter certos pixels na tela, dependendo de alguns testes disponibilizados
para este buffer. muito utilizado em simuladores onde necessrio manter certas reas e alterar outras.
30
Buffer de acumulao. Pode ser utilizado para trabalhar com diversas tcnicas como, por exemplo, antialiasing, motion
blur (borro) ou profundidade de campo. Em um conjunto de imagens, cada imagem renderizada acumulada neste
buffer, manipulando-a caso necessrio. A imagem resultante destas acumulaes exibida atravs da transferncia
para um buffer de cor.
3.7 Animao
No OpenGL no h rotinas especficas para produo de animaes. Uma opo a utilizao de um double buffering, desde
que seja disponvel pelo sistema de janelas. No X, por exemplo, h um comando denominado glXSwapBuffers(), que
disponibiliza este recurso [22]. Dessa forma, enquanto um quadro exibido na tela, o prximo quadro est sendo renderizado
no buffer no visvel (auxiliar).
3.8 Concluso
OpenGL uma API grfica 3D que permite ao programador descrever uma variedade de tarefas de renderizao. Este
padro foi projetado para fornecer o mximo acesso s capacidades de diferentes hardwares grficos, sendo implementvel
e executvel em uma variedade de sistemas. Pela sua flexibilidade em modelar e renderizar objetos geomtricos, serve como
uma excelente base para construir bibliotecas para determinados contextos de aplicao, como Java 3D que ser vista na
prxima seo.
4 Java 3D
Java 3D uma interface criada para o desenvolvimento de aplicaes grficas trimidensionais em Java, executada no topo
de bibliotecas grficas de mais baixo nvel, tais como OpenGL e Direct3D, conforme ilustra a Figura 12. De forma mais
precisa, Java 3D um componente da Sun Microsystems, junto com as vrias tecnologias multimdia e grficas suportadas
pela extenso padro Java Media Framework, para o desenvolvimento de aplicaes (aplicativos e/ou applets) 3D.
Figura 12: Relao entre as vrias camadas de software

no contexto de Java 3D.
Com isto, os programadores de aplicaes passam a explorar, agora no mbito das aplicaes grficas tridimensionais, o
conjunto de facilidades e vantagens da plataforma Java, como orientao a objetos, segurana e independncia de plataforma.
Em particular, a orientao a objetos oferece uma abordagem de alto nvel programao e possibilita que o desenvolvedor se
dedique mais criao do que aos problemas de mais baixo nvel pertinentes programao 3D, os quais exigem um esforo
considervel. Por essa razo, programadores no familiarizados com tais detalhes podem tambm explorar o universo 3D em
suas aplicaes. Esta tecnologia grfica vem ainda ao encontro de uma crescente demanda por operaes 3D requisitada hoje
pela Web. Neste sentido, Java 3D se apresenta como uma soluo fortemente vivel, considerando que a mesma disponibiliza
uma interface robusta para Web.
Estas caractersticas facilitam e agilizam o desenvolvimento de aplicaes 3D mais complexas, uma vez que a reutilizao
uma realidade e a compatibilidade com diferentes plataformas uma das premissas bsicas de Java.
Java 3D utiliza alguns conceitos que so comuns a outras tecnologias, tais como a VRML (ver Seo 5), considerada
por alguns autores como sendo a prima mais prxima da Java 3D [26]. Uma aplicao Java 3D projetada a partir de um
31
grafo de cena contendo objetos grficos, luz, som, objetos de interao, entre outros, que possibilitam ao programador criar
mundos virtuais com personagens que interagem entre si e/ou com o usurio [27]. Descrever uma cena usando um grafo
tarefa mais simples do que construir a mesma usando linhas de comando que especificam primitivas grficas, tais como as
do OpenGL. Esta abordagem de mais alto nvel valoriza significativamente a produtividade dos desenvolvedores e facilita
em muito a tarefa dos programadores com pouca experincia em programao 3D.
O conjunto de ferramentas oferecidas por Java 3D possibilita, alm de construir uma cena 3D a partir de um programa,
que esta seja carregada de um arquivo externo, por exemplo uma cena no formato VRML. Este conjunto de propriedades
d a Java 3D grande flexibilidade, fazendo dela uma plataforma vivel para diferentes aplicaes grficas. A literatura
cita aplicaes em visualizao molecular, visualizao cientfica, realidade virtual, sistemas de informao geogrfica,
animao, entre outros [28].
Antes de comearmos a estudar Java 3D, importante fazer uma breve introduo da linguagem Java.
4.1 Java
Java 3D um componente da linguagem Java, que uma linguagem de programao de alto nvel desenvolvida pela Sun
Microsystems. Java se tornou muito popular para a construo de pginas altamente interativas na Web.
Java pode ser usada tanto para o desenvolvimento de programas independentes quanto para o de applets, que so executados dentro de um ambiente hospedeiro (o browser). Os applets so tratados pelo browser como qualquer outro tipo de
objeto da pgina HTML, como uma imagem ou um vdeo: ele transmitido do servidor para o cliente, onde executado e
visualizado dentro do browser.
Java uma linguagem orientada a objetos de propsito geral (semelhante a C++) e projetada para ser simples. Todos os
recursos considerados desnecessrios foram propositalmente deixados de fora da linguagem. Java no possui, por exemplo,
apontadores, estruturas, vetores multi-dimensionais e converso implcita de tipos. Tambm no h necessidade de gerenciamento de memria em Java, pois ela tem um programa interno (garbage collector) que automaticamente libera partes
ocupadas da memria que no tero mais uso.
Outra caracterstica essencial de Java ser independente de plataforma. O cdigo-fonte de um programa Java prcompilado em bytecodes, que so conjuntos de instrues semelhantes ao cdigo de mquina, mas sem serem especficos de
qualquer plataforma. As instrues em bytecodes so verificadas na mquina local antes de serem executadas, garantindo a
segurana da linguagem. Os bytecodes podem ser interpretados por Mquinas Virtuais Java (JVMs Java Virtual Machines)
instaladas em qualquer plataforma, sem necessidade de recompilao do programa. Praticamente todos os browsers j
incorporam a JVM em sua implementao.
4.2 O grafo de cena em Java 3D

O primeiro procedimento na elaborao de uma aplicao Java 3D definir o universo virtual, que composto por um ou
mais grafos de cena. O grafo de cena uma estrutura do tipo rvore cujos ns so objetos instanciados das classes Java 3D e
os arcos representam o tipo de relao estabelecida entre dois ns. Os objetos definem a geometria, luz, aparncia, orientao,
localizao, entre outros aspectos, tanto dos personagens quanto do cenrio que compem um dado mundo virtual. A Figura
13 ilustra um possvel exemplo de um grafo de cenas. Nos prximos pargrafos discute-se, entre outros aspectos, os tipos
de ns que esto representados nesta figura. Foge do escopo deste texto uma abordagem mais prxima dos construtores de
cada tipo de n, para este fim sugere-se [29]. Na seo 4.2.1 mostra-se um procedimento bsico que pode ser empregado na
construo de programas Java 3D e um primeiro exemplo de cdigo.
Os grafos de cenas (ou subgrafos) so conectados ao universo virtual (representado na Figura 13 atravs do n VirtualUniverse) por meio de um n Locale. Um n VirtualUniverse pode ter um ou mais ns Locale, cuja
finalidade fornecer um sistema de coordenadas ao mundo virtual. O n raiz de um grafo de cena (branch graph) sempre
um objeto BranchGroup.
Os branch graphs so classificados em duas categorias: de contedo (content branch graph) e de vista (view branch
graph). Os content branch graphs descrevem os objetos que sero renderizados, i.e., especificam a geometria, textura, som,
objetos de interao, luz, como estes objetos sero localizados no espao, etc. (na Figura 13 o ramo esquerda do n
Locale). Os view branch graphs especificam as atividades e parmetros relacionados com o controle da vista da cena, tais
como orientao e localizao do usurio (na figura o ramo direita do n Locale). Os branch graphs no determinam a
ordem em que os objetos sero renderizados, mas sim o que ser renderizado.
32
Figura 13: Grafo de uma cena em Java 3D.
Um caminho entre o n raiz do grafo de cenas at um de seus ns folhas determina de forma nica todas as informaes
necessrias para se processar este n. Assim, uma forma 3D depende somente das informaes do seu caminho para ser
renderizada. O modelo de renderizao de Java 3D explora este fato renderizando os ns folhas em uma ordem que ele
determina ser a mais eficiente. Em geral o programador no se preocupa em determinar uma ordem de renderizao, uma
vez que Java 3D far isto da forma mais eficiente. No entanto, um programador poder exercer, de forma limitada, algum
controle usando um n OrderedGroup, que assegura que seus filhos sero renderizados em uma ordem pr-definida,
ou um n Switch, que seleciona um ou mais filhos a serem renderizados. O modelo de renderizao mais largamente
discutido em [26].
Java 3D organiza o universo virtual usando o conceito de agrupamento, i.e., um n mantm uma combinao de outros
ns de modo a formar um componente nico. Estes ns so denominados Group. Um n Group pode ter uma quantidade
arbitrria de filhos que so inseridos ou removidos dependendo do que se pretende realizar. Discutimos anteriormente os
ns BranchGroup, OrderedGroup e Switch. Inserem-se ainda nesta categoria os ns TransformGroup, que so
usados para alterar a localizao, orientao e/ou escala do grupo de ns descendentes. A Figura 14 mostra alguns nveis da
hierarquia de classes dos componentes que compem um grafo de cenas.
Figura 14: Hierarquia de classes de alguns componentes de uma cena Java 3D.
Um n que no possui filhos pertence a uma segunda categoria e denominado n Leaf. Estes ns so usados para
especificar luz, som, procedimentos de interao, forma dos objetos geomtricos, orientao e localizao do observador no
33
mundo virtual, entre outros. Estas informaes esto armazenadas no prprio n Leaf ou ento feita uma referncia a um
objeto NodeComponent que mantm os dados necessrios para o processo de renderizao. Os objetos NodeComponent
no fazem parte do grafo de cenas, i.e., a relao entre um n Leaf e um NodeComponent no do tipo pai-filho, mas
de referncia. Este fato possibilita que diferentes ns Leaf referenciem um mesmo NodeComponent sem violar as
propriedades do grafo de cenas, que um grafo direcionado acclico.
Como exemplos de ns Leaf podem ser citados: Light, Sound, Behavior, Shape3D e ViewPlatform. Ns
Shape3D so usados para construir formas 3D a partir de informaes geomtricas e atributos que esto armazenados
em um objeto NodeComponent (na Figura 13, so os elementos referenciados por arcos tracejados a prxima seo
aborda detalhadamente este tpico). Os ns Behavior so usados na manipulao de eventos disparados pelo usurio e
na animao de objetos do universo virtual, as Sees 4.4 e 4.5 fornecem as informaes bsicas sobre como estes objetos
podem ser especificados em um programa Java 3D. Um n ViewPlatform usado para definir a localizao e orientao
do observador (ou do usurio) no mundo virtual. Um programa Java 3D pode fazer o observador navegar pelo mundo virtual
aplicando transformaes de translaes, rotaes e escalonamentos neste n.
Ao contrrio das APIs que possuem apenas o modelo de vista que simulam uma cmera (denominado camera-based),
Java 3D oferece um sofisticado modelo de vista que diferencia claramente o mundo virtual do mundo fsico. O ViewPlatform o nico n presente no grafo de cenas que faz referncias aos objetos que definem este mundo fsico (PhysicalBody, PhysicalEnvironment, View, Canvas 3D e Screen 3D). Essa associao entre o mundo virtual e o fsico
possibilita o desenvolvimento de aplicaes que exigem um nvel de controle e um sincronismo entre estes ambientes, como
por exemplo aplicaes de realidade virtual. Para uma descrio detalhada do modelo de vista de Java 3D verificar [29].
4.2.1 Escrevendo um programa em Java 3D
A estrutura tpica de um programa Java 3D em geral tem dois ramos: um view branch e um content branch. Assim, escrever
um programa em Java 3D requer basicamente criar os objetos necessrios para construir os ramos (as superestruturas para
anexar os BranchGroup), construir um view branch e um content branch. Um bom ponto de partida a seqncia de
passos sugerida por [30]:
1. Criar um objeto Canvas3D
2. Criar um objeto VirtualUniverse
3. Criar um objeto Locale e anex-lo ao VirtualUniverse
4. Construir um grafo view branch
(a) Criar um objeto View
(b) Criar um objeto ViewPlatform
(c) Criar um objeto PhysicalBody
(d) Criar um objeto PhysicalEnvironment
(e) Anexar os objetos criados em (b), (c) e (d) ao objeto View
5. Construir um ou mais grafos content branch
6. Compilar o(s) branch graph(s)
7. Inserir os subgrafos ao n Locale
A construo do grafo view branch (item 4 acima) mantm a mesma estrutura para a maioria dos programas Java3D.
Uma forma de ganhar tempo usar a classe SimpleUniverse definida no pacote com.sun.j3d.utils.universe.
Esta classe cria todos os objetos necessrios para a composio de um view branch. O construtor SimpleUniverse()
retorna um universo virtual com os ns VirtualUniverse (item 2 acima), Locale (item 3), ViewPlatform e os
objetos relativos ao item 4.
A seguir apresentado o cdigo completo de uma aplicao cuja utilidade se limita a ser um exemplo didtico. Seu
objetivo criar um grafo de cenas, ilustrado na Figura 15, que desenha um cubo rotacionado de =4 radianos no eixo x e =5
radianos no eixo y (ver Figura 16). Procura-se evidenciar os passos da seqncia dada anteriormente e fornecer comentrios
que contribuam para o entendimento do Exemplo01 (adaptado de [30]):
34
Figura 15: Grafo de cena do Exemplo01.
import
import
import
import
import
import
import
import
import
java.applet.Applet;
java.awt.BorderLayout;
java.awt.Frame;
java.awt.event.*;
com.sun.j3d.utils.applet.MainFrame;
com.sun.j3d.utils.universe.*;
com.sun.j3d.utils.geometry.ColorCube;
javax.media.j3d.*;
javax.vecmath.*;
public class Exemplo01 extends Applet {

public Exemplo01 () {
setLayout(new BorderLayout());
Canvas3D canvas3D = new Canvas3D(null);
add("Center", canvas3D);
BranchGroup s = ConstroiContentBranch();
s.compile();
// passo 1
// passo 5
// passo 6
// A instanciao de um objeto SimpleUniverse corresponde

// aos passos 2, 3, e 4 da "receita"
SimpleUniverse su = new SimpleUniverse(canvas3D);
// Desloca o ViewPlatform para trs para que os
// objetos da cena possam ser vistos.
su.getViewingPlatform().setNominalViewingTransform();
// Anexa o content graph ao n Locale : passo 7
su.addBranchGraph(s);
}
public BranchGroup ConstroiContentBranch() {
// Especifica-se aqui os contedos grficos a serem renderizados
BranchGroup objRoot = new BranchGroup();
// O trecho de cdigo a seguir especifica duas transformaes
// 3D, uma para rotacionar o cubo no eixo x e a outra no eixo y
// e por fim combina as duas transformaes
Transform3D rotate1 = new Transform3D();
35
Transform3D rotate2 = new Transform3D();

rotate1.rotX(Math.PI/4.0d);
rotate2.rotY(Math.PI/5.0d);
rotate1.mul(rotate2);
TransformGroup objRotate = new TransformGroup(rotate1);
objRoot.addChild(objRotate);
objRotate.addChild(new ColorCube(0.4));
return objRoot;
}
// O mtodo a seguir permite que o applet Exemplo01 seja
// executado como uma aplicao
public static void main (String[] args) {
Frame frame = new MainFrame (new Exemplo01(), 256, 256);
}
}
Figura 16: Imagem produzida pelo Exemplo01.
4.2.2 Configurando as capacidades de um objeto Java 3D

O grafo de cenas Java 3D pode ser convertido para uma representao interna que torna o processo de renderizao mais
eficiente. Esta converso pode ser efetuada anexando cada branch graph a um n Locale, tornando-os vivos (live) e,
conseqentemente, cada objeto do branch graph dito estar vivo. A segunda maneira compilando cada branch graph,
usando o mtodo compile(), de forma a torn-los objetos compilados. Uma conseqncia de um objeto ser vivo e/ou
compilado que seus parmetros no podem ser alterados a menos que tais alteraes tenham sido explicitamente codificadas
no programa antes da converso. A lista de parmetros que podem ser acessados denomominada capabilities e varia de
objeto para objeto. O exemplo a seguir cria um n TransformGroup e configura-o para escrita. Isto significa que o
valor da transformada associada ao objeto TransformGroup poder ser alterada mesmo depois dele tornar-se vivo e/ou
compilado.
TransformGroup alvo = new TransformGroup();
36
alvo.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
4.3 Modelagem
Um objeto 3D uma instncia da classe Shape3D, representado no grafo de cenas por um n do tipo Leaf. O n Shape3D
no contm os atributos que definem o objeto 3D, tais como seu contedo geomtrico e sua aparncia (cor, transparncia,
tipo de material, textura, entre outros). Estes atributos esto armazenados em objetos do tipo NodeComponent. Um objeto
Shape3D pode ser definido pela frmula Shape3D = geometria + aparncia. Em Java 3D este objeto pode ser instanciado
pelo construtor:
Shape3D (Geometry geometry, Appearance appearence);
Uma alternativa definir um objeto 3D como sendo uma extenso da classe Shape3D, o que bastante til quando se
deseja criar mltiplas instncias do objeto 3D com os mesmos atributos. Um pseudo-cdigo para esta finalidade pode ter a
seguinte organizao:
public class Modelo3D extends Shape3D
{
private Geometry g;
private Appearance a;
public Modelo3D()
{
g = constroiGeometria();
a = constroiAparencia();
this.setGeometry(g);
this.setAppearance(a);
}
private Geometry constroiGeometria ()
{
// Inserir o cdigo que cria a geometria desejada
}
private Appearance constroiAparencia ()
{
// Inserir o cdigo que cria a aparncia desejada
}
}
4.3.1 Definindo a geometria de um objeto 3D
Para que um objeto 3D seja funcional necessrio especificar pelo menos seu contedo geomtrico. Java 3D oferece
basicamente trs maneiras de se criar um contedo geomtrico. O primeiro mtodo o mais simples e consiste no emprego
de primitivas geomtricas, tais como Box, Sphere, Cylinder e Cone, cuja composio determina a forma do objeto desejado.
Por exemplo, um haltere pode ser a soma das seguintes primitivas: esfera + cilindro + esfera. Cada primitiva possui um
mtodo construtor onde so especificadas as dimenses do objeto (ou ento estes so instanciados com dimenses default).
Por exemplo, mostrado a seguir um trecho de cdigo para criar uma caixa, centrada na origem, com aparncia a e de
dimenses X, Y, Z, que especificam comprimento, largura e altura respectivamente:
Appearance a = new Appearance();
Primitive caixa = new Box (X, Y, Z, a);
37
Em razo da limitao inerente a este mtodo como, por exemplo, a impossibilidade de alterao da geometria das
primitivas, ele no o mais apropriado para modelar a geometria de um objeto 3D mais complexo.
Um segundo mtodo permite que o programador especifique outras formas geomtricas para um objeto 3D em alternativa
s formas pr-definidas discutidas acima. Neste mtodo, os dados geomtricos que modelam a forma do objeto 3D (primitivas geomtricas definidas pelo programador) so especificados vrtice a vrtice em uma estrutura vetorial. Esta estrutura
definida usando as subclasses de GeometryArray como por exemplo: PointArray define um vetor de vrtices,
LineArray define um vetor de segmentos, TriangleArray define um vetor de tringulos individuais e QuadArray define um vetor de vrtices onde cada quatro vrtices correspondem a um quadrado individual. Estes polgonos
devem ser convexos e planares.
A subclasse GeometryStripArray permite definir atravs de suas subclasses (LineStripArray,
TriangleStripArray e TriangleFanArray) estruturas geomtricas que compartilham o uso dos vrtices especificados. Um objeto LineStripArray define uma lista de segmentos conectados, um objeto TriangleStripArray
define uma lista de tringulos, onde cada dois tringulos consecutivos possuem uma aresta em comum e um objeto TriangleFanArray define uma lista de tringulos onde cada dois tringulos consecutivos possuem uma aresta em comum e
todos compartilham um mesmo vrtice (Figura 17).
Figura 17: Objetos array e strip.
Um objeto GeometryArray pode armazenar, alm das coordenadas de localizao, coordenadas do vetor normal
superfcie, coordenadas de cores e de texturas.
O cdigo a seguir exemplifica como construir a geometria de um objeto Shape3D usando a classe QuadArray.
private Geometry constroiGeometria (){
private static final float[]
1.0f, -1.0f,
1.0f, 1.0f,
-1.0f, 1.0f,
-1.0f, -1.0f,
}
private static final float[]
// Azul
0.0f, 0.0f,
0.0f, 0.0f,
0.0f, 0.0f,
0.0f, 0.0f,
}
vertice = {
1.0f,
1.0f,
1.0f,
1.0f
cor = {
1.0f,
1.0f,
1.0f,
1.0f,
// Cria um objeto QuadArray vazio com 4 vrtices e o flag de formato

// de vrtices definido para coordenadas de localizao e cores
QuadArray quadrado = new QuadArray (4, COODINATES| COLOR_3);
// Atribui o valor dos vertices ao quadrado
38
quadrado.setCoordinates (0, vertice);

// Atribui as informaes de cores ao quadrado
quadrado.setColor (0, cor);
return quadrado;
}
No exemplo acima foi necessrio especificar 4 vrtices para definir um quadrado. Se o objeto a ser modelado fosse um
cubo seria necessrio especificar 4 x 6 = 24 vrtices. Certamente existe uma grande redundncia, pois um cubo tem apenas
8 vrtices. Uma forma alternativa de definir esta geometria, eliminando esta redundncia, usar a classe IndexedGeometryArray (subclasse de GeometryArray). Como o prprio nome sugere, um objeto IndexedGeometryArray
precisa, alm do vetor de dados, de um vetor de ndices para fazer referncias aos elementos do vetor de dados. Voltando ao
exemplo do cubo, um possvel pseudo-cdigo seria:
// Criar vetor de dados com 8 vrtices
// Criar objeto IndexedGeometryArray tendo como parmetros
// - quantidade de vrtices
// - tipo de coordenada
// - tamanho do vetor de ndices: 4 x 6 = 24
}
As alternativas apresentadas no segundo mtodo so mais satisfatrias que as apresentadas no primeiro. Elas oferecem
ao programador mais flexibilidade na definio da forma dos objetos, mas ainda pesam contra elas algumas desvantagens.
A criao de um contedo geomtrico mais elaborado vai exigir grande quantidade de tempo e de linhas de cdigo para
computar matematicamente ou especificar a lista de vrtices do objeto de interesse. Esta baixa performance no motivar o
programador a desenvolver formas mais sofisticadas.
Ainda com relao a esta abordagem de definir a forma do objeto 3D usando fora bruta, Java 3D disponibiliza um
pacote com.sun.j3d.utils.geometry que oferece algumas facilidades neste processo. Por exemplo, ao invs de
especificar exaustivamente as coordenadas, tringulo a tringulo, especifica-se um polgono arbitrrio P (que pode ser noplanar e com buracos) usando um objeto GeometryInfo, e a seguir efetua-se a triangulao de P usando um objeto
Triangulator, como exemplifica o trecho de cdigo a seguir.
// . . .
GeometryInfo P = new GeometryInfo (GeometryInfo.POLYGON_ARRAY);
P.setCoordinates (vertices_do_poligono);
Triangulator PT = new Triangulator();
PT.triangulate(P);
return P.getGeometryArray();
// . . .
}
A triangulao de um polgono no-planar pode gerar diferentes superfcies, de modo que o resultado obtido pode no
ser o desejado. Isto leva o programador a um processo de tentativas at obter a forma desejada. Estes problemas mostram
que escrever universos virtuais 3D complexos no uma tarefa trivial.
Felizmente, Java 3D tambm oferece um terceiro mtodo, baseado na importao de dados geomtricos criados por outras
aplicaes, que resolve em grande parte os problemas citados anteriormente. Neste tipo de abordagem comum usar um
software especfico para modelagem geomtrica que oferea facilidades para criar o modelo desejado. Feito isto, o contedo
geomtrico ento armazenado em um arquivo de formato padro que posteriormente ser importado para um programa
Java 3D, processado e adicionado a um grafo de cenas. O trabalho de importao destes dados para um programa Java 3D
39
realizado pelos loaders. Um loader sabe como ler um formato de arquivo 3D padro e ento construir uma cena Java 3D a
partir dele. Existe uma grande variedade de formatos disponveis na Web, por exemplo o formato VRML (.wrl), Wavefront
(.obj), AutoCAD (.dfx), 3D Studio (.3ds), LightWave (.lws), entre outros. Uma cena Java 3D pode ainda ser construda
combinando diferentes formatos de arquivo. Para isso suficiente usar os loaders correspondentes. Por fim, vale observar que
estes loaders no fazem parte da Java 3D, so implementaes da interface definida no pacote com.sun.j3d.loaders.
Maiores detalhes sobre como escrever um loader para um dado formato de arquivo so mostrados em [30].
4.3.2 Definindo a aparncia de um objeto 3D
Um n Shape3D pode, opcionalmente, referenciar um objeto Appearance para especificar suas propriedades, tais como textura, transparncia, tipo de material, estilo de linha, entre outros. Estas informaes no so mantidas no objeto
Appearance, que faz referncia a outros objetos NodeComponent que mantm tais informaes (ver Figura 18).
Figura 18: Subgrafo da cena relativa ao Exemplo02.
Estas propriedades, ou atributos, so definidas usando as subclasses de NodeComponent. Alguns exemplos, entre as
vrias subclasses existentes, so: LineAttributes, PoligonAttributes e ColoringAttributes. Um objeto
LineAttributes usado para definir a largura em pixels da linha, seu padro (linha solida, tracejada, pontilhada ou
tracejada-pontilhada) e tratamento de antialiasing (habilita ou desabilita). Um objeto PolygonAttributes define, por
exemplo, como os polgonos sero renderizados (preenchido, wireframe ou apenas os vrtices). Um objeto ColoringAttributes define a cor dos objetos e o modelo de shading.
O exemplo02 a seguir emprega os mtodos das subclasses discutidas no pargrafo anterior para especificar os atributos
de linha, polgono e cor para um objeto 3D qualquer. O grafo de cena resultante mostrado na Figura 18.
private Appearance constroiAparencia () {
Appearance ap = new Appearance();
LineAttributes al = new LineAttributes();
al.setLineWidth(2.0f);
al.setLinePattern(PATTERN_SOLID);
ap.setColoringAttributes(al);
ColoringAttributes aCor = new ColoringAttributes();
aCor.setColor(new Color3f(1.0f, 0.0f, 0.0f));
ap.setColoringAttributes(aCor);
PolygonAttributes pa = new PolygonAttributes();
pa.setPolygonMode(PolygonAttributes.Polygon_FILL);
ap.setPolygonAttributes(pa);
return ap;
40
4.4 Interao
Programar um objeto para reagir a determinados eventos uma capacidade desejvel na grande maioria das aplicaes 3D. A
reao resultante de um certo evento tem por objetivo provocar alguma mudana no mundo virtual que depender da natureza
da aplicao e ser determinada pelo programador. Por exemplo, um evento poderia ser pressionar uma tecla, o movimento
do mouse ou a coliso entre objetos, cuja reao seria alterar algum objeto (mudar cor, forma, posio, entre outros) ou o
grafo de cenas (adicionar ou excluir um objeto). Quando estas alteraes so resultantes diretas da ao do usurio elas so
denominadas interaes. As alteraes realizadas independentemente do usurio so denominadas animaes [30].
Java 3D implementa os conceitos de interao e animao na classe abstrata Behavior. Esta classe disponibiliza
ao desenvolvedor de aplicaes 3D uma grande variedade de mtodos para capacitar seus programas a perceber e tratar
diferentes tipos de eventos. Permite ainda que o programador implemente seus prprios mtodos (ver seo seguinte). Os
behaviors so os ns do grafo de cena usados para especificar o incio da execuo de uma determinada ao baseado na
ocorrncia de um conjunto de eventos, denominado WakeupCondition, ou seja, quando determinada combinao de
eventos ocorrer Java 3D deve acionar o behavior correspondente para que execute as alteraes programadas.
Uma WakeupCondition, condio usada para disparar um behavior, consiste de uma combinao de objetos WakeupCriterion, que so os objetos Java 3D usados para definir um evento ou uma combinao lgica de eventos.
Os behaviors so representados no grafo de cena por um n Leaf, sempre fazendo referncia a um objeto do grafo.
atravs deste objeto, denominado objeto alvo, e em geral representado por um TranformGroup, que os behaviors
promovem as alteraes no mundo virtual.
4.4.1
Estrutura de um behavior
Todos os behaviors so subclasses da classe abstrata Behavior. Eles compartilham uma estrutura bsica composta de um
mtodo construtor, um mtodo inicializador e um mtodo processStimulus(). Estes dois timos so fornecidos pela
classe Behavior e devem ser implementados por todos behaviors definidos pelo usurio.
O mtodo initialize() chamado uma vez quando o behavior torna-se vivo (live). Um objeto do grafo de cena
dito vivo se ele faz parte de um brach graph anexado a um n Locale (ver Seo 4.2.2). A conseqncia deste fato que
estes objetos so passveis de serem renderizados. No caso de um n Behavior, o fato de estar vivo significa que ele est
pronto para ser invocado. Define-se neste mtodo o valor inicial da WakeupCondition.
O mtodo processStimulus() chamado quando a condio de disparo especificada para o behavior ocorrer
e ele estiver ativo (ver seo seguinte). Esta rotina ento efetua todo o processamento programado e define a prxima
WakeupCondition, i.e., informa quando o behavior deve ser invocado novamente.
O cdigo apresentado a seguir (adaptado de [30]) exemplifica como escrever um behavior para rotacionar um objeto
sempre que uma tecla for pressionada.
public class Rotaciona extends Behavior {
private TransformGroup alvo;
private Transform3D r = new Transform3D();
private double angulo = 0.0;
// Mtodo construtor
Rotaciona ( TransformGroup
this.alvo = alvo;
}
alvo ){
// Mtodo initialize
public void initialize() {
this.wakeupOn (new WakeupOnAWTEvent(KeyEvent.KEY_PRESSED));
}
// Mtodo processStimulus
public void processStimulus( Enumeration criteria ) {
41
angulo += 0.1;
r.rotY (angulo);
alvo.setTransform(r);
this.wakeupOn(new WakeupOnAWTEvent(KeyEvent.KEY_PRESSED));
}
}
Para adicionar um objeto Behavior a um programa Java 3D deve-se basicamente: (i) criar o suporte necessrio exigido
pelo behavior (e.g., um behavior Rotaciona precisa referenciar um n TransformGroup), (ii) criar um objeto Behavior
e efetuar as referncias necessrias, (iii) definir um scheduling bound para o behavior (ver seo seguinte) e (iv) configurar
as capacidades do objeto alvo. O mtodo ConstroiContentBranch visto a seguir ilustra este processo para o behavior
Rotaciona.
public BranchGroup ConstroiContentBranch( ) {
// (i) suporte para o behavior
// (iv) configurar capacidades do objeto alvo
TransformGroup objRotate = new TransformGroup();
objRotate.setCapability (TransformGroup.ALLOW_TRANSFORM_WRITE);
objRoot.addChild(objRotate);
objRotate.addChild(new ColorCube(0.4));
// (ii) criao do behavior referenciando o objeto que ser rotacionado
Rotaciona RotacionaBehavior = new Rotaciona(objRotate);
// (iii) definio do scheduling bound
RotacionaBehavior.setSchedulingBounds (new BoundingSphere());
objRoot.addChild(RotacionaBehavior);
objRoot.compile();
return objRoot;
}
4.4.2 Behaviors ativos
Por uma questo de desempenho, o programador define uma regio limitada do espao (por exemplo, uma esfera ou um
paraleleppedo), denominada scheduling bound para o behavior (Figura 19). Ele dito estar ativo quando seu scheduling
bound intercepta o volume de cena. Apenas os behaviors ativos esto aptos a receber eventos. Dessa forma, o cmputo
necessrio a manipulao dos behaviors se reduz apenas aos que esto ativos, liberando assim mais tempo de CPU para o
processo de renderizao. Na verdade o scheduling bound mais do que uma questo de performance, se ele no for definido
o behavior associado nunca ser executado [29].
4.5 Animao
Algumas alteraes do mundo virtual podem ser realizadas independentemente da ao do usurio. Elas podem, por exemplo,
ser disparadas em funo do passar do tempo. Como comentado anteriormente, estas alteraes so denominadas animaes.
Animaes em Java 3D tambm so implementadas usando behaviors. Java 3D disponibiliza alguns conjuntos de classes,
tambm baseadas em behaviors, que so prprias para implementar animaes. Um primeiro conjunto destas classes so os
interpoladores.
Os Interpolators so verses especializadas de behaviors usados para gerar uma animao baseada no tempo. O
processo de animao acontece atravs de dois mapeamentos. No primeiro, um dado intervalo de tempo (em milissegundos)
42
Figura 19: Scheduling bound.
mapeado sobre o intervalo fechado I=[0.0, 1.0], a seguir I mapeado em um espao de valores pertinente ao objeto do
grafo de cenas que se deseja animar (por exemplo, atributos de um objeto Shape3D ou a transformada associada a um
objeto TransformGroup).
O primeiro mapeamento efetuado por um objeto Alpha, que determina como o tempo ser mapeado de forma a
gerar os valores do intervalo I, denominados valores alpha. Alpha pode ser visto como uma aplicao do tempo que
fornece os valores alpha em funo dos seus parmetros e do tempo. O segundo mapeamento determinado por um objeto
Interpolator que, a partir dos valores alpha, realiza a animao do objeto referenciado.
4.5.1 Mapeamento do tempo em Alpha
As caracteristicas de um objeto Alpha so determinadas por uma lista de parmetros que podem variar at um total de dez.
A Figura 20 mostra o grfico de Alpha onde os valores alpha so obtidos em funo de todos estes parmetros. A forma do
grfico varia conforme a quantidade de parmetros especificados.
Figura 20: Grfico Alpha: tempo x valores alpha.
fcil identificar quatro fases bem distintas em um grfico Alpha: uma fase de crescimento dos valores alpha (increasingAlphaDuration
e
increasingAlphaRampDuration),
uma
fase
de
decrescimento
(decreasingAlphaDuration e decreasingAlphaRampDuration), uma fase com valores alpha constantes em
zero
(alphaAtOneDuration) e uma fase com valores alpha constantes em um (alphaAtZeroDuration). A definio
de um objeto Alpha pode ter todas ou apenas algumas destas fases. Os parmetros correspondentes a cada uma das fases
de Alpha permitem controlar o nmero de vezes (loopCount) que os valores alpha so gerados, o modo em que os
valores alpha so gerados (INCREASING_ENABLE e/ou DECREASING_ENABLE), a velocidade (increasingAlphaDuration e decreasingAlphaDuration) e acelerao (increasingAlphaRampDuration e decreasingAlphaRampDuration) com que uma trajetria do espao de valores ser percorrida. O parmetro phaseDelayDuration permite especificar um tempo de espera, antes que os valores alpha comecem a ser gerados. Este tipo de controle
bastante til em um ambiente multithreading como o Java 3D. Imagine-se, por exemplo, a situao onde Java 3D tenha
iniciado o processo de renderizao antes que a janela de display seja aberta. Neste caso, o usurio poder ver a animao a
43
partir de um instante que no corresponda ao inicial, o que pode ser evitado estabelecendo um atraso.
O exemplo a seguir define um objeto Alpha que gera os valores alpha um nmero infinito de vezes, gastando 4000 milissegundos (ou 4 segundos) em cada perodo. Os parmetros que no aparecem na lista recebem o valor zero, a menos do parmetro que define o modo em que os valores alpha so gerados que configurado com a constante INCREASING_ENABLE.
A Figura 21 mostra o grfico relativo a este exemplo.
Alpha valoresalpha = new Alpha(-1, 4000);
Figura 21: Grfico Alpha com infinitos ciclos.
O grande nmero de parmetros que podem ser especificados na construo de um objeto Alpha oferece um maior
controle do processo de interpolao. No entanto, isto tem o custo do programador necessitar calibrar corretamente os
valores de tais parmetros para obter um resultado mais prximo possvel do desejado, o que faz este mtodo ser um tanto
quanto trabalhoso. Por outro lado, um objeto Alpha pode ser compartilhado, permitindo economizar trabalho e memria.
Uma apresentao detalhada da lista dos parmetros de Alpha pode ser encontrada em [26] e [29].
4.5.2 Mapeamento de Alpha para o espao de valores
O programador pode projetar seus prprios interpoladores usando os valores alpha para animar objetos do mundo virtual. No
entanto, Java 3D disponibiliza classes de behaviors pr-definidos, denominados Interpolators, que atende a maioria
das aplicaes (ColorInterpolator, PositionInterpolator, RotationInterpolator entre outros). O
procedimento usado para adicionar um objeto Interpolator segue um padro bsico, parecido com o apresentado na
Seo 4.4.1, que independe do tipo de interpolador a ser usado:
1. Criar o objeto a ser interpolado, o objeto alvo, e configurar os bits de capacidades necessrios;
2. Criar um objeto Alpha que descreve como gerar os valores alpha;
3. Criar um objeto Interpolator usando Alpha e o objeto alvo;
4. Atribuir um scheduling bound ao Interpolator;
5. Anexar o Interpolator ao grafo de cenas;
O exemplo apresentado a seguir (adaptado de [30]) usa a classe RotationInterpolator para criar uma animao.
Esta animao consiste em rotacionar um cubo um nmero infinito de vezes, onde cada rotao gasta 4 segundos.
public BranchGroup ConstroiContentBranch () {
// Cria a raiz do grafo content branch
// Passo 1
44
TransformGroup alvo = new TransformGroup();

alvo.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
// Passo 2
Alpha vAlpha = new Alpha(-1, 4000);
// Passo 3
RotationInterpolator r = new RotationInterpolator(vAlpha, alvo);
// Passo 4
BoundingSphere bounds = new BoundingSphere();
r.setSchedulingBounds(bounds);
// Passo 5
objRoot.addChild(alvo);
alvo.addChild(new ColorCube(0.4));
objRoot.addChild(r);
return objRoot;
}
Existem ainda as classes billboard e LOD (Level of Detail) que tambm permitem especificar animaes, mas neste
conjunto de classes as alteraes so guiadas segundo a orientao ou posio da vista. Para maiores detalhes consultar [30].
4.6 Concluso
O conjunto de capacidades incorporado por Java 3D oferece um ambiente de desenvolvimento de alto nvel, eficiente e
rpido no desenvolvimento e manipulao de complexas aplicaes 3D. A programao de alto nvel, no entanto, obtida
escondendo do programador detalhes de mais baixo nvel como, por exemplo, no processo de renderizao, o que implica
menos flexibilidade. Em contrapartida programadores com pouca experincia em programao 3D podem criar facilmente
mundos virtuais em suas aplicaes.
As dificuldades encontradas na construo da geometria de modelos mais complexos so resolvidas usando programas
de modelagem. A VRML, que essencialmente um formato de arquivo para cenas 3D, uma excelente escolha para esta
finalidade. Aguarda-se para um futuro prximo uma maior compatibilidade entre estas duas tecnologias.
5 VRML (Virtual Reality Modeling Language)

A linguagem VRML surgiu da necessidade de prover um formato grfico 3D para a Web seguindo um modelo similar
HTML, ou seja, uma linguagem textual independente de plataforma para a descrio de cenas. A linguagem escolhida como
referncia foi a Open Inventor da SGI. Em 1995 foi lanada a VRML 1.0, que era basicamente um formato para a descrio
de cenas estticas 3D. Em 1997 foi lanada a VRML 2.0 (ou VRML 97) [31], que adicionou linguagem conceitos de
realidade virtual, tais como possibilidade de mover objetos da cena e criao de sensores para detectar e gerar eventos.
O projeto da VRML sempre foi aberto. As especificaes so escritas por um consrcio envolvendo vrias empresas e
pesquisadores acadmicos e so imediatamente disponibilizadas para realimentao, sugestes e crticas de toda a comunidade interessada. At 1999, este consrcio se chamava VRML Consortium, e depois passou a se chamar Web 3D Consortium
[32]. Sua principal atividade a elaborao e manuteno de novos padres para a transmisso de contedo tridimensional
atravs da Web. Dentre outras tarefas, isto inclui uma melhor integrao entre VRML, Java 3D, MPEG-4 e outras tecnologias
relacionadas.
Apesar de ser geralmente vista como uma espcie de HTML tridimensional, a VRML muito mais que isso [33],
sendo capaz de criar ricos ambientes 3D interativos e se conectar a programas externos que podem realizar processamentos
sofisticados, teis em reas como a visualizao cientfica.
A visualizao de uma cena VRML (tambm chamada mundo VRML VRML world) se d por meio de um browser
VRML, normalmente um plug-in de um browser Web convencional. O browser VRML l e interpreta o arquivo de descrio
45
do mundo virtual (extenso .wrl), o desenha em uma janela e prov uma interface para que o usurio possa andar pelo
ambiente criado e interagir com objetos dele.
5.1 Estrutura hierrquica da cena

O paradigma para a criao de mundos VRML baseado em ns, que so conjuntos de abstraes de objetos e de certas
entidades do mundo real, tais como formas geomtricas, luz e som. Ns so os componentes fundamentais de uma cena
VRML porque esta constituda a partir da disposio, combinao e interao entre os ns.
Assim como em Java 3D, um mundo VRML um grafo hierrquico em forma de rvore. As hierarquias so criadas
atravs de ns de agrupamento, os quais contm um campo chamado children que engloba uma lista de ns filhos. H
vrios tipos de ns em VRML [34].
Agrupamento. Como j comentado, ns de agrupamento criam a estrutura hierrquica da cena e permitem que operaes
sejam aplicadas a um conjunto de ns simultaneamente. Alguns exemplos desse tipo de n so:
Anchor. um n de agrupamento que recupera o contedo de um URL quando o usurio ativa alguma geometria
contida em algum de seus ns filhos (clica com o mouse sobre eles, por exemplo). o n que cria links com
outros mundos VRML, pginas HTML, ou qualquer outro tipo de documento presente no referido URL. Um
Anchor definido com os seguintes valores default para seus parmetros:
Anchor {
# objetos da cena que contm hyperlinks para outros arquivos.
children
[ ]
description " "
parameter
[ ]
url
[ ] # url do arquivo a ser carregado
bboxCenter
0 0 0
bboxSize
-1 -1 -1 }
Transform. um n de agrupamento que define um sistema de coordenadas para seus filhos que est relacionado
com o sistema de coordenadas de seus pais. Sobre este sistema de coordenadas podem ser realizadas operaes
de translao, rotao e escalonamento. Os seguintes valores default so definidos:
Transform {
bboxCenter
0 0 0
bboxSize
-1 -1 -1
translation
0 0 0
rotation
0 0 1
scale
1 1 1
scaleOrientation
0 0 1
center
0 0 0
# ns filhos, que so afetados pelas transformaes especificadas neste n.
children
[ ]
}
Group. um n de agrupamento que contm um nmero qualquer de filhos. Ele equivalente ao n Transform
sem os campos de transformao. A diferena bsica entre o Group e o Transform que o primeiro
usado quando se deseja criar um novo objeto constitudo da combinao de outros. Quando se deseja agrupar
espacialmente os objetos, ou seja, posicion-los em certa regio da cena, usa-se o n Transform.
Geomtrico. Define a forma e a aparncia de um objeto do mundo. O n Shape, em particular, possui dois parmetros:
geometry, que define a forma do objeto e appearance, que define as propriedades visuais dos objetos (material
ou textura). Alguns exemplos de ns geomtricos so:
Box. Este n geomtrico representa um slido retangular (uma caixa) centrado na origem (0, 0, 0) do sistema de
coordenadas local e alinhado com os eixos cartesianos. O campo size representa as dimenses do slido nos
eixos x, y e z.
46
Box { size
2 2 2 }
Cone. Representa um cone centrado na origem do sistema local de coordenadas cujo eixo central est alinhado com
o eixo y.
Cylinder. Define um cilindro centrado na origem do sistema de coordenadas e com eixo central ao longo do eixo y.
Sphere. Especifica uma esfera centrada na origem.
Text. Desenha uma ou mais strings de texto em um estilo especfico.
IndexedLineSet e IndexedFaceSet. Estes ns descrevem, respectivamente, objetos 3D a partir de segmentos de reta
e polgonos cujos vrtices esto localizados em coordenadas dadas.
Appearance. Este n aparece apenas no campo appearance de um n Shape e responsvel pela definio das propriedades visuais das figuras geomtricas (material e textura).
Cmera. O n Viewpoint define, entre outros parmetros, a posio e orientao da cmera (ponto de vista do usurio).
Este tipo de n chamado bindable porque apenas um pode estar ativo na cena.
Iluminao. Luzes em VRML no so como luzes no mundo real. No mundo real, luzes so objetos fsicos que emitem luz
e que podem ser vistos, assim como a luz por ele emitida. Em VRML, um n de iluminao descrito como parte do
mundo mas no cria automaticamente uma geometria para represent-lo. Para que uma fonte de luz em uma cena seja
um objeto visvel necessrio criar uma geometria e coloc-la em um determinado local na cena. Existem trs tipos
de ns de iluminao em VRML:
DirectionalLight. Este n define uma fonte de luz direcional com raios paralelos.
PointLight. Define uma fonte de luz pontual em um local 3D fixo. Este tipo de fonte ilumina igualmente em todas as
direes.
SpotLight. Define um cone direcional de iluminao.
Alm desses tipos bsicos, existem ainda os ns sensores, os interpoladores e o n Script, que sero vistos mais
adiante.
5.2 Prototipao e reuso

Os mecanismos de prototipao da VRML permitem definir um novo tipo de n baseado na combinao de ns j existentes.
permitido, inclusive, a criao de cenas distribudas, pois o subgrafo (prottipo) pode ser definido em um arquivo remoto
cujo URL conhecido.
Atribuindo-se um nome a um n atravs da palavra DEF, pode-se futuramente referenci-lo atravs da palavra USE.
Sendo assim, caso seja necessria a reutilizao de um mesmo n vrias vezes em uma cena, mais eficiente atribuir-lhe um
nome na primeira vez que ele descrito e posteriormente referenci-lo por este nome. Essa tcnica torna o arquivo menor e
mais fcil de ler, diminuindo o tempo necessrio para carregar a cena.
Em resumo, VRML permite o encapsulamento (prottipos) e reutilizao de subgrafos da cena. O exemplo a seguir
mostra uma cena VRML simples (2 cones verdes), utilizando alguns dos conceitos apresentados at aqui (a primeira linha
do arquivo deve ser sempre #VRML V2.0 utf8 e os comentrios devem comear com #):
#VRML V2.0 utf8
# Posio da cmera (ou observador)
Viewpoint {
position 0 0 10 }
# Fonte de luz pontual
PointLight{
ambientIntensity 0
attenuation 1 0 0
color 1 1 1
# luz branca
47
intensity .2
location 0 0 2
on TRUE
radius 20 }
# posio da fonte
# est "ligada"
Transform {
# Um cone definido e posicionado na origem (valor default = 0 0 0)
children [
DEF Cone_Verde Shape {
geometry Cone {}
# cone
appearance Appearance {
material Material {
diffuseColor 0 1 0
# cor verde
}
}
}
# reutilizao do cone
Transform {
translation 2 0 3
children USE Cone_Verde
}
# posicionamento em (2 0 3)
]
}
5.3 Tipos de parmetros e roteamento de eventos

Cada n VRML define um nome, um tipo e um valor default para seus parmetros. Estes parmetros diferenciam um n
de outros de mesmo tipo (por exemplo, o raio de uma esfera a diferencia de outra). H dois tipos de parmetros possveis:
campos (fields) e eventos (events). Campos podem ser modificveis (exposedFields) ou no (fields). Um exposedField , na
verdade, uma composio de um evento de entrada, um evento de sada e o valor do campo (exposedField = eventIn + field
+ eventOut).
Os eventos podem ser enviados para outros ns por um parmetro do tipo eventOut e recebidos por um eventIn. Eventos
sinalizam mudanas causadas por estmulos externos e podem ser propagados entre os ns da cena por meio de roteamentos
(Routes) que conectam um eventOut de um n a um eventIn de outro n, desde que eles sejam eventos do mesmo tipo.
5.4 Sensores e interpoladores

Os ns sensores e interpoladores so especialmente importantes porque so os responsveis pela interatividade e dinamismo
dos mundos VRML.
Os sensores geram eventos baseados nas aes do usurio. O n TouchSensor, por exemplo, detecta quando o usurio
aciona o mouse sobre um determinado objeto (ou grupo de objetos) da cena. O ProximitySensor, por sua vez, detecta
quando o usurio est navegando em uma regio prxima ao objeto de interesse. Os sensores so responsveis pela interao
com o usurio, mas no esto restritos a gerar eventos a partir de aes dos mesmos. O TimeSensor, por exemplo,
gera automaticamente um evento a cada pulso do relgio. Os eventOuts gerados pelos sensores podem ser ligados a outros
eventIns da cena, iniciando uma animao, por exemplo.
A seguir alguns sensores so descritos:
TimeSensor. O n TimeSensor gera eventos como passos de tempo e em conjunto com interpoladores pode produzir
animaes.
TimeSensor {
cycleInterval
enabled
1
TRUE
48
loop
startTime
stopTime
FALSE
0
0 }
O campo cycleInterval determina a durao, em segundos, de cada ciclo, devendo ser maior que zero. Se o
campo enabled for TRUE os eventos relacionados ao tempo so gerados caso outras condies sejam encontradas e
se for FALSE os eventos relacionados ao tempo no so gerados. O campo loop indica que o sensor de tempo deve
repetir indefinidamente ou deve parar depois de um ciclo. O campo startTime indica quando a gerao de eventos
se inicia e o campo stopTime quando a gerao de eventos pra.
TouchSensor. O n TouchSensor detecta quando um objeto do grupo do seu pai ativado (clique do mouse, por exemplo). Esse sensor gera um evento de sada chamado touchTime que pode disparar um TimeSensor, iniciando uma
animao.
TouchSensor {
enabled TRUE }
O campo enabled indica se o sensor est ou no habilitado para enviar e receber eventos.
ProximitySensor. O n ProximitySensor gera eventos quando o usurio entra, sai e/ou se move em uma regio do
espao. O sensor de proximidade habilitado ou desabilitado pelo envio de um evento enabled com o valor TRUE
ou FALSE.
VisibilitySensor. O n VisibilitySensor detecta quando certa parte do mundo (rea ou objeto especfico) torna-se
visvel ao usurio. Quando a rea est visvel, o sensor pode ativar um procedimento ou animao.
A forma mais comum de se criar animaes usando keyframes (quadros-chave), especificando os momentos-chave na
seqncia da animao. Os quadros intermedirios so obtidos atravs da interpolao dos quadros-chave. Ns interpoladores servem para definir este tipo de animao, associando valores-chave (de posio, cor, etc.) que sero linearmente
interpolados. Alguns exemplos de interpoladores so:
PositionInterpolator. O n PositionInterpolator permite realizar uma animao keyframe em uma localizao no
espao 3D. Exemplo:
PositionInterpolator {
key
[0, .5, 1]
keyValue [ 0 0 0, 0 10 0, 0 0 0 ] }
# instantes de tempo
# valores-chave associados aos instantes
CoordinateInterpolator, ColorInterpolator, OrientationInterpolator. De forma similar interpolam, respectivamente, uma

lista de coordenadas, valores de cor e valores de rotao.
Os eventos gerados por sensores e interpoladores, ligados a ns geomtricos, de iluminao ou de agrupamento, podem
definir comportamentos dinmicos para os elementos do ambiente. Um exemplo tpico (Figura 22) rotear um TouchSensor em um TimeSensor, causando o disparo do relgio quando o usurio clicar sobre um objeto. O TimeSensor, por
sua vez, roteado em um interpolador, enviando para ele valores de tempo para a funo de interpolao. O interpolador
ento roteado em um n geomtrico, definindo as alteraes deste objeto.
A seguir mostrado um exemplo de utilizao de sensores e interpoladores [33].
#VRML V2.0 utf8
# Uso de sensores e interpoladores.
# Quando a bola for tocada (clique do mouse sobre ela) o texto ir mover-se na
# horizontal e quando a caixa for tocada o texto ir mover-se na vertical.
Viewpoint { position 0 0 50 } # observador
49
Figura 22: Roteamento de eventos em uma interao tpica de VRML.
Group {
children [
Transform {
translation -4 8 0
children [
Shape {
geometry Sphere { radius 1.5 } # bola
material Material {
diffuseColor .73 .56 .56
}
}
}
DEF STOUCH TouchSensor{} # sensor da bola
]
}
Transform {
translation 4 8 0
children [
Shape {
geometry Box { size 2 2 2 } # caixa
material Material {
diffuseColor 0 1 0
}
}
}
DEF BTOUCH TouchSensor{} # sensor da caixa
]
}
# Sensores de tempo
DEF XTIMERH TimeSensor { cycleInterval 2 }
DEF XTIMERV TimeSensor { cycleInterval 2 }
# Interpoladores
# Horizontal
DEF ANIMAH PositionInterpolator {
key [ 0, .25, .5, .75, 1 ]
keyValue [ 0 0 0, 8 0 0, 16 0 0, -8 0 0, 0 0 0 ]
}
# Vertical
50
DEF ANIMAV PositionInterpolator {

key [ 0, .25, .5, .75, 1 ]
keyValue [ 0 0 0, 0 -8 0, 0 -16 0, 0 -8 0, 0 0 0 ]
}
# Texto
DEF SFORM Transform {
children Shape {
geometry Text {
string ["Virtual" ]
fontStyle FontStyle {
style "BOLD"
justify "MIDDLE"
}
length[7]
maxExtent 20
}
}
}
]
}
# Toque na esfera inicia relgio
ROUTE STOUCH.touchTime TO XTIMERH.set_startTime
# Valores do relgio entram no interpolador horizontal
ROUTE XTIMERH.fraction_changed TO ANIMAH.set_fraction
# Valores gerados pelo interpolador transladam texto horizontalmente
ROUTE ANIMAH.value_changed TO SFORM.set_translation
# Procedimento similar para a caixa
ROUTE BTOUCH.touchTime TO XTIMERV.set_startTime
ROUTE XTIMERV.fraction_changed TO ANIMAV.set_fraction
ROUTE ANIMAV.value_changed TO SFORM.set_translation
5.5 N Script
Apesar de ser um recurso poderoso, o roteamento de eventos entre os ns no suficiente para o tratamento de vrias classes
de comportamento. Por exemplo, no possvel escolher entre duas trajetrias pr-definidas (lgica de deciso). Para superar
esta limitao, VRML define um n especial chamado Script, que permite conectar o mundo VRML a programas externos,
onde os eventos podem ser processados. Este programa externo, teoricamente, pode ser escrito em qualquer linguagem de
programao, desde que o browser a suporte. Na prtica, apenas Java e JavaScript so usadas.
O n Script ativado pelo recebimento de um evento. Quando isso ocorre, o browser inicia a execuo do programa
definido no campo url do n Script. Este programa capaz de receber, processar e gerar eventos que controlam o
comportamento do mundo virtual. Por meio do n Script possvel usar tcnicas bem mais sofisticadas que a intepolao
linear para a gerao de animaes.
Script {
ExposedField MFString url
Field SFBool mustEvaluate
Field SFBool DirectOutput
[name.class ] # url do programa

FALSE # browser atrasa o envio dos eventos ao
# script at serem necessrios ao browser
FALSE # script tem acesso a informao via seus eventos
}
A seguir dado um exemplo utilizando o n Script, cujo roteamento representado graficamente na Figura 23.
#VRML V2.0 utf8
51
# Este exemplo define um cubo e uma esfera. O cubo muda de cor com um toque. A esfera
# est continuamente rotacionando a menos que o cubo tenha mais de 50% de cor vermelha
Group {
children [
# Esfera
DEF Sph Transform {
children Shape {
geometry Sphere {}
material Material { diffuseColor 1 0 0 }
}
}
}
Transform {
translation -2.4 .2 1
rotation 0 1 1 .9
children [
# Cubo
Shape {
geometry Box {}
material DEF MATERIAL Material {}
}
}
DEF TS TouchSensor {} # sensor associado ao cubo
]
}
# Arquivo script associado
DEF SC Script {
url "extouchcube.class"
field SFColor currentColor 0 0 0
eventIn SFColor colorIn
eventOut SFBool isRed
}
]
}
DEF myColor ColorInterpolator {
keys [0.0, 0.3, 0.6, 1.0 ]
# red, green, red, blue
values [1 0 0 , 0 1 0, 1 0 0, 0 0 1]
}
DEF myClock TimeSensor {
cycleInterval 10 # 10 segundos de animao red -> green -> red -> blue
}
DEF XTIMER TimeSensor {
loop TRUE
cycleInterval 5
}
52
DEF ENGINE OrientationInterpolator {

keys [ 0, .5, 1]
values [ 0 1 0 0, 0 1 0 3.14, 0 1 0 6.28]
}
# Toque no cubo inicia alterao de cor no mesmo
# sensor -> relgio -> interpolador -> cor do cubo
ROUTE TS.touchTime TO myClock.set_startTime
ROUTE myClock.fraction TO myColor.set_fraction
ROUTE myColor.value_changed TO MATERIAL.diffuseColor
# Alterao de cor do cubo enviada para Script
ROUTE myColor.value_changed TO SC.colorIn
# Evento gerado pelo n Script habilita ou desabilita relgio
ROUTE SC.isRed TO XTIMER.enabled
# Relgio determina rotao da esfera
# relgio -> interpolador -> movimento da esfera
ROUTE XTIMER.fraction TO ENGINE.set_fraction
ROUTE ENGINE.value_changed TO Sph.set_rotation
Figura 23: Roteamento de eventos para o exemplo usando o n Script.
O programa Java que implementa a funcionalidade do n Script do exemplo acima (extouchcube.java) mostrado a seguir.
import vrml.*;
import vrml.field.*;
import vrml.node.*;
public class extouchcube extends Script
53
{
// declaraes dos campos e eventOuts usados
private SFColor currentColor;
private SFBool isRed;
public void initialize() {
// alocao dos campos e eventos
currentColor = (SFColor) getField("currentColor");
isRed = (SFBool) getEventOut("isRed");
}
// mtodo chamado no recebimento do evento colorIn
public void processEvent(Event e) {
currentColor.setValue((ConstSFColor)e.getValue());
}
public void eventsProcessed() {
// componente vermelho da cor maior que 50% -> envio de isRed = FALSE,
// o que desabilita o relgio que controla a rotao da esfera da cena
if (currentColor.getRed() >= 0.5)
isRed.setValue(false);
else isRed.setValue(true);
}
}
5.6 EAI (External Authoring Interface)

A EAI [35] uma interface para permitir que ambientes externos acessem os ns de uma cena VRML. Embora tenha
objetivos similares aos do n Script (processamento de eventos, definindo o comportamento dos objetos do mundo virtual),
a EAI funciona de maneira diferente. A EAI opera na forma de um applet Java independente, enquanto o n Script opera
dentro do browser VRML. Dentre as vantagens da EAI com relao ao n Script esto includas uma maior modularidade
e simplicidade dos programas, alm de maior liberdade para a construo de interfaces complexas para a interao com o
mundo VRML.
De uma maneira geral, pode-se dizer que o n Script adequado quando se deseja adicionar um comportamento
individual a objetos da cena. A EAI, por sua vez, mais adequada para a criao de sistemas multimdia complexos, onde
VRML apenas um meio de apresentao. O blaxxun Contact [36] um exemplo de sistema que usa a EAI. Ele um cliente
para comunicao multimdia que oferece recursos como suporte a VRML, chats, message boards, interao com agentes,
etc. Vrios usurios imersos no mesmo mundo virtual VRML podem se comunicar e interagir por meio de recursos
implementados com a EAI.
Para utilizar os recursos da EAI, necessrio criar uma pgina HTML incluindo a cena VRML e um applet que realiza
a interao com a cena. O applet que interage com a cena um applet Java convencional, que utiliza alguns mtodos para
realizar a comunicao com a cena.
Para receber eventos da cena, a seguinte seqncia de passos deve ser realizada [37]:
1. Criar uma classe observadora dos eventos, que implementa a interface EventOutObserver. Deve-se implementar
o mtodo callback desta classe, que realiza o processamento dos eventos.
2. Criar uma instncia dessa classe no cdigo do applet.
3. Obter a referncia do n gerador do evento e do EventOut desejado. O mtodo advise usado para indicar ao
browser que h o interesse em detectar este evento.
A seqncia acima traduzida no seguinte cdigo (adaptado de [37]).
54
// 1. Cria classe observadora

class MeuObservador implements EventOutObserver {
public void callback (EventOut ev, double timeStamp, Object o)
{
// Processamento sobre o evento...
}
}
class MinhaClasseVRML {
public void MinhaClasseVRML ( )
{
// Conectando ao browser VRML
Browser b = Browser.getBrowser();
// 2. Criando uma instncia da classe observadora
MeuObservador obs = new MeuObservador();
// 3. Obtendo a referncia do n gerador do evento e
// registrando o evento de interesse.
// "NodeName" deve ser o nome do n na cena VRML (DEF NodeName)
b.getNode( "NodeName" ).getEventOut( "fraction_changed" ).advise(obs, null);
// ...
}
}
Para enviar eventos para a cena, o procedimento similar, consistindo nos seguintes passos:
1. Obter a referncia do n para o qual se deseja enviar o evento.
2. Obter a referncia do EventIn deste n.
3. Enviar os valores desejados por meio do mtodo setValue.
Traduzindo isto em cdigo, considere a esfera a seguir, que ser movimentada atravs do campo translation do n
Transform (adaptado de [37]).
#VRML v2.0 utf8
DEF move_esfera Transform {
translation 2 0 -1
children Shape {
geometry Sphere { radius 1.5 }
}
}
O seguinte applet colocar a esfera em uma nova posio.
// Importando algumas classes da EAI
import vrml.external.*;
import vrml.external.field.*;
import java.applet.*;
public class MeuApplet extends Applet {
public void start ( ) {
Browser b = b.getBrowser();
55
// 1. Obtendo referncia do n Transform

Node aTransform = b.getNode( "move_esfera" );
// 2. Obtendo referncia do EventIn "set_translation"
EventInSFVec3f tx =
(EventInSFVec3f) aTransform.getEventIn( "set_translation" );
// 3. Enviando nova posio para o EventIn obtido acima
float nova_posicao[] = {0, 1, 0.5f};
tx.setValue(nova_posicao);
}
}
Recentemente, a EAI e os ns Script foram englobados no que est sendo chamado de Scene Authoring Interface [38],
usada para a manipulao de objetos de uma cena. Esta interface acessvel por meio dos ns Script da cena VRML ou
por meio de aplicaes externas ao browser (EAI).
5.7 X3D (Extensible 3D)

Apesar de ser um padro bastante usado, o Web 3D Consortium reconhece a necessidade de aprimoramento da VRML 97.
A principal tendncia nesse sentido a X3D. X3D [39] uma proposta, ainda em fase de elaborao, para uma nova verso
de VRML com quatro objetivos principais:
Compatibilidade com VRML 97. A tecnologia X3D continuar permitindo a utilizao do contedo escrito em VRML 97.
Integrao com XML. A idia prover as capacidades da VRML 97 usando XML (Extensible Markup Language) [40].
XML um padro que tem sido bastante usado para a definio de estruturas de dados transmitidos pela Internet.
XML chamada extensvel porque no uma linguagem de marcao pr-definida, como HTML. Na verdade, ela
uma metalinguagem (linguagem para descrever outras linguagens) que permite definir novas linguagens de marcao.
Uma linguagem de marcao define a maneira de descrever a informao em uma certa classe de documentos. A
HTML, por exemplo, uma linguagem de marcao que define a estrutura de documentos hipertexto. Na prtica, a
XML permite que seja definido um novo conjunto de rtulos (tags), adequado classe de documentos que se deseja
representar (no caso da X3D, ambientes tridimensionais). O objetivo da integrao entre VRML e XML , alm de
ampliar o pblico usurio da VRML, estar em sintonia com a prxima gerao da Web, que dever ter XML como
padro para transmisso de dados.
Componentizao. Pretende-se identificar a funcionalidade crucial da VRML e encapsul-la em um ncleo simples e extensvel, que todas as aplicaes devem implementar.
Extensibilidade. O ncleo pode ser expandido para prover novas funcionalidades (adio de componentes). A VRML 97
seria, portanto, apenas uma das possveis extenses da X3D. Outras extenses propostas so a GeoVRML [41] e a
H-Anim (Humanoid Animation) [42]. A GeoVRML uma extenso para a representao, usando VRML, de dados
geogrficos, tais como mapas e modelos 3D de terrenos. A H-Anim uma extenso para modelagem e animao de
humanides.
Como j comentado, a X3D ainda est em fase de elaborao, mas o exemplo a seguir ilustra como descrever uma esfera
em X3D baseado no seu estado atual de implementao ( muito parecido com o arquivo em VRML 97, apenas trocando
os ns e parmetros por tags). O arquivo DTD (Document Type Definition) definido no incio a declarao em XML da
sintaxe do X3D, onde esto definidos formalmente os significados das tags uilizadas.
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE X3D PUBLIC
"http://www.web3D.org/TaskGroups/x3d/translation/x3d-compromise.dtd"
"file://localhost/C:/www.web3D.org/TaskGroups/x3d/translation/x3d-compromise.dtd"
56
[
<!ENTITY % Vrml97Profile "INCLUDE">
<!ENTITY % CoreProfile
"IGNORE">
<!ENTITY % X3dExtensions "IGNORE">
<!ENTITY % GeoVrmlProfile "INCLUDE">
<!ENTITY % HAnimProfile
"INCLUDE">
]>
<X3D>
<Scene>
<Transform>
<children>
<NavigationInfo headlight="false" avatarSize=" 0.25 1.6 0.75"
type=""EXAMINE""/>
<DirectionalLight/>
<Transform translation="3.0 0.0 1.0">
<children>
<Shape>
<geometry>
<Sphere radius="2.3"/>
</geometry>
<appearance>
<Appearance>
<material>
<Material diffuseColor="1.0 0.0 0.0"/>
</material>
</Appearance>
</appearance>
</Shape>
</children>
</Transform>
</children>
</Transform>
</Scene>
</X3D>
6 Concluso
Este curso mostrou uma viso geral de algumas tecnologias livres (ou abertas) relacionadas Computao Grfica, adotando
uma abordagem bottom-up, partindo da programao de mais baixo nvel de abstrao para a de mais alto nvel. medida
que o nvel de abstrao aumenta, a programao torna-se mais simples, o que leva possibilidade de implementar aplicaes mais sofisticadas. Em contrapartida, s a programao de mais baixo nvel prov a flexibilidade necessria em certas
situaes. Por esta razo, a abordagem passando por todos estes nveis mostra uma viso abrangente das tecnologias de
Computao Grfica.
O X Window System um sistema de janelas, que pode ser combinado com o OpenGL para a programao grfica.
Java 3D construda sobre a linguagem Java e sobre APIs grficas, como o OpenGL. Alm disso, ela oferece recursos mais
sofisticados, como estruturao da cena, animao e interao com os usurios. VRML tem funcionalidade similar a Java
3D, mas no uma linguagem de programao, apenas um formato para a transmisso de dados 3D pela Internet. Os
recursos mais sofisticados so realizados em VRML por programas externos conectados via n Script ou EAI. Tanto Java
3D quanto VRML so esforos no sentido de prover um padro para a representao e transmisso de contedo interativo
tridimensional atravs da Web.
O que h de comum entre todas as tecnologias apresentadas (alm da relao com a Computao Grfica) e motivou
a elaborao deste curso a filosofia de desenvolvimento das mesmas. Todas estas tecnologias so baseadas nas idias de
57
software livre, de forma mais ampla (como X ou VRML, desenvolvidos por consrcios de empresas e grupos acadmicos)
ou menos rigorosa (software proprietrio, mas gratuito e de cdigo aberto, como OpenGL e Java 3D). A adoo destas
filosofias, alm de aumentar a aceitao dos produtos, garantem maior confiabilidade e sobrevivncia dos mesmos, pois a
comunidade de usurios contribui ativamente em seu desenvolvimento, identificando erros e promovendo a manuteno dos
mesmos. Alm disso, a diversidade de interesses dos grupos desenvolvedores impede a criao de monoplios. Por todos
estes motivos, acreditamos em software livre e incentivamos seu uso e desenvolvimento.
Referncias
[1] Scheifler, R. and Gettys, J. The X Window System. ACM Transactions on Graphics, 5 (2): 79-109, April 1986.
[2] Gettys, J. and Scheifler, R. Xlib C language X interface. Maynard, Digital Equipment Corporation/X Consortium,
1994.
[3] McCormack, J.; Asente, P.; Swick, R. and Converse, D. X Toolkit Intrinsics C Language Interface. Digital Equipment
Corporation/X Consortium, 1994.
[4] The Open Group. X Window System, Version 11, Release 6.4: Release Notes. Cambridge, Open Group, 1998.
[5] Scheifler, R. X Window System Protocol. Cambridge, X Consortium, 1994.
[6] Tanembaum, A. S. Computer Networks. Upper Saddle River, Prentice Hall, 1996.
[7] Rosenthal, D. and Marks, S. W. Inter-Client Communication Conventions Manual. Sun Microsystems/X Consortium,
1994.
[8] Packard, Keith. The X Selection Mechanism.
[9] Nye, A. and OReilly, T. X Toolkit Intrinsics Programming Manual. Sebastopol, OReilly & Associates, 1990.
[10] Open Group Desktop Technologies Motif. http://www.camb.opengroup.org/tech/desktop/motif/.
[11] The OffiX Project. 1997. http://leb.net/OffiX/
[12] Lindall, J. JX C++ Application Framewrk for the X Window System. Disponvel em http://www.
newplanetsoftware.com/jx/.
[13] Lindall. J. Drag-And-Drop Protocol
newplanetsoftware.com/xdnd/.
for
the
Window
System.
Disponvel
em
http://www.
[14] Jones, O. Introduction to the X Window System. Englewood Cliffs, Prentice Hall, 1990.
[15] Theisen, T. Ghostview and GSview. http://www.cs.wisc.edu/~ghost/
[16] The F? Virtual Window Manager home page. http://www.fvwm.org/
[17] Gettys, J. The Two Edged Sword. Disponvel em http://freshmeat.net/editorials/
[18] GNOME the GNU Network Object Model Environment. http://www.gnome.org/
[19] Peterson, C. D. Athena Widget Set C Language Interface. Maynard, Digital Equipment Corporation/X Consortium,
1994.
[20] Segal, M. and Akeley, K. The OpenGL Graphics Interface. Silicon Graphics Computer Systems, Mountain View, CA,
1994. Disponvel em http://trant.sgi.com/opengl/docs/white_papers/segal.ps
[21] Segal, M. and Akeley, K. The Design of the OpenGL Graphics Interface. Silicon Graphics Computer Systems, Mountain View, CA, 1996. Disponvel em http://trant.sgi.com/opengl/docs/white_papers/design.
ps
58
[22] Neither, J.; Davis, T. and Mason, W. OpenGL Architecture Review Board, OpenGL Programming Guide. Addison
Wesley Longman, Inc., 1993.
[23] Kilgard, M. J. OpenGL and X, Part 1: An Introduction. 1994. Disponvel em http://www.sgi.com/software/
opengl/glandx/intro/intro.html
[24] Kilgard, M. J. The OpenGL Utility Toolkit (GLUT) Programming Interface API Version 3. 1996. Disponvel em http:
//reality.sgi.com/opengl/spec3/spec3.html
[25] Angel, E. Interactive computer graphics: a top-down approach with OpenGL. Addison Wesley Longman, Inc., 1997.
[26] Brown, K. and Daniel, P. Ready-to-Run Java 3D. Wiley Computer Publishing, 1999.
[27] Sowirzal, H. A.; Nadeau, D. R. and Bailey, M. Introduction to Programming with Java 3D. 1998. Disponvel em
http://www.sdsc.edu/~nadeau/Courses/SDSCjava3d/
[28] Sowizral, H. A. and Deering, M. The Java 3D API and Virtual Reality. IEEE Computer Graphics and Applications, 19
(3): 12-15, May/June 1999.
[29] Suns Java 3D API Specification Document. Disponvel em http://java.sun.com/products/
java-media/3D/forDevelopers/j3dguide/j3dTOC.doc.html
[30] Getting Started with Java 3DTM API. Tutorial preparado para Sun Microsystems por K Computing, 1999. Disponvel
em http://sun.com/desktop/java3d/collateral
[31] Web 3D Consortium. The Virtual Reality Modeling Language. International Standard ISO/IEC DIS 14772-1. 1997.
Disponvel em http://www.web3d.org/technicalinfo/specifications/vrml97/index.htm
[32] Web 3D Consortium. http://www.web3d.org
[33] Magalhes, L. P.; Raposo, A. B. and Tamiosso, F. S. VRML 2.0 An Introductory View by Examples. Disponvel em
http://www.dca.fee.unicamp.br/~leopini/tut-vrml/vrml-tut.html
[34] Hartman, J. and Wernecke, J. The VRML 2.0 Handbook Building Moving Worlds on the Web. Addison-Wesley, 1996.
[35] Web 3D Consortium. The Virtual Reality Modeling Language - Part 2: External Authoring interface and bindings.
ISO/IEC 14772-2:xxxx. 1999. Disponvel em http://www.web3d.org/WorkingGroups/vrml-eai/
[36] blaxxun interactive. blaxxun Contact 4.4. 2000. Disponvel em http://www.blaxxun.com/products/
contact
[37] Roehl, B. et al. Late Night VRML 2.0 with Java. Ziff-Davis Press, 1997.
[38] Web 3D Consortium. VRML 200x Draft Specification. April 2000. Disponvel em http://www.web3d.org/
TaskGroups/x3d/specification
[39] Web 3D Consortium. X3D Task Group. 2000. http://www.web3d.org/TaskGroups/x3d
[40] The World Wide Web Consortium (W3C). Extensible Markup Language (XML). 2000. http://www.w3.org/XML
[41] Web 3D Consortium. GeoVRML.org. 2000. http://www.geovrml.org
[42] Humanoid Animation Working Group - Web 3D Consortium. Specification for a Standard Humanoid 1.1. Agosto 1999.
Disponvel em http://ece.uwaterloo.ca:80/~h-anim/spec1.1/
Agradecimentos. Agradecemos s instituies a que estamos vinculados pelo apoio e aos rgos que nos financiam:
FAPESP, CAPES e CNPq.
59

Software Livre para Animação e Computação Gráfica (Tutorial)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Software Livre para Animação e Computação Gráfica (Tutorial)

Enviado por

Direitos autorais:

Formatos disponíveis

Software Livre para Computao Grfica e Animao por Computador

Alberto B. Raposo, Adailton J. A. da Cruz; y, Alessandro L. Bicho ,

2.1 Arquitetura do X Window System

Figura 1: Relacionamento hierrquico entre janelas: A

2.2 Interfaces que constituem o sistema de janelas

2.3 Conceitos importantes e terminologia

Figura 2: Fluxo de mensagens

2.5 Autenticao de usurios

2.6 Recursos do servidor

2.7 Comunicao entre clientes

2.8 Arrastar e soltar

2.9 Gerenciamento de janelas

2.10 Tcnicas de programao

2.11 Bibliotecas e toolkits

2.11.2 X Toolkit (Xt)

 inicializao do toolkit e da aplicao;

2.12 Prtica de programao para X

identifica o display a usar */

descobre a tela padro, */

/* "Hints" para o window manager */

/* torna a janela visvel no display */

Lao de Tratamento de Eventos

XtAppAddActions(app, actions, XtNumber(actions));

XDrawArc(display, d, gc, x, y, width, height, angle1, angle2)

Retngulos. XDrawRectangle e XDrawRectangle permitem desenhar um ou diversos retngulos de cada vez:

2.12.5 Manipulao de contextos grficos

 Home-page do projeto LessTif: http://www.lesstif.org/

3.1 Objetos geomtricos

Figura 6: Primitivas geomtricas do OpenGL [23].

matriz atual aquela que est no topo da pilha.

Figura 7: O volume de visualizao da projeo perspectiva.

Figura 8: O volume de visualizao da projeo ortogonal.

Figura 9: Um tringulo desenhado no modo smooth.

// Define somente a posio da fonte de luz - os valores das

Figura 10: Exemplo do modelo de

Figura 11: Exemplo do mapeamento de

Figura 12: Relao entre as vrias camadas de software

4.2 O grafo de cena em Java 3D

Figura 13: Grafo de uma cena em Java 3D.

Figura 15: Grafo de cena do Exemplo01.

public class Exemplo01 extends Applet {

// A instanciao de um objeto SimpleUniverse corresponde

Transform3D rotate2 = new Transform3D();

Figura 16: Imagem produzida pelo Exemplo01.

4.2.2 Configurando as capacidades de um objeto Java 3D

TransformGroup alvo = new TransformGroup();

Figura 17: Objetos array e strip.

// Cria um objeto QuadArray vazio com 4 vrtices e o flag de formato

quadrado.setCoordinates (0, vertice);

Figura 18: Subgrafo da cena relativa ao Exemplo02.

Figura 19: Scheduling bound.

Figura 20: Grfico Alpha: tempo x valores alpha.

Alpha valoresalpha = new Alpha(-1, 4000);

Figura 21: Grfico Alpha com infinitos ciclos.

TransformGroup alvo = new TransformGroup();

5 VRML (Virtual Reality Modeling Language)

5.1 Estrutura hierrquica da cena

5.2 Prototipao e reuso

5.3 Tipos de parmetros e roteamento de eventos

5.4 Sensores e interpoladores

CoordinateInterpolator, ColorInterpolator, OrientationInterpolator. De forma similar interpolam, respectivamente, uma

Figura 22: Roteamento de eventos em uma interao tpica de VRML.

DEF ANIMAV PositionInterpolator {

inicializao do toolkit e da aplicao;

Home-page do projeto LessTif: http://www.lesstif.org/