240 likes | 321 Views
VRJuggler. Bruno Barberi Gnecco Rita de Fátima Rodrigues. Realidade Virtual Prof. Marcelo Knörich Zuffo. Programação da Apresentação. Visão Geral (Rita) O que é VRJuggler ? Histórico Arquitetura Object Application Visão prática (Bruno) Estrutura geral de um programa VRJuggler
E N D
VRJuggler Bruno Barberi Gnecco Rita de Fátima Rodrigues Realidade Virtual Prof. Marcelo Knörich Zuffo
Programação da Apresentação • Visão Geral (Rita) • O que é VRJuggler ? • Histórico • Arquitetura • Object Application • Visão prática (Bruno) • Estrutura geral de um programa VRJuggler • Exemplo simples • Comparação com outras soluções • Conclusão
Filosofia de desenvolvimento • Sem main(): “Don't call me, I'll call you” • Objetos da aplicação derivam de classes base • Desenvolvimento de aplicativo via “Filling in the Blanks”
Aplicativos objeto • Modificações em tempo de execução • Baixa interdependência • Interfaces estáveis
Desenvolvimento de programas • Programa é um objeto: class userApp : public vrj::App { public: init(); preFrame(); postFrame(); ... }
Aplicativos como objetos • Derivação de classes permite minimizar trabalho • Programa pode ser derivado de classes mais avançadas, como: • GlApp (OpenGL) • PfApp (Performer) • OpenSGApp • VTKApp
Estrutura de classes vjApp init apiInit exit … vjGlApp draw contextInit contextClose userOglApp Init apiInit draw preFrame postFrame
Aplicativo Instancia a kernel Instancia o aplicativo int main (int argc, char* argv[]) { vjKernel* kernel = vjKernel::instance(); simpleApp* app = new simpleApp(); kernel->loadConfigFile(...); kernel->start(); kernel->setApplication(app); while ( ! exit ) { // sleep } } Configura a kernel Inicia a kernel Especifica o aplicativo
Portando aplicativos • Portar aplicativos OpenGL, CAVElib: “receita de bolo” • Problema: comandos compilados (p.e., display lists) não são compartilhados entre contextos • Em VR Juggler estas inicializações devem ir em vrj::GlApp::contextInit().
NetJuggler • Layer sobre o VRJuggler. • Torna um cluster gráfico em uma máquina VRJuggler single image. • Executa a distribuição e sincronia de dados e computações entre os nós automaticamente. • Implementação sobre MPI.
Estudo comparativo • Outras soluções semelhantes existem • CAVElib • Syzygy • Chromium • FreeVR • DICElib
CAVElib • Primeira biblioteca do gênero • Padrão para aplicativos CAVE em SGI • Paga, código fechado • Inicialmente só para IRIX, agora também para SUN, HPUX, LINUX e WIN32
CAVElib (II) • Funcionamento semelhante ao GLUT, mas muito mais poderoso • Calcula janelas e projeção perspectiva automaticamente. • Compatível com OpenGL e Performer • Abstração de input • Suporta multiprocessamento
Exemplo de CAVElib Configura Cavelib main(int argc,char **argv) { CAVEConfigure(&argc,argv,NULL); app_shared_init(argc,argv); CAVEInit(); CAVEInitApplication(app_init_gl,0); CAVEDisplay(app_draw,0); app_compute_init(argc,argv); while (!getbutton(ESCKEY)) { app_compute(); } CAVEExit(); } Inicializa Cavelib Callback de inicialização OpenGL Callback de desenho Termina Cavelib
Prós Padrão conhecido Sistema desenvolvido e estável Portabilidade Base de programas grande Simples de usar Contras Código fechado Cara Som é suportado por biblioteca externa CAVElib: prós e contras
Syzygy • High-End VR on Whatever Random Crap “You have Lying Around” • Desenvolvida para clusters. • Tile rendering • Open source • Universidade deIllinois at Urbana
Syzygy II • Implementa um “SO distribuído”: Phleet • Instalação complexa • Suporte a input • Implementa scene graph e som 3D
Chromium • Solução para divisão de renderização (tile rendering) • Nova versão da WireGL • Emula OpenGL • Extensível • Open source • Único ponto de vista (futuro?)
FreeVR • Solução open source independente • Suporta diversos sistemas de I/O • Desenvolvido para ser fácil de rodar • Portável: • SGI IRIX 6.x (o32, n32 & 64 bit) • Linux • BSD Unix (Free/Net/Open) • Solaris • Macintosh OS/X (Darwin w/ XFree86) • Cygwin (Undergoing development) • HP-UX • Tru-64
DICElib • Biblioteca com sincronia (barreira) e compartilhamento de dados (síncrono). • Não suporta input, configurações de visualização • Escrita sobre sockets: TCP e UDP. • Programas alvo: pouco compartilhamento de memória, alta taxa de sincronia. • Poucas modificações necessárias do programa single-view para executar no cluster. • Estável, nova versão em curso.
Estudo de caso: CAVEQuake 3 • Escrito por Paul Rajlich (paul@visbox.com) • http://brighton.ncsa.uiuc.edu/~prajlich/ • Suporta 7 interfaces diferentes: • CAVElib • VRJuggler • GLUT • SGI MPSDK • FreeVR • SDL • GLX • [Syzygy]
Conclusão I • Alternativa poderosa e portável • Arquitetura complexa com muitas abstrações • Perda de performance • Curva de aprendizado • Estruturação lógica do código e do programa • Pode ser difícil portar programas existentes (ou não) • Programas são sempre semelhantes e fáceis de entender e modificar • Instalação e configuração não triviais
Conclusão II • Integração com várias APIs: OpenGL, Performer, OpenSG, VTK… • Extensível • Como disse o Stroustroup: “C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg”
Referências • VRJuggler: http://www.vrjuggler.org • CAVElib: http://www.cavelib.com • Syzygy: http://www.isl.uiuc.edu/ClusteredVR/ClusteredVR.htm • FreeVR: http://www.freevr.org/ • Chromium: http://chromium.sourceforge.net • DICElib: http://www.lsi.usp.br/~brunobg • CAVEQuake: http://brighton.ncsa.uiuc.edu/~prajlich/