Desarrollo de técnicas cooperativas para un editor de ... · Desarrollo de técnicas cooperativas...

Desarrollo de técnicas cooperativ as paraun editor de objetos 3D

ProyectodeFin deCarreraIngenieríaInformática

David SánchezCrespilloUniversitatdelesIlles Balears

Año 2000

Índice General

1. Intr oducción 6

I. Conceptos generales 8

2. El sistema M3D y el editor 92.1. El sistemaM3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. Estructuray aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . 102.2. El editordeobjetos3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3. Estructuradela aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Open Inventor y VRML 97 153.1. El grafodeescena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2. Operacionessobreel grafodeescena. . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2. Estadoglobaldeunaescena . . . . . . . . . . . . . . . . . . . . . . . 193.2.3. Modificacionesdel grafodeescena . . . . . . . . . . . . . . . . . . . 193.2.4. Borradodenodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3. Nodosprincipalesenel grafodeescena . . . . . . . . . . . . . . . . . . . . . 203.3.1. Nodosdeagrupación. . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2. Nodosdegeometría . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.3. Nodosdepropiedad . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Visualizacióndeunaescena . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5. RelaciónentreOpenInventory VRML 97 . . . . . . . . . . . . . . . . . . . . 24

3.5.1. El formatoVRML 97 . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.2. DiferenciasentreOpenInventory VRML 97 . . . . . . . . . . . . . . 253.5.3. SoporteparaVRML 97enOpenInventor . . . . . . . . . . . . . . . . 27

4. Sopor te al trabajo cooperativ o 304.1. La plataformaJESP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.1. Estructurageneral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.2. Mododeejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.3. InterfazEditor - JESP . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2. La basededatospersistenteenmemoria . . . . . . . . . . . . . . . . . . . . . 334.3. El protocoloMu3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

David SánchezCrespillo.UniversitatdelesIlles Balears Página2

ÍndiceGeneral

II. Técnicas cooperativ as desarr olladas 40

5. Manejo cooperativ o de los datos 3D 415.1. Definicióndeobjeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2. Gestióncooperativadeescenasmúltiples. . . . . . . . . . . . . . . . . . . . . 41

5.2.1. Estructuradel conjuntodeescenas. . . . . . . . . . . . . . . . . . . . 425.2.2. Operacionesbásicassobreescenas. . . . . . . . . . . . . . . . . . . . 435.2.3. Soportecooperativo a la gestióndeescenasmúltiples . . . . . . . . . . 44

5.3. Formatostridimensionalessoportados . . . . . . . . . . . . . . . . . . . . . . 455.4. Entraday salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.4.2. Almacenamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6. Acceso concurrente a los objetos 3D 496.1. Conceptodeselección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2. Implementacióndela políticadeselección. . . . . . . . . . . . . . . . . . . . 50

6.2.1. Controldeseleccioneslocales . . . . . . . . . . . . . . . . . . . . . . 516.2.2. Controldeseleccionesremotas. . . . . . . . . . . . . . . . . . . . . . 52

6.3. Representacióngráficadelasselecciones . . . . . . . . . . . . . . . . . . . . 53

7. Edición básica cooperativ a 557.1. Requerimientosgenerales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2. Insercióny borradodeobjetos . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2.1. Insercióndeun objeto . . . . . . . . . . . . . . . . . . . . . . . . . . 567.2.2. Borradodeun objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.3. Manipulacióngeométricainteractiva . . . . . . . . . . . . . . . . . . . . . . . 577.3.1. Introduccióna losmanipuladores . . . . . . . . . . . . . . . . . . . . 577.3.2. Gestióndelosmanipuladores . . . . . . . . . . . . . . . . . . . . . . 58

7.4. Materiales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.4.1. Introduccióna losmateriales. . . . . . . . . . . . . . . . . . . . . . . 607.4.2. Gestióndeeditoresdemateriales . . . . . . . . . . . . . . . . . . . . 61

7.5. Iluminacióndeunaescena . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.5.1. Introduccióna lasluces. . . . . . . . . . . . . . . . . . . . . . . . . . 637.5.2. Localizacióndelaslucesencadagrafodeescena. . . . . . . . . . . . 647.5.3. Gestióndelasluces. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8. Por tapapeles cooperativ os 698.1. Requerimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.2. Estructurasdedatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.3. Implementacióndelasoperaciones. . . . . . . . . . . . . . . . . . . . . . . . 70

8.3.1. Soportecooperativo . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.3.2. Implementacióndela operacióndecopiar . . . . . . . . . . . . . . . . 708.3.3. Implementacióndela operacióndepegar . . . . . . . . . . . . . . . . 71

8.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


ÍndiceGeneral

9. Vuelta atrás en un entorno cooperativ o 739.1. Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739.2. El conceptodeámbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

9.2.1. El ámbitodeselección . . . . . . . . . . . . . . . . . . . . . . . . . . 759.2.2. El ámbitodeinserción . . . . . . . . . . . . . . . . . . . . . . . . . . 769.2.3. El ámbitodeborrado . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9.3. Almacenamientodel estadoprevio . . . . . . . . . . . . . . . . . . . . . . . . 779.3.1. Almacenamientodel estadoprevio enel ámbitodeselección. . . . . . 779.3.2. Almacenamientodel estadoprevio enel ámbitodeinserción . . . . . . 789.3.3. Almacenamientodel estadoprevio enel ámbitodeborrado. . . . . . . 79

9.4. Realizacióndela vueltaatrás . . . . . . . . . . . . . . . . . . . . . . . . . . . 799.4.1. Realizacióndela vueltaatrásenel ámbitodeselección. . . . . . . . . 799.4.2. Realizacióndela vueltaatrásenel ámbitodeinserción . . . . . . . . . 809.4.3. Realizacióndela vueltaatrásenel ámbitodeborrado. . . . . . . . . . 80

9.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

III. Conc lusiones 82

10.Conc lusión 8310.1.Resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8310.2.Trabajofuturo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8410.3.Problemasencontrados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.4.Herramientasy lenguajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.5.Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

IV. Apéndices 87

A. Desarr ollo de versiones concurrentes 88A.1. El sistemaCVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A.2. Políticadeutilización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A.3. Configuracióny aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

B. Por tabilidad y múltiples plataf ormas 94B.1. Consideracionesprevias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94B.2. Portarla aplicacióndeIrix a WindowsNT . . . . . . . . . . . . . . . . . . . . 95

B.2.1. Estadoinicial dela aplicación.La plataformaIrix . . . . . . . . . . . . 95B.2.2. WindowsNT y el entornodeprogramaciónVisualC++ . . . . . . . . . 96B.2.3. El procesodeadaptacióndecódigo . . . . . . . . . . . . . . . . . . . 97B.2.4. Procesodepruebasy problemasencontrados. . . . . . . . . . . . . . 98

B.3. Desarrollosimultáneodela aplicaciónenIrix y WindowsNT . . . . . . . . . . 98


ÍndiceGeneral

V. Índices y bibliografía 100


1. Intr oducción

En estamemoriapresentamosun conjuntode módulosy técnicasimplementadosduranteeldesarrollode un editor interactivo de objetostridimensionalesparatrabajocooperativo. Es-tosmódulosy técnicasestándestinadosa hacerposibleel trabajocooperativo entremúltiplesusuariossimultáneos.El editorserviráparaquearquitectoseingenierospuedantrabajarcoope-rativamentesobreunamismaescenatridimensional,aunqueseencuentrensituadosendistintoslugaresgeográficamentedispersos(inclusoendistintospaíseseuropeos).

El hechode queel editor estéenfocadoal trabajocooperativo esuno de los puntosmásimportantesdel proyecto.Esnecesariotenerunaarquitecturaderedsubyacentey utilizar losprotocolosdeaplicaciónadecuados,demaneraqueel trabajocooperativo seaposible,razona-blementerápidoy fiable.

Del mismomodo,el editorhadeseraplicadoal ámbitodela construcción.Estosignificaquedebeincorporarunaseriedecaracterísticasdeediciónquesondemandadasporlosusuariosfinalesdela aplicación,esdecir, arquitectoseingenieros.Estascaracterísticasdeedicióndebenfuncionardeformacooperativa.

Porotraparte,el editorimplementafuncionesquehansidodiseñadase implementadaspordistintasempresasy centrosde investigacióndentrodel mismoproyecto.Porello, sudiseñogeneralesabiertoy permiteintegrarestasfuncionesdesdedistintasfuentes.Además,hadeserextensible,de forma quesepuedanintroducir nuevascaracterísticassin afectaral restode laaplicación.

Otra de las característicasquepresentael editor esquese tratade unaaplicacióndesa-rrollada por un equipode programadores,no por unasola persona.La comunicaciónentreprogramadores,la estabilizaciónde código, la implantaciónde nuevasversiones,presentanproblemasquesedebensolucionar, paraqueel tiempodedesarrollonosealarguey sepuedancumplir los plazosdeentregadelproductosoftware.

A lo largodeestamemoria,explicaremosdequémanerahemosimplementadoel funciona-mientocooperativo delasoperacionesbásicasdeediciónenel editor, y el deotrasoperacionesmásavanzadas,comolastécnicasdeportapapelesy la vueltaatrás.

En la primeraparte,explicamoslosconceptosgeneralesenlos quesehaapoyadoel desa-rrollo de lastécnicascooperativas.El Capítulo2 explica la estructurageneraldel editor3D yel sistemageneral.El Capítulo3 describeOpenInventor, el sistemadelibreríasdedesarrollo3D utilizadoenla aplicación.Porúltimo, el Capítulo4 describelasplataformasdesoportealtrabajocooperativo quehemosutilizadoparala implementación.

La segundaparteexplica las técnicasimplementadasy extendidasparahacerposibleeltrabajocooperativo conel editordeobjetos3D. En el Capítulo5 explicamosla formaenquehemosimplementadoel manejode los datostridimensionalesen el marcocooperativo. El


Capítulo1. Introducción

Capítulo6 explica la implementacióndel control de concurrenciausandoexclusión mutuaentreusuariosal accedera objetos3D, medianteunatécnicabasadaenseleccionesdeobjetos.El Capítulo7 explica la implementaciónde lasfuncionesbásicasdel editor (entraday salida,manipulacióngeométricainteractiva,edicióndematerialesy parámetrosdeiluminación)desdeel punto de vista cooperativo. Por último, los Capítulos8 y 9 explican la implementacióncooperativadedosfuncionesmásavanzadas:lasoperacionesdeportapapelesy la vueltaatrás.

Seha incluido unasecciónde apéndicesquereflejanaspectosimportantes,tantodel de-sarrollode las técnicascooperativas,comodel diseñogeneralde la aplicación. Hemoscon-sideradonecesarioincluirlos, puestoquereflejanunadimensióncomplementariadel procesode implementación.El ApéndiceA explica el sistemadedesarrolloconcurrenteadoptadoporel equipodeprogramadores.El ApéndiceB, por último, explica lasconsideracionesseguidassobreportabilidady multiplataformaduranteel desarrollodela aplicación.

Esteeditorhasidodiseñadoe implementadodentrodelmarcodel proyectoeuropeoM3D,quereunea seissociosde trespaíseseuropeos,entreellos la Universitatde les Illes Balears.Los seissociossonlossiguientes:

� UniversitatdelesIlles Balears(PalmadeMallorca,España).

� ADETTI (Lisboa,Portugal).

� EuropeanDesignCenter(Eindhoven,Holanda).

� OficinadeArquitectura(Lisboa,Portugal).

� IDOM (Barcelona,España).

� ArqMaq(PalmadeMallorca,España).

Tresdelossocios(UIB, ADETTI y EDC)actúancomodesarrolladores,mientrasquelosotrostressocios(OA, IDOM y ArqMaq) actúancomousuariosde los productosgeneradosen elproyecto.Estosusuariosaportansugerenciasy líneasdetrabajoquedeterminanalgunasdelascaracterísticasimplementadasdentrodel editor.


Parte I.

Conceptos generales


2. El sistema M3D y el editor

El editor cooperativo de objetos3D es la aplicaciónsobrela quehemosimplementadolasfuncionesy técnicasexplicadasenestamemoria.Esteeditorrecibeel nombredeM3D Editor([SC00b],[SC99a]) y estáintegradoenel sistemaM3D. Enestecapítulodescribimosel sistemaM3D, losmódulosdequeconsta,el propósitodel editory suestructura.

2.1. El sistema M3D

El sistemaM3D ([Gal97], [Luo98], [Gal99], [Luo99], [Luo00]), implementadoy financiadopor el proyectoeuropeoESPRIT26287del mismonombre,surgea partir de la problemáticaa la horade integrary coordinardiseñosdedistintasespecialidadesenunaproducciónarqui-tectónica.En el diseñoy construccióndeun edificio esnecesarioqueespecialistasdiferentestrabajencoordinadamente.Sinembargo,cuandosehandeintegrarlosplanosgeneradosporunarquitectoconlos diseñosdeestructurasy conlos diseñosdecañeríasdeotrosdosingenierosdistintos,esfácil queaparezcanproblemasdecoherencia.Estoesdebidoa la falta de un so-portetecnológicointegradoquefacilite el intercambiodeinformación.Porello, habitualmentetienelugarun ciclo de“pruebay error” hastaqueseobtieneel resultadofinal. Esteproblemaralentizael procesode producción,ya quelos problemasde coherenciasondetectadosnor-malmenteen fasesavanzadasdel proyecto,inclusoen la fasede construcción,lo queresultaextremadamentecostosodesolventar.

El proyectoM3D presentaunasolucióndoble a esteproblema. Las dos partesde estasoluciónsonlassiguientes:

� Porun lado,el proyectoproponeun replanteamientodel procesodenegocio,basadoenla utilizacióndeherramientastecnológicasy decomunicación.

� Por otra parte,el proyectopresentaun sistema,el sistemaM3D, quedarásoportealtrabajocooperativo básicoenla producciónarquitectónica,durantela fasedediseño.

El objetivo técnicoprincipaldel sistemaM3D consisteenhacerposibleel accesoy el usodela informacióntécnica(principalmenteinformacióngeométrica)paraespecialidadesdistintas(arquitectose ingenieros).Estoimplica queel sistemahadetenerlassiguientescapacidades:

� Visualizacióndistribuidadela informacióngeométricay técnica.

� Modificacióninteractivay cooperativa de los objetosCAD por un equipodediseñoar-quitectónico.


Capítulo2. El sistemaM3D y el editor

� Almacenamientoy recuperacióndelosdatosenunabasededatoscompartida([SC99b]).

Los objetivosespecíficosdel sistemaM3D, quehandeterminadoel diseñoposteriorde suselementos,sonlossiguientes:

� Proporcionarinformaciónactualizadalo antesposibleatodoslosusuariosqueparticipenen un proyectoarquitectónico(arquitectose ingenieros).Estoevitará quelos usuariosdesarrollensutrabajoconinformacióndesfasada.

� Proporcionarla capacidaddevisualizacióny ediciónparala agregacióny desagregacióndeldiseñoprincipalconel restodeproyectosdeespecialidadesdistintas.Estacapacidadde visualizacióny edicióndebedarsetanto en modode trabajocooperativo comoenmododetrabajomonousuario.

� Proporcionardetecciónbásicadeinconsistenciasdurantela agregacióndeproyectosdediferentesespecialidades.

� Identificarlasmodificacionesenlageometría,asícomolosautoresdeéstas,deformaqueel coordinadordelproyectopuedacontactarconlosautoresy discutirlasmodificaciones.

� Almacenamientodela informacióncomplementariaacercadel proyectoarquitectónico,tal comotablas,descripcionestextualesy anotaciones.

� Inclusióndeherramientascomplementariasdecomunicaciónquefaciliten la interacciónduranteel trabajocooperativo, talescomoaplicacionesdeaudioy videoconferencia.

� Disponibilidaddel sistemaparahardware de bajo coste(estacionesde trabajobasadasenarquitecturasPC,ademásdelasarquitecturasSiliconGraphics).

� Bajo consumode anchode banda,quepermitautilizar sistemasde comunicacionesdebajo coste. El estándarde conectividad adoptadoha sido la Red Digital de ServiciosIntegrados(RDSI).

Uno de los ámbitosde aplicaciónmásimportantesdel sistemaM3D tiene quever con losconceptosdeagregacióny desagregacióndela informacióninvolucradaenun proyectoarqui-tectónico.La agregaciónde la informaciónesnecesariaparapodercomprobarla coherenciadelosdatosprocedentesdelasdiferentesespecialidades.La desagregacióndela información,por otro lado, esnecesariaparaque los distintosespecialistaspuedantrabajarpor separadoensusdiseñosrespectivos. De hecho,el procesoactualdeproducciónarquitectónicaconsistebásicamenteenunciclo iterativodeagregacióny desagregacióndelasdistintasespecialidades,hastaobtenerel resultadointegradofinal.

2.1.1. Estructura y aplicaciones

El sistemaM3D proporcionaun entornototalmentedistribuidodestinadoal diseñoarquitectó-nico,queconstadelassiguientesaplicaciones:



� Un editorcooperativo deobjetostridimensionales:M3D Editor.

� Un módulo de verificación de diseñosarquitectónicosy detecciónde interferencias:M3D Interdetect.

� Unabasededatoscompartidaespecializadaentratamientodeobjetostridimensionales:M3D Database.

� Un sistemadesoporteal trabajocooperativo: M3D Metaconference.

Comosepuedeverenla Figura2.1,el sistemaM3D sigueunaestructuradereplicacióndeapli-caciones,deformaquecadaunadelasestacionesdetrabajoejecutaunainstanciadelsoftwaredeaplicación.La comunicacióntienelugarmedianteel envío demensajes,y la comparticióndedatosserealizamedianteel accesoconcurrentea la basededatos.

� � ��

� � ��

� � ��

� � ��

� � ��

� � ��

� � ��

� � ��

Figura2.1.:Esquemadela estructuradeejecucióndel SistemaM3D.

La herramientaprincipaldel sistemaM3D esel M3D Editor. Estaaplicaciónrepresentaelmarcoprincipaldondeel usuariopodrávisualizar, verificary editarla geometríatridimensionaldeun diseñoarquitectónico.El editor integra,asimismo,otrosmódulos,talescomoM3D In-terdetecty los módulosde accesoa la basededatos.Estosmódulosseránvisiblesal usuariomediantesuinterfazconel editor.

La basededatoscompartida([SC99b])contienelasdistintasversionesdecadaunodelosdiseñosarquitectónicosy permitela recuperaciónpor contenidode cadauno de los objetos.La recuperacióny almacenamientode los objetostienelugar medianteunainterfazHTTP ymedianteel módulodeaccesointegradoenel editor.

La ejecuciónde cadauna de las aplicacioneses gestionadapor una aplicaciónde altonivel quecontrolalasfuncionesrelacionadasconel trabajoengrupo.Estaaplicación,llamada



M3D Metaconference([Alm95]), seencargadesimularun entornodeconectividadtotalentrelos usuariosmedianteel controlsobrela sesióncolaborativa.

2.2. El editor de objetos 3D

El editorseejecutadeformadistribuidaencadaunadelasestacionesdetrabajo.Cadaunadeellasejecutaunaréplicade la aplicaciónde forma sincronizada.El porquéde estemododeejecuciónseilustraenel Capítulo4. Un esquemadeestemododeejecuciónsepuedever enla Figura2.2.Esposibletambiénla ejecucióndel programaenmodolocal.

� � � �

�� ! " #

$ % & '

( ) * + ) ,

� � � �

�� ! " #

$ % & '

( ) * + ) ,

� � � �

�� ! " #

$ % & '

( ) * + ) ,

- . / 021 3 4

Figura2.2.:Esquemadela ejecucióndistribuidadel editor

El editorpermiterealizaroperacionesdevisualizacióny ediciónde los datostridimensio-nalesqueformanun diseñoarquitectónico.Además,proporcionaun entornocooperativo detrabajo,en el cual los usuariospuedenobservar la localizaciónde cadaparticipanteen unasesióncooperativay el puntodevistadecadauno.

El entornocooperativo de trabajodel editor siguediversosestándaresde realidadvirtualampliamenteaceptados([Bro96b], [Bro96a],[Bro97a],[Bro97b]),comosonlossiguientes:

5 La inmersiónen la escenatridimensional.Los usuariostienenla capacidadde navegardentrode la escenay de introducirsevirtualmente“dentro” de los edificioso construc-cionesarquitectónicas.

5 La representaciónde los demásusuariosen la escena.Paraello, sesigueel métododerepresentaciónmedianteavatares. Un avatarconsisteenla representacióndeun usuario(generalmenteenformahumanoide),conla mismaposicióny orientaciónqueel usuariotieneenesemomento.De estemomento,cadausuariosabequéusuariosseencuentranenla escena,asícomola posicióny la orientacióndeéstos.



Ademásde la posibilidadde navegar por la escenay de visualizara los otrosparticipantes,los usuariospuedenmodificarlos objetosquela forman.Lasmodificacionessonvisualizadasinteractivamenteentodaslasréplicasdel editor.

Figura2.3.:Pantallaprincipaldel editor.

La interfazde usuariodel editor ofrecetodaslas facilidadesposiblesparaaccedera losdatosarquitectónicosdediversasformas.Unaimagendeestainterfazdeusuariopuedeverseenla Figura2.3.

El editorutiliza el formatoVRML deficherosdedatostridimensionales.Esteformatoesconsideradoun estándarparala mayoríadeaplicacionesdemanejodeobjetos3D. Sobreesteformatohablaremosenel Capítulo3.

2.3. Estructura de la aplicación

Comopodemosver enla Figura2.4,el editorhasidodiseñadoenbaseaunaestructuramodu-lar. En la figurapodemosver los distintosmódulosdequeestácompuesto,queexplicamosacontinuación:

6 Módulo de interfazde usuario(User Interface), queimplementalas funciones(depen-dientesdel sistemade ventanassobreel que el editor estáimplantado)relativasa lagestióndeloselementosdeinterfazgráficadeusuario.

6 Módulo de entraday salida(Input andOutput), querecogelas funcionesy estructurasdedatosquedansoportea las rutinasdeentraday salida,tantoa discocomoa basededatos.



7 Módulodeedición(Editing), queagrupalasoperacionesrealizadassobrelosdatosgeo-métricosdeunaescena.

7 Módulo devisualización(Viewing), enel cualseimplementanlasoperacionesrelativasa la presentacióndelosdatosgeométricosdediversasformasútilesparael usuariofinal.

7 Módulo degestiónlocal dedatos(Local Data Management), dentrodel cualseencuen-tranlasoperacionesdegestióny actualizacióndelasestructurasdedatosinternas.

7 Módulodeconsistenciadememoria(MemoryConsistency), queincluyelasoperacionesnecesariasparamantenerconsistenteslasdistintasréplicasdelosdatosgeométricos.

7 Módulo desoporteal trabajocooperativo (CSCWSupport), en el cual seincluye la in-terfazcon la plataformade soporteal trabajocooperativo, implementadaen forma deInterfazdeProgramacióndeAplicaciones(ApplicationProgrammingInterface, enade-lanteAPI).

User Interface

Input and Output Editing Viewing

CSCW Support

MemoryConsistency

Local DataManagement

Figura2.4.:Estructuramodulardel editor.

Losmódulosdel editorsecomunicanentresí medianteinterfacescomunes.La implemen-taciónde la mayoríadeellosserealizasiguiendoel paradigmade la programaciónorientadaa objetos([Bud94]), medianteclases.El desarrollodel editorha sido realizadoíntegramenteen lenguajeC++ ([HO93], [Lip91]). Las operacionesde alto nivel de manejode los objetostridimensionaleshansido implementadasutilizandolas libreríasestándarOpenInventor, queexplicamosconmásdetalleenel Capítulo3.


3. Open Inventor y VRML 97

En el desarrollodecualquieraplicación3D conunamínimaenvergadura,esnecesarioutilizarfuncionesy estructurasde datosde alto nivel, queliberenal programadorde la complejidadquesuponedesarrollaralgoritmosdemanejodelasestructurasdedatos,devisualización,o degestióndel hardwaredevisualizacióndegráficos.

El conjuntodelibreríasOpenInventor([Wer94a],[Wer94b]),desarrolladopor la empresaSilicon Graphics1, presentaunainterfazdeprogramacióndeaplicacionesquepermiteal pro-gramadorconstruirunaaplicaciónutilizandopocasinstruccionesdebajonivel. OpenInventorestáconstruidoa suvezaprovechandolas libreríasOpenGL([SGI95]),desarrolladastambiénporSilicon Graphics,queconstituyenun estándardefacto.

OpenInventorconsiste,desdeel puntodevistadel programador, enun conjuntodeclasesenlenguajeC++quepermitendiseñareimplementaraplicacionesquesiganel paradigmadelaprogramaciónorientadaaobjetos.Lasrelacionesdeherenciaentrelasdistintasclasespermitendefinirunajerarquía,deformaqueel programadorpuedaescogerlasquemásseadaptenasusnecesidades.Además,OpenInventordefineun formatode ficheroquepermiteintercambiarla informacióngeneradapordistintasaplicacionesrápidamente,sin necesidaddeimplementaralgoritmosdeconversiónaotrosformatos.

A lo largo de todo estecapítulonoscentraremosespecialmenteen los aspectosde OpenInventorquehemosutilizadoen la aplicaciónquenosocupa. Realizarunaintroducciónquecubracadaaspectodeestaslibreríasocuparíamuchoespacioy estáfueradel alcancedeestamemoria. Por eso,cubriremosen ella únicamentelos aspectosmásbásicosy los aspectosavanzadosquesonutilizadosenla aplicación.

En primer lugar presentaremosla estructurade datosfundamentalutilizadapor estasli-brerías,el grafo de escena,y la manerade manipularlo. A continuación,describiremoslasoperacionesmásimportantesenunaescenatridimensional,entérminosderecorridossobreelgrafoy demodificacionessobreéste.A continuación,introduciremosalgunosdelosnodosdelgrafomásimportantesy suspropiedades.Finalmente,veremosdequémanerasevisualizalaescenaasociadaa un grafo de escenay cómoserelacionacon el sistemaoperativo quele dasoporte.

El formatoVRML 97,propuestoporel mismoequipoquediseñóOpenInventor, esel for-matobásicoadoptadoparael proyectoM3D. En la secciónfinal deestecapítulodescribiremosbrevementesufilosofía y funcionamiento,asícomolassemejanzasy diferenciasquepresen-

1Hacealgunosaños,Silicon GraphicsvendióunalicenciadedesarrollosobreOpenInventora la empresaTem-plateGraphicsSoftware(TGS),quehadesarrolladolasúltimasversionesdeestaslibreríasparamúltiplespla-taformas.Lasversionescon lasquesehatrabajadoenesteproyectohansido la 2.5.2deTGSparael sistemaoperativo WindowsNT, y la 2.1.2deSGI parael sistemaoperativo Irix.


Capítulo3. OpenInventory VRML 97

ta con el formatode ficherode OpenInventory el soportequeofreceOpenInventorparaelformatoVRML 97. Tambiéncomentaremoslosproblemasencontradosenestesoporte.

3.1. El graf o de escena

La estructuradedatosbásicaenOpenInventoresel grafo deescena. Todoslosdatosdela es-cenatridimensional,yaseandatosgeométricos,matricesdetransformación,informaciónsobreel materialdecadaobjeto,o datosdeiluminación,estánorganizadosdeformajerárquica.Estaorganizaciónjerárquicaadquiereforma de grafo dirigido acíclico o DirectedAcyclic Graph,DAG ([Aho88]), de formaquecadanododel grafocontieneunapartedela informacióndelaescena.

Paraoperarconun grafo dirigido acíclicosepuedenadoptardospuntosde vista: unodeellosconsisteentratarlocomoun grafoconciertasrestricciones,mientrasqueel otro consisteen tratarlo como un árbol con algunasextensiones.Las libreríasOpenInventor adoptanelsegundopuntodevista,deformaqueel grafodeescenapuedesermanejadodeacuerdoconlasiguientedefinición:

Un grafodeescenaesun árbol cuyosnodospuedentenercero o másdescendien-tes,y unoo másascendientes.En ningúncasoun nodopuedeserascendientedeun ascendientesuyo.Esdecir, no sepuedencrearciclosdeprecedencia.

Paralocalizarla posicióndeunnodoenungrafodeescenaesnecesariodefinirquéascendien-testiene,esdecir, quénodoesel padre,dequénodoeshijo el padre,etc.,hastallegara la raízdelárbol.OpenInventordefineel conceptoderuta (Path) paraindicarla posicióndeestenodocomounacadenadeíndicesquecomienzaenla raízdel árboly acabaenel nodoespecificado.

Asiento Respaldo Izquierda Derecha

Pata

Figura3.1.:Esquemadeun grafodeescenadeOpenInventorquereutilizaun nodo.

Parailustrar la utilidad del conceptoderuta,emplearemosun casopráctico.Supongamosqueestamosmodelandodeformasimplificadael bancodeunparque,compuestodeunasiento,



Figura3.2.:Visualizacióndeun ficheroOpenInventorquereutilizanodosgeométricos.

unrespaldoy dospatas.Existelaposibilidaddequedefinamosunasolavezunadelaspatasy laañadamoscomohija dosvecesadistintosnodosdeagrupación.Cuandoel grafosearecorrido,la acciónderedibujadopasarádosvecesporla mismapatay la dibujarádosveces.Un esquemadeestegrafodeescenasepuedeverenla Figura3.1;el resultadodela visualizaciónsemuestraenla Figura3.2.

Al seleccionarunadelasdospatas,la diferenciaentreunay otraestaráenla rutapor la quehayasidoseleccionada,ya quesetratadel mismonodo.Así, accederemosa la pataizquierdao a la pataderechaa travésde susrutascorrespondientes.Cuandoel usuarioseleccioneunobjeto,la rutaadecuadaserádevueltapor la aplicación.En la Figura3.1podemosverresaltadala rutaa la pataderecha,cuyosíndicesformaránla cadena3-1 (la numeraciónde los índicesdel grafocomienzaenel 0). La rutaa la pataizquierdaestaríaformadapor los índices2-1.

3.2. Operaciones sobre el graf o de escena

Comotodaestructuradedatos,el grafodeescenapuedeserconsultadoy manipulado.En estaseccióndescribiremoslasoperacionesdeconsultaquepuedenserrealizadassobreun grafodeescenadeOpenInventor, asícomoloscambiosqueéstasrealizansobreel estadoglobaldeunaescena.Posteriormenteveremosla manerade modificar la estructurade un grafo de escena.Finalmente,describiremosla formadeeliminarnodosdel grafo.



3.2.1. Acciones

Pararealizaroperacionesqueconsultenel grafodeescena,esnecesarioefectuarun recorridoenpreordensobreél o sobreun subconjunto.Unaoperaciónsobreel grafodeescenarecibeelnombredeacciónenOpenInventor. Unaacciónpuedeconsistirenvisualizarla escena,buscarun nodo,o calcularla boundingboxasociadaa la geometría,entreotras.

Una acciónpuedeseraplicadaa un nodoo a unaruta. El protocolode utilización de lasaccionesnormalmentesecomponedetresfases:

8 Inicialización de la acción. Asignaciónde los valoresa los parámetrosasociadosa laacción.Paracadatipo deacciónexistendistintosmétodosespecíficosdeinicialización.

8 Aplicacióndela acción. La aplicacióndeunaaccióna un nodoo a unarutatienelugarmediantela invocacióndel métodoapply().

8 Recogidade los resultadosde la acción. Normalmente,todaslas accionesretornancomoresultadounarutao unalistaderutas.Paraobtenerlosresultadossepuedeinvocara los métodosgetPath()o getPaths(). En casoderetornarotrostipos,sepuedeninvocarmétodosespecíficosparacadatipo deacción.

Las accionesconstituyenla forma estándarde extraer datosde la escena.Cadanodo tieneasociadoun comportamientopropioparacadatipo de acción.Los tiposdeaccionesmásim-portantesenOpenInventorsonlassiguientes:

8 Acción de visualización(render). Recorreel grafoasociadoy dibuja la geometríaquecontiene,junto consuspropiedades,enun dispositivo desalida. Estaacciónesbásica,yaquesin ellano esposiblevisualizarla geometríadela escena.

8 Accióndebúsqueda(search). Buscaunnodoo conjuntodenodosenel grafodeacuerdoconalgúncriterio,comoel tipo o el nombre.Segúnel tipo debúsqueda,puederetornarel primernodo,el último, o bientodoslos quecumplanconel criterio debúsqueda.Lasaccionesdebúsquedasirventambiénparaobtenerla rutaasociadaaunnododetermina-do.

8 Accióndecálculodela boundingbox2. Retornala boundingboxasociadaal nodoo rutaal cualseaplicala acción.Estaacciónesútil paradiversasaplicaciones,comoel cálculodecolisionesentreobjetos,o pararesaltarunobjetoseleccionadodibujandosuboundingbox.

8 Acción deescritura(write). Realizala escrituraenun ficherodel grafodeescenaal queseaplicala acción.Esteesel métodoestándarparaimplementarel almacenamientoendiscodeunaescena.

2Unaboundingboxesel menorprismacuadrangularrectoqueincluyecompletamenteel volumendela geometríaasociada.



3.2.2. Estado global de una escena

OpenInventormantieneun conjuntodevariablesglobalesdeestado; estasvariablesdeestadoafectana la visualizacióndecadaunodelosnodosquesonrecorridoporunaacciónderende-ring. El estadoglobalenunmomentodadoincluyela matrizdetransformacióngeométrica,elmaterial,el modelodeiluminacióny otrascaracterísticasdela escena.Segúnel tipo denodo,el estadoglobalpuedesermodificadoo no enel momentoenqueunaaccióndevisualizaciónlo recorre.

LasvariablesglobalesdeestadodeOpenInventortienenrelacióndirectaconlasvariablesglobalesquemantieneOpenGL([SGI95]). La diferenciaradicaenqueconOpenInventorelprogramadorno necesitaasignarvaloresa las variablesde estadoexplícitamente.Estaope-raciónesrealizadade forma implícita por la acciónde visualizaciónal recorrerel grafo. Eltrabajodel programador, pues,consisteen organizarel árbol de forma apropiada,de maneraqueel resultadodela visualizaciónseacorrecto.

3.2.3. Modificaciones del graf o de escena

ParaeditarunaescenatridimensionalenOpenInventor, esnecesariorealizarmodificacionesenel grafodeescenaasociado.Porejemplo,paracambiarla posiciónu orientacióndeun objetoesnecesariomodificarel nodoquerepresentasumatrizdetransformación.

Existendostiposdemodificacionesbásicasquesepuedenrealizarsobreungrafodeesce-na.El primertipoconsisteenmodificarunsolonododeformaaislada.El segundotipo consisteen modificarla forma en quelos nodosestánorganizados,esdecir, cambiarla topologíadelgrafo.Veremosa continuaciónenquéconsistecadauno.

9 Cadauno de los nodosde OpenInventor contieneunaseriede campos,a los queseasignaun valor. Es posibleobtenerel valor de estoscamposy modificarlo,mediantemétodosespecíficos.La formaestándarderealizarestasoperacionesesllamandoa losmétodosgetValue()y setValue(). Deestaforma,sepuedemodificarcualquiernododelaescenadeformaaislada,cambiandoel valordealgunodesuscampos.

9 Paramodificarla topologíadelgrafo,OpenInventordefineoperacionesestándardema-nejo de árboles,similaresa las descritasen [Aho88]. En un grafo de escenaexistennodosque funcionancomo ascendientes,o padresde otros, comoveremoscon deta-lle másadelante.Cualquiermodificaciónen la topologíadel grafoconsistiráenañadir,insertar, sustituiro eliminarhijos deunodeestosnodos.Paraello, OpenInventorpro-porcionadistintosmétodosestándar, talescomogetNumChildren, addChild, insertChild,replaceChildy removeChild, entreotros.

Unavezmodificadoel grafodeescena,unaaplicaciónOpenInventorpuededetectarel cambioy, si esnecesario,aplicarlasaccionesapropiadas,comoporejemplo,el redibujadodelaescena.De estaforma, el programadorno tieneque realizarexplícitamentellamadasde redibujado.Tambiénesposibleconfigurarla aplicaciónparaquesólo seredibuje cuandoel programalosolicitedeformaexplícita,aefectosdeeficiencia.



3.2.4. Borrado de nodos

OpenInventorgestionala memoriautilizadapor losnodosdeungrafodeescenadeformaqueesposibleinstanciarnuevosnodosexplícitamente3, peronoborrarlos.El borradodelosnodostienelugardeformaimplícitasiguiendoun sistemadereferencias.Explicamosacontinuaciónenquéconsisteestesistemadereferenciasy la formaenqueafectaal borradodelosnodos.

CadanododeOpenInventorcontieneunavariableenteraqueindicalasvecesquehasidoreferenciadoestenodo.El numerodereferencias(llamadoenOpenInventorreferencecount)se incrementacadavez que el nodo es añadidocomo hijo a un nodo de agrupación4, y sedecrementacadavezqueunodelosascendientesdirectosdel nodolo retira(pormediodeunallamadaal métodoremoveChild).

La eliminaciónde un nodode OpenInventorde la memoriatienelugarautomáticamenteenel momentoqueel númerodereferenciaspasade1 a0. Esdecir, enel momentoenqueunnodopasaano serhijo deningúnotro,la memoriaqueocupabaesliberada.

Estesistemadereferenciasdebesergestionadoconun cuidadoespecialenel casode losnodosraízdela escena.Comolosnodosraíznotienenascendientes,sunúmerodereferenciasesinicialmentecero.Porotro lado,cadavezqueunaacciónesaplicadaaun nodo,el compor-tamientoestándardeéstaconsisteenreferenciarel nodoal principio,ydecrementarel númerodereferenciasal final. Ello implicaqueunnodoraízpuedehacerquesunúmerodereferenciaspasede 1 a 0 al finalizar la acción,de formaqueel nodoseaborrado.Porello, esnecesariorealizarunaprimerareferenciaexplícita al nodoraíz,conunallamadaal métodoref().

3.3. Nodos principales en el graf o de escena

Un nodode OpenInventorencapsulaunapartede los elementostridimensionalesquerepre-sentael grafodeescena.Existendistintostiposdenodos,cadaunodeellos representadoporunaclaseC++, con propiedadesdistintasy reaccionesdiferentesanteunaacción. Veremosa continuaciónalgunosde los tipos de nodosmásimportantesquepodemosencontraren ungrafodeescenadeOpenInventor.

3.3.1. Nodos de agrupación

Enunaestructurajerárquica,comoel árboldeescena,algunosdelosnodosdebenactuarcomo“padres”deotros.Enel casodeOpenInventor, estosnodossonllamadosnodosdeagrupación,o grupos. Existenmuchasclasesdegruposy cadaunopresentauncomportamientoligeramentedistintoanteel recorridodeunaacción.Nosotrosnoscentraremosenlostrestiposmásusados:los gruposbásicos,losseparadoresy los nodosdeselección.

3Medianteel operadornew deC++.4Comohemoscomentadoanteriormente,unnodopuedetenermásdeunpadre,siemprequeel grafosemantenga

sin ciclos.



Grupos básicos

Los gruposbásicosagrupansimplementelos nodosquesonhijos suyos,sin realizarningunaotraoperación.Esdecir, si unaaccióndevisualizaciónllegaa un grupo,lo únicoquehaceesrecorrerdeizquierdaa derechatodoslos nodosqueseanhijos deesegrupo.

La funcióndeestetipo denodosdeagrupaciónconsisteúnicamenteenpropagarla accióna sushijos, sin modificarni guardarel estadoglobalde la escena.Suutilidad quedalimitadameramenteaestructurarla escenatridimensional.Comoveremosacontinuación,existenotrostiposdegruposmásútiles,queofrecenfuncionalidadesadicionales.

Separadores

Los separadoresañadenunafuncionalidadmása los gruposbásicos:la capacidadde man-tenerun estadolocal. El estadoglobal de OpenInventor, introducidoen la Sección3.2, esmodificadoporel separadoral serrecorridoporunaacción,dela siguienteforma:

: Guardarel estadoglobaldela escena.

: Hacerquela acciónrecorratodoslosnodoshijos del separador.

: Restaurarel estadopreviamenteguardado.

Es decir, las modificacionesen el estadoglobal que se hayanrealizadoen nodoshijos delseparadorno tendránningúnefectosobrenodosqueno seandescendientesdeéste,ya queelestadoglobalanterioresrestauradoenel momentoenquela acciónabandonael separador.

Paraguardarel estadoglobal, OpenInventorutiliza operacionesde alto nivel proporcio-nadaspor la libreríaOpenGL.Estalibreríamantieneunapila enla quesepuedealmacenarelestadoglobal endistintosmomentosde la ejecucióndel programa.De estamanera,median-te sucesivasllamadasa las operacionesglPushy glPop, esposiblemantenerun conjuntodeelementostridimensionales,cadaunoconun sistemadecoordenadaspropio([SGI95]).

A continuaciónmostraremosun ejemplode la utilidad deestetipo denodo.Supongamosquedebemosrepresentarun sistemaplanetario,condistintosplanetasquegiran alrededordeunaestrella,cadaunocon algunossatélites.Utilizando separadores,podemosrepresentarelmovimiento de la órbitade los satélitesalrededordecadaplanetadeforma local, sin preocu-parnosdel tipo de órbitaquedescribiráel planetaalrededorde la estrella. Inclusoesposiblemodificarel movimientodelsistemacompletoañadiendounatransformación,sinqueello im-pliquemodificarenabsolutoel movimientolocal decadaelementodel sistema.

Nodos de selección

Un nododeselecciónrealiza,ademásdetodaslasfuncionesdeunseparador, otrasquefacilitanla interacciónconel usuario.Estasfuncionessonlassiguientes:

: Cuandoel usuariocolocael punterodel ratónsobreuno de los objetosde la escenayhaceclic sobreél, la aplicaciónOpenInventorponeenmarchaunafunciónquecalculaquéobjetoha sido apuntado,a partir de las coordenadasdel ratón. Si el objetoesun



descendientede un nodo de selección,éstese encarga de gestionarestafunción, deformatransparenteal programador, y demantenerunalistadeobjetosseleccionados,deacuerdocon distintaspolíticasde selección.De estamanera,si el usuariorealizaunaoperaciónsobreel objetoseleccionado,el programasólotienequeconsultaral nododeseleccióncorrespondiente,parasaberquénodoestáseleccionado.

; Paraaccedera la lista deobjetosseleccionados,el programadorrealizallamadasa mé-todospropiosdel nododeselección.Estosmétodospermitenun ampliocontrolde losnodosseleccionados,asícomode la selecciónde nodosnuevos, o retirar nodosde lalista.

; Laspolíticasdeseleccióntienenquever con la interacciónconel usuarioquesedeseaofrecerconla aplicación.Segúnla políticaquedefinael programadorde la aplicación,el usuariopodrátenerseleccionadounoo variosobjetosa la vez,condistintasinterfacesposibles.

3.3.2. Nodos de geometría

Los nodosde geometríadescribenla informacióngeométricade la escena.Estainformaciónpuedevenirdadaenformadeprimitivas(OpenInventordefineconos,cubos,cilindrosy esfe-rascomoobjetosprimitivos), de representaciónmediantevértices, o de superficiesNURBS.Para más información sobreestostipos de representaciónde sólidos, se puedenconsultar[Fol92] y [Hea94].

En esteapartadonoscentraremosprincipalmenteen los nodosquedefinenunageometríamediantevértices,ya quesonlos quehemosutilizadomásextensamenteenla aplicación.LasprimitivasdefinidasporOpenInventorsondemasiadosimplesparaserutilizadas,mientrasquelas superficiesNURBS exigen un tiempode computaciónmuy elevado,y ademásno tienenutilidad parala mayoríadeproyectosarquitectónicos.

Todos los nodosde geometríaque implementanformasmediantevérticesen OpenIn-ventorestánimplementadoscomoclasesC++ derivadasde la claseSoVertexShape. Existendiversasclasesderivadasdeestaclasebásica,cadaunacondiferentesparticularidades.Dadoquecomentarcadaunadeellasporseparadoseríademasiadoextensoparael propósitodeesteapartado,detallaremosa continuaciónalgunasdelascaracterísticascomunesquecomparten.

La representacióndeformasgeométricastridimensionalesbasadasenvérticessigueel mo-delo llamadode fronteras (BoundaryREPresentation, o BREP).La informaciónalmacenadaenestemodeloseagrupaendospartes.Porun lado,seguardantodoslos vérticesdel sólido,enun vectorglobal. Porotro lado,sealmacenala descripcióndetodaslascarasdel sólido,enformadeotrovectordeíndicesordenadosal vectordevértices.

OpenInventorrepresentaestemodelodefronterasmediantenodosdel mismoárbol,comohacecon todaslasdemáscaracterísticasdeunaescena.Así, el conjuntodevérticestridimen-sionalesesrepresentadopor un nodode tipo SoCoordinate3, en formade vectorglobal. Lascaracterísticasdel sólido(sentidodeordenaciónde los vérticesenunacara,por ejemplo)sonrepresentadaspor un nododetipo SoShapeHints. Otro nodo,detipo SoNormalindicael con-juntodevectoresnormalesacadacara.Finalmente,otronodo(SoFaceSeto SoIndexedFaceSet)



contendráel vectordeíndicesordenadosrespectoal vectorglobaldepuntos.

3.3.3. Nodos de propiedad

Los nodosdepropiedadmodificanel estadoglobaldela escenadeunaformaparticular. Losdostiposdenodosdepropiedadmásimportantessonlos nodosdematerialy las transforma-cionesgeométricas.

Los nodosdematerial, comotodoslos nodosdepropiedadexceptolas transformaciones,sustituyenlos parámetrosde visualizaciónglobalespor los propios. Estosparámetrosde vi-sualizaciónpuedenserel color ambiental,el color difuso,el color especular, la transparencia,y otros.

Las transformacionesgeométricasrepresentanunaoperacióngeométricarealizadasobreel restodela escenaquequedaporserrecorridaporunaacción.Cuandounaacciónrecorreunnododetransformación,la transformacióngeométricarepresentadaporestenodoseconcatenaconla transformacióngeométricaglobaldela escena.Esteesel únicotipo denododepropie-dadquenosustituyecompletamenteel estadoglobaldela escena.Haymuchostiposdenodosde transformación,cadauno con distintaspropiedades,quesirven paradefinir traslaciones,rotaciones,escalados,etc.

Losnodosdepropiedadmodificanel estadoglobaldelárboldeescena,por lo quedeberánsercolocadosdemaneraquelos nodosa los queafectenquedensiemprea la derechay/o pordebajo.De estemodo,cuandounaaccióncualquierarecorrael árboldeescena,encontraráenprimerlugarel nododepropiedad,y a continuaciónel restodenodosa los queestapropiedadseaplica.

3.4. Visualización de una escena

Paravisualizarunaescenatridimensionalo partede ella, OpenInventorutiliza los llamadosvisores(viewers), queseasocianaungrafoo subgrafodeescena.Un visorasociadoaungrafodeescenaejecutaunaaccióndevisualizacióncadavezquepartedelgrafoesmodificada.Cadavisor contieneun áreade visualización(RenderArea) asociada,sobrela cual sedibuja unaproyecciónbidimensionaldela geometríaavisualizar.

La actualizacióndel áreade visualizaciónde la escenaen el visor tiene lugar de formaautomáticacadavezquepartede la geometríaquesevisualizaesmodificada,o biencuandotiene lugar un cambioen un nodo de selecciónasociado. La forma de actualizaciónde laimagenpuedeserconfiguradaa travésdela aplicación.

OpenInventordefinedistintostiposdevisores,queofrecendistintoscomportamientosdenavegaciónal usuario. Así, podemosencontrarun visor de examen(ExaminerViewer) quepermitegirar alrededorde la escena.Un visor depaseo(Walk Viewer) haráquela cámarasedesplacepor la escenacomosi caminarasobreella. Un visor devuelo (Fly Viewer) ofreceráunavistadepájarodela escena,y permitiráal usuariomoverseenun soloplanosobreella.

La implementacióndeun visor dependedel sistemaoperativo quedésoportea la versióndeOpenInventorqueseestéutilizando.Si la aplicaciónestáprogramadasobreentornoUnix,el visor estarárelacionadocon un Widget del sistemaX-Windows. En casode aplicaciones



Figura3.3.:Ejemplodevisor deOpenInventor.

programadasconla API deMicrosoftWindows,el visorserelacionaráconunaclasedeventa-na.Finalmente,si seprogramaconlasMicrosoftFoundationClasses,el visorserelacionaconunavistadela aplicación.

Enla Figura3.3sepuedeverunvisordeexamenconlosbotonesy controlesasociados.Laimplementacióndeestevisoresla deWindowsNT, realizadaporTemplateGraphicsSoftware.

3.5. Relación entre Open Inventor y VRML 97

Merecela penadedicarunasecciónacomentarlassemejanzasy diferenciasentreOpenInven-tor y VRML 97, ya queVRML esel formatocon el quetrabajala aplicación. Por un lado,VRML 97 no espropiamenteOpenInventor, conlo queno esposibletrabajardeformatrans-parenteconlos dosformatos.Porotro lado,existenmuchasrelacionesy semejanzasentrelosdosformatos,lo quehaceposiblequesepuedandefinir interaccionesentreellos.

Enestaseccióndescribiremosbrevementeenquéconsisteel formatoVRML 97. Detallare-moslasdiferenciasqueel formatoVRML 97presentaconel formatopropiodeOpenInventor.Finalmente,explicaremoslasfuncionalidadesquelasúltimasversionesdeOpenInventorim-plementanparapermitir y facilitar la gestióndel formatoVRML 97.



3.5.1. El formato VRML 97

El estándarISO/IEC14772,conocidocomoVRML 97 ([Car97],[Har96]), defineun formatode fichero textual parala representaciónde escenastridimensionalesinteractivas, junto concontenidomultimedia. Su especificaciónse deriva de unapropuestade Silicon Graphicsypresentaunafilosofía básicasimilar al formatode ficherode OpenInventor, comoveremosmásadelante.

Entre los elementosmásimportantesque componenVRML 97, se puedendestacarlossiguientes:

< Representaciónde mundostridimensionalesestáticosy dinámicos. Al igual queconOpenInventor, esposiblerepresentarescenastridimensionalesqueinteraccionenconelusuario.

< Posibilidaddeincluir distintostiposdeelementosmultimedia,talescomotexto, imáge-nes,audiodigitalizado,sonidosintéticoo secuenciasdevídeo.Estohacequeel formatoVRML 97 seacapazdemodelarentornosmultimediacomplejos.

< Hipervínculosentredistintoselementosde una mismaescenay entre distintasesce-nastridimensionales.Esteaspectopermiteel diseñoestructuradodemúltiplesmundosVRML, entrelos queel usuariopuedenavegar.

< Posibilidadde extenderlas funcionalidadesde unaescenamedianteinterfacescon len-guajesde scripting comúnmenteutilizados, talescomo JavaScripto VBScript. Estaextensiónpermitequesepuedanprogramarfuncionalidadescomplejasen unaescenaVRML, sinnecesidaddedependerdel navegadorparasuimplementación.

El formatoVRML 97 modelala escenatridimensionalcomoun grafodirigido acíclico,igualqueOpenInventor. Los nodospresentancomportamientosmuy similaresa los quehansidoestudiadosenla Sección3.3.

3.5.2. Diferencias entre Open Inventor y VRML 97

En primer lugar, resaltemosunadiferenciabásica:bajo el título OpenInventorseenglobanvariosconceptos.Estosconceptosincluyen:

< Un conjuntodelibreríasgráficasdemanejodeescenastridimensionales.

< Unainterfazdeprogramacióndeaplicaciones(API).

< Un formatodeficheroquepermiteintercambiarescenastridimensionales.

En cambio,VRML 97 essólounformatodefichero, lo queimplica quela formademanejarloquedaal arbitriodel programador. Deestamanera,no esinverosímilqueunaaplicaciónOpenInventorpuedamanejarficherosVRML 97,yaquesonsimplementeunformatográficomás.

Bajoestaperspectiva,y teniendoencuentaquela comparaciónquetendrálugarseráentreformatosdefichero únicamente,pasamosadestacarlasdiferenciasmásnotablesentreambos.



En el apartadoanteriorhemosconstatadoqueexistensemejanzasmuy clarasentreel for-mato definidopor OpenInventor y el quedefineVRML 97. Las diferenciasse encuentransobretodo en las nuevasfuncionalidadesqueintroduceVRML 97, y sobretodo,en la orga-nizacióny recorridodel grafo de escena.A continuación,explicaremosen quéconsisteestaúltima diferenciafundamental.

Organización del graf o de escena y estado global

La diferenciamásimportantede VRML 97 con el formato de fichero de OpenInventor seencuentraenla supresióndela propagacióndeatributos. Estosignificaqueun nodonopuedemodificarel estadoglobalqueafecteaotrosnodossituadosa la derechay arribaenel grafodeescena.A nivel prácticoestosemanifiestaendosaspectosmuy concretos:La especificaciónde atributosen el interior de los nodosde geometría,y el comportamientode los nodosdeagrupación.

A diferenciadela especificacióndelosatributosenOpenInventor, quetienelugarmedian-tenodosindependientescolocadosa la izquierdao arriba,VRML 97especificalosatributosenformadecampos. Cadanodogeométrico(implementadoenOpenInventorcomounaclasedeltipo SoVRMLShape) contieneuncampo,implementadoenformadenodo,detipo SoVRMLAp-pearance. Estenodocontienelosposiblesatributosdelnodogeométrico,atributosquepuedenserel material(SoVRMLMaterial), el color (SoVRMLColor), etc.

OpenInventordefinenodosde agrupaciónquepresentancomportamientosmuy distintosrespectoa la propagacióndel estadoglobalde la escena(explicadoenel Apartado3.2.2).Encambio,los nodosdeagrupacióndefinidosenVRML 97 no permitenqueel los atributosqueforman partedel estadoglobal afectena nodosquese encuentrenfuera de ellos. Es decir,su comportamientoestándares como mínimo similar al que tiene el nodo SoSeparator deOpenInventor. No existeenVRML 97 ningúnnodoconla funcionalidadequivalenteal nodoSoGroupdeOpenInventor, queúnicamenterecorrelos hijos sin impedirqueel estadoglobalsemodifiquey propague.

Otradiferenciamuy importanteentrelosnodosdeagrupacióndeVRML 97y losdeOpenInventorradicaenla formaenquesetratanlosdescendientes.De hecho,los descendientesdeun nodoseencuentrancontenidosenéste,comosi deun campomássetratara.

Para modelar las transformacionesque tienen lugar sobreuna determinadageometría,VRML 97 defineun nodollamadoSoVRMLTransform, quecombinalas funcionalidadesdelSoSeparator y del SoTransformde OpenInventor. Esto significa que las transformacionesgeométricasdefinidasen estenodoafectaránsólo a los nodosgeométricosqueseanhijos deéste.

La decisióndeno incluir la propagacióndeatributosenel formatoVRML 97respondealaposibilidaddemantenerel formatodeficheromássencilloy fácil deoptimizar. Porejemplo,los nodosSoVRMLTransformpermitenlocalizardeformainmediatacuálesla transformaciónque afectaa un nodo determinado,ya quesiemprees el nodo padre. Como contrapartida,debidoa estacaracterísticade diseño,los ficherosVRML 97 tienentendenciaa estarmásprofundamenteanidadosquelos ficherosOpenInventor, lo quepuedeimplicar másconsumodememoriaenun recorridorecursivo.



3.5.3. Sopor te para VRML 97 en Open Inventor

La empresaTemplateGraphicsSoftware(TGS),quedesdehaceunosañosesla quedesarro-lla nuevasversionesde OpenInventor, ha implementadosoporteparael formatode ficheroVRML 97 ([Hec97]).A continuaciónexplicaremosbrevementeenquéconsisteestesoporte.

Inclusión de nodos VRML

OpenInventorincluye desdesuversión2.45 soporteparanodosVRML 97. Cadaunode losnodosVRML 97 estáimplementadoenformadeclaseC++, comosi deun nodocorrientesetratara.A nivel denomenclatura,esfácil distinguirsi un nodoesVRML o esOpenInventor,ya quelos nombresdelasclasesqueimplementanlos nodosVRML comienzanpor el prefijoSoVRML. Tambiénhasido implementadoun sistemade herenciade nodosVRML, deformaqueseaposibleabstraerpropiedadescomunesentrelos nodosInventor y VRML, así comopropiedadescomunesa losnodosVRML.

La inclusiónenOpenInventordeunagranmayoríade nodosVRML 97 facilita enorme-mentela tareaal programador, queno debepreocuparsedetratarestosnuevosnodoscomounformatoaparte.De hecho,podemosdecirqueel formatoactualdeOpenInventorcomprendetanto los nodosestándarde OpenInventorcomolos nodosVRML. Sepuedever tambiénalformatodeOpenInventorcomoun “superconjunto”deVRML 97.

Funciones de conveniencia para nodos de agrupación

La nocióndedescendientesy ascendientesdeun nodocambialigeramenteenVRML 97 res-pectoa OpenInventor, ya quelos hijos deun nodoestáncontenidosen camposde éste.Sinembargo, las libreríasOpenInventormantienenlas mismasfuncionesde accesoy modifica-cióndeloshijosdeunnodo,talescomoaddChild, removeChild, getNumChildren, etc.Deestamanera,el manejode los nodoshijos de un nodode agrupaciónsehacemástransparentealprogramador.

Acceso a la ruta de un nodo VRML 97

Unarutapermiteaccederala instanciaconcretadeunnodo,comoseexplicaenla Sección3.1.Estaestructuraesmuy importante,ya quepermitediferenciarentredistintasinstanciasen elcasodenodosreferenciadosmásdeunavez,y ademáspermiteaccedera los ascendientesdeun nodo.

Hemoscomentadoanteriormente,no obstante,que los nodosVRML no tienen“hijos”en el mismosentidoquelos puedentenerlos nodosde OpenInventor. Un hijo de un nodode agrupaciónesun campode éste. Por estemotivo, la aplicaciónde unaaccióncualquieraque debadevolver un nodo VRML 97 devolveráuna ruta que llegaráúnicamentehastalaprofundidaddel primer nodoVRML 97 encontrado,sin continuarcon susdescendientes,yaquelos consideracamposdeun nodo.

5La versiónactualdeOpenInventoresla 2.6.



Porestemotivo, esnecesarioutilizar un nuevo mecanismodeOpenInventor, llamadorutacompleta(SoFullPath). Unarutacompletaseobtienea partir deunarutaestándarrealizandounaconversióndetipos(casting). Estanuevarutacontendrála cadenacompletahastael nodoVRML 97 solicitado.

El mecanismoderutacompletaesutilizadotambiénenotrocontexto, los llamadosconjun-tosdenodoso NodeKits([Wer94a]),quenosonutilizadosenesteeditor, y quepor tantonoseexplicanenestamemoria.

Entrada y salida por ficher o

Uno de los factoresdecisivosquehay quecontemplarnecesariamenteen el soportequeunaaplicaciónofrezcaal formatoVRML 97, es la implementaciónde la entraday salidapor fi-chero. Es decir, la capacidadde leer y de exportar un ficherocon formatoVRML 97. Enesteapartadoexplicamosel soportequeOpenInventorofreceparaleery escribirficherosquecontengannodosVRML 97.

Graciasal soportedelasúltimasversionesdeOpenInventor, losnodosVRML 97sonacep-tadosenel formatoOpenInventorcomosi de nodosestándarsetratara.Por tanto,la lecturade un fichero“mezclado”quecontenganodosVRML 97 y OpenInventorno presentarámáscomplicaciónquela deunoquecontengaúnicamentenodosdeOpenInventor. Encasodeleerun ficheroVRML 97 “puro”, la última versióndeOpenInventorproporcionaunafunciónquepermiteleerdeficherotodoun árbolVRML y queretornaun nododeagrupaciónVRML 97(a diferenciade la función estándar, que retornaun nodoseparadorde OpenInventor). Lacapacidadde leer directamenteun ficheroquecontenganodosVRML 97 evita la necesidaddeconstruirun analizadorléxico-sintácticoquerealicela conversiónentrenodosVRML 97 ynodosdeOpenInventor.

En el casodela escritura,encontramosdostiposdealmacenamientoposibles:

= En formato OpenInventor, prácticamenteequivalentea la representacióninternadelgrafodeescena,connodosmezcladosOpenInventory VRML 97.

= En formatoVRML 97, deformaquesepuedanexportarlos datosa otrasaplicaciones,conlo cualel ficheroresultanteno debecontenermásquenodosVRML 97 válidos.

Encasodequeel usuariodeseeguardarsutrabajoenformatoVRML 97,seránecesariorealizaruna conversión, de forma que los nodosOpenInventor seansustituidospor su equivalenteVRML 97. OpenInventorimplementaunaacción(comolasexplicadasenel Apartado3.2.1)llamadaSoToVRMLAction. Estaacciónpermiteconvertir un árbol de escenaque contengaúnicamente6 nodosOpenInventoraotro equivalenteconteniendosólonodosVRML 97.

Carencias y errores en el sopor te de Open Inventor para VRML 97

El hechode queOpenInventorofrezcasoporteparaun formatode ficherocomoVRML 97no significaqueestesoporteseaperfecto. Existendiversascarencias,y diversosfallos que

6De hecho,hemospodidocomprobarquela aplicacióndeestaaccióna un subárbolquecontenganodosVRML97 dalugara uncomportamientoindeterminadodela aplicación,y a unasalidaerrónea.



complicanel trabajodel programador, y quedebenser tenidosen cuentaen el momentodeimplementarnuevasfuncionalidadesqueafectena nodosVRML 97. Pasamosa enumeraracontinuaciónalgunasdelaslagunasmásimportantesquehemosencontrado.

Existeunaseriede nodosVRML 97 queno hansido implementadosen OpenInventor.En el momentode recibir un fichero que contengaalgunosde estosnodos,OpenInventorlos leerácomo“nodosdesconocidos”y no serácapazde procesarlosautomáticamente.Estosignificaqueel programadordebeextenderel soportepor sucuentasi quierequeésteincluyacompletamenteel formatoVRML 97.

Comohemoscomentadomásarriba,laaplicacióndeunaacciónqueretornenodosVRML 97dacomoresultadounarutaincompleta.Encasoqueestarutaseavisibledesdela aplicación,esposiblerealizarunaconversióndetipos.Sinembargo,OpenInventoraplicaaccionesdeformainterna,comoesel casodel redibujado(rendering). En el transcursode la aplicacióndeunadeestasacciones,éstaspuedenretornarcadenasdeíndicesincompletas,lo cualprovocaquelaaplicaciónfuncioneincorrectamente.

AunqueOpenInventorproporcionaunaacciónquepermiteconvertir un árbol de escenapropio al formatoVRML 97, si el árbol contienealgúnnodoVRML 97, el funcionamientode estaacciónesindeterminadoy erróneo.En la versión2.5.0, la aplicaciónde estaaccióndabacomoresultadoungrafoVRML 97queconteníamultituddenodosSoSeparator deOpenInventorvacíos.Estoprovocabaqueel ficheroresultanteno pudieraserreconocidopor nave-gadoresdeVRML. Con la nueva versión2.5.2,al aplicarestaaccióna un nodoVRML 97,elresultadoesunnododeagrupacióndeVRML 97 vacío.


4. Sopor te al trabajo cooperativ o

El editorhasidoconcebidocomounaherramientadel tipo CSCW(Computer-SupportedCoo-perative Work, trabajocooperativo asistidopor ordenador[VV.94]), al igual queel SistemaM3D. Portanto,presentaunaseriedecaracterísticascomunesa todoslossistemasCSCW, quecomentamosacontinuación.

La característicaprincipal de los sistemasCSCWesla interacciónentrevariosusuarios,de forma queseaposiblerealizarunaactividad en grupo. Estetrabajoen grupo esposiblegraciasal usode diversasherramientascomplementarias,quefacilitan la comunicaciónentrelos usuarios.Entreestasherramientasde soporte,podemoscitar la comunicacióntextual (elcomandotalk delossistemasUnix, porejemplo),la audioconferenciay la videoconferencia.

Porotro lado,cualquierherramientadeproducciónquesepretendaintegrarenun entornoCSCWdebepresentarlassiguientescaracterísticas:

> Usuariosfísicamentedispersosdebentrabajarenun entornocompartido.

> La informacióncontenidaeneseentornocompartidodebeserprotegidapormecanismosdecontroldeacceso.

> La coordinacióndeactividadesdebeserfacilitadaporel usodecanalesdecomunicaciónapropiados.

En estecapítuloexplicamosla estructurade soporteal trabajocooperativo queha sido im-plementadaen el editor, así como las decisionesde diseñoquese han tomado. En primerlugar, describiremosla plataformabásicadegestiónCSCW, llamadaJESP(Joint Editing Ser-vicePlatform [Alm95]). A continuación,hablaremosde la estructuraabstractadereplicaciónen memoria,llamadabasede datospersistente.Finalmente,introduciremosel protocolodeaplicaciónMu3D, utilizadoparael envío demensajesentrelasréplicasdelos datos.

4.1. La plataf orma JESP

El diseñode un sistemacolaborativo puedeestarbasadoen dos enfoquesprincipales. Unode ellos consisteen desarrollarun sistemacompletamentededicadoal soportede unao másaplicacionesconcretas,de forma quesecreeun entornocolaborativo con característicases-pecíficas.El otro enfoqueapuntaa la creaciónde unaplataformaqueproporcioneserviciosde soportegenéricoparaaplicacionesdistribuidas. Esteúltimo enfoqueproporcionamayorflexibilidad, ya quelos miembrosde unasesióncooperativa puedenelegir quéherramientasutilizar, sinnecesidaddemodificarla plataformadesoporte.Porotraparte,la implementación


Capítulo4. Soporteal trabajocooperativo

delasaplicacionessepuedemantenerseparadadela plataforma,deformaqueel desarrollodefuncionesadicionalessobreéstasemantienecompletamentetransparentea las aplicaciones.De estemodo,la arquitecturapermaneceabiertaa desarrollosfuturos.

La plataformaJESP, diseñadasegún esteúltimo enfoque,proporcionaa las aplicaciones(y enconcretoanuestroeditor)el soportenecesarioparahacerposiblelasoperacionescoope-rativas. Estaplataformaha sidodiseñadaparaproporcionardostiposdiferentesde servicios:controldesesióny comunicacióndegrupo. Estosserviciosestándisponiblesparalasaplica-cionesatravésdeunaAPI común.Losmecanismosdecontroldesesiónliberanala aplicacióndel costede implementarlasfuncionesnecesariasparala inclusiónenentornoscooperativos.Los serviciosdecomunicaciónocultana lasaplicacionesla configuraciónpunto-a-multipuntodebajonivel.

En estasecciónexplicaremosla estructurade la plataformaJESP, asícomolos módulosdedicadosa implementarel controldesesióny la comunicación,y la API implementadaparainteractuarconel editor.

4.1.1. Estructura general

Los mecanismosdecontroldesesióny decomunicaciónestánorganizadosenunaestructuraporcapas,comosemuestraenlaFigura4.1.La implementacióndeestosgruposdeoperacionesseha realizadomedianteel desarrollode dosmódulosindependientes,queseejecutancomoprocesosseparadosencadaunadelasmáquinasqueparticipanenla sesióncooperativa.

Network

Operating System

SMI UI

M3D Application

UI SMI

M3D Application

SAP

SAP SAP

Session Manager (SM)

Group Communication (GC)

Figura4.1.:Estructuramodulardela plataformaJESP, y surelaciónconlasaplicaciones.



Comosepuedever enla figura,los dosmódulosencargadosdelasoperacionesnecesariasparael trabajocooperativo recibenel nombredeSessionManager(SM), paralasoperacionesde control de la sesión,y Group Communication(GC), para las operacionesrelativas a lacomunicaciónpunto-multipunto.

Cadaaplicacióndistribuida puedeutilizar un protocolode aplicaciónespecíficoparaelintercambiode mensajes(enel casodel editor, el protocoloMu3D). Estosmensajessonen-capsuladospor la aplicacióny enviadosal restode sitios medianteunapeticiónde serviciorealizadaal móduloSM. El módulode la aplicaciónqueestructurala comunicaciónentrelacapadeaplicacióny la capaSM recibeel nombregenéricodeSMI (SessionManagerInterfa-ce).

Los módulosde la plataformainteractúancon el sistemaoperativo mediantellamadasalos serviciosqueproporcionala pila deprotocolosTCP-IP, presenteenla prácticatotalidaddesistemasoperativosmodernos.

4.1.2. Modo de ejecución

La plataformaJESPdistingueentredostiposdeusuarios,segúnel rol queocupenenla sesióncooperativa. Estosdostiposdeusuariosrecibenel nombredeservidorese iniciador. Explica-mosacontinuaciónenquéconsisteestadiferenciación:

? El iniciadorseencargadeenviar la ordendeinicio a lasdemásréplicasdela plataforma.

? Losservidoresseejecutany quedana la esperadela ordendeinicio porpartedel inicia-dor. Unavezestaordenhasidorecibidapor todoslos servidores,la sesióncooperativaquedaconstituida.

De acuerdoconla estructuradecapasdela plataformaJESP, el móduloGC esnecesarioparala ejecucióndel móduloSM. Porello, suejecucióndebeiniciarseprimero.

Cadausuarioenla plataformaJESPseidentificamedianteun nombredeusuario(userna-me) y unaestacióndetrabajo(host). Éstosdebenestarregistradospreviamenteenun listadode miembros.Estelistadode miembrosestácontenidoenun ficherodetexto llamadoJESP-Members. Cadalíneadel ficheroJESPMemberscontiene,entreotros,los siguientescampos:

? El nombrededominiodela estacióndetrabajo.

? El nombredel usuariocorrespondiente.

? Un númerosecuencialúnico,queidentificael par formadopor el nombredel usuarioyel nombredela estacióndetrabajo.

Cuandoun usuarioinicia la plataformaJESP, seidentificaconel nombrequetengaasignado.El programacompruebaentoncesqueel parformadoporel nombredeusuarioy la estacióndetrabajoconla queseconectaseencuentrenenel ficheroJESPMembers.



4.1.3. Interfaz Editor - JESP

La comunicaciónentreel editor y la plataformaJESPha sido implementadamedianteunainterfazde programaciónde aplicaciones(API). En esteapartadodescribimoslas funcionesprincipalesdeestaAPI, y sufuncionamiento.

Las funcionesde interfazentrela aplicacióny la plataformaJESPsepuedenagruparentres tipos de operaciones:inicializaciónde la plataforma,envío y recepciónde mensajes,ygestióndelosusuariosdelgrupodetrabajocooperativo. Listamosacontinuaciónlasfuncionesutilizadasencadatipo:

@ Funcionesdeinicializacióndela plataforma.

– JSPInitPlatform. Realizala configuraciónde la plataformaJESP, e inicializa lasestructurasdedatosnecesarias.

@ Funcionesdeinterfazdela aplicaciónconel móduloSM:

– JSPSendMsg. Funcióndeenvío demensajesestándar.

– JSPSendSimpleMsg. Funcióndeenvío demensajescortos,sinparámetros.

– JSPQueryTeleEvent. Funcióndelecturadelos eventosremotosrecibidos.

@ Funcionesdegestióndeusuariosenel grupodetrabajocooperativo:

– JSPGetGroupMemb. Funciónde consultade la lista internade miembrosde lasesión.

– JSPAddGroupMemb. Funcióndeactualizaciónde la lista internademiembrosdela sesión.

– JSPFindMembID. Funcióndeconsultadel identificadordeusuarioenla lista inter-nademiembrosdela sesión.

El editor, al igualquela plataformaJESP, precisaqueseindiqueel rol delusuarioal inicio delaejecución.Esdecir, losusuariosdeberánindicarsi sonservidoreso el iniciador. Lasinstanciasdel editor queactúencomoservidoresquedarána la esperade queel iniciador indiquequepuedencomenzar.

4.2. La base de datos persistente en memoria

Unade lasdecisionesmásimportantesenel diseñodeun sistemaCSCWesla elecciónentreunaarquitecturacentralizaday unaarquitecturareplicada.Explicamosa continuaciónenquéconsistecadauna, susventajase inconvenientes,y la decisióntomadaen el desarrollodeleditor.

Unaarquitecturacentralizadaconsisteenmantenerunaúnicacopiadela aplicaciónejecu-tándoseenunservidor, deformaquetodosloseventosproducidosporlosclientessonenviados



al servidor, y la salidadeésteesdistribuidaa todoslos clientes.El estadode la aplicaciónsepuedemantenerfácilmenteconsistente,ya que todaslas modificacionesproducidaspor losusuariossonserializadas.Loscambiosenel estadoafectansolamenteaunacopiadelosdatos.El principalinconvenientedeesteesquemaesel altoconsumodeanchodebanda,y losretrasosen la respuesta,queresultandel dobletrayectodel mensajeenviadopor el clienteal servidor,y dela respuestadevueltaporel servidoral cliente.Un esquemadeestaarquitecturasepuedeobservarenla Figura4.2.

En el casodela arquitectura replicada, cadasitio enla sesióndetrabajoejecutaunacopiade la aplicación.Todoslos eventosproducidospor los usuariossonprocesadoslocalmenteydistribuidosa los otrossitios. Conestesistema,el tráficosobrela redcontienesolamenteco-mandos,demodoqueel tiempoderespuestaesmuchomenor, y el anchodebandarequeridoesmuchomáspequeñoqueconel enfoqueprecedente.El principalproblemadeestaconfigu-raciónesla necesidaddemantenerla consistenciaentretodaslascopiasde la aplicación.Unesquemadeestaarquitecturapuedeobservarseenla Figura4.3.

Cliente 1

Cliente 2

Cliente 3Cliente 4

Control de sesión

Aplicación

Soporte de red

Figura4.2.:EsquemadeunaarquitecturaCSCWcentralizada.

Unodelosrequerimientosprincipalesenel desarrollodeleditoresla capacidaddelsistemadeejecutarseatravésderedesdeordenadoresdeanchodebandamedioo bajo.Enconcreto,sehabuscadoun rendimientoaceptableenredesRDSI,queconstituyenun estándardeconexiónenpequeñasy medianasempresasentodaEuropa.

Otrorequerimientobásico,implícitoenlapropianaturalezadelosdatos,eselaccesorápidoa los datos.La visualizacióno renderingde datostridimensionalescomportaun volumendedatosmuy elevado.Si esavisualizaciónsedeberealizara frecuenciasqueasegurenunaciertainteractividad(al menos10framesporsegundo),el accesorápidoa todoesevolumendedatosescrucial.



Soporte de red

Control de sesión

Aplicación

Control de sesión

Aplicación

Control de sesión

Aplicación

Control de sesión

Aplicación

Figura4.3.:EsquemadeunaarquitecturaCSCWreplicada.

Teniendoencuentaestosrequerimientos,sehaoptadoporunaarquitecturadedatostotal-mentereplicadaen los sitios deejecución.Los grafosdeescenasehallanreplicadosen cadaunade las instanciasdel editor y formanun esquemade memoriacompartidadistribuida,deformaquecadaréplicaconstituyeunacopiacoherentedeunabasededatosconceptual,quehasidollamada“Basededatospersistenteenmemoria”.

Cadaunade lasréplicasdel editorcontieneunacopiade los datosgeométricostridimen-sionales.El accesoa esosdatos,por tanto,estanrápidocomopermitael hardwaredevisuali-zacióngráficadela estacióndetrabajo,y nodependedela posiblesobrecargadela red.

La basededatospersistenteenmemoriaesconstruidasimétricamenteenel momentoquetodaslas réplicasde la aplicaciónson iniciadas. Al inicio de la ejecución,por tanto, cadaréplicacontieneexactamentelosmismosdatosrelativosal diseñoarquitectónico.

Dadoqueno existeunacopiacentraldelos datosgeométricos,todaslasréplicassedebenmantenercoherentesa lo largo de la ejecuciónde la aplicación. Esteesun aspectobásico,ya quecualquierfuncionalidadnueva del editordeberáserimplementadarespetandoentodomomentola coherenciaentrelos datosreplicados.

En la siguientesecciónexplicaremosla formadeenvío deestosmensajes,suestructura,yel protocolodeaplicaciónquelesdasoporte.

4.3. El protocolo Mu3D

Enla secciónanteriorhemosvistocomolasréplicasdela basededatospersistenteenmemoriadebenpermanecercoherentesa lo largo de la ejecuciónde la aplicación. Estacoherenciaseconsiguemedianteel envío demensajesentrelasréplicascadavezqueunadeellassufreuna



modificación.Poresemotivo, el editorhautilizadoun protocolodemensajes,llamadoMu3D([SD97], [Gal00]).

El protocoloMu3D esun protocolode nivel de aplicación,queconstituyeun elementoesencialparael soportede la interacciónentrevariosusuariosenel entornocompartidode laaplicación.Esteprotocoloesimplementadomedianteel intercambiodePDUs(ProtocolDataUnits) entrelasréplicasdela aplicación.

Los cambioslocalesenel entornocompartidosonnotificadosal restode las réplicasme-diantemensajesdeactualización,quesonenviadosdeformaasíncrona,en formade eventos.El formatode estosmensajesesdefinidopor el protocolo. De estemodo,cadaréplicade laaplicaciónescapazdemodificarlosparámetrosdela escenacompartida.El trabajodegestióndeloseventos,desdeel puntodevistadel editor, comprendedostareas:

A Creaciónlocal del evento. Cuandounamodificaciónha sido realizadasobrelos datostridimensionales,la aplicaciónencapsulalosvaloresdeéstaenunnuevomensajeMu3D,y los transmiteal restoderéplicas.

A Recreacióndeeventosremotos. Cuandounaréplicadela aplicaciónrecibeun mensaje,lo decodificae interpreta,y modificalos parámetrosadecuadosdesucopialocal de losdatostridimensionales.

Los mensajesqueconstituyenel protocoloMu3D debenser de un tamañolo máspequeñoposible,de forma queel anchode bandaconsumidopor el tráfico de mensajesseamínimo.Esteesunrequerimientocrítico,dadoqueunmayortamañodelosmensajesimplicaunmayortiempode transferencia.Estemayortiempode transferenciapuedecomprometerseriamentela interactividad de la aplicación. Si un usuariomodificaun diseñoarquitectónicoy su mo-dificaciónno estransmitidaa los demásusuariosen un tiemporazonable,o peoraún,no estransmitidaenabsoluto,el trabajocooperativo sevuelve imposible.Porestemotivo, los men-sajesdel protocoloMu3D contienenla informaciónmínimanecesariaparaqueel destinatarioreproduzcalocalmentelos eventosremotos,representadospor los mensajesquellegan. En laimplementaciónactual,el tamañomediodeun mensajeMu3D oscilaentre130y 150bytes1.Estepequeñotamaño,junto con la técnicade replicaciónde los datostridimensionales,pro-porcionauntiempoderespuestamásrápido,yaquela recreaciónlocaldeuneventoremotonodependedel tráficodered.

CadamensajeMu3D constade diversoscamposdivididos en cabeceray datos,comosepuedever enla Figura4.4.Describimosacontinuacióncadaunodeellos:

A El campoUSERID contieneel identificadordel usuarioqueenvía el mensaje.

A El campoEVENT describeel tipo de evento. De acuerdocon estetipo de evento,elrestodecampospuedentenerun conjuntodevaloresdiferente,asícomoun significadodistinto.

1Enla implementaciónactual,partedelosmensajessonenviadosíntegramenteconrepresentaciónentextoASCII.Es posiblereduciraúnmásel tamañode los mensajesempaquetándolos,o enviandolos datosnuméricosenrepresentaciónbinaria.



B El campoLOCAL TS (Local Timestamp) seutiliza parala ordenacióndelosmensajes.

B El campoSCENEID contieneel identificadordela escenasobrela queel eventohasidogenerado.

B El campoSIZEScontienelos tamañosdeloscamposdedatosdel mensaje.

B El campoOBJECTCLASSdescribela clasedeobjetoa la cualseaplicael evento.Susvalorespuedenvariardeacuerdoconel tipo deevento,y suelentenerrelaciónconel tipodenodoamodificar.

B El campoOBJECTPATH contienela ruta OpenInventor de índicesque identifica alobjetoafectadoporel evento.

B El campoOBJECTDATA contienedatosvariables,relacionadosconel eventoy conlaclasedeobjetodelmensaje.

LOCAL TS SCENE ID

EVENT DATA

OBJECT OBJECTDATA

OBJECTPATHData CLASSEVENTUSER ID

PathClass

SIZES

MESSAGE HEADER

Figura4.4.:Formatodeun mensajeMu3D.

El significadoconcretode cadacampodependedel tipo de evento que ha generadoelmensaje,y dela clasedeobjetoa la queésteesaplicado,comosepuedever enla Tabla4.2.

El conjuntodemensajesdel protocoloMu3D sedivideendistintostipos,segúnel áreadeaplicacióndecadauno.Los enumeramosa continuación:

B Mensajesdecontrol de la sesión. Utilizadosparacontrolarel inicio deunasesióncoo-perativa.

– TELEINIT. Indicaqueunodelos usuariosquiereiniciar unanuevasesión.

– TELENOTIFY. Indicaqueun usuariosehaunidoa la sesión.

B Mensajesdecontrol de los objetos. Utilizadosparaimplementarel bloqueode objetosparasuediciónposterior.

– SELECT. Un usuariohaseleccionadounobjeto.

– DESELECT. Un usuariohaliberadoun objetoqueteníaseleccionado.

– SELECTNACK. Un usuarioha rechazadola selecciónde un objetopor partedeotro.

B Mensajesde control de escenas. Utilizadosparala implementaciónde lasoperacionesbásicassobreescenas.Consistenenun únicoevento,SCENE,conlassiguientesclases:



– SCENE-NEW. Un usuariohacreadounanuevaescena.

– SCENE-REMOVE. Un usuariohaborradounaescenadememoria.

– SCENE-ACTIVATE. Un usuariohacambiadoaotraescena.

C Mensajesde edición. Utilizadosparala notificaciónde modificacionessobrela escenatridimensional.

– ADD. Un nuevo objetohasidoañadidoa la escena.

– REMOVE. Un objetohasidoborradodela escena.

– MODIFY. Unapartedela escenahasidomodificada.

– CLIPBOARD. Unaoperacióndeportapapeleshasidoaplicada.

– RPC.Llamadaremotaaun procedimientocomplejo.

Unadescripcióndetalladadelosvaloresdecadatipo demensajedelprotocoloMu3D sepuedeobservarenla Tabla4.2.

El protocoloMu3D, que en un principio constabade un conjuntomínimo de clasesdemensajes,hademostradoserampliabley flexible. Comoveremosen los siguientescapítulos,noshasidoposibleextenderel conjuntodetiposdemensajes,enel momentodeintroducirunanueva funcióno característicaenel editor, sinmodificarla estructuradel protocolo.



Evento Clase Datos Acción

ADD FILE Nombre fichero Inserta una escena desde un fichero.

AVATAR Nombre fichero Inserta un avatar en la escena.

URL URL Inserta una escena desde la web.

SECTION Nombre Añade una sección a la escena.

ANNOTATION Texto o enlace Inserta una nueva anotación en forma de

texto o enlace.

RESTORE ID de usuario Restaura un objeto de la papelera.

VIEWPOINT Parámetros Inserta un nuevo punto de vista.

Otros Tipo de nodo Crea e inserta un nuevo nodo.

REMOVE Otros Borra el nodo de la escena.

LIGHT Nodo de luz Borra la luz dada de la escena.

MODIFY AVATAR Transformación Modifica la posición del avatar.

NAME Cadena Cambia el nombre del nodo especificado.

TRANSFORM Transformación Modifica la transformación del objeto.

MATERIAL Material Modifica el material del objeto.

ANNOTATION Texto Modifica el texto o URL de la anotación.

SECTION Ruta Modifica los planos de corte de la sección.

VIEWPOINT Parámetros Modifica un punto de vista de la escena.

LIGHT Nodo de luz Modifica los parámetros de la luz.

CLIPBOARD COPY Objeto Copia el objeto al portapapeles.

PASTE Objeto Pega el objeto del portapapeles.

SCENE NEW ID de usuario Crea una nueva escena vacía y le asigna

un identificador.

REMOVE ID de escena Borra la escena de la memoria.

ACTIVATE ID de escena Coloca el avatar remoto en la escena.

NAME Cadena Cambia el nombre de la escena.

SELECT GROUP Objeto Marca el objeto como seleccionado.

SELECT

NACK

USER Booleano Rechaza una selección por conflicto.

DESELECT GROUP Objeto Libera la selección del objeto.

TELEINIT USER ID de usuario Inicializa una sesión de trabajo e informa a

todos los participantes.

TELENOTIFY USER ID de usuario Respuesta de un nuevo participante.

RPC GROUP Objeto Agrupa el subárbol según un criterio deter-

minado.

MOVE Objeto Mueve un objeto a otra localización en el

grafo de escena.

Tabla4.2.:Estructuray principaleseventosdelprotocoloMu3D


Parte II.

Técnicas cooperativ asdesarr olladas


5. Manejo cooperativ o de los datos 3D

5.1. Definición de objeto

Un “objeto” esla unidadmínimautilizablepor el usuarioen nuestroprograma.Un objetoesun subgrafodeescenaquecontienelos elementosgeométricosmínimosparasermanipuladoo editadoindependientementedel restodel grafodeescena.Porello, la raízdeestesubgrafoes un nodo separador. Cadaobjeto independientecontienesu propia geometría,su propiamatrizdetransformacióny supropionododematerial.Un ejemplodeobjetomínimosepuedeobservarenla Figura5.1.

La granularidaddelasoperacionesdeleditorescomomínimoanivel deobjeto.Portanto,no esposibleseleccionary modificarnodosaisladosdel grafodeescena.Todaslasmodifica-cionesquetenganlugar sobreobjetosestaránencapsuladasmedianteoperacionesde usuariodealtonivel: modificacionesgeométricas,edicióndemateriales,etc.

Los objetospuedenestaragrupados,como ya hemosvisto, formandouna jerarquíadeárbol. Las característicasde un grupode objetospuedenser modificadas,de forma que lamodificaciónafectea todoslosobjetosdel grupo,queseencuentranpordebajoy a la derecha.

Separator

Transform Material Shape

Figura5.1.:Estructuramínimadeun objetotridimensionalutilizableporel editor

5.2. Gestión cooperativ a de escenas múltiples

La gestióndeescenasmúltiplesesunacaracterísticamuy extendidaenlos editoresdeobjetos3D. Estacaracterísticapermiteincrementarla productividad,yaquepermiteal usuariotrabajar


Capítulo5. Manejocooperativo delos datos3D

a la vezsobrediseñostridimensionalesdistintos.Por escenaentendemosun conjuntode datosgeométricosinterrelacionados,quepueden

servisualizadosy modificadospor el usuario. Cadaescenapuedeestarcompuestade uno omásobjetos,queseiránañadiendoa elladeformaacumulativa.

El editor permitegestionarmúltiples escenas,asociandocadauna de ellas a una o másventanas.De estemodo,el usuariopuedetrabajarcon variasescenasen distintasventanas,teniendoentodomomentounaúnicaescenaactiva.

Las escenasmúltiplesseencuentranintegradasen el editor formandoun único grafo deescena.Cadaescenaseasociaa una o másventanas,de forma que la raíz de su subárbolasociadoseasignaa losvisoresOpenInventorcorrespondientes.

La gestiónde múltiples escenasexige la definición de un conjuntode operaciones.Ennuestrocaso,esteconjuntodeoperacionescontendrálassiguientes:

D Creaciónde unaescenaen memoria. Estaoperaciónsuponela creaciónde unanuevaescena,bienvacía,o bienconteniendodetosleídosdeunficheroOpenInventoroVRML.

D Eliminacióndeunaescena. Estaoperaciónconsisteenel borradodememoriadetodoslosdatosrelacionadosconla escena.

D Activacióndeunaescena. En un momentodado,sólounaescenaestaráactiva a la vez.La activacióndeunaescenaimplicarála desactivacióndela anteriorescenaactiva.

Enestasecciónmostraremosla estructuraglobalutilizadaparaagruparel conjuntodeescenas,asícomola estructurainternade cadaescenaindividual. Explicaremosademáslasoperacio-nesbásicassobrelasescenasquehemosdesarrollado,y el conjuntodemensajesdel protocoloMu3D quehansidoañadidosparacubrir el aspectocooperativo dela gestióndeescenasmúl-tiples.

5.2.1. Estructura del conjunto de escenas

El árbolqueagrupala estructuraglobaldelconjuntodelasescenassemuestraenla Figura5.2.En la figura se ilustra la organizacióngeneralde las escenas,y la estructurainternade unade ellas. Describiremosen primer lugar la estructurageneraldel grafo en su totalidad,y acontinuacióndescribiremosla estructuradecadaescenaenparticular.

El árbolglobalagrupabajounnodoraízcomún(llamadoSceneManagerenlafigura)todoslos subárbolescorrespondientesa cadaescena.Bajo la raíz global seencuentrala siguienteestructura:

D Un subárbolquecontienedatosinternos,comunesa todaslas escenas,comoson losPortapapeles(Clipboard) y lasPapeleras(ThrashBin).

D Unoo mássubárbolesquecorrespondenacadaunadelasescenascargadasenmemoriaenel momentoactual.



Todaslasescenastienencomoraízun nododeseleccióndel tipo Local SceneManager(LSMen la figura), utilizado para la gestiónde los objetosseleccionadosinteractivamentepor elusuario. Sobreestetipo de nodoy su implementaciónhablaremosmásextensamenteen elCapítulo6.

CadanodoLSM tienecomohijo un nododeagrupacióndetipo separador, llamadoRoot,bajoel cualseencuentratodala estructuradela escena.Los hijos quecontieneel nodoRoot,poresteorden,sonlos siguientes:

E Un subárbolquecontienetodaslaslucesdela escena(Lights).

E Un subárbolcontodoslospuntosdevistapredefinidosdela escena(Viewpoints).

E Un subárbolcon elementoscomunesde visualizaciónde la escena,talescomoejesdecoordenadas,y otros(Common).

E Un subárbolquecontienetodoslos avataresde los usuariosremotosen la sesión(Ava-tars).

E Un subárbolcontodaslasseccionesy cortesdevisualizacióndela escena(Sections).

E Un subárbolquecontienetodoslos objetosde la escena,llamadoObjects. Bajo estesubárbolestaráncolocadostodoslosobjetosgeométricosincluidosenla escena.

Cadaescenaestáidentificadaporunnúmerosecuencial,queseutilizaráparael soportecoope-rativo a la gestióndeescenasmúltiples,comoveremosenlossiguientesapartados.

5.2.2. Operaciones básicas sobre escenas

La aplicación,hemosdicho,definetresoperacionesbásicasa realizarsobrelasescenas:crea-ción,borradoy activación.A continuación,describimosla implementacióndeestasoperacio-nes.

La creacióndeunanueva escenaconsisteen la inserciónbajo la raízdel árbolgeneraldela escenadeun nuevo nododeselección,de tipo LSM, bajoel cualcolgaráunaestructuradeárbolcomola descritaanteriormente.El usuarioquehayacreadola escenala activaráenesemomento.La nueva escenaestarávacíaal principio, esdecir, bajoel subárbolde objetosnohabráningúnnodo.El usuariopuedeelegir entrecrearla nueva escenavacía(operaciónFile-New), o crearlaconteniendodatosleídosde un fichero(operaciónFile-Open),con lo queseinsertaránunoo másobjetosenla escenadespuésdesucreación.

El borradodeunaescenaconsisteenel borradodel nodoraízdeseleccióndeésta.Todoslos datosrelativosa la escenasondescargadosdememoria,y seactivaotradelasescenasquehayaenmemoriaenesemomento.

La activacióndeunaescenaconsisteenasignarel nododeseleccióndela escenaal visoractivo de la aplicación,de maneraquesevisualicela nueva escenaactiva. Además,sedebemodificarel indicadordela escenaactiva,paraqueapunteal identificadordela nuevaescena.



SceneManager

Internal LSM 1 LSM 2 LSM n

Clipboards Thrash binsF

Root Pick Filter

Lights Viewpoints Common Avatars Sections Objects

Object 1 Object n

Figura5.2.:Estructuradel árboldeescenasdel editor.

5.2.3. Sopor te cooperativ o a la gestión de escenas múltiples

Lasoperacionessobreescenasdescritasanteriormentedebencomunicarsea todaslasréplicasdela aplicaciónenla sesión.Porello, el protocoloMu3D hasidoextendidoconun nuevo tipodeevento,llamadoSCENE,queincluyedistintasclasesdeeventos,unaparacadaoperación.Veremosacontinuacióncuálessonestasclases,y el comportamientodela aplicaciónal recibirun mensajedeestostipos.

G El mensajeSCENE-NEWesenviado en el momentode la creaciónde unaescena.Alrecibir estemensaje,lasotrasinstanciasdel editor recreanel evento,y activanla nuevaescena.

G El mensajeSCENE-DELETEesenviadoenel momentodel borradodeunaescena.

G El mensajeSCENE-ACTIVATE seenvía enel momentoqueun usuariocambiadeunaescenaa otra. El identificadorde la escenade destinoesenviado dentrodel mensaje.Al recibir estemensaje,cadainstanciadel editormueve el avatardel usuarioorigena lanuevaescenaactiva.



El borradodeunaescenaesunaoperacióndelicada,desdeel puntodevistacooperativo. Porestemotivo, hemostenidoquedefinir unaseriederestricciones.Lasdescribimosa continua-ción:

H Una escenano puedeserborradasi otrosusuarios,ademásdel que la va a borrar, seencuentranenella,esdecir, si la tienenactivada.Paracomprobaresto,sepuedeconsultarel subárboldeavataresremotosdela escena,y ver si contienealgúnelemento.

H Tampocoha de serposibleborrarunaescenasi otrosusuarios,aunqueno seencuen-tren en ella, mantienenalgúnobjetoseleccionadodentrode la misma. Estosepuedecomprobarconsultandola lista de objetosremotamenteseleccionadosdel nodo LSMcorrespondiente,sobrela quehablaremoscondetalleenel Capítulo6.

H Porotra parte,unaescenano debepoderserborradasi no hayningunaotra escenaenmemoria.Portanto,la aplicaciónsiempretendrácargadaal menosunaescena.

Comohemosexplicadoenla Sección4.3,cadamensajedel protocoloMu3D lleva incluido elidentificadorde la escenaen la cual seha generadoel evento. Estecampofue añadidoparaquelos datoscontenidosen cadamensaje,talescomola ruta al objetoqueseaplica, fueranrelativos a la escena.Los eventosrecibidosson recreadostomandocomo puntode partidala escenaquecontienen.De estemodo,todaslas escenassonactualizadasautomáticamente,independientementedecuálseala escenaactivadecadausuarioenun momentodado.

5.3. Formatos tridimensionales sopor tados

El editordebeofrecersoporteparalosformatosmásestandarizadosderepresentacióntridimen-sional. Estesoporteincluye tantola importacióncomola exportacióndeficheros.El soportequehemosimplementadoincluyelossiguientesformatos:

H El formatoOpenInventor, nativo delaslibreríasdedesarrollo.

H El formatoVRML 1.0,primeraversióndelestándarVRML.

H El formatoISO estándarVRML 97 ([Car97]),la versiónmásrecientedel estándar.

Estostresformatossonmuysimilaresenla filosofía,yaquelos tressebasanenel conceptodegrafo deescena.Pasamosa continuacióna explicar la relaciónentreellos,desdeel puntodevistadela conversiónentreformatos.

H Enprimerlugar, podemosconsiderar, aefectosdela aplicaciónquehemosdesarrollado,quelosformatosOpenInventory VRML 1.0sonprácticamenteidénticos,yaqueutilizanlos mismostiposdenodos.La únicadiferenciaseencuentraen la cabeceradel fichero,por lo quedeberemosmodificarlasegúnel formatoenel quesegrabeenfichero.

H Porotraparte,comoseexplica enla Sección3.5,el formatoVRML 97 sediferenciadelosdosanterioresprincipalmenteenla estructuradel grafodeescena,y enla utilizacióndenodosdistintos,tantoennomenclaturacomoencomportamiento.



Si el usuariotrabajahabitualmentecon otro formato,comopor ejemploDXF ([Rul96]), for-mato propio del programaAutoCAD [Aut90], que constituyeun estándarde facto, o 3DS([Rul96]), formatotridimensionaldel programa3DStudio([Aut94]), deberárealizarunacon-versiónal formato VRML 97 o a OpenInventor. Estaconversiónpuedeser realizadaconalgunode los múltiplesprogramascomercialesqueexisten([Cad]), o bienutilizandoun mó-dulo deconversióndesarrolladodentrodel proyectoM3D ([HF99]), quepermitecargarestostiposdeficherosenel editor, deformatransparente.

5.4. Entrada y salida

Las operacionesde lecturay almacenamientode todo el grafo de escenao de unapartesonindependientesde la localizaciónfísica de los datos. Por tanto, los mismosdatossepuedenleer o guardaren un disco local a cadausuario,o bien en una basede datoscentralizada,utilizandolasmismastécnicas.

La entraday salidasonconsideradasenel editordesdedospuntosde vistadistintos:porun lado,hemosdedeterminardequéformaseleeny escribenlos datostridimensionales.Porel otro, hemosde definir quécomportamientotienenlas operacionesde entraday salidaenel entornocooperativo en quefuncionael editor. A continuaciónexplicamosde quémanerahemosimplementadoestosdosaspectos,tantoen la lecturacomoen el almacenamientodedatos.

5.4.1. Lectura

El principalproblemarelativo a los datosa leervienedeterminadopor el formatodeéstos.Elformatoquepresentamásdiferenciasde los tresformatosnativosesVRML 97, comohemosvisto en la secciónanterior. A continuaciónexplicaremosdequéformahemosimplementadoel soporteparala lecturadeficherosVRML 97.

Las últimasversionesde OpenInventor hanincorporadosoporteinternoparanodosdelformatoVRML 97 ([Hec97]),por lo quemanejaresteformatono implica la construccióndeanalizadoressintácticos,ni deotrasherramientasdeconversióna la horadecargarun ficheroVRML 97. Sin embargo, ya hemoscomentadoqueel manejode nodosVRML 97 presentanumerososproblemas,debidoa fallosenla implementacióndeOpenInventor, quenohansidosolucionadosporcompletotodavía.

Porestosmotivos,hemostomadola decisióndeutilizar comoformatointernoúnicamenteel de OpenInventor(o VRML 1.0), de forma queaseguraremosqueel grafo de escenasólocontenganodosdeestosformatos,cuandoestécargadoenmemoria.

No obstante,nuestromódulodelecturaaprovechalasfuncionesdeanálisisléxicoy sintác-tico deOpenInventor, quepermitencargarunficheroVRML 97aungrafodeescena.Unavezel grafodeescenaestácargado,esconvertidoa otro grafodeescenaquecontienesólonodosVRML 1.0 utilizandounafuncióndesarrolladaparala ocasión,querecorrerecursivamenteelgrafodenodosVRML 97 y vagenerandoun grafoconnodosVRML 1.0. Un esquemadeestaoperaciónsepuedever enla Figura5.3.

La funcióndeconversióndeVRML 97aVRML 1.0aprovechadoscaracterísticasbásicas:



I La simplicidadestructuraldelos ficherosVRML 97, quepermitenconvertir fácilmenteunaestructuraVRML 97 enunaestructuraVRML 1.0.

I La correspondenciaqueexisteentrelosnodosdelosdosformatos,quepermiteencontrarun nodoequivalenteVRML 1.0paracadanodoVRML 97.

Estafunción de conversión,presentaalgunascarencias,entrelas quepodemosenumerarlassiguientes:

I Falta de soporteal prototipadode nodos,una de las característicasmáspotentesdeVRML 97,queno essoportadocompletamentepor laslibreríasOpenInventor.

I FaltadeequivalenteVRML 1.0paraalgunosnodosVRML 97.

No obstante,la funciónimplementadahademostradosersuficienteparala totalidaddeproyec-tosarquitectónicosutilizadoscomomodelosdeprueba.

Conversor

Fichero VRML 97 Árbol VRML 97J

Árbol VRML 1.0J

Figura5.3.:ConversióndeficherosVRML 97 aOpenInventor.

La lecturade datosdesdeun fichero o basede datosdebeser implementadade formacooperativa, de modoque los distintosusuariosrealicensimultáneamentelas lecturas. Paraseguir estafilosofía,cadavezqueunaréplicadel programacargadatosenmemoria,envía unmensajedel protocoloMu3D al restoderéplicas,deformaquehaganlo propio.Estemensaje,de tipo ADD, puedeserde la claseFILE, si los datossoncargadosdesdeun fichero,o de laclaseURL, si losdatossoncargadosdesdeunabasededatos.

5.4.2. Almacenamiento

En un momentodado,un usuariopuedeguardaren el discolocal o en unabasede datoslaescenaactiva,o bienunapartedeésta.La escenaactivacontieneunaseriedeinformaciónqueno interesaguardar. Estainformaciónincluyeavatares,ejes,manipuladores,y otroselementosdel grafo de escena,queno estánreplicadosdel mismomodoparatodoslos usuarios.Paramantenerla coherenciaentrelasdistintasréplicas,y paraasegurarquela escenaesguardadade igual modopor cualquierusuario,seránecesariorealizarun procesodefiltradosobreésta.Estefiltrado constadedosfases:

I En la primerafaseseretirantodoslos manipuladoresdel árbol de la escena,tanto losmanipuladoresdelaslucescomolos manipuladoresgeométricosinteractivos.



K Enla segundafase,secreaunanuevaestructuradeárboltemporalparael guardado.Paraello, secreaun nuevo nodopadretemporal,al queseañadencomohijos los distintosobjetosquecontienela escena,asícomoel subárboldelaslucesdela escena.Esenodotemporal,y conél todosloshijosqueselehanañadido,seguardaenunfichero,medianteunaaccióndeescrituraendiscodeOpenInventor. Unavezhatenidolugarla operacióndeguardado,el nodotemporalseborra,deformaqueel árbolquedaigual queantesdelinicio deestasegundafase.Un esquemadeestatécnicasepuedever enla Figura5.4.

Root

Lights Viewpoints Common AvatarsL

Sections Objects

Object 1 Object n

TEMP

Figura5.4.:Técnicadel separadortemporalutilizadaparaguardarel fichero.

Utilizandoestatécnica,seguardanúnicamentelos objetosy laslucesdela escena,sin losmanipuladoresni la informaciónlocal complementaria,quepuedevariardeusuarioa usuario.De estemodo,unacopiaalmacenadaen un momentodado,en discolocal o en unabasededatos,contendrála mismainformación,independientementedelusuarioquela hayaguardado.

Paraalmacenarlos elementosde unaescenaen formatoOpenInventoro VRML 1.0 noesnecesariorealizarmásoperaciónquela inserciónde la cabeceradeficheroapropiada.Losnodosdeambosformatossonidénticos.

El almacenamientode los elementosde unaescenaenformatoVRML 97 hacenecesariala aplicacióndeunaaccióndeconversión,llamadaSoToVRML2Action, comosehaexplicadoenla Sección3.5. Estaacciónesaplicadaa cadaunodelos subárbolesquecontenganobjetosgeométricos,antesdeserguardados.


6. Acceso concurrente a los objetos 3D

El editordebesercapazdegestionarel accesoconcurrentea losobjetos3D deunaescena.Lagestióndeesteaccesoconcurrentehasidoimplementadamedianteunmecanismodeselección.La selecciónesun aspectocrucial en el entornocooperativo sobreel quefuncionael editor.Estemecanismogarantizala exclusiónmutuaentrelos usuariosal realizaroperacionessobrelosobjetostridimensionalesqueformanel grafodeescena,medianteunaoperaciónde locking(bloqueo)implícito. De estamanera,seevita quedosusuariossesobreescribanentreelloslasmodificacionesrealizadasa unobjeto.

En estecapítuloexplicaremosel conceptodeselección,la formacomohasidoimplemen-tadoenel editor, y losaspectosrelacionadosconla representacióndelosobjetosseleccionadoslocal y remotamente.

6.1. Concepto de selección

Unaselecciónesla formadeespecificarel objetotridimensionalsobreel quesevana realizarlasoperaciones.Enel Capítulo3 hemosexplicadocomoOpenInventorrepresentala selecciónmedianteunnododeagrupamientoespecial,llamadonododeselección, quemantieneunalistacontodoslos objetosseleccionadosporel usuario.

La implementaciónde la selecciónrealizadapor OpenInventor se limita a los objetosseleccionadospor el usuariolocal. En el entornocooperativo en el queha de funcionareleditor, estaimplementaciónesnecesariaperono suficiente.Por tanto,debemosampliaresteconceptoal casocooperativo y añadirunaseriedecondicionesadicionalesa la selección:

M Un usuariosólopuederealizaroperacionesdeediciónsobreun objetosi lo haseleccio-nadopreviamente.

M Un mismoobjetosólopuedeestarseleccionadosimultáneamenteporun usuario.

Estasrestriccionesvienendadaspor la necesidadde gestionarel accesoconcurrentea cadaobjeto por partede múltiples usuarios. Esto lleva a la necesidadde exclusión mutuaentreusuarioscuandoseestámodificandoun mismoobjeto. En términosdeconcurrenciaclásicos,podemosrepresentarlasmodificacionessobrecadaunode los objetosde la escenacomounaregión crítica ([Sil94]), a la cualúnicamenteun usuariopuedeteneraccesoal mismotiempo.

En baseaestasrestricciones,hemosdefinidola siguientepolíticadeselección:

Cadavez queun usuarioseleccionaun objeto,seconvierte en el propietario deesteobjeto,hastaquelo deselecciona.Duranteesteintervalo detiempo,sóloese


Capítulo6. Accesoconcurrentea los objetos3D

usuario(el propietario)puederealizaroperacionesde ediciónsobreel objeto,yningúnotro usuariopuederealizaredicionessobreéste,ni tampocoseleccionarlo.

Esdecir, entérminosprácticos,unaseleccióndeunobjetoimplicaunbloqueo(locking) deéste.Estapolíticadebloqueodeobjetosbasadaenseleccionesnospermitemantenerla consistenciaentretodaslasréplicasdela basededatospersistente.A continuaciónexplicamosla formaenqueestapolíticahasidoimplementadaenel editor.

Figura6.1.:Ejemplodeselecciónlocal resaltadaencolor rojo.

6.2. Implementación de la política de selección

El nododeseleccióndeOpenInventor, definidoenel Capítulo3,noessuficienteparasatisfacerlas restriccionesquehemosdefinidoen la secciónanterior. Porello, hemosimplementadounnuevo tipo de nodoOpenInventor, llamadoLocalSM(Local SelectionManager, gestorlocaldeselecciones),comounanuevaclaseenlenguajeC++ queheredalaspropiedadesdela clasedel nododeselección,y queincorporanuevasfuncionalidades.Estassonlassiguientes:

N Gestióndeunalistadeobjetosseleccionadosremotamente.

N Controldela posibilidado no deseleccionarun objetolocalmente.

N Envío demensajesapropiadoscuandoun objetoesseleccionadoo liberadolocalmente.

En la Sección5.2 hemosexplicadocomocadaunade las escenascargadaspor el editor enmemoriatienecomoraíz un nododel tipo LocalSM, de maneraquetodaslas seleccionesydeseleccionesquetienenlugar sobreunamismaescenasonprocesadaspor el mismogestorlocal.

El gestorlocaldeseleccionestienedoscometidosprincipales:el controldelasseleccioneslocales,y el control de las seleccionesremotas. A continuacióncomentamoscómo hemosimplementadolasfuncionesnecesariasparacubrirestosdoscometidos.



6.2.1. Contr ol de selecciones locales

OpenInventordefinela posibilidaddecapturarloseventosdeseleccióny deselecciónmedian-te funcionescallback1. La aplicaciónaprovechaestesoporteparagestionarlas seleccioneslocales.En nuestrocaso,hemosutilizadotresfuncionesdiferentes,quesonllamadasencasodeproducirselossiguienteseventos:

O En el momentode pulsaro de soltar el botón del ratón sobreun determinadoobjeto(operacióndepicking).

O En el momentodeseleccionarun objetodela escena(operacióndeselección).

O En el momentodedeseleccionarun objetodela escena(operacióndedeselección).

Lasfuncionescallback asociadasa losdistintoseventossehanimplementadocomomiembrosestáticos2 dela claseC++ LocalSM.

A continuaciónse detalla,de forma general,el comportamientode la aplicaciónen elmomentodeinvocacióndecadaunadelasfuncionescallback.

Función de manejo de picking

La función miembroSelectionPickCBesinvocadaen el momentoen queel usuariopulsaoliberael botóndel ratón.Enel casomásfrecuente,enel quesehaceclic sobreel mismoobjetosin apenasdesplazarel ratón,la funciónseráinvocadadosvecesconlosmismosargumentos.

Estafunción recibecomo argumentounaaccióndel tipo SoRayPickAction, queha sidoaplicadaal objetoenviandoun rayo en la direcciónde vista de la cámara,y localizandoelobjetou objetosqueintersectanconesterayo. En el momentode la llamadaa la función,losobjetosseencuentranenla listaderesultadosdela acción.

Trasrealizarlasoperacionesadecuadas,la funciónretornaunaruta deOpenInventorqueserápasadacomoparámetroal nododeselecciónparaserañadidaala listadeobjetosseleccio-nadoslocalmente.El valor de la rutaa retornarpuedesermodificadodentrodeestafunción,de maneraquela selecciónseproduzcasobreel objetoseñaladopor el usuario,sobreotro, ono seproduzca.

Enel momentoenquela funcióndepickingesinvocada,serealizaunaoperacióndefiltradode los objetoscontenidosen la acciónSoRayPickAction, quecompruebael tipo de nodoqueson,y actúade acuerdocon un conjuntode reglas establecidas.Esteconjuntode reglas esextensiblea medidaquesevan añadiendonuevasfuncionalidadesa la aplicación,y en estemomentosonlassiguientes:

O Si el objetoestáseleccionadoremotamentepor otro usuario,no podráserseleccionadode nuevo localmente. Por tanto, la función retornaráuna ruta vacía,de forma que laselecciónnoserealice.

1Una función callback no es llamadaexplícitamentepor la aplicación,sino quees invocadapor la librería desoporteo porel sistemaoperativo enel momentoquesucedeun determinadoevento.

2El lenguajeC++ exige quelas funcionescallback no esténligadasa ningunainstanciade las clases,y por esoestasfuncionessehandeclaradocomoestáticas(static).



P Si el objetoesel manipuladordeunaluz, noserealizaráningunaoperacióndeselecciónsobreella. Portanto,la funciónretornaráunarutavacía.

P Si el objetohasidodefinidocomoinvisible3, tampocopodráserseleccionado,y la fun-ción retornaráunarutavacía.

P Si nosecumpleningunadeestasreglas,el objetoesseleccionado,y la funciónretornarála ruta que lleva hastael nodode agrupación(SoGroup) máspróximo a la geometríaconsiderada.

Comopodemosver enestaúltima regla, la funcióndemanejodepicking no devuelveel nodosobreel queseha posicionadoel ratón,sino su ascendientemáscercano,de acuerdocon loqueseexplica enla Sección5.1.

El hechodedevolverla rutadelascendientemásdirectodelnodoqueelusuariohaseñaladopermitetenerun referentefijo parapoderoperarcon la selección.De estemodo,aunquesemodifiquealgunade las propiedadesdel objeto (por ejemplo,insertandoun nuevo nododematerial),la ruta queidentificaal nodoseleccionadono cambiará,ya quela insercióntienelugarpordebajodeél.

Función de manejo de selecciones

La función miembroSelectionCBesinvocadacadavezqueun objetoesseleccionado.En elmomentodela invocación,el objetoya hasidoañadidoa la listadeseleccionesquemantieneel nodode seleccióny espasadoa la funcióncomoparámetro.La operaciónquerealizaestafunciónconsistebásicamenteenla notificaciónde la realizacióndeestaseleccióna todoslosdemásmiembrosdela sesióncooperativa.

Dichanotificacióntienelugarmedianteel envío deun mensajeMu3D detipo SELECTatodoslos demásmiembrosdela sesión,incluyendola rutaal objetoaseleccionar.

Función de manejo de deselecciones

La función miembroDeselectionCBseinvocacadavezqueun objetoesdeseleccionado.Enel momentode la invocación,el objetoya ha sido retiradode la lista de seleccioneslocalesmantenidaporel nododeselección.

La función realizael envío de un mensajeMu3D de tipo DESELECTa todoslos demásmiembrosdela sesión,incluyendola rutaal objetoa deseleccionar.

6.2.2. Contr ol de selecciones remotas

Una selecciónremotatienelugaren unainstanciadel programaen la sesióncooperativa dis-tinta de la instancialocal. Cadavezqueunaseleccióntienelugarenunode los ordenadoresmiembro,la instanciadel programaenvía un mensajenotificándoloa los demásmiembros,demaneraquetambiénellostenganconstanciadeestaselección.

3La capacidaddeocultarobjetosenel editorhasidoimplementadaporseparado,y noseexplicaenestamemoria.



Paraalmacenarlasdistintasseleccionesremotas,cadagestorlocaldeseleccionesmantieneunalista con punterosa los objetostridimensionalesseleccionadosremotamente.En el mo-mentoquellega un mensajeMu3D de tipo SELECTo DESELECT, estalista esactualizada.La consultade la lista tienelugar cadavezqueun usuariointentaseleccionarlocalmenteunobjeto,paracomprobarqueeseobjetono estáyaseleccionadoenotradelasmáquinas.

6.3. Representación gráfica de las selecciones

Un objetoseleccionadoesrepresentadoen pantallapor OpenInventormedianteun resaltado(highlight). Esteresaltadosevisualizamedianteel contornodela boundingboxdel objeto.

Para distinguir entrelas seleccionesrealizadaslocalmentey las seleccionesremotas,eleditor utiliza dos colores: rojo paralas seleccioneslocales,y amarillo para las seleccionesremotas.Un ejemplosepuedeverenla Figura6.2.

La representaciónenrojo de los objetosseleccionadoslocalmenteestáimplementadapordefectoenOpenInventor. No ocurrelo mismoconla representaciónenamarillo,quehatenidoque ser implementadaen nuestroeditor. Explicamosa continuaciónel procesoquehemosseguido.

El resaltadodel objetoesrepresentadointernamentecomoun objetomásdeOpenInven-tor, formadopor un separador, un nodoquerepresentala formade la boundingbox, otro querepresentael color, y otro queindicaquesólosedebevisualizarel contornodelasaristas(re-presentaciónwireframe). Esteobjetoescreadopor la acciónde visualizacióncuandorecorreel grafodeescenay encuentraun objetoseleccionado.La aplicaciónextiendeestecomporta-mientodeformaquesemodifiqueel color segúnel tipo deselección,localo remota.Paraellohemoscreadounanueva acciónde visualizaciónquerealizaestecomportamiento.La nuevaacciónhasidoimplementadacomounanuevaclaseC++ derivadadela claseSoRenderAction,siguiendolas técnicasdescritasen [Wer94b]. Hemosllamadoa estaclaseownHighlightRen-derAction.

El funcionamientode la nueva accióndevisualizaciónesmuy similar en lo fundamentala la clasebasede la cual heredael comportamiento.La únicadiferenciaradicaen queman-tieneun pequeñografoOpenInventor, quecontienela estructurabásicadeunaboundingbox(geometríadela caja,color e indicacionesdevisualización).Cadavezquela nuevaaccióndevisualizaciónatraviesaunnododel grafodeescena,realizalassiguientesoperaciones:

Q Comprobarsi el nodoseencuentraenla listadeseleccioneslocales.

– Si esasí,calcularsu boundingbox, aplicarsusmedidasa la cajade resaltado,ydibujarlaencolor rojo, enmodowireframe.

Q Comprobarsi el nodoseencuentraenla listadeseleccionesremotas.

– Si esasí,calcularsu boundingbox, aplicarsusmedidasa la cajade resaltado,ydibujarlaencolor amarillo,enmodowireframe.

Q Aplicar la acciónbasedevisualizaciónal nodo.



La nuevaaccióndevisualizacióny resaltadoesasignadaa cualquieradelos visoresdel editormedianteel métodosetGLRenderAction. Deestemodo,la acciónesaplicadaautomáticamentecadavezquelageometríaesmodificada,o biencuandounaselecciónlocalo remotaesactivadao desactivada.

Figura6.2.:Selecciónlocal (enrojo) y selecciónremota(enamarillo).


7. Edición básica cooperativ a

Lasfuncionesbásicasdeediciónpresentesencualquiereditordeobjetostridimensionaleshansido implementadastambiénen la aplicación. El desarrollode estasfuncionesbásicasseharealizadoteniendopresenteel entornocooperativo enel queseejecutala aplicación.

En estecapítulopresentamosla implementaciónde las funcionesbásicasdel editor: in-sercióny borradode objetos,manipulacióngeométricainteractiva, ediciónde materiales,eiluminación. Hemosadaptadocadaunade estasfuncionesal trabajocooperativo, utilizandoel protocoloMu3D y el conceptode memoriacompartidadistribuidacon replicaciónactiva,ambosexplicadosen el Capítulo4. A continuaciónexplicamosla forma en que lo hemoshecho.

7.1. Requerimientos generales

El desarrollode cualquierfunción de ediciónsobrelos objetostridimensionalesdebecum-plir unaseriede condicionesdesdeel momentoenqueestafuncióndeberealizarseenmodocooperativo. Estascondicionessonlassiguientes:

1. Controldel accesoconcurrentedemúltiplesusuariosal accederal mismoobjeto

2. Coherenciadelosdatosa manejarenla escena.

Paraquesecumplanestasdoscondiciones,ya hemosintroducidoen capítulosanterioreslassuguientestécnicas:

1. Exclusiónmutuaentreusuarios,medianteel bloqueodelosobjetosseleccionados,comoseexplica enel Capítulo6.

2. Replicacióndelosdatosdela escenaencadainstanciadela aplicación,y notificaciónyreproduccióndelasmodificacionesquetenganlugarsobrecadaréplica.

Paraquela implementaciónenel editordelasfuncionesdeediciónsatisfagaestasdoscondicio-nes,esnecesarioquela operacióndeediciónseaaplicadaúnicamenteaunobjetoseleccionadolocalmente,deformaquesepuedaasegurarqueningúnotro usuariolo estámodificando.Porotro lado, es necesarioque todaslas modificacionesqueel usuariorealiceinteractivamentesobreel objetoseancomunicadasal restoderéplicaspresentesenla sesióncooperativa,y queesasoperacionesdeediciónseanrecreadasremotamente.


Capítulo7. Ediciónbásicacooperativa

La combinacióndeestasdostécnicas(bloqueoprevio delosobjetosaeditar, y envío delasmodificaciones)sonsuficientesparaqueel trabajocooperativo seaposible. En los próximosapartados,explicaremosla implementacióndecadaunadelasoperacionesbásicasdeedición,utilizandoestasdostécnicas.

7.2. Inser ción y borrado de objetos

La insercióny borradode objetostridimensionalessondosoperacionesquemodificanla es-tructurade la escena.Por estemotivo, esnecesarioconsiderarcon sumocuidadola imple-mentaciónde su soportecooperativo, de forma que las réplicasde la escenase mantenganconsistentes.El usuariopuedeinsertarobjetosen la escenadesdeficheroso basede datos,oborrarcualquierobjetogeométricode la escena.A continuaciónexplicamosla formaenquehemosimplementadola estasdosoperacionesenel editorcooperativo.

7.2.1. Inser ción de un objeto

Cuandoun objetotridimensionalescargadodesdeun ficheroo basededatos,comoseexplicaenla Sección5.4,segeneraunnuevosubgrafodeescena.Estesubgrafodebeseremplazadoenun lugarbajoel grafodeescenageneral.La posiciónenquesecoloquevariarádeacuerdoconunaestrategia predefinida.A continuaciónexplicamoslas dosestrategiasde emplazamientoquehemosdesarrolladoenel editor:

R La inserciónpuedetenerlugaren un lugarestándardel grafo de la escena.En la Sec-ción5.2explicábamoscomocadaescenacontieneunseparadorllamadoObjects, bajoelcualseinsertanlosobjetoscargados.El nuevo subgrafodeescenaesañadidocomohijoa esteseparador.

R La inserciónpuedetenerlugar tambiéncolocandoel subgrafode escenacargadobajoun nodode agrupacióndesignadopor el usuario.La forma de designarel lugardondeseinsertael nuevo objetoconsisteen seleccionarloprimero. El nuevo objetoseañadecomohijo al nododeagrupaciónseleccionado.

La insercióndel nuevo objetodebesernotificadaa las demásréplicasde la aplicación.Paraello seutiliza el eventoADD delprotocoloMu3D.Un eventoADD puedereferirseaunficheroen discolocal (claseFILE) o a unaconsultaa unabasededatospor mediodeInternet(claseURL). El mensajea enviar contieneel nombredel ficheroo URL quesedebecargar. En elmomentoderecibiresteevento,lasinstanciasremotasdeleditorlo recreanrealizandola mismaoperación,esdecir, la insercióndelobjetoreferenciadoporel evento.

7.2.2. Borrado de un objeto

El borradode un objetoesotra de las operacionesbásicasofrecidaspor el editor. El objetoseleccionadoesretiradode la escena,y colocadoenun espaciodealmacenamientotemporal,



llamadopapelera. A no serqueel usuariodecidarestaurarel objeto (como veremosen elCapítulo9), éstepermaneceráfueradela escena.

La implementacióndelsoportecooperativo parala operacióndeborradodebeserconside-radacon cuidado,ya queestaoperaciónmodificala estructurade la escena.Si un objetoesborradoenunainstanciadel editor, y no enotra,lasdosréplicasadquierendistintaestructura,y las rutasa los objetosquedaninconsistentes.Por tanto,unarutaquereferenciea un objetoenunainstanciapodríano existir enotra,dandolugaraerroresdeprograma.

Un requisitoimprescindibleparaborrarun objetoesqueningúnusuariolo tengaselec-cionadoenesemomento.Poderborrarun objetoseleccionadopor otro usuariodificultaríalainteracciónen el trabajocooperativo. Paraaseguraresacondición,el programarestringelacapacidadde borrar a objetosseleccionados.De estamanera,segarantizaqueningún otrousuariolo estámodificandoenel momentodeborrarlo.

La implementacióndelborradodeunobjetoconsistebásicamenteenmovereseobjetoa lapapelera.Estatécnicapermitequeel objetopuedaserrecuperadomástarde,si esnecesario.

La comunicaciónde la operaciónde borradoa las demásréplicasde la aplicacióntienelugarmedianteel envío del mensajeREMOVE del protocoloMu3D. Estemensajecontienelarutadelobjetoaborrar, demodoqueal serrecibidoencadaunadelasmáquinasqueejecutanlaaplicación,el editortieneinformaciónsuficientepararecrearlocalmenteel borradodel objeto.

7.3. Manipulación geométrica interactiv a

El editorpermiteeditarde forma interactiva los objetosgeométricosqueformanunaescena,por mediode los manipuladoresinteractivos. En estasecciónexplicamosla implementacióndel módulode gestiónde manipuladoresen el editor y suadaptaciónparael funcionamientoenel entornocooperativo.

7.3.1. Intr oducción a los manipuladores

Un manipuladorgeométricointeractivo esun componenteestándardeOpenInventorquepro-porcionaal usuariola posibilidadde modificar interactivamentela matriz de transformaciónqueafectaa un objeto.

El manipuladorcontieneunamatrizde transformación,y escapazde modificarel estadoglobaldela matrizgeométricadeOpenInventorcuandounaacciónlo atraviesa.Además,con-tienegeometríaquefuncionacomointerfazdeusuario,y haceposiblequesepuedamodificarestamatrizdetransformacióndeformainteractiva. Estamodificacióntienelugarmedianteelratón,haciendoclic y arrastrandolosdiferentescontrolesdel manipulador.

OpenInventordefinedistintostiposdemanipuladores.Cadaunodeellosofreceal usuarioun conjuntodistintodecapacidadesde interacción.Los tiposdemanipuladoresutilizadosenla aplicación,segúnlasfacilidadesdeinteracciónqueofrecen,sonlossiguientes:

S El manipuladorTransformboxpermiterealizartraslacionesy escaladossimétricossobreel objeto.



T El manipuladorHandleboxpermitela realizacióndetraslacionesy deescaladosasimé-tricossobreel objeto.

T El manipuladorJack permitela realizacióndetraslaciones,derotacionesy deescaladosasimétricossobreel objeto.

T El manipuladorTrackball permiterealizarrotacionesdeunobjetosobresupropiocentro.

T El manipuladorCenterballpermitela realizaciónderotacionesdeun objetorespectoaun puntocentraldefinibleporel usuario.

Figura7.1.:EjemplodemanipuladorCenterball.

7.3.2. Gestión de los manipuladores

La clase ManipMNG

Lasoperacionesrelativasal manejoy gestiónde los manipuladoreshansidoencapsuladasenunaclaseC++, llamadaManipMNG. Estaclaseseencargadegestionarlasoperacionesbásicasdemanipulacióninteractiva sobreun objeto,quesonla adicióny retiradadeun manipulador,y la propagacióndeloscambios.

Cadaescenacontienesupropiogestordemanipuladores,por lo quela claseManipMNGseráinstanciadaporcadanuevaescenacreada.

Adición de un manipulador

Un manipuladorseasociaaunobjetopormediodeunasustitución.El nododetransformaciónque contieneun objeto es sustituidopor el manipuladorcorrespondiente,que se colocaensu lugar, y recibelos valoresanterioresde la matrizde transformación.Estotienelugarpormediodeunallamadaal métodoreplaceNodedela clasedelmanipulador. Un esquemadeestasustituciónsepuedeobservarenla Figura7.2.



Encasodenoexistir ningúnnododetransformaciónenel objetoamanipular, el programacreauno nuevo antesde sustituirlopor el manipulador, y comunicaestamodificacióna lasdemásréplicasde la aplicaciónmedianteun eventoMu3D quecontieneel evento ADD, laclase“Transform”,y la rutaal objeto.

Separator


Manipulator

Figura7.2.:Sustitucióndeun nododetransformaciónporun manipulador.

Retirada de un manipulador

La retiradadeun manipuladorconsisteensustituiréstepor un nuevo nododetransformación,que heredalos valoresde la matriz de transformaciónincluida en el manipulador. Esto seconsiguemedianteunallamadaal métodoreplaceManipdela clasedel manipulador. Cuandoel manipuladoresreemplazado,esborradoimplícitamentedela memoria.

Propagación de los cambios

La adicióny la retiradadeunmanipuladorsonoperacioneslocales,quenonecesitansercomu-nicadasa lasdemásréplicasdela aplicación,ni reproducidasenéstas,ya quesólodebepoderutilizar el manipuladorquientieneseleccionadoel objeto.Por tanto,estasdosoperacionesnonecesitanseradaptadasparael trabajocooperativo y no generaránel envío de ningúneventoMu3D.

En cambio,todaslasmodificacionesprovocadaspor la manipulacióndel objetodebensercomunicadasa lasdemásinstanciasdel editor, demaneraquela matrizdetransformacióndelobjetoseaactualizadaencadaréplica.

El envío decadamodificacióntienelugardentrodeunafuncióncallback, queesllamadacadavezquela matrizde transformacióndel manipuladorsemodifica. La ejecuciónde estafunciónenvíaunmensajeMu3D detipo MODIFY y clase“Transform”,quecontienela rutaalnododetransformacióny el contenidoactualizadodeéste.



Cuandolasréplicasremotasrecibenestetipo demensaje,sustituyenel contenidodel nodode transformaciónpor el contenidoactualizadoquellega en el mensaje.De estamanera,lasecuenciadeoperacionesseguidaparamanipularun objetoseve reflejadainmediatamenteencadaunodelossitiosremotos.

7.4. Materiales

Los nodosde materialhacenquela escenaseavisualizadamostrandosuscaracterísticasdecolor, brillo, transparencia,etc. Un usuarioqueestétrabajandosobreunaconstrucciónpodrádistinguirmásfácilmenteentredistintoscomponentesdeésta(comoporejemplo,entrepuertasy paredes),si estoscomponentestienendistintocolor.

En estasecciónexplicamoslas facilidadesimplementadasen el editor parapermitir lamodificacióninteractivadelos materialesdeun objetoenla escena.Explicaremostambiénlaformaenquehemosimplementadoel soportecooperativo parala edicióndemateriales.

7.4.1. Intr oducción a los materiales

En términosde OpenInventor, llamaremosmaterial al conjuntode característicasquedeter-minanlosparámetrosdevisualización.Estascaracterísticascomprendenla intensidaddecadaunodelos parámetrosdecolor, quesonlossiguientes:

U Color difuso. El color propiodel objetoal queafectael material.

U Color ambiental. Color reflejadode un objeto en respuestaa la luz ambientalde laescena.

U Color especular. Color queesreflejadopor un objetoen respuestaa unailuminacióndirecta.

U Color deemisión. Color dela luz emitidaporunobjeto.

U Brillo . Gradodebrillantezdela superficiedeunobjeto.

U Transparencia. Gradodetransparenciadela superficiedeun objeto.

Todasestascaracterísticasseencuentranencapsuladasenformadecamposde un nodo. Estenodo,llamadonododematerial, modificael estadoglobalde visualización,sustituyendolosvaloresdelos atributospor losquecontiene.

OpenInventor proporcionaal programadorun componenteestándar, llamadoeditor demateriales. Estecomponenteestáimplementadode forma distintadependiendodel sistemaoperativo, e implementala interfazde usuarioparala edición interactiva de un nodode ma-terial. Comopodemosver en la Figura7.3, el editorde materialescontienedistintoscontro-les interactivosquepermitenmodificarcadauno de los camposintroducidosanteriormente.La implementaciónesrealizadaenformadeunaclaseC++, llamadaSoWinMaterialEditor, oSoXtMaterialEditor, segúnel sistemaoperativo. Además,OpenInventorproporcionaunaAPIsimplificadaparamanejarlos componentesdeedicióndemateriales.



Figura7.3.:Ejemplodeeditordemateriales.ImplementaciónparaWindowsNT.

7.4.2. Gestión de editores de materiales

Enesteapartadoexplicaremosla implementacióndeungestordemateriales,queseencargaderealizarlasoperacionesnecesarias,y deasegurarquesecumplenlosrequerimientosexplicadosanteriormenteparael funcionamientoenformacooperativa.

La clase MaterialMNG

Lasoperacionesrelativasa la gestióndelos editoresdematerialesseencuentranencapsuladasenunaclaseC++, llamadaMaterialMNG. Estaclasecontienelassiguientesoperaciones:

V Adición deun editordemateriales.

V Retiradadeuneditordemateriales.

V Seguimientodelasmodificacionesenel materialasociadoa un editor.

Existeun gestordematerialesasociadoparacadaescena,y por tanto,la aplicacióninstanciaun nuevo objetodela claseMaterialMNGparacadaescenaquesecree.

Adición de un editor de materiales

Paraqueel materialde un objetopuedasereditadocon el editorde materiales,esnecesarioasociarel nodode materialcon éste. Estotienelugar mediantela llamadaal métodoattach



del componente.Desdeel momentoen queestallamadaha tenidolugar, las modificacionesqueel usuariorealiceen la ventanadel editordematerialessereflejaránautomáticamenteenlos camposdel nodo de material,enlazadoscon los controlesdel editor. El esquemade laasociacióndeun editordematerialesaun nododematerialseilustraenla Figura7.4.

Separator


Material Editor

Figura7.4.:Enlacedeun editordematerialesconel nododematerialdeun objeto

Si el objeto cuyo materialse deseamodificar no contieneningún nodo de material,elprogramainsertauno bajo el separadordel objeto, y envía un mensajeMu3D a las demásinstancias,paraquereproduzcanla inserción.El mensajecontendráel eventoADD, la clase“Material” y la rutaal objeto.

Retirada de un editor de materiales

La retiradadeun editordematerialestienelugarmediantela rupturade la asociacióndeéstecon el nodode materialal queestabaasociado.Estotiene lugar por mediode unallamadaal métododetach del componente.La retiradade un editor de materialestiene lugar en lossiguientescasos:

W Cuandoel usuariolo solicitaexplícitamentemedianteunaopcióndemenú.

W Cuandola ventanadel editorsecierra.

W Cuandoel objetoal queel editordematerialesestabaasociadoesdeseleccionado.

El editorde materialesno esborradode la memoriaal serretirado. Un punteroa éstequedaalmacenadoenel objetodela claseMaterialMNG. Estoimplicaquenoseránecesariovolverloa instanciarparaasociarloa otroobjeto.



Propagación de las modificaciones

Del mismomodoqueen el casola adicióny retiradade manipuladoresinteractivos, la adi-ción y retiradade un editor de materialesno generanningúnmensajeMu3D, dadoquesonoperacioneslocales,queno debentenerrepercusiónenlasdemásinstanciasdel editor.

Encambio,lasmodificacionessobreun materialdebensercomunicadasa lasdemásrépli-casdela aplicación,deformaqueel materialmodificadoseaactualizadoentodasellas.

Los mensajessongeneradospor unafuncióncallback, queesllamadacadavezquetienelugar la modificacióndel material. En esemomento,se generaun mensajeMu3D de tipoMODIFY y clase“Material”, quecontienela rutaal materiala modificar, y los nuevosvaloresdeesematerial.Lasréplicasdeleditorquerecibanesemensaje,tendráninformaciónsuficienteparasercapacesdeactualizarel nodoapropiadoconlosnuevosvalores.

7.5. Iluminación de una escena

Unaescena3D no esdirectamentevisible si no seaplicaalgúntipo deiluminaciónsobreella.Existendistintosalgoritmosdeiluminación,queproducendiferentesefectosenel momentodevisualizarla escena.Segúnel algoritmoempleado,hablaremosdedistintostiposdeluces.

En estasecciónseexplica de quémanerasegestionala iluminaciónde unaescenaen eleditor, los distintostipos de lucesquese ofrecenal usuario,y las manipulacionesqueéstepuederealizarsobreellas. Explicamostambiénla implementacióndel soportecooperativo ala gestiónde la iluminación,de modoqueéstasemantengaigual en todaslas réplicasde laaplicación.

7.5.1. Intr oducción a las luces

Unaluz enOpenInventorserepresentacomounnododetipo SoLightquesecolocaenel grafoy modificala iluminacióndetodoslos nodosqueseencuentrenmása la derechay másabajo,segúnlos parámetrosquecontenga.OpenInventordefinetrestiposdelucesestándar:

X Las lucesdireccionales(DirectionalLights), tambiénllamadaslucesinfinitas, iluminandeformauniformeenunaúnicadireccióndeterminada,queno dependedesuposición.Un símil enel mundorealesla luz del sol.

X Laslucespuntuales(Point Lights) síocupanunaposiciónenel espacio3D,desdela cualemitenluz uniformementeen todasdirecciones.Sonun tipo de luz similar al de unabombillaesférica.

X Las lucesfocales(SpotLights) tambiénocupanunaposiciónenel espacio3D, y desdeesepuntoiluminanenunadireccióndada.El áreailuminadaformaun volumencónico.Suequivalenteenel mundorealsonlos focosdeunteatro.

Estostrestiposdelucesutilizanalgoritmosdeiluminaciónrelativamenterápidosquepermitensumodificacióny manipulaciónenunentornointeractivo. Esposibleasociarunmanipuladoracadaluz, deformasimilara losmanipuladoresgeométricos.Esdecir, el manipuladorsustituye



a la luz duranteel tiempoqueesmodificadainteractivamente,y enel momentoquesedejadeutilizar, vuelve a sersustituidopor la luz. Un ejemplode la interfazde los manipuladoresdelucessepuedever enla Figura7.5.

Figura7.5.:Aspectodeunaescenacontreslucesañadidas.

Los trestiposdelucespresentantambiéndiferenciasencuantoa velocidadderepresenta-ción,segúnsucomplejidad.Deestemodo,la luz direccionalesmásrápidadecalcular, yaquesólo implica calcularunadirección.La luz puntualimplica mástiempodecálculo,ya queseha de calcularun puntoy distintasdirecciones.Porúltimo, la luz focal esla queocupamástiempodetodas,yaqueademássedeberestringirel áreailuminada.

7.5.2. Localización de las luces en cada graf o de escena

Las lucesmanipulablespor el usuarioselocalizarántodasbajoel mismosubárbol,queestaráa la izquierdadel todo del grafo de la escena. Como se ha visto en la Sección5.2, cadaescenadispondrádesu propiogrupode luces. Estegrupoestáidentificadopor unaetiqueta,“M3DLights”, quepermitereconocerlocuandoseinsertaenla escenaun ficheroquecontengaluces,de maneraquetodaslas lucesgeneradaspor la aplicaciónen la escenaseencontraránjuntasenel momentodeeditarlas.

En el momentode insertarun objetoenunaescena,la aplicaciónbuscaenesteobjetounsubárbolquetengala etiqueta“M3DLights”. En casode encontrarlo,colocatodossushijosbajoel subárbolcomúndelucesdela escena,y despuéslo borra.

Cuandosedebeguardarunaescenaen disco, la aplicaciónguardajunto a la geometríael subárbolde las luces,tal comoseha explicadoen la Sección5.4. Aunquela iluminaciónde la escenasemantengaseparadade la geometría,esimportante,a efectosdevisualización,



queno seavolátil. Esdecir, quelos cambiosde iluminaciónsepuedanguardarentresesionescooperativas.

7.5.3. Gestión de las luces

Explicamosa continuacióncómosegestionanlas operacionessobrelas lucesde la escena.EstasoperacionesseencuentranencapsuladasenunaclaseC++, e incluyenla adicióndeunaluz, la manipulación,el borradoy la edición.

La clase LightMNG

Todaslas operacionesreferidasa luces,así como un conjuntode datosnecesariosparasugestión,se encuentranimplementadasdentrode una claseC++, llamadaLightMNG (LightManager). Existeun gestorde lucesparacadaunade las escenasen el editor, y por tantoestaclaseseinstanciarátantasvecescomoescenassecreen.Lasaccionesquela clasepermiterealizarsobrelaslucessonlassiguientes:

Y Adicióndeunaluz. Introduccióndeunanueva luz enla escena.

Y Manipulacióndeunaluz. Modificaciónvisualinteractivadeunaluz.

Y Borradodeunaluz. Eliminacióndeunaluz dela escena.

Y Edicióndeunaluz direccional. Edicióninteractivadeunaluz direccional,conla ayudadeun componenteestándar.

Cadaunade las accionesposiblessobreunaluz seha implementadoteniendoen cuentalosaspectoscooperativosdela aplicación.Enlossiguientesapartadosveremoslasoperacionesquehemosimplementadoparaejecutarcadaunadeestasacciones,asícomoel soportecooperativodesarrolladoparacadaunadeellas.

Adición de una luz

Cuandoun usuarioordenaal programaañadirunaluz deun determinadotipo, debenrealizar-seunaseriede operaciones.Éstasdebengarantizarqueestaadiciónesposible,y quetienelugar en todaslas réplicasde la aplicaciónqueseejecutansimultáneamente.Enumeramosacontinuaciónlasoperacionesquetienenlugar.

En primer lugarsecompruebaqueesposibleañadirunanueva luz al grafodeescena.Esdecir, si esposiblecrearun nodomás.La creacióndeéstetienelugardeformadinámica,yaqueel tipo del nodoespasadocomoparámetroa la funcióndeadicióndela luz.

Cuandoel nuevo nododeluz hasidocreado,esañadidocomohijo al grupodelucescorres-pondientea la escenaadecuada.Durantela adicióndelasluces,la aplicaciónvacolocandolosnuevosnodosensecuenciacomohijos del mismonododeagrupación,deformaquela últimaluz añadidaesel último hijo del grupodeluces.

Si la adicióndeunaluz hatenidolugardeforma local (esdecir, hasidoresultadodeunaordendel usuariodela instancialocal dela aplicación),éstasecomunicaa lasdemásréplicas



remotaspresentesen la sesiónmedianteel envío deun mensajeMu3D conel eventoADD yla claseLIGHT. Las demásréplicasejecutaránexactamentela mismafunción, con la únicadiferenciade queno enviaránningúnmensajepor la red. El envío o no de un mensajeestáparametrizadoenla funcióndeadicióndela luz.

Por último, la aplicaciónañadeun manipuladora la luz reciénañadida.En el próximoapartadoveremoslospasosquesesigueparaañadirun manipulador.

Manipulación de una luz

Por“manipulacióndeunaluz” entendemosel hechodepermitir al usuariomodificarinteracti-vamentelosparámetrosdeunaluz medianteun manipulador. El manipuladordeunaluz esunnodo,deunaclaseespecialderivadadeSoLight. Estenodocontienegeometríaqueproporcionaunainterfazdeusuarioparamanipularla luz, a la quesustituye.Un esquemadela operaciónde sustituciónsepuedever en la Figura7.6. En el momentode sustituirel manipuladordenuevo, los valoresmodificadospasanotravezal nododeluz original.

La adicióny retiradadeun manipuladorde lucesson,al igual quela adicióny retiradadeun manipuladorgeométrico,operacioneslocalesqueno requierenel envío demensajesMu3Dde insercióno borrado.No obstante,la manipulaciónde unaluz seconsideraunaedición,ycomotal, setratade forma análogaa la ediciónde cualquiernodode geometríaselecciona-do. La diferenciaconla seleccióndeun nodogeométricoseencuentraenla imposibilidaddeseleccionarla luz medianteunapulsacióndel ratón. Porestemotivo, no sesiguenlos pasosquecorresponderíana unaselecciónestándar(explicadosen el Capítulo6), sino queseen-víandirectamentelos mensajesMu3D deseleccióny deselección(conlos eventosSELECTyDESELECT)enel momentodeasociarun manipuladora unaluz y deretirarlo.

Lasmodificacionesenlosparámetrosdeunaluz queresultandesumanipulaciónsonenvia-dasa los demásmiembrosdela sesióncooperativa. Paraqueestoseaposible,el manipuladorestáasociadoa unafunción callback, queesllamadacadavezquetengalugarun cambioenalgunodelos camposdela luz. Estafuncióncallback seencargadeenviar un mensajeMu3Dde modificaciónde la luz, con el evento MODIFY y la claseLIGHT, conteniendolos nue-vos valoresde la luz, a todaslas réplicasde la aplicaciónpresentesen la sesióncooperativa.Cuandoéstasrecibanel mensaje,asignaránlos nuevosvaloresal nododeluz adecuado.

Borrado de una luz

El borradode unaluz equivale a eliminar el nodoasociadodel grafo de escena,retirándolodel subgrafode luces. El métodoencargadode estaoperaciónseocupade realizardiversascomprobaciones,la másimportantedelascualesseaseguradequela luz no estásiendomani-puladao editadaremotamente(entérminosdenuestroeditor, quenoestéseleccionadaporotrousuario).Estosehacemedianteunaconsultaa la lista deobjetosseleccionadosremotamente,explicadaenel Capítulo6, quetambiéncontienelasluces.

Unavezcomprobadoquela luz no estáseleccionadaremotamente,el métododeborradoretira,si existen,el manipuladory el editordelucesasociadoaésta.A continuación,esenviadoun mensajeMu3D, con el evento REMOVE, la claseLIGHT y la ruta a la luz, a todaslas



Lights subtree

Light 1 Light n

Manipulator

Figura7.6.:Sustitucióndeunaluz porun manipulador.

réplicasremotasparaqueeliminena suvezla luz desusgrafosdeescena.Finalmente,la luzeseliminadadela escena.

Edición de una luz direccional

OpenInventordefineun componenteestándar, dependientedel sistemaoperativo, queimple-mentaunainterfazdeusuarioquepermiteeditarinteractivamentelos parámetrosde las lucesdireccionales.Estecomponente,llamadoeditor de lucesdireccionales, es implementadoenformadeunaclaseC++, llamadaSoWinDirectionalLightEditor o SoXtDirectionalLightEditor,segúnel sistemaoperativo. En el editorutilizamosestecomponenteestándarparapermitirqueel usuariopuedaeditarla dirección,la intensidady el color de la luz direccionalde la formaqueprefiera.

La adiciónde un editor de lucesdireccionalestienelugar mediantela asociaciónde éstea un nodode luz direccional.Los camposde la luz quedaránasociadosa los controlesde laventanadel editor, y cadamodificaciónsobreéstosesreflejadaenla escenainstantáneamente.Pararetirarun editordelucesdireccionales,serompela asociacióndeésteconel nododeluz.

La adicióny retiradadeun editordelucesdireccionalesno implicanla inclusióno retiradadeningúnnodoen las réplicasremotasde la escena,y por tanto,no seenvía ningúnmensajeMu3D deinsercióno retiradaal restodelasréplicas.

No obstante,debemosteneren cuentaque,al igual queunamanipulación,editarunaluzdireccionalimplica la necesidadde unaexclusión mutuaentrelos usuarios,de maneraquedesdeel momentoen queseeligeunaluz direccionalparaeditar, seestáseleccionandoésta,y ningúnotro usuariodeberápoderseleccionarlahastaquequienla tienela deseleccione.Portanto,la adicióny retiradadeun editordelucesdireccionalesprovocaráel envío demensajesMu3D deseleccióny dedeselección(conlos eventosSELECTy DESELECT).

Lasmodificacionesproducidassobrela luz direccionalasociada,medianteel usodeleditor,



soncapturadaspor unafuncióncallback, quesellamacadavezquetienelugarunamodifica-ción. Estafunciónseencargadeenviar loscamposmodificadosatodaslasdemásinstanciasdela aplicación,enformadeunmensajeMu3D quecontengael eventoMODIFY, la claseLIGHTy los nuevosvalores.Cuandolas instanciasremotasrecibanestemensaje,sobreescribiránlosvaloresdelnododeluz apropiadoconlosquecontieneel mensaje.Deestamanera,seasegurala coherenciaentrelasdistintasréplicasdela escenaentodaslasinstancias,tambiénenlo querespectaa los parámetrosdeiluminación.


8. Por tapapeles cooperativ os

Lasoperacionesdeportapapelesconstituyenunametáforamuy frecuenteparala transferenciadedatosenlasaplicacionesinteractivas,y enconcretoenaquellasconinterfazgráficadeusua-rio. Estasoperaciones,llamadascortar, copiar y pegar, operansobreun espaciodememoria,llamadoportapapeles,dondesepuedencolocardatosdela aplicación(mediantelasoperacio-nesdecortary copiar),y desdedondesepuedeninsertardenuevo (mediantela operacióndepegar). La mayoríade estándaresde interfacesde usuarioutilizan de unamanerau otraestametáfora([IBM92],[Mic95]).

8.1. Requerimientos

La implementaciónde las operacionesde portapapelesno implica un problemaespecialenaplicacionesdestinadasaunsolousuario.Suformamássencillatienelugarmediantela gestiónde un buffer de memoria. Sin embargo, en una aplicacióncooperativa, esnecesarioque laimplementacióndelosportapapelescumplaunaseriedecondiciones:

Z Porunlado,esnecesariocomunicarloscambiosproducidosporlasoperacionesdeporta-papelesenla escenaatodaslasdemásréplicasdela aplicación,paraquelosreproduzcan,yaquesedebemantenerla coherenciaentrelasmúltiplescopiasdecadaescena.

Z Por otra parte,y siguiendola filosofía básicade enviar las modificacionesen formade mensajeslo máspequeñosposible,no nos interesaenviar el contenidoíntegro delos datosque se han de copiar, cortar o pegar, debidoal alto tráfico de red que elloprovocaría. Por otra parte,en el casode objetosmuy voluminosos,el envío de todoslos datosexigiría la subdivisión deéstosentrozos,con la problemáticaqueestopuedeprovocar1.

8.2. Estructuras de datos

Siguiendolas doscondicionesintroducidasen la secciónanterior, hemosimplementadounaestructurade datosreplicadaparacontenerlos portapapelesde cadausuario. La aplicaciónmantieneun subárbolespecialdestinadoúnicamentea los portapapeles, comoseexplica enla Sección5.2. Estesubárbolcontieneun portapapelespor cadausuariopresenteenla sesión.Deestamanera,cadainstanciadela aplicacióncontienelosportapapelesdetodoslosusuarios

1Comopor ejemplo,la interdependenciadeunosmensajesrespectoa otros.


Capítulo8. Portapapelescooperativos

en cadamomento,y el contenidode éstossedebemantenersiemprecoherenteen todaslasinstancias.

Los subárbolesdel subárbolde portapapelescorrespondientesa cadausuariorecibenelnombredel identificadordeusuariocorrespondientea la sesión.De estaforma, la aplicaciónescapazdeaccederal portapapelesdecualquierusuariomedianteel identificadordeéste.

La implementacióndecadaunadelasoperacionesdeportapapelessobreestaestructuradedatosvienedadaenfuncióndela tareacooperativaa realizar.

8.3. Implementación de las operaciones

Lasoperacionesdeportapapelesimplementadashansidolastresmásusuales,esdecir, cortar,copiary pegar. Sehadesarrolladounatécnicapropiaparalasoperacionesdecopiary depegar.La implementacióndela operacióndecortarseharealizadosiguiendosuesquemaconceptual,en formadeun operaciónde copiar, seguidadeun borradodel objeto(de la formaexplicadaenla Sección7.2).

8.3.1. Sopor te cooperativ o

Para la implementaciónde la técnicade portapapelescooperativos,hemosimplementadounnuevo tipo de evento Mu3D, llamadoCLIPBOARD, que puedeser de dos clasesdistintas:COPYy PASTE. Cadavezqueel contenidodel portapapelesde un usuariocambia(esdecir,cuandotienelugarunaoperaciónde cortado,copiadoo pegado),la instancialocal del editorenvía un mensajeMu3D detipo CLIPBOARD, demaneraquecadaunadelasdemásréplicasreproduzcala modificaciónadecuada.Los camposdeestenuevo mensajecontieneninforma-ción suficienteparareproducirla operación.Estossonlos siguientes:

[ El identificadordelusuarioqueenvía el mensaje.

[ La ruta quellevaal objetoafectado.

[ El tipo deoperacióna realizar(copiaro pegar).

A nivel deprotocolo,no tienesentidoimplementarun mensajeespecialparala operacióndecortar, ya que quedacubiertaal subdividirla en dos operacionesatómicas:copiar y borrar.La atomicidadde la función de cortar no quedacomprometida,dadoque tiene lugar sobreun objetoseleccionadopreviamente,y por tanto,no hay peligro de quela operaciónde otrousuarioseintercaleentrelasdospartesdelasqueconsta.

Explicamosacontinuacióncómohemosimplementadolasoperacionesdecopiary pegar.

8.3.2. Implementación de la operación de copiar

La aplicacióndela operacióndecopiartienelugarsobreun objetoseleccionadopreviamente.En rigor, noseríanecesariobloquearel objetopararealizarunaoperaciónque,dehecho,no lomodifica.Sinembargo,dadoqueno existeenel editorningunaotraformadeindicarel objeto



destinodeunaoperación,y queunaoperacióndecopiapuedeir seguidadeunborrado(enunaoperacióndecortar),hemosmantenidoestarestricción.

Cuandoun usuarioquierecopiarel objetoseleccionadoal portapapeles,la instancialocaldel programacolocaunacopiaen el portapapelescorrespondienteal usuariolocal. A conti-nuación,envía un mensajeMu3D detipo CLIPBOARD y declaseCOPYconla rutaal objetoa copiara las otrasinstanciasde la aplicaciónen la sesióncooperativa. En el momentoqueunainstanciaremotadel editor recibeun mensajede esetipo, accedeal portapapelescorres-pondienteal usuarioqueenvía el mensaje,medianteel identificadorqueéstecontiene,y añadeesteobjetoa esteportapapeles.

8.3.3. Implementación de la operación de pegar

Cuandoun usuarioquierepegar el objetoquehay en su portapapeleslocal en la escena,lainstancialocaldeleditorinsertaenla escenaactivaunacopiadelcontenidodesuportapapeles.A continuación,seenvía un mensajea todoslos demásmiembrosen la sesióncooperativa.Cuandouna instanciaremotadel editor recibeun mensajede tipo CLIPBOARD y de clasePASTE,accedeal portapapelesquecorrespondeal usuarioquehaenviadoel mensajey colocaunacopiadesucontenidoenla escenaactiva.

El lugardondesedebepegarel objetoestáindicadoenel contenidodel mensaje,deformaqueel usuariopuedeelegir enquéposicióndela escenacolocael objeto.Paraello, disponededosopcionesdemenú:Paste(con lo queel objetoseañadiráa la escenaenunalocalizaciónestándar)y Pasteunderselection(conlo queel objetoseañadiráa la escenacomohijo deunnododeagrupaciónseleccionado).

El contenidodel portapapelesno eseliminadoconla operacióndepegar, deformaquesepuederepetirestaoperacióntantasvecescomodeseeel usuario,y enlos lugaresdela escenaqueésteelija.

B A B A

Mensaje Mu3D

Usuario A Usuario B

Figura8.1.:Pegadodel contenidodelportapapelesdelusuarioA.



8.4. Conc lusión

En la implementaciónde la técnicade portapapelesreplicadosquehemosdesarrollado,losmensajesMu3D enviadosdurantelasoperacionesdecopiary pegarno incluyenel contenidoíntegro del portapapeles.Debidoa ello, la sobrecarga de la red esmínima. De hecho,cadaoperacióndeportapapelesgeneraráel mismotráficodered,independientementedel volumendedatosa transferir.

La contrapartidaa estabajaocupacióndel recursoderedseencuentraenla memoriaextraqueesnecesarioocuparparamantenerel subárboldeportapapelescooperativos. Estesubár-bol puedecontenerun volumende datosmuy grande,segúnel tamañode los objetosqueunusuariotransfieraal portapapeles,y estaocupaciónextra dememoriatendrálugarentodaslasinstanciasde la aplicación. No obstante,dadoqueuno de los recursosmáscríticosen unaaplicacióndistribuiday cooperativaesel anchodebanda,y quela memoriatieneunbajocosteenla actualidad,podemosafirmarquenuestrasoluciónessatisfactoria.

El desarrollode estatécnicade portapapelesreplicadosen cadainstanciadel editor nospermite,por tanto,mantenerunafuncionalidadde portapapelesquefuncionede forma coo-perativa, siguiendolas directricesbásicasquedebecumplir todaoperaciónen nuestroeditor(mantenimientode la coherenciaen todaslas réplicas),y con muy pocasobrecarga de men-sajesasociada,ya quela aplicaciónno necesitaenviar el contenidode los portapapeles,sinosolamentesuidentificador.


9. Vuelta atrás en un entorno cooperativ o

9.1. Intr oducción

La vueltaatrás1 esunade las operacionesmásfrecuentesen cualquieraplicacióninteractivamoderna.Suimplementaciónconstituye,por tanto,un requerimientoparanuestroeditortridi-mensional,requerimientoqueademáshasidosolicitadopor lossociosusuariosdel proyecto.

La implementaciónde la vueltaatrásen unaaplicaciónestándarmonousuariopuederea-lizarsede forma sencillamediantela implementaciónde estructurasde datosde tipo lista opila. Estaslistaspuedencontenerla historiade los estadosde los datos,o bien la historiademodificacionessobrelosdatosdeusuariodel programa.

Sin embargo, la vueltaatrásen un entornocooperativo no esunatareatan sencilla. Sedebedefinir un cierto“protocolodefuncionamiento”,o “etiqueta”,queno conviertael entor-no cooperativo en un “entornocompetitivo”. Respectoa esta“etiqueta”,hemosdefinidodosrestriccionesbásicas,quesepuedenenunciardela siguienteforma:

\ Un usuariono debepoderdeshacerlasmodificacionesrealizadaspor otro usuario.Te-niendoen cuentaqueestamosen un entornocooperativo, si un usuariodeshacelo queotrohahecho,estopuededarlugaral efectocontrarioala cooperaciónquedeseamosennuestraaplicación.

\ Ademásdelasmodificacionesajenas,deshacerlasmodificacionespropiassobreunobje-to no estarápermitidosi otrousuariolo hamodificadoposteriormente.Estonosllevaríaal mismocasoqueel puntoanterior, ya quevolver a un estadoanteriora nuestrasmo-dificacionessignificaríainvalidar lasmodificacionesposterioresrealizadasen la escenaporotro usuario.

Ademásdelasrestriccionesinherentesa la vueltaatráscooperativa,dadoqueéstatienelugarsobreoperacionesdeedición,debecumplir lasmismascondicionesqueel restodeoperacionescooperativasimplementadas.Por tanto,cualquiercambio,ya seahaciadelanteo haciaatrás,debesercomunicadoa todaslasdemásinstanciasdeleditor, deformaquetodaslasréplicasdela escenaesténactualizadas.

Estasrestriccionesresultanrelativamenteseveras,ya querestringenla operacióndevueltaatrása un ámbitomuy concreto. Sin embargo, éstasno debenimpedir que los usuariosdel

1LlamadanormalmenteUndoen la terminologíaanglosajona,lo quesetraducegeneralmentepor el verbo“des-hacer”. Nosotrosusaremosestetérminocuandousemosla forma verbal,y el término“vuelta atrás”cuandoutilicemosel sustantivo.


Capítulo9. Vueltaatrásenun entornocooperativo

programatenganla posibilidadde volver atrásenun momentodado,ya seaparavolver a unestadoanteriordespuésdeunaoperacióndeprueba,o bienparadeshacerun eventualerror.

Enestecapítuloexplicamosla soluciónquehemosimplementado,demaneraquesepuedallegaraunequilibrioentreestosdosfactoresopuestos:porun lado,lasrestriccionesquedebencumplirseenel entornocooperativo, y porel otro, la posibilidadderealizarla mayorcantidadposibledeoperacionesde“deshacer”.

Hemosde hacernotar que nuestroobjetivo no ha consistidoen diseñarningún entornogeneralparadeshaceroperacionesenentornoscooperativos,al estilo de lo queseexplica en[Pra92] y [Pra94]. Másbien,hemosqueridodesarrollarunasoluciónconcretaa un problemaconcreto. Estasolución,no obstante,ha sido pensadaparaque puedaser extendida,comoveremosmásadelante.

Lasoperacionescorrespondientesala vueltaatráshansidoencapsuladasenunaclaseC++,llamadaUndoMG(UndoManager). Estaclasecontienetodaslasestructurasdedatosdefinidasmásadelante,y defineunaAPI paraquepuedaserinvocadadesdeel editor. Cadaescenaestáasociadaconunainstanciadeestaclase.

9.2. El concepto de ámbito

Paraquela implementaciónde la operaciónde vueltaatrásseaposible,hemosdesarrolladoun nuevo concepto,quehemosdenominadoámbito. Esteconceptosedefinede la siguientemanera:

Llamaremosámbitoa un conjuntodeoperacionessobreun objetoquepuedenserrevertidaspor un usuarioenun momentodado.

En un determinadomomento,un usuariopuedeencontrarsedentrode ceroo másámbitos,ysóloserácapazdedeshaceraquellasoperacionesrealizadasdentrodelosámbitosenlosqueseencuentre.Comosedesprendedela definiciónanterior, cadaámbitollevaasociadoun objeto,sobreel cualsehanaplicadolasoperacionesquesepuedendeshacer. Cuandoel usuariosaledeunámbito,medianteunacondicióndesalida,yano puedevolvera él.

Operaciones a aplicarCondiciones de entrada Condiciones de salida

Ámbito

Figura9.1.:Esquemabásicodeunámbitodevueltaatrás.

Cadaunode los ámbitostieneunaseriedecaracterísticaspropiasquelo definen,enbasea los cualesdescribiremoslosdistintostipos. Un esquemaqueilustrala interrelaciónentrelas



característicasde un ámbitosepuedeobservar en la Figura9.1. Estascaracterísticassonlassiguientes:

] Un conjuntodeoperacionesquesepuedendeshacerdentrodeun ámbitosobreel objetoasociadoa éste.

] Un conjuntodecondicionesdeentrada, quedefinenenquémomentoel usuarioentraenun ámbito.

] Un conjuntodecondicionesdesalida, quedefinenenquémomentoel usuarioabandonael ámbitoenel queestaba.

Paradefinir quéámbitossonnecesariosparanuestraaplicación,hemosempezadodefiniendoquéoperacionessedebenpoderdeshacer, y hemosidentificadolassiguientes:

] Edición de un objeto. Las operacionesde ediciónpuedencomprenderla modificacióndesumatrizdetransformacióngeométrica,los parámetrosdevisualizacióno la modifi-cacióndealgunodesuspuntos.Todasestassonoperacionesquetienenlugarsobreunobjeto,duranteel periodoenqueestáseleccionado.

] Insercióndeunobjetoenla escena.Comohemosexplicadoenla Sección7.2,unainser-cióncolocaunaseriededatosgeométricosenla escena,bienenunlugarpredeterminado,o bienbajoel objetoseleccionado.

] Borradodeunobjetodela escena.Comoexplicamosenla Sección7.2,unborradoretiradela escenael objetoseleccionadoenesemomento.

Basándonosenestosgruposdeoperaciones,hemosdefinidotresgrandesámbitos,queexpli-caremosa continuación.Estossonel ámbitodeselección, el ámbitode inserción y el ámbitodeborrado.

9.2.1. El ámbito de selección

El ámbitode selecciónseapoyaen el conceptode selección,explicadoen el Capítulo6. Enéstecapítulohemosexplicadoqueun usuarioesel único propietariode un objetodesdequelo seleccionahastaquerealizaunadeselecciónsobreél. Por tanto,si el usuarioseencuentradentrodel ámbitodeselección,el conjuntodeoperacionesquesepodrándeshacerserántodaslasrealizadasdesdeel momentodela selecciónhastael momentoactual.

Definimosa continuaciónel ámbitode selecciónen términosde suscaracterísticas(con-junto deoperaciones,condicionesdeentraday condicionesdesalida).

El conjuntodeoperacionessobreunobjetoseleccionadoqueel editorescapazdedeshacercomprendelossiguientestipos:

] Modificaciónde la transformacióngeométricade un objeto,ya seamedianteun mani-puladorinteractivo,o bienmedianteun menúcondatosnuméricos.



^ Modificacióndelosparámetrosdevisualizacióndel objeto.

^ Modificacióndeun conjuntodevérticescoplanaresdel objeto.

El conjuntode condicionesde entradase reducea la selecciónde un objeto. El hechodeseleccionarun objetohacequeel ámbitodeselecciónseenfoquehaciaesteobjeto.

El conjuntodecondicionesdesalidaestáformadopor lassiguientes:

^ La deseleccióndelobjetoasociado.Unavezqueel usuariodeseleccionaunobjeto,todaslasoperacionesquehayarealizadosobreéstedesdeel momentodesuselecciónquedanconfirmadas,y no seráposibledeshacerlas.

^ La selecciónde un objeto distinto al actual. Hemosvisto en el Capítulo6 como laselecciónde un objetoimplica automáticamentela deseleccióndel objetoquepudieraestarseleccionadoanteriormente.

^ El borradodel objetoasociado.En el momentodeborrarel objetoasociadoa la selec-ción, todoel conjuntodeoperacionesrealizadassobreéstedejadeestaralmacenado,yaqueno tienesentidodeshacerlas.

9.2.2. El ámbito de inser ción

El ámbitodeinserciónsirveparaqueel usuariovuelvaatráseninsercionespropiasdeobjetosen la escena.Estoesmuy útil paracorregir erroresqueconsistanen la insercióndeun objetoequivocado.

El conjuntodeoperacionesqueesposibledeshacersereducea unasolainserciónsobreelobjetoasociado.

La condicióndeentradaenesteámbitoesla inserciónpropiadeunobjetoenlaescena.Estopuedetenerlugarexplícitamente,utilizandoun comandode inserción,o bien implícitamente,medianteunaoperacióndepegadodesdeel portapapeles.

El conjuntodecondicionesdesalidadeesteámbitoestáformadopor lassiguientes:

^ La insercióndeotroobjetoenla escena,realizadalocalmente.Enestemomento,sesaledel ámbitodeinsercióndel objetoanterior, paraentrarenel ámbitodeinsercióndeotroobjeto.

^ La modificacióndel objetoinsertado.Unavezel objetohasidomodificado,no sepuedevolveratrásensuinserción.

^ El borradodel objeto insertado.Estoesobvio, ya quedejade existir el objeto,y portantosuinserciónno puedeserrevertida.

Hemosrestringidoel conjuntodeoperacionesquesepuedendeshaceraunasolainserción,pormotivosdesencillezdegestión.La insercióndeun objetomodificala estructuradel grafodeescena,asícomolos índicesde lasrutasdelos demásnodos,conlo queextenderla operativaa sucesivasinsercionespuedesercomplejo.



9.2.3. El ámbito de borrado

El ámbitode borradoserviráparaqueel usuariovuelva atrásen casode eliminacionesacci-dentalesdeun objeto.

El conjuntodeoperacionesquesepuedendeshacerenesteámbitosereduceúnicamentealúltimo borrado.

La condicióndeentradaúnicaparaesteámbitoesla eliminacióndela escenadeunobjetocualquiera,yaseamedianteunaordenexplícita,o bienmedianteunaoperacióndeportapapeles(la operacióndeCortar).

El conjuntodecondicionesdesalidaparaesteámbitocomprendelassiguientes:

_ La insercióndeunobjetocualquiera.

_ El borradodeun objetocualquiera.

Por motivosde sencillezde gestión,hemosrestringidoel conjuntode operacionesal últimoborrado.Debemostenerencuentaque,al igual queenel casode la inserción,la eliminaciónde un objetomodificala estructuradel grafo de escenaquelo contiene,asícomolos índicesdelasrutasquellevananodosvecinosal objeto.Estasmodificacionessecomplicaríanmáseneliminacionessucesivas.

9.3. Almacenamiento del estado previo

Parapoderdeshacerunamodificación,sealmacenael estadoanteriorde la escena.En estasecciónexplicamosquéinformaciónesguardada,enquéestructuras,y enquémomento.

9.3.1. Almacenamiento del estado previo en el ámbito de selección

El conjuntode operacionesquesepuedendeshacersobreun objetoseleccionadocomprendeen la actualidadmodificacionessobrela matriz de transformación,el materialy el conjuntode vértices.Parapodercontemplarestosdistintostiposdeoperacionesy paraquesepuedanañadirnuevos tipos de operacionesen nuevasversionesdel editor, la implementaciónde lavueltaatrásdentrodeesteámbitoseharealizadoporseparadoparacadatipo deoperación.

La aplicaciónmantieneunconjuntode listasdeestado, unaporcadatipo deoperación,enlascualessealmacenael estadodeunobjeto.La agrupaciónendistintaslistassiguecomocri-terio la característicaqueuntipo deediciónpuedemodificarsobreunobjeto.Así, semantieneunalista con lasmatricesde transformacióndel objeto,otracon los materiales,y otra conelsubconjuntodevérticesmodificados,antesdeproducirsela modificación.

Ademásdemantenerunalistaconcadacaracterísticaamodificardel objeto,sedisponedeunalista maestra, a la queel programaconsultarácuandoel usuarioquieradeshacerla últimaoperación. Esta lista indica el tipo de modificacionesque se han realizadosobreel objetoen cadamomento,de maneraqueesposibledeterminarde quétipo fue la última operación,parapoderaccedera la lista adecuada.Un ejemplodel estadode las listassepuedever en laFigura9.2.



T`

T`

T`

T`

T`

M M MV V V

Transformaciones

Materiales

Vértices

Lista maestra

Figura9.2.:Listasdeestadoutilizadasparala vueltaatrás.

Todaslas listassonvaciadascadavez queel usuariorealizaunanueva selección.Cadavezqueserealizaunaoperaciónatómicadeediciónsobreel objetoseleccionado,seañadeunelementonuevo a la lista,conel estadoanteriora la operación.

Debemosdefinir quéconsideramosunaoperación atómica, ya queestonosindicaráquégranularidadtendrála vueltaatrás. Las operacionesatómicasqueconsideramosson las si-guientes:

a El inicio de manipulacióninteractiva de un objeto. Es decir, el momentoen que unusuariopulsasobreun objetoparaempezara modificarlo.

a La modificaciónmediantemenúnuméricodealgúnvalordela matrizdetransformacióngeométricadeunobjeto.

a La aperturadeunaventanadel editordemateriales.

a La modificacióndeunoo másvérticesdel objeto.

De estemodo,cadavez queel objetoesmodificado,tienenlugar las siguientesoperacionessobrelaslistas:

a El estadoprevio a la modificaciónesañadidoa la lista de estadosapropiada,según eltipo demodificación.

a El tipo demodificaciónesañadidoa la listamaestra.

9.3.2. Almacenamiento del estado previo en el ámbito de inser ción

Losdatosalmacenadosenmemoriacuandoel programaseencuentraenel ámbitodeinserciónsirvenparapoderdeshacerla inserciónrealizada,y consistenbásicamenteenunpuntero haciael objetodentrodel grafodeescena,demaneraqueseaposibleborrarlo.

Sealmacenael punteroal último nodoinsertado,envezdela rutaquellevaa éste,debidoa la posibilidaddequelosíndicesdela rutacambien,acausadela insercióno borradodeotrosnodosenel grafodeescena.Si seguardael puntero,suvalorpermaneceinvariableaunquesemodifiquevariasvecesel grafodeescena.



Los datossoninvalidados,asignándolesun valor nulo, enel momentoqueseabandonaelámbitodeinserción.

9.3.3. Almacenamiento del estado previo en el ámbito de borrado

Losdatosalmacenadoscuandoel programaseencuentraenel ámbitodeborradopermitenqueel último borradosepuedadeshacer. Estosdatossonlos siguientes:

b Una copiadel objetoborrado,situadoen la papelera del usuariolocal (descritaen laSección5.2).

b La ruta haciael nodopadredelobjeto.

b La posicióndel objetobajoel nodopadre(esdecir, si erael primerhijo, el tercero,etc.).

Una copia de las papelerasde cadausuarioes mantenidabajo un subárbolespecial. Cadainstanciadel editorcontienetodaslaspapelerasdelos usuariosenla sesióncooperativa.Estaspapelerassonactualizadascadavezquetienelugarel borradode un objetoen cualquieradelasinstanciasdela aplicación:

b Cuandotienelugarla eliminaciónlocaldeunobjeto,unacopiadeésteescolocadaenlapapelera local correspondientea eseusuario.

b Si la eliminacióndel objetoesrealizadaporotro usuario,la copiadel objetosecolocaráenla papeleracorrespondienteal usuarioqueharealizadoel borrado.

En el momentodeabandonarel ámbitodeborrado,la papeleralocal esvaciada,y el restodedatossoninvalidados.

9.4. Realización de la vuelta atrás

Un usuariopuededeshacerla última de las operacionesrealizadasen el ámbitoen el queseencuentre.Enestasecciónexplicamoslospasosaseguir encasoderealizarla vueltaatrásparacadaunodelosámbitosconsiderados.

9.4.1. Realización de la vuelta atrás en el ámbito de selección

Cuandounusuarioseleccionael comando“Deshacer”dentrodeunaselección,tienenlugarlassiguientesacciones:

b Consultaenla lista maestradel tipo del último cambiorealizado.

b Restauracióndelosvaloresdela listadeestadoapropiadadentrodelobjetoseleccionado,y retiradadela listadel estadoantiguo.

b Retiradadela listamaestradel tipo dela última acción.



c Envío dela modificacióna lasdemásréplicasdela aplicaciónenla sesión,medianteunmensajeMu3D detipo MODIFY, y dela clasecorrespondienteal tipo demodificación.Estemensajecontienelos valoresa restaurar.

Mantenerunalistadecadatipo demodificaciónrealizadasobrela selecciónactivahaceposiblequesepuedair volviendoatrásen todaslas modificacionesde los tipos mencionados,hastallegaral momentoenquesehaseleccionadoel objeto.

9.4.2. Realización de la vuelta atrás en el ámbito de inser ción

Cuandounusuariosolicitadeshacerlaúltimaoperacióndeinserción,tienenlugarlossiguientespasos:

c Seleccióndel último objetoinsertado,paraevitar queseamodificadopor otro usuariodurantela realizacióndela vueltaatrás.

c Borradodeéste,y envío deun mensajeMu3D detipo REMOVE a lasotrasréplicasdela aplicaciónparaquereproduzcanesteborrado.

c Invalidaciónde los datosalmacenados,asignándolesun valornulo, y abandonodel ám-bito deinserción.

9.4.3. Realización de la vuelta atrás en el ámbito de borrado

Cuandoun usuariosolicitadeshacerla últimaoperacióndeborrado,tienenlugarlossiguientespasos:

c Restauracióndel objetode la papeleralocal, bajo el nodoqueestáalmacenado,en laposiciónadecuada.

c Envío deun mensajeMu3D detipo ADD y declaseRESTORE,conteniendola rutadelobjetobajoel quesedeberestaurary la posición,a lasdemásréplicasdela aplicación,paraquerestaurenel objetodelascopiaslocalesdela papeleradel usuarioqueenvía elmensaje.En la Figura9.3podemosobservar la restauracióndeun objetodel usuarioA,queesreplicadoenel grafodeescenadel usuarioB. Tantoenunocomoenotro caso,lapapeleraA estomadacomoorigen.

c Invalidacióndelosdatosdelugary posicióny vaciadodela papeleralocal,deformaqueel ámbitodeborradoesabandonado.

9.5. Conc lusión

La implementacióncooperativa de la operaciónde vueltaatrásquehemospresentadocubreunagranpartedel espectrocompletode operacionesposiblesennuestroeditor. Estopermiteunafuncionalidadmásqueaceptable,teniendoencuentael tipo deusoquesele daráal editor.



B A B A

Mensaje Mu3D

Usuario A Usuario B

Figura9.3.:Restauracióndel contenidodela papeleraenunasesióncooperativa.

Porotraparte,el conceptodeámbitoshademostradoserextensibleal implementarnuevasoperacionessobrela aplicación.En el casodeoperacionessobreun objeto,bastaconañadirnuevaslistas,asícomounanueva rutina de gestiónadaptadaal tipo de propiedadquesehade modificar. La ediciónde vérticesde un objeto, por ejemplo,fue implementadadespuésde definir la operaciónde “deshacer”,y la adaptaciónde la operaciónparaquepudieraserreversiblefue unatareasencilla.

Otroejemplodela extensibilidaddelconceptodesarrolladoesel siguiente.Enel momentode escribirestamemoria,seestáprobandola implantaciónen el editor de un nuevo ámbito,no asociadoa un objeto,relacionadocon los puntosdevistade la cámara.De estamanera,elusuarioserácapazde volver a unaposicióndevisualizaciónanterior. Estafuncionalidadfuedemandadapor los sociosusuariosdel proyecto,y su implementaciónfue sorprendentementerápiday sencilla,aprovechandola estructurayacreadadela claseUndoMG.

La implementaciónde“papeleras”replicadasencadainstanciadela aplicaciónreduceengranmedidala sobrecargadered,ya queno esnecesarioquela aplicaciónenvíe el contenidocompletodela papeleraencadamomento,sinosolamentesuidentificador. Portanto,deshacerel borradodeun objetoprovocaráel mismotráficodered independientementedel tamañodeesteobjeto.

Al igual queenel casode los portapapelescooperativos,la contrapartidaa estabajaocu-paciónde red seencuentraen el consumoextra de memoriaquesuponeel almacenamientodetodaslaspapeleras.No obstante,la gananciaenestabilidadtemporaldela aplicación(conmenosretrasosprovocadosporsaturacióndela red)compensael gastodememoria.


Parte III.

Conc lusiones


10. Conc lusión

EstamemoriaresumepartedeltrabajoquehemosrealizadodentrodelproyectoeuropeoM3D.Podemosdestacarvarios aspectosque hancaracterizadoestetrabajo,y quehemosqueridoreflejarenestamemoria:

d En primer lugar, ha sido un trabajode investigación. Sehanampliadoy desarrolladoestructurasdedatosy algoritmosparaun campodeaplicaciónparael quehay, todavía,terrenoporexplorar.

d En segundolugar, el trabajohatenidomuchodecontinuidad. Noshemosincorporadoaun proyectoyaenmarcha,y hemostenidoqueutilizar lasherramientasya definidas,asícomocódigoqueya estabaescrito.En ciertosentido,ello puedesermáscomplejoqueempezara trabajardesdecero.

d Finalmente,hemostenidoquetrabajarenequipo, de formaquenuestrotrabajoy el delosotrosprogramadorespudieraintegrarsedentrodeunamismaaplicación.El usodeunsistemaautomatizadodecontroldeversioneshasidocrucialparaestetrabajoenequipo.

Partedel trabajodescritoen estamemoriaha sido objetode difusión medianteartículospu-blicadosencongresosespecializados,comosepuedever enlasreferencias[SC99a],[SC00a].Unadescripciónexhaustivadeleditor(quetodavíaestáendesarrollo),enabril del2000,sepue-de consultaren [SC00b]. Asimismo,unavisión másgeneraly de la aplicacióny del sistemaM3D sepuedeencontrarenlasreferencias[Gal97], [Luo98], [Gal99], [Luo99], [Luo00].

10.1. Resultados

Estamemoriailustra la aplicaciónde técnicascooperativasal casode la ediciónde objetos3D. La tareaquehemosrealizadoha consistidoen implementaralgunasde las operacionescomunesenun editor3D, deformaquefuncionendeformacooperativa. Los aspectosen losquenoshemoscentradohanincluido:

d Aspectosdevisualización.

d Aspectosdeedición.

La implementacióncooperativadelasoperacionescumpledoscondicionesesencialesparaqueel trabajocooperativo seaposible:


Capítulo10.Conclusión

e Exclusiónmutuaentreusuariosparaaccedera cadaobjetodeunaescena.

e Coherenciacontinuaentrelasréplicasdela escena.

El conjuntodeoperacionesquehemosadaptadoal trabajocooperativo cubreel espectrodelasoperacionesmásbásicassobreobjetostridimensionales.

10.2. Trabajo futur o

El temaquehemosabordadotieneun alcancemuy amplio,y permitemúltiplescaminosparaampliarel trabajorealizado.Lasposiblesvíasdetrabajofuturo incluyenlassiguientes:

e Ampliacióndelsoportedevueltaatráscooperativa.Estaampliación,demandadarecien-tementepor los usuarios,incluyeun rangomásampliodeoperaciones,incluidaslasdevisualización.Comohemosexplicadoen el Capítulo9, algunasde estasampliacionesyahansidorealizadas,y seencuentranenfasedepruebas.

e Soportedealtonivel al trabajocooperativo. Lastécnicascooperativasimplementadasenel editorno incluyenun aspecto“de alto nivel”, quehasido requeridopor los usuariosde la aplicación:el intercambiode informacióntextual asociadaa cadaobjeto. En laactualidad,seestátrabajandoenla implementaciónde“Post-Its”,asociadosa un objetotridimensional,quecumpliránla tareadealmacenaranotacionesreferentesacadaobjeto.Estos“Post-Its”puedenserutilizadosparatransmitirencargosentrelosusuarios,duranteunasesióncooperativa, y entredistintassesiones,ya quealmacenanaspectoscomolafechadeemisión,responsable,prioridad,estado.. .

e Implementacióndefuncionesespecializadasparael trabajoarquitectónico.Másalládelalcancedel trabajopresentadoen estamemoria,sehallan en fasede implementaciónfuncionescooperativas relacionadascon el trabajoarquitectónico. Estasoperacionesincluyen,entreotras,lassiguientes:

– Edicióninteractivadevérticesdeun objeto.

– Reduccióndecomplejidadmediantela unificacióndecarascoplanaresdeun obje-to.

– Reagrupacióndelosobjetosdeunaescena,deacuerdoconel elementoarquitectó-nico querepresentan.

– Visualizacióncooperativaavanzadadela escenaarquitectónica(seccionesy planosdecorte).

Dadoqueel ProyectoM3D tieneunaduraciónhastael mesdeabril del2001,seprevéqueestetrabajofuturoseveacompletadopróximamente.



10.3. Problemas encontrados

El hechode trabajarcon libreríasde alto nivel implica aceptarel funcionamientode éstas.Estefuncionamientopuedesererróneo.En nuestrocaso,dadoquela librería OpenInventorescódigocerrado,no ha sido posiblesubsanaresoserrores. Otrasveces,los problemasdeimplementaciónhanpartidodela propianaturalezadel funcionamientodela librería,y delasherramientasutilizadas.

Como ejemplode los problemasencontrados,podemoscitar dos: el manejode nodosVRML 97,y la gestióndela memoriadinámicaenOpenInventor.

f La versióndeOpenInventorutilizadaconteníanumerososerroresen el tratamientodenodosVRML 97,explicadosenel Capítulo3,quehanhechoimposibleel manejodirectode éstosen nuestraaplicación. Por ello, hemostenidoqueimplementarla técnicadefiltrado explicadaenla Sección5.4.

f Porotro lado,el hechodeempleardeformaextensivamemoriadinámicaparala instan-ciacióndetodaslasestructurasdedatos,y másenun lenguajecomoC++,haobligadoaqueseamosextremadamentecuidadososen lascomprobacionesdepunteros,siguiendotécnicasdeprogramaciónsegura,de formaquedebíamoscomprobarentodomomentosi el resultadodecualquierfunciónapuntabaa un espaciodememoriaválido.

10.4. Herramientas y lenguajes

Las herramientasy lenguajesutilizadoshansido determinadosdentrodel ProyectoM3D, ytienenrelaciónconel entornodedesarrolloutilizado.

La versióndela aplicaciónparaIrix hasidoimplementadautilizandolassiguientesherra-mientasdedesarrollo:

f SistemaOperativo Irix 6.3y 6.5.

f CompiladordeC++ propiodeSiliconGraphics.

f Laslibreríasgráficasutilizadashansidolassiguientes:

– OpenInventor2.1.2(SiliconGraphics)

– X Toolkit.

– Motif.

La versiónde la aplicaciónparaWindows hasido implementadautilizandolassiguienteshe-rramientasdedesarrollo:

f SistemaOperativo WindowsNT 4.0.

f EntornodedesarrolloVisualC++ 6.0,EnterpriseEdition.



g Laslibreríasgráficasutilizadashansidolassiguientes:

– OpenInventor2.5.0y 2.5.2(TemplateGraphicsSoftware)

– Microsoft FoundationClasses(MFC).

– InteractiveVisualFramework (IVF) deTemplateGraphicsSoftware.

Estasherramientashan sido ejecutadassobreestacionesde trabajoSilicon Graphicsy PC,respectivamente,equipadasconaceleracióngráficaparaOpenGL.

10.5. Agradecimientos

Losdirectores(einspiradores)deesteproyectodefin decarrerahansidoRicardoGalli Granaday YuhuaLuo. Esperoquesuvaliosay complementariaayudaparadarlea estamemoriaunadimensióntécnicay paradotarladecoherenciasehayavisto reflejadaenestaspáginas.

El trabajoenequipono hubieraexistido sin un equipopreparadoy capaz,el equipoM3Ddela UIB, formadopor Toni BennasarObrador, JuanFornésChicharro,JosepGayàMiralles,JuanManuelHuéscarFelguerasy JuanCarlosSerraCanals. El buenambiente,la comuni-caciónconstantey el apoyomutuoqueha tenidolugar duranteel desarrollodel proyectoharepercutidomuypositivamenteensucalidad.

El trabajode portar la aplicaciónde Irix a Windows NT fue desarrolladoen el centrode investigaciónADETTI (Lisboa,Portugal),duranteunasemanade marzode 1999. Porelsoportelogístico,el apoyoenel trabajo,y la exquisitahospitalidad,estoyendeudaconMiguelDias,conSérgio y Susana,y conMarcoy Renato.

Porúltimo, deborecordara dosgruposdepersonasmuy especiales.Porun lado,un redu-cido grupoformadopor los mejoresamigosy amigasquesoycapazdeimaginar. Porotro,mifamilia. Porsucariño,suapoyoy supacienciaincondicionales,gracias.


Parte IV.

Apéndices


A. Desarrollo de versiones concurrentes

El editor es fruto del trabajocoordinadode un equipo,formadoen la actualidadpor cincopersonas,quetrabajanconcurrentementesobreel mismocódigofuente.Estasituaciónpuededar lugar a problemasde coordinaciónentrelos distintosprogramadoresen el momentodeimplantarunanuevafuncionalidad,la solucióndeunfallo, o engeneralcualquiermodificaciónenel código,pormínimaquesea.

En concreto,nuestroequiponecesitadisponeren plazosconcretosde versionesestablesdel editor. El primer enfoquequeaplicamosparaobteneresteresultadoconsistióen man-tenerunacopia maestra establedel código,dondecadadesarrolladoraplicaríamanualmentelos cambiosquefuerahaciendo,unavezprobados.Esteenfoquesereveló impracticable,yaquecadadesarrolladordebíateneren cuentacadaunode los cambiosquehabíahechoen elcódigo,sin contarlos cambiosya aplicadosa la copiamaestra.Estoprovocabaperiodosdebajaproductividad,ya quela aplicacióndeun conjuntodecambios,junto a laspruebas,podíaocuparvariosdíasde implantaciónde modificaciones,determinarlos cambiosrealizadosporcadaprogramador, resolver conflictos,etc., todo ello de forma manual. Por otra parte,cadaprogramadordebíadisponerdeloscambiosdelos demásparapodercontinuarconsutrabajo,conel consiguienteretraso.

No obstante,la necesidadde unacopiamaestraestable,quepuedatomarsecomopuntodereferencia,y permitavolver atrásencasodeerroresenel código,esunanecesidadcrucial,si queremosmantenerla calidaddel software queestamosdesarrollando.Estacopiamaestradebeseractualizadaperiódicamente,sincomprometerel tiempodedesarrollo.

Por ello, paraoptimizar el tiempo de desarrollo,y evitar una aplicaciónmanualde loscambios,tareatediosay propensaaerrores,seoptópor la instalacióndeunsistemaautomáticodecontroldeversionesconcurrentes,llamadoCVS (ConcurrentVersionsSystem).

A.1. El sistema CVS

El sistemaCVS([Ced93],[Fog99])esutilizadoampliamenteendiversosentornosdedesarrollode softwaredondeintervieneun alto númerode desarrolladores,y en particularen diversosproyectosde software“opensource”, dondelas contribucionesde cientosde desarrolladoresesporádicosestána la ordendel día.

La utilidaddelsistemaCVSradicaenla posibilidaddeautomatizaralgunosdelosprocesosde modificacióny comprobaciónde cambiosen el códigofuente,asícomoen su capacidadparaguardarmúltiplesversiones,de forma quesepuedarecuperarunaversióndesarrolladaanteriormenteen casode ser necesario.Ello aceleraenormementeel tiempode desarrollo,


CapítuloA. Desarrollodeversionesconcurrentes

comohemospodidocomprobar, yaquela implantacióndecambiosenel códigoesmuchomásrápida,y la mayoríadelasvecesinstantánea.

La eleccióndel sistemaCVS, en vez de otro sistemade control de versiones(comoporejemplo,Visual SourceSafede Microsoft, incluido con Visual C++, nuestraherramientadedesarrolloprincipal,y quefuetambiénconsiderado)tuvo lugarteniendoencuentadosmotivosprincipales:

h Enprimerlugar, el soportequeCVSofreceparamúltiplesplataformas,y la estandariza-ción defactoquesuponesuampliaimplantación.

h Ensegundolugar, la flexibilidad queproporcionaensuuso.Otrossistemas,porejemplo,requierenel bloqueode los ficherosen los queestátrabajandocadaprogramador. ConCVS, en cambio,doso másprogramadorespuedenrealizarcambiossimultáneamentesobreel mismofichero,sin necesidadde configurarlode forma especial. Estoes im-portante,yaquela aplicacióncontieneficheroscomunesquedebensermodificadosconmuchafrecuencia,y avecessimultáneamentepordoso másprogramadores.

El sistemaCVS basasufilosofíadetrabajoenel mantenimientodeunabasededatoscentra-lizada,llamadarepositorio. Esterepositoriocontieneel códigofuentey ficherosdeapoyodelos distintosproyectossoftwareenlosqueseestátrabajando.

Además,el sistemaproporcionaoperacionesy mecanismosdeactualizacióndel reposito-rio, quepermitenquela actualizacióndeésteseaunatarearelativamentesencilla.

El sistemaCVS utiliza unaarquitecturacliente-servidor, quepermitela interaccióndesdedistintasmáquinasclientesconel repositoriocentral.La parteclientedela aplicacióngestionala conexión conel servidorcentral,utilizandodistintosprotocolosdeautentificación.

Loscomandosmásusualesdel sistemasonlossiguientes:

h Checkout. Generaunacopialocal deunode los módulosdel repositorio,y la vinculaaéste.

h Update. Actualizala copialocalconel contenidoactualdel repositorio,avisandodequéficheroshandeseractualizados,cuáleshansidomodificados,etc.

h Commit. Actualizael repositorioconel contenidomodificadodela copialocal.

h Release. Liberala copialocal del vínculoconel repositoriocentral.

h Add. Añadeun ficheroal repositoriocentral.El añadidoseráconfirmadoenla siguienteejecucióndelcomandocommit.

h Remove. Borra un fichero del repositoriocentral. El borradoseráconfirmadocon lasiguienteejecucióndel comandocommit.

h Status. Generaun listadodel estado,númerodeversióny modificacionesdeunoo másficheros.



En el momentodeactualizarla copialocal del programa,medianteel comandoupdate, el sis-temacompruebalos ficherosde código fuentemodificadosdesdela última actualización,ylos comparacon los quehansidomodificadoslocalmente.En el casodeencontrarun mismoficheromodificadolocalmentey enel repositorio,el programaintentacombinarlasdosmodi-ficaciones.Un fallo al combinarsellamaconflictoenla terminologíadel CVS, y puedevenirdadopordoscausas:

i La combinaciónno ha podido iniciarse. En esecaso,el sistemaguardaen el clienteunacopiade seguridadde la versiónlocal del fichero,y la sustituyepor la versióndelrepositorio.La combinacióndeberáserrealizadaa manoporel programador.

i La combinaciónsehainiciado,peronohapodidollevarseacabocorrectamente.Enestecaso,elsistemaguardaenel clienteunacopiadeseguridaddela versiónlocaldelfichero,y la sustituyeporunonuevo, quecontienelasseccionesdecódigoqueentranenconflic-to, delimitadaspor caracteresespeciales.El programadordeberáresolver manualmenteestosconflictos.

Ademásdeloscomandosanteriores,quecontienenmúltiplesopciones,el sistemaCVSpropor-cionaotros,quepermitenidentificarversionesdistintasdeun módulode software.Nosotroshemosutilizadoúnicamenteel comandoTag, queasignaetiquetasa distintasversiones.Estasversionespuedenrecuperarsemástardedesdeel repositorio,identificándolasporsuetiqueta.

A.2. Política de utilización

Lasoperacionesquehemosdescritoenla secciónanteriorno sonsuficientesparaimpedirquelasdistintasversionesdel programapierdanla coherencia,o queundesarrolladorsobreescribalos cambiosde otro por error. Comoseexplica en el manualde usode CVS ([Ced93]),esnecesariodefinir y aplicarunapolítica de utilización del sistema,quepermitamantenerunnivel deproductividady decalidadelevado.

A continuaciónexplicamoslasreglasdeusoquehemosdefinidoparala correctautilizacióndel sistemaCVS enel desarrollodel editor.

i Actualizaciónfrecuentede las copiaslocalesdesdeel repositorio,de forma quecadaprogramadortengala versióndel códigofuentelo másactualizadaposible.Conello, seminimizala presenciadeconflictos,y sefavorecesurápidadeteccióny solución.

i Antesderealizarunaactualizacióndela copialocal(conel comandoupdate), esmuyútilsimularesaactualización,utilizandoel comando-n -q update. Estecomandomuestralosmismosmensajesdesalidaqueupdate, sin realizarningunadelasmodificacionesdeéste.De estemodo,sepuedecomprobarquéficheroshansidomodificados,tantoenlacopialocal comoenel repositorio,y los posiblesconflictospuedenserdetectadosantesdequeaparezcan.

i Antesdeenviar los cambiosde la copialocal al repositorio,esobligatoriorealizarunaactualizaciónde ésta,y resolver los conflictosqueaparezcan.Hemosde hacernotar



queel sistemaCVS puededetectarlos conflictos,y marcarlos,perono garantizarálaintegridaddel código,ni prohibiráqueseenvíencambiosquecontenganconflictos.

j Por la mismarazón,se intentano enviar al repositoriounaversiónqueno hayasidoprobadasuficientementecon anterioridad.Si un programadorenvía al repositoriounaversióninestable,o que inclusono sepuedacompilar correctamente,propagaráestoserroresal restodel equipo,sinqueel sistemaCVS puedaevitarlo.

Estapolíticadeutilizacióndel sistemaCVS hasidodifundidaentreel equipodeprogramado-res,y aplicadaal desarrollodel editor cooperativo. Su aplicaciónnoshapermitidomantenerun tiempodedesarrollosostenido,evitandoretrasospormotivosdeintegración.

A.3. Configuración y aplicación

La instalacióndeun sistemacliente-servidordebeadaptarseal entornohardware existente,ya las necesidadesconcretasde funcionamientode esteentorno. En estasecciónexplicamoscómoseha instaladoel sistemaCVS en las plataformasde quedisponeel laboratorio,parahacerposiblesuutilizaciónduranteel desarrollodeleditor. Además,describiremoscómoseharealizadola integracióndelosclientesCVS conlosentornosdedesarrollo,y quéherramientasdesoportehansidoañadidasal sistema.

La estructuracliente-servidordel sistemaCVS sehaimplantadoenlasmáquinasdel labo-ratoriodela siguienteforma:

j El servidorsehainstaladoenel servidorgeneraldel proyectoM3D. EsteservidoresunIntel PentiumIII, conel sistemaoperativo Linux RedHat6.1.

j Los clienteshansido instaladosen estacionesgráficasPCsconWindows NT, y enunaestacióndetrabajoSiliconGraphicsconel sistemaoperativo Irix 6.5.

Un esquemadeestaestructurasepuedeobservarenla FiguraA.1.La ejecuciónde la parteclientedel sistematienelugarmediantelíneadecomandos.Los

argumentosdelcomandoCVSpuedenserintroducidosdeformatextual,medianteunainterfazdecomandos.Estainterfaztextual,no obstante,hasidointegradaconel entornodedesarrollode Visual C++, en forma de herramientaexterna. De estaforma, los parámetrospuedenserintroducidosdesdeel entornointegrado,y la salidatextualdel comandoesredirigidaa unadelasventanasdetexto del entornoVisualC++.

La consultadel repositoriotienelugar, por lo general,mediantelos comandoslog y statusdel sistemaCVS. La salidade estecomandoesgeneradaen forma textual, de forma quesuconsultaespocoamigable.Paramejoraresteaspecto,hemosinstaladoherramientasgráficasdeconsultaal repositorio.Estasherramientaspresentanunasalidahipertextuala loscomandosintroducidos.

La herramientaCVS2HTML [Tof] esun programaqueseejecutaperiódicamentesobreel repositorio,y generaun conjuntodepáginaswebestáticasquecontienenel estadodecada



Servidor CVS

Repositorio

Clientes de desarrollo

FiguraA.1.: Esquemadela instalacióndelCVS enel laboratorioM3D dela UIB.

ficherodecódigofuente.Un aspectodela interficiedeestaherramienta,queofreceunaimagengeneraldecadaficheroenel contexto delosdirectorios,sepuedeverenla FiguraA.2.

La herramientaCVSWeb[Fen],encambio,esunscript CGI queseejecutacadavezqueelusuarioaccedeala páginaweb. Ello permiteunaccesopermanentementeactualizadoal estadodetodoslos ficherosdel repositorio,ya quelaspáginassongeneradasdinámicamentea partirdel estadodecadafichero.El accesoa la historiadecambiosserealizaenbasea los distintosficherosdecódigofuente,de formaqueesposibleconsultarquécambioshansidorealizadosúltimamenteenun ficheroconcreto,y porquién,comosepuedever enla FiguraA.3.

Las herramientasde accesoweb añadena la potenciadel sistemaCVS la facilidad deconsultade los cambios,de maneraqueel conjuntode los ficherosde códigoesfácilmentecontrolable.Estoesindispensableenunproyectocomoel nuestro,dondeel volumendecódigoesconsiderable(unas70000líneasdecódigoenla actualidad).



FiguraA.2.: Aspectodela interfazdeCVS2HTML

FiguraA.3.: Aspectodela interfazdeCVSWeb


B. Por tabilidad y múltiples plataf ormas

B.1. Consideraciones previas

Uno delos requisitosdenuestraaplicacióndesdeel momentode la definicióndel proyectoesqueseamultiplataforma. Es decir, quepuedafuncionarsobredistintossistemasoperativos,conservandouna funcionalidadlo mássimilar posibleentre todosellos. Los dos sistemasoperativosrequeridosenel proyectoM3D hansidoIrix deSiliconGraphicsy WindowsNT deMicrosoft,sobrelos quehablaremosmásadelante.

El hechode utilizar un conjuntode libreríasestándarcomoesOpenInventornosha per-mitido construirla aplicaciónsobredistintasplataformas,minimizandoel tiempodedesarrollodedicadoa implementarfuncionesdiferentesparacadaplataforma.Dadoquela mayorpartedela aplicaciónutiliza la API deOpenInventor, portarlaa otrasplataformasrequieretenerencuentadosaspectos:

k Quela plataformaelegidacuenteconunaversiónde OpenInventor(lo queocurreconla mayorpartedesistemasUnix, y conlasúltimasversionesdeMicrosoft Windows).

k Quelos aspectosdeinterfazdeusuarioseanconsideradosdeformaseparadarespectoalasfuncionesbásicasdela aplicación.

La implementaciónde la interfazde usuarioesmuy distintasegún el sistemaoperativo y laslibreríasautilizar, yaquecambiael paradigmadeprogramación.El hechodeutilizar OpenIn-ventornoshacondicionado,porotraparte,aescogerunou otroparadigmadeprogramacióndeinterfacesgráficasdeusuario,yaquela versióndeOpenInventorparaUnix seencuentramuyligadaal X toolkit ([Rei92], [Nye92]), mientrasquela versiónparaMicrosoft Windows ofre-cefacilidadesparaquesela useconjuntamenteconlasMicrosoftFoundationClasseso MFC([Tem97]).Utilizar OpenInventorparaWindows sin ligarlo a lasMFC supondríarenunciaraunareducciónenel tiempodedesarrollodela interfazdeusuario,lo cualnoesadmisibleenunproyectotancomplejocomoel nuestro,y conplazosdeentregayafijadosparala aplicación.

Parafacilitar la generacióndecódigoportable,sehaenfatizadola separaciónendistintosmódulos, conunnivel deacoplamientorelativamentebajo,deformaquecambiarunoimpliqueel mínimonúmerodecambiosenlosdemás.

Esposiblequeen un mismomódulosedebanseparargruposde instruccionesdecódigo,segúnla plataformaa utilizar. Paraello, utilizamosdirectivasdeprecompilación, queindicanal compiladorquécódigoreconocer, según el sistemaoperativo. De estamanera,el códigoejecutablegeneradoserádistintoparacadaunadelasplataformasconsideradas.


CapítuloB. Portabilidady múltiplesplataformas

B.2. Por tar la aplicación de Irix a Windo ws NT

En estasecciónexplicamosel procesoseguido paraportar la aplicacióna partir desu estadoinicial, ensistemaoperativo Irix, auncódigocapazdesercompiladoy ejecutadocorrectamentetantoenIrix comoenWindowsNT. Esteprocesotuvo lugarduranteunasemanadetrabajoenla sedede ADETTI (Lisboa),otro de los sociosdesarrolladoresdel proyectoM3D, con cuyoequipodedesarrollocolaboramosenla adaptaciónparala portabilidad.

B.2.1. Estado inicial de la aplicación. La plataf orma Irix

La aplicaciónseempezóa desarrollarúnicamentesobreel sistemaoperativo Irix, de SiliconGraphics.Sedesarrollóunainterfazdeusuariomuy sencilla,conunaúnicaventanadevisua-lización. Los comandosdeusuarioeranintroducidosmedianteun menú.El aspectoinicial dela aplicaciónsepuedeobservarenla FiguraB.1.

La interfazdeusuariosedesarrollóbasándoseenel sistemadeventanasX-Windows,uti-lizandola libreríaX toolkit ([Rei92], [Nye92]). Estalibreríadefineel conjuntodeoperacionesbásicoparagestionarloselementosgráficosdecontrol,a losquellamawidgets. Parapoderserutilizada,necesitaasociarseaunconjuntoseparadodewidgets. La versiónparaIrix denuestraaplicaciónutiliza el conjuntode widgetsMotif ([Hel94]), uno de los másestandarizadosenentornosUnix, sobreel cualseimplementaunagrancantidaddeaplicaciones.

La versiónde la aplicaciónde la quepartimosconteníaun conjuntomínimo de funcio-nes.La implementacióndealgunasdeellaseraincompleta,y otrasseencontrabanenfasedepruebas.Estasfuncionesincluían:

l Navegacióna lo largo deunaúnicaescena.

l Seleccionesbásicas.

l Manipulacióngeométricainteractiva.

l Edicióndemateriales.

l Gestióndeiluminación.

Tomamosla decisiónde portarestaversióninicial de la aplicaciónal sistemaoperativo Win-dows NT paracontinuarel trabajosobreestaplataformapordistintosmotivos,queincluyen:

l El sistemaoperativo Windows NT eraunade las plataformasde ejecuciónrequeridasporel proyectoM3D.

l El bajocostedelasestacionesgráficasdedesarrollobasadasenPC,frentea lasbasadasenla arquitecturaSiliconGraphicshacíamássencilloobtenerel equipamientonecesarioparael desarrollo.

l La mayorfacilidaddeobtenerparala plataformaWindowsNT herramientasdedesarro-llo conentornosintegrados,y capacesdegenerarinterfacesdeusuariovisualmente.Ennuestrocaso,el entornoVisualC++ 6.0.



La necesidaddeportarla aplicaciónenesemomentovino dictadapor la complejidadcrecientedela aplicación,quehacíapreverqueportarlamásadelanteresultaríamáscomplicado.

FiguraB.1.: Aspectodela implementacióndela aplicaciónparael sistemaoperativo Irix.

B.2.2. Windo ws NT y el entorno de programación Visual C++

WindowsNT esun sistemaoperativo propiedaddeMicrosoft,quedefineunaAPI completadefunciones.Éstaspermitenescribiraplicaciones“desdeabajo”,siguiendounaslíneasdeestilodefinidaspor Microsoft ([Mic95]). Parareducirla complejidady la lentituddedesarrolloqueello supone,distintosfabricanteshancreadolibreríasde clasesC++, queseajustana estaslíneasde estilo, y que permitanal programadortrabajara másalto nivel, sobretodo en loquerespectaa los detallesde interfazdeusuario,conla consiguientereduccióndel tiempodedesarrollo.

El propio Microsoft desarrollay distribuye una librería de clasesde estetipo, llamadaMicrosoftFoundationClasseso MFC ([Feu97],[Kai99]), quevieneintegradaconsuentornode desarrollo,Visual C++. Estafue la libreríaelegida parael desarrollodel editor, ya quelaversiónparaWindows NT de OpenInventorestábasadaen esteentorno,y ademáspresentafacilidadesparala integraciónconMFC.

La librería MFC favoreceel desarrollode aplicacionesquesiganel modelodocumento-vista.Estemodelonoesmásqueunaaplicación,conotronombre,delparadigmaModel-View-Controller, o MVC ([Lew95]), desarrolladoen Xerox Parc junto con el lenguajeorientadoaobjetosSmalltalk.Explicamosacontinuaciónenquéconsisteel modelodocumento-vista.

El modelodocumento-vistaseparalos datosde la aplicación(llamadosdocumentoen laterminologíadeMicrosoft)dela presentaciónquesedaaéstos(aestapresentaciónsela llamavista). Los datosde un mismodocumentopuedenestarrepresentadospor numerosasvistasdiferentes.Porejemplo,unahojadecálculopuedepresentarlosmismosdatosendosventanasdistintas,unaenformadeceldas,y la otraenformadeun gráficodebarras.



La interaccióncon el usuarioescontroladapor la ventanaprincipal de la aplicación,lla-madaFrameWindowenterminologíade MFC. Estaventanarecogey procesalos eventosdela interfazdeusuarioy lospasaal documentoo a la vista.

La tripleta formadapor el documento,la vista y ventanaprincipal escoordinaday con-troladapor unacuartaclaseC++, querepresentala aplicación. Estaclaseesresponsablederealizartodoel procesode inicialización,ejecucióny recepcióndemensajesnecesarioenunaaplicaciónparaWindows.

LosmensajesdeWindowssontratadosporMFC mediantemanejadoresdemensajes(hand-lers) asociadosacadaclaseprincipal.Estosmanejadoressonfuncionescallback queseejecu-tanenel momentoenquellegael mensajeasociado.Los manejadoressonasociadoscon losmensajescorrespondientesmedianteun mapademensajes(messagemap).

Estemodelodedesarrollodeaplicacionesesfavorecidoengranmedidapor lasMFC, asícomoporel entornodedesarrolloVisualC++. Portanto,unaaplicaciónquequieraaprovecharel potencialqueel entornode desarrolloofrece(aspectosde interfazde usuario,generaciónautomáticadecódigoparalasclasesC++,etc.),deberáceñirsea estemodelodedesarrollo.

B.2.3. El proceso de adaptación de código

La adaptaciónde códigoparaportar la aplicaciónde Irix a Windows NT siguió un procesoduranteel cual se identificaronlas porcionesde códigocomunesa ambasplataformas,y lasqueerandependientesdel sistemaoperativo empleado.

Deestaforma,losmódulosqueconteníanúnicamentecódigoestándardeOpenInventor, yqueconstituíanel corazóndela aplicación,fueronaislados.Al serestosmódulosconsideradosindependientesde la plataforma,los módulosdedicadosa la interfaz de usuariorealizaríanllamadasa losmóduloscomunes.

A continuación,serealizóun procesode identificaciónde los elementosprincipalesde laaplicaciónconloselementosprincipalesdeunaaplicaciónMFC. Trasesteproceso,obtuvimoslos siguientesresultados:

m El grafoprincipaldecadaescenaserelacionóconla clasecorrespondienteal documento,CM3dpcDoc.

m Cadaunodelos visoresdeOpenInventorutilizadosserelacionóconlasdistintasvistasdela aplicación,comola claseCM3dpcView.

m Parala ventanaprincipaldela aplicaciónsecreóunanuevaclase,CMainFrame.

m Porúltimo, el códigocorrespondientea la inicializaciónde la aplicaciónsesituóen elmétodoapropiadode la claseaplicación. La clasesellama CM3dpc, y su métododeinicializaciónestándaresOnInitApp().

Una vez realizadoesteprocesode identificación,sereescribieronlasoperacionescorrespon-dientesal árboldemenús,y la barradebotones,deformaquepudimosobtenerunaaplicaciónejecutableenWindowsconunafuncionalidadequivalenteala anteriorversión,quefuncionabaenIrix.



B.2.4. Proceso de pruebas y problemas encontrados

El procesodepruebasseguidoparacomprobarlos resultadosconsistióenunapruebaexhaus-tivadetodaslasfuncionesexistentesenaquelmomentoenla aplicación.

Laspruebasserealizaronenmodocooperativo entredosmáquinas,unaestacióndetrabajoSilicon Graphicsy un PC.Estaspruebaspermitieronidentificarproblemasy puntosa tenerencuenta.

El principal problemaencontradoen estafasetuvo quever con las diferentesformasderepresentarlasrutasdelos directoriosenlos distintossistemasoperativos. ComovimosenelCapítulo4,algunosdelosmensajesMu3D envíanla rutacompletadeunarchivo. Losdistintoscaracteresutilizadospor unay otra plataforma(“/” en Unix, y “\” en Windows), producíanproblemasde ejecuciónen las dos plataformas,por lo que tuvieron queser sustituidosporunarepresentaciónneutra(el carácter“|”). Estarepresentaciónneutraesconvertidaal carácteradecuado,segúnla plataforma.

B.3. Desarrollo sim ultáneo de la aplicación en Irix yWindo ws NT

Una vez sedisponede unamismaversiónde la aplicaciónparaWindows NT, esnecesariocontinuarsudesarrollosimultáneamenteenambasplataformas.Paraello, hemosseguidodostécnicasprincipales,queexplicamosa continuación.

En primer lugar, hemosorganizadoel conjuntodeficherosfuenteendirectorios,deformaqueel conjuntodeinstruccionesdecompilaciónencadaplataforma(MakefileenIrix, archivode proyectoenWindows) incluyaúnicamentelos ficherosnecesarios.La estructuraprincipaldelosficherosesla siguiente:

comun Directorioquecontienelos ficherosde implementacióncomunesa lasdosversionesdela aplicación.SecomponeprincipalmentedecódigoestándarenC++basadoenOpenInventor.

inc lude Directorioconlosficherosdecabeceracomunesa lasdosversionesdela aplicación.

gui_wnt Directoriocon los ficherosde implementaciónpropiosde la interfazde usuariodeWindowsNT. SecomponeprincipalmentedecódigoenC++ utilizandoMFC.

inc lude Directorio con los ficherosde cabecerapropiosde la interfazde usuariodeWindowsNT.

gui_sgi Directorio con los ficherosde implementaciónpropiosde la interfazde usuariodeIrix. SecomponeprincipalmentedecódigobasadoenX Toolkit y Motif.

inc lude Directorio con los ficherosde cabecerapropiosde la interfazde usuariodeIrix.



En segundolugar, hemosintroducido,en los ficherosdecódigofuentecomunesquelo nece-sitaban,directivasde preprocesado,quepermitenquesegenereuno u otro códigosegún ladirectiva. Un ejemplodeestatécnicasepuedever enla FiguraB.2.

Estatécnicasehaaplicado,sobretodo,enfuncionescuyaimplementacióndebaserdistintaparalasdiferentesplataformas.

void myFunction(v oid) {#ifdef WIN32

// Fragmento de código para Windows#elif IRIX53__

// Fragmento de código para Irix#endif

}

FiguraB.2.: Ejemplodeseparacióndecódigosegúnla plataforma.

La combinacióndeestasdostécnicasnoshapermitidoobtenerdosresultadosdiferentes.Porun lado,mantenerel códigoindependientedela plataformaseparadodel códigodedicadoa la interfazdeusuario.Porel otro,hasidoposiblerealizardosimplementacionesalternativasdela mismafuncióncuandoéstaserandistintasparalasdiferentesplataformas.


Parte V.

Índices y bib liografía


Índice de Figuras

2.1. Esquemadela estructuradeejecucióndel SistemaM3D. . . . . . . . . . . . . 112.2. Esquemadela ejecucióndistribuidadel editor . . . . . . . . . . . . . . . . . . 122.3. Pantallaprincipaldel editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4. Estructuramodulardel editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1. Esquemadeun grafodeescenadeOpenInventorquereutilizaunnodo. . . . . 163.2. Visualizacióndeun ficheroOpenInventorquereutilizanodosgeométricos. . . 173.3. EjemplodevisordeOpenInventor. . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Estructuramodulardela plataformaJESP, y surelaciónconlasaplicaciones. . 314.2. EsquemadeunaarquitecturaCSCWcentralizada.. . . . . . . . . . . . . . . . 344.3. EsquemadeunaarquitecturaCSCWreplicada. . . . . . . . . . . . . . . . . . 354.4. Formatodeun mensajeMu3D. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1. Estructuramínimadeun objetotridimensionalutilizableporel editor . . . . . 415.2. Estructuradel árboldeescenasdel editor. . . . . . . . . . . . . . . . . . . . . 445.3. ConversióndeficherosVRML 97 aOpenInventor. . . . . . . . . . . . . . . . 475.4. Técnicadel separadortemporalutilizadaparaguardarel fichero. . . . . . . . . 48

6.1. Ejemplodeselecciónlocal resaltadaencolor rojo. . . . . . . . . . . . . . . . . 506.2. Selecciónlocal (enrojo) y selecciónremota(enamarillo). . . . . . . . . . . . 54

7.1. EjemplodemanipuladorCenterball. . . . . . . . . . . . . . . . . . . . . . . . 587.2. Sustitucióndeun nododetransformaciónporun manipulador. . . . . . . . . . 597.3. Ejemplodeeditordemateriales.ImplementaciónparaWindowsNT. . . . . . . 617.4. Enlacedeun editordematerialesconel nododematerialdeun objeto . . . . . 627.5. Aspectodeunaescenacontreslucesañadidas. . . . . . . . . . . . . . . . . . 647.6. Sustitucióndeunaluz porun manipulador. . . . . . . . . . . . . . . . . . . . . 67

8.1. Pegadodel contenidodel portapapelesdel usuarioA. . . . . . . . . . . . . . . 71

9.1. Esquemabásicodeun ámbitodevueltaatrás. . . . . . . . . . . . . . . . . . . 749.2. Listasdeestadoutilizadasparala vueltaatrás.. . . . . . . . . . . . . . . . . . 789.3. Restauracióndel contenidodela papeleraenunasesióncooperativa. . . . . . . 81

A.1. Esquemadela instalacióndel CVS enel laboratorioM3D dela UIB. . . . . . . 92


ÍndicedeFiguras

A.2. Aspectodela interfazdeCVS2HTML . . . . . . . . . . . . . . . . . . . . . . 93A.3. Aspectodela interfazdeCVSWeb . . . . . . . . . . . . . . . . . . . . . . . . 93

B.1. Aspectodela implementacióndela aplicaciónparael sistemaoperativo Irix. . 96B.2. Ejemplodeseparacióndecódigosegúnla plataforma.. . . . . . . . . . . . . . 99


Bib liografía

[Aho88] Alfred V. Aho, JohnE. Hopcroft, y Jeffrey D. Ullman. Estructuras de datosyalgoritmos. AddisonWesley Iberoamericana,1988.

[Alm95] A. Almeiday C. A. Belo. SupportFor MultimediaCooperativeSessionsOver Dis-tributedEnvironments.En SouthamptonSocietyfor ComputerSimulation,editor,ProceedingsMediacomm’95. abril 1995.

[Aut90] AutoDesk,Inc.,SanRafael,California. AutoCADReferenceManual, 1990.

[Aut94] AutoDesk,Inc.,SanRafael,California.3D StudioRelease3 File Toolkit: ReferenceManual, junio 1994.

[Bro96a] Wolfang Broll. ExtendingVRML to supportCollaborative Virtual Environments.En UK University of Nottingham,editor, Proceedingsof CVE 96, WorkshoponCollaborativeVirtual Environments. septiembre1996.

[Bro96b] WolfgangBroll. InteractionandBehaviour in WebBasedSharedVirtual Environ-ments.EnProceedingsof theIEEEGlobal Internet96. London,noviembre1996.

[Bro97a] WolfgangBroll. DistributedVirtual Reality for Everyone:A Framework for Net-workedVR on the Internet.En IEEE ComputerSocietyPress,editor, Proceedingsof theIEEE Virtual RealityAnnualInternationalSymposium1997(VRAIS97), pá-ginas121–128.1997.

[Bro97b] Wolfgang Broll. Populatingthe Internet: SupportingMultiple UsersandSharedApplicationswith VRML. En ACM SIGGRAPH,editor, Proceedingof theVRML97 Symposium, páginas87–94.Monterrey, CA, febrero1997.

[Bud94] T. Budd. ProgramaciónOrientadaa Objetos. AddisonWesley, 1994.

[Cad] CadStudio.VRMLout for AutoCAD. http://www.cadstudio.cz/indexuk.html.

[Car97] Rikk Carey, Gavin Bell, y Chris Marrin. ISO/IEC 14772-1:1997, Virtual Reality Modeling Language, (VRML97), 1997.http://www.vrml.org/Specifications/VRML97.

[Ced93] PerCederqvist.VersionManagementwith CVS. SignumSupportAB, 1993.

[Fen] Bill Fenner, HennerZeller, HenrikNordström,y KenCoar. CVSWeb.http://stud.fh-heilbronn.de/zeller/cgi/cvsweb.cgi.


Bibliografía

[Feu97] Alan R. Feuer. MFC Programming. AddisonWesley, Reading,Mass.,1997.

[Fog99] Karl Fogel. OpenSource Developmentwith CVS. The Coriolis Group, octubre1999.

[Fol92] J.D. Foley, A. VanDam,S.K. Feiner, y J.F. Hughes.ComputerGraphics:Princi-plesandPractice. AddisonWesley, Reading,Massachusetts,secondedición,1992.

[Gal97] R. Galli, P. Palmer, M. Mascaró,M. Dias, y Y. Luo. A Cooperative 3D DesignSystem.En Proceedingsof CEIG97,Barcelona,Spain. junio 1997.

[Gal99] RicardoGalli, YuhuaLuo, David Sánchez,Sérgio Alves,Miguel Dias,RenatoMar-ques,Antonio Almeida,JorgeSilva, JoséManuelFonseca,y BasTummers.M3DTechnicalSpecifications.Deliverable1.2, ESPRITProjectNo 26287M3D, abril1999.

[Gal00] RicardoGalli y YuhuaLuo. Mu3D: A CausalConsistency Protocolfor a Collabo-rative VRML Editor. En ACM SIGGRAPH,editor, Proceedingof theVRML2000Symposium. Monterrey, California,febrero2000.

[Har96] J. Hard y J. Wernecke. The VRML 2.0 Handbook. Addison Wesley PublishingCompany, 1996.

[Hea94] D. Hearny M. P. Baker. ComputerGraphics. PrenticeHall InternationalEditions,secondedición,1994.

[Hec97] MichaelM. Heck. VRML 2.0 for OpenInventorProgrammers.A TechnicalWhitePaper. Informetécnico,TemplateGraphicsSoftware,1997.

[Hel94] Dan Heller, PaulaM. Ferguson,y David Brennan. Motif ProgrammingManual,tomo6A deTheDefinitiveGuidesto theXWindowSystem. O’Reilly andAssociates,febrero1994.

[HF99] JuanManuelHuéscarFelgueras,RicardoGalli, y YuhuaLuo. ConversióndeobjetosCAD enVRML. En Actasdel IX CongresoEspañoldeInformáticaGráfica. junio1999.

[HO93] EnriqueHernándezOrallo y JoséHernándezOrallo. ProgramaciónenC++ . Edi-torial Paraninfo,1993.

[IBM92] IBM. Object-OrientedInterfaceDesign: IBM CommonUser AccessGuidelines.IBM, Carmel,Indiana,Que.,1992.

[Kai99] EugèneKain. TheMFC answerbook: Solutionsfor effectiveVisual C++ applica-tions. AddisonWesley, Reading,Mass.,1999.

[Lew95] SimonLewis. TheArt andScienceof Smalltalk. PrenticeHall / Hewlett-PackardProfessionalBooks,1995.


Bibliografía

[Lip91] Stanley B. Lippman. C++ Primer. AddisonWesley PublishingCompany, 2aedi-ción,diciembre1991.

[Luo98] Y. Luo, R. Galli, M. Mascaró,y P. Palmer. CooperativeDesignFor3D Virtual Sce-nes. En Proceedingsof the Third IEEE InternationalFoundationOn CooperativeInformationSystems(CoopIS’98),New York, USA, páginas373–381.agosto1998.

[Luo99] Y. Luo, R. Galli, A. Almeida, y M. Dias. A PrototypeSystemFor CooperativeArchitectureDesign. En Proceedingsof IEEE Symposiumon InformationVisuali-zation. julio 1999.

[Luo00] YuhuaLuo, RicardoGalli, David Sánchez,Antonio Bennasar, Antonio CarlosAl-meida,y Miguel Dias.A CooperativeArchitectureDesignSystemVia Communica-tion Networks.En StanfordUniversity, editor, Proceedingsof the8th InternationalConferenceOn ComputerAidedDesign,BuildingConstructionandCivil Enginee-ring. agosto2000.

[Mic95] Microsoft.TheWindowsInterfaceGuidelinesfor SoftwareDesign. MicrosoftPress,1995.

[Nye92] Adrian Nye y Tim O’Reilly. X Toolkit Intrinsics ProgrammingManual for X11,Release5, tomo 4 de Definitive Guidesto the X WindowSystem. O’Reilly andAssociates,agosto1992.

[Pra92] Atul Prakashy Michael J. Knister. UndoingActions In Collaborative Work. EnProceedingsOf ACM CSCW’92ConferenceOn Computer-SupportedCooperativeWork, páginas273–280.octubre1992.

[Pra94] Atul Prakashy MichaelJ.Knister. A Framework ForUndoingActionsIn Collabo-rativeSystems.ACM TransactionsonComputer-HumanInteraction, 1(4):295–330,1994.

[Rei92] Tim O Reilly, Mark Langley, y David Flanagan(Editor). X Toolkit IntrinsicsRefe-renceManual for Version11 of theWindowSystem, tomo5 deDefinitiveGuidestotheX WindowSystem. O’Reilly andAssociates,3aedición,julio 1992.

[Rul96] Keith Rule. 3D GraphicsFile Formats.A Programmer’sReference, páginas195–240. AddisonWesley DevelopersPress,septiembre1996.

[SC99a] David SánchezCrespillo,RicardoGalli, y YuhuaLuo. Un editor 3D interactivoparatrabajocooperativo. En Actasdel CongresoEspañolde InformáticaGráfica.junio 1999.

[SC99b] JuanCarlosSerraCanals,RicardoGalli, y YuhuaLuo. Almacenamientoy recu-peraciónremotadeescenas3D. En Actasdel IX CongresoEspañoldeInformáticaGráfica. junio 1999.


Bibliografía

[SC00a] David SánchezCrespillo,AntonioFranciscoBennasarObrador, RicardoGalli Gra-nada,y YuhuaLuo. Implementationof mechanismsfor concurrent3D designandvisualisation.En Proceedingsof IEEE Symposiumon CooperativeDesignandVi-sualization. julio 2000.

[SC00b] David SánchezCrespillo,Antonio Bennasar, JuanFornés,RicardoGalli, JuanMa-nuelHuéscar, JuanCarlosSerra,YuhuaLuo, ManuelGamito,y Marc Albiol. TheMulti-Site EditingTool ForArchitecturalProduction.Deliverable2.1,ESPRITPro-jectNo 26287M3D, abril 2000.

[SD97] JoséMiguel SallesDias, RicardoGalli, Antonio CarlosAlmeida, A. C. Belo, yJoséManuel Rebordao. mWorld: A Multiuser 3D Virtual Environment. IEEEComputerGraphicsandApplications, 17(2),marzo1997.

[SGI95] SiliconGraphicsInc. TheOpenGLGraphicsSystem:A Specification(Version1.1).Informetécnico,SiliconGraphicsInc, 1995.

[Sil94] A. Silberschatz,J.Peterson,y P. Galvin. Sistemasoperativos.Conceptosfundamen-tales. AddisonWesley Iberoamericana,terceraedición,1994.

[Tem97] TemplateGraphicsSoftware. OpenInventor for Win32. IVF. Interactive VisualFrameworkFor VisualC++ andMFC, 1997.

[Tof] PeterToft. CVS2HTML. http://www.sslug.dk/cvs2html/.

[VV.94] VV. AA. Computer-SupportedCooperative Work. Computer, 27(5),mayo1994.IEEE ComputerSociety.

[Wer94a] JosieWernecke.TheInventorMentor. AddisonWesley PublishingCompany, 1994.

[Wer94b] JosieWernecke.TheInventorToolmaker. AddisonWesley PublishingCompany,1994.


Desarrollo de técnicas cooperativas para un editor de ... · Desarrollo de técnicas cooperativas...

Documents

Transcript of Desarrollo de técnicas cooperativas para un editor de ... · Desarrollo de técnicas cooperativas...