Capitulo 7

1 VRML 2.0 con Java CAPÍTULO 7

Propuesta de Vida en los Mundos

Contenido CAPÍTULO 7 • Historia y Evolución • Algunos Filosofía básica • Algunos Jerga

2 VRML 2.0 con Java CAPÍTULO 7

• La Vida Mundos Modelo Conceptual • ¿Cómo funciona todo • Otros Temas

Historia y Evolución La Vida Mundos propuesta fue formulada por un grupo de tres empresas: Domingo Negro interactivo, apartado Internacional, y Sony. Cada uno de los tres tiene su propia tecnología de multiusuario, y todos ellos vieron la necesidad de algún tipo de interfaz estándar para VRML que permitan a los creadores de contenidos multiusuario para construir mundos y objetos que trabajar con todos sus sistemas (y muchos más). Los tres decidieron colaborar en la creación de una norma.

3 VRML 2.0 con Java CAPÍTULO 7

Su primer proyecto fue lanzado en octubre de 1996, y ha sido objeto de revisión significativa desde entonces. Uno de los más importantes principios de la iniciativa de los mundos de vida es que nada debe establecerse de manera concreta hasta que exista el código de trabajo real para copia de seguridad del mismo-una sabia decisión, a partir de la cual muchas otras iniciativas de las normas a través de los años podría haber beneficiado. Como este libro va a la imprenta, la Vida Mundos propuesta sigue evolucionando a un ritmo. Una advertencia de tipo es, por tanto, con el fin de: No crea todo lo que lea en este capítulo. La fuente definitiva de información acerca de los mundos de vida es el sitio oficial, http://www.livingworlds.com, donde se pueden encontrar copias de la propuesta. La Vida Mundos propuesta serán en breve objeto de un grupo de trabajo en el nuevo Consorcio de VRML, que se asegurará de que el proceso por el cual es desarrollado estará abierta a todos. Podemos esperar que muchas de las mejoras se harán en la propuesta como resultado de ese proceso. En este capítulo vamos a examinar los conceptos básicos detrás de los mundos de vida, así como algunas de las características específicas de la norma. Incluso si los datos cambian, las ideas presentadas aquí se hacen más fácil para usted para comprender la evolución de cada especificación.

Algunos Filosofía básica Es importante entender los objetivos y la filosofía detrás de los mundos de vida antes de intentar comprender la propuesta en sí. En particular, es esencial para obtener un identificador de lo que la propuesta está tratando de lograr, y lo que no lo es. Gran parte de la confusión acerca de los mundos de vida se deriva de la falta de este entendimiento.

Algunos principios rectores La mayoría de las preguntas que surgen en relación con los mundos de vida son de la forma, "¿Por qué lo hacen así?" Casi todas esas preguntas pueden ser contestadas mediante el examen de los principios rectores de la propuesta. Hay razones para cada elección en el diseño de mundos de vida,

4 VRML 2.0 con Java CAPÍTULO 7

aunque usted aún puede encontrar las opciones de sorprender, es útil para entender el razonamiento detrás de ellos.

Código de Ejecución de exigir Ya hemos mencionado un aspecto clave de la filosofía de vida Mundos: requieren ejecutar código. Este requisito garantiza que la propuesta puede ser aplicada y cualquier ayuda a señalar las áreas problemáticas. En muchos sentidos, esta es una reminiscencia de las pruebas de interoperabilidad que se hizo en los primeros días de TCP / IP y otros protocolos.

Inicio de la construcción en VRML Una segunda idea clave es que los mundos de vida debe basarse en el fundamento de VRML 2.0. Este punto es una fuente común de confusión; Vida Mundos ha sido criticada sobre la base de que es demasiado "centrado en VRML", es decir, muy bien acoplado a VRML. Bien intencionadas, sin embargo, que puede ser crítica, es algo sin sentido, la esencia misma de los mundos de vida es que es una manera estándar de VRML para comunicarse con la tecnología subyacente de multiusuario. Diciendo que es demasiado centrada en VRML es como decir que un diccionario Inglés-Francés-Inglés es demasiado específica.

La neutralidad de arquitectura Mundos de vida también se esfuerza por ser "agnóstico arquitectura", es decir que no en todos los supuestos sobre lo que la tecnología subyacente es como multiusuario. En particular, se esfuerza por evitar la asunción de un servidor central. Es un éxito moderado en este sentido, sin embargo, el hecho de que los tres de las empresas que están trabajando en los mundos de vida ha elegido un diseño basado en grandes servidores centrales es problemático. Como la norma se desarrolla, es de esperar que la influencia de otras empresas y grupos de investigación se hará sentir, y que los restantes supuestos arquitectónico será anulada. Como acotación al margen, vale la pena señalar que existen problemas con los servidores centrales mundos cuando empiezan a llegar a ser muy grande, es por qué tantos sistemas multiusuario (DIS, BUCEO, SPLINE, y otros) han abandonado el enfoque de centro-servidor. Sin embargo, la mayoría de las organizaciones comerciales (incluidos los que impulsan la propuesta de los mundos de vida) utiliza un modelo de negocio que en torno a regalar el código de cliente y la venta de los servidores.

5 VRML 2.0 con Java CAPÍTULO 7

El papel del mercado Hablando de comerciales, otro elemento importante de la vida Mundos iniciativa es "respetar el papel del mercado." Este tema es de nuevo un tanto problemática, la propuesta (en la actualidad) dice que "El objetivo no es diseñar el mejor sistema imaginable" y que "el tiempo de comercialización es de la esencia." Aunque este práctico es admirable, queda por ver qué efecto tendrá sobre la propuesta en sí.

El último elemento de la filosofía que hay detrás de los mundos de vida es, esencialmente, que el diseño debe ser minimalististic para evitar sofocar la innovación. Esta idea es uno de los más importantes aspectos del universo de vida y es uno de sus mejores características.

¿Qué se necesita Vivir la propuesta identifica diez Mundos "metas técnicas" que son suficientes para la creación de entornos multiusuario. Estos objetivos se resumen a continuación. Insertar y eliminar objetos Tiene que haber alguna forma de nuevos objetos (incluidos los avatares de los usuarios) que se añadirá al entorno virtual y, posteriormente excluidos del mismo. Adición de un objeto en un cliente debe añadir que un mismo objeto en todos los demás clientes (por lo menos, aquellos a los que ese objeto es pertinente). Combinar múltiples corrientes de sonido Streaming de audio en tiempo real es un ingrediente esencial para la eficacia de los entornos virtuales multiusuario. Tiene que haber alguna forma de gestionar la distribución de la información asociada a los objetos en el entorno virtual. El seguimiento y la comunicación y el comportamiento de objetos Estado Como objetos moverse y cambiar su estado, que la información tiene que ser distribuidos a otros clientes en la red. Tenga en cuenta que los mundos de vida no se intenta abordar la compleja cuestión de lo que constituye el estado de un objeto virtual, sino que sólo señala que un mecanismo debe ser creado para permitir que el intercambio de información de estado.

6 VRML 2.0 con Java CAPÍTULO 7

Permitir que los objetos que se "impulsada" por los usuarios en tiempo real Humanos usuarios controlar muchos objetos, el caso más común que un usuario hacer funcionar su avatar. Esto requiere que el usuario se presente con algún tipo de interfaz que les permitan ejercer este control. Hazte dejar objetos persistentes El término persistencia se refiere al hecho de que algunos objetos están destinados a seguir siendo parte del mundo incluso después de que el usuario que los creó ha desconectado del sistema. Persistencia plantea una serie de interesantes cuestiones técnicas. Mundos de vida reconoce la necesidad de mecanismos de persistencia de algún tipo. Proteger la escena de los daños Esto se refiere a la integridad de los datos, es decir, asegurar que la escena no es dañado o incompatible. Esto es en gran parte la responsabilidad de la multi-tecnología, pero, de nuevo, los mundos de vida que reconoce como una característica que cualquier distribuidos mundo tendrá que tener. Asignar objetos a los propietarios Evidentemente, queremos ser capaces de identificar los objetos que pueden ser modificados mediante los cuales los usuarios, después de todo, no queremos que la gente modifica sus respectivos avatares o propiedad sin permiso. Para que esto sea posible, tenemos que asociar con cada propietario de un objeto. El propietario puede cambiar con el tiempo, pero en un momento determinado tendrá un objeto (como máximo) un propietario. Apoyo a la persistencia de roles Con el fin de que conceptos como objeto de propiedad tiene sentido, tenemos que ser capaces de identificar a los usuarios y especificar sus derechos de acceso en el mundo. Esta noción de la persistencia de los papeles es complejo, y en cierto grado se convierte en una cuestión filosófica sobre la naturaleza de la identidad. Enlace externo a la dinámica de objetos de datos y funciones El mundo virtual con vínculos a fuentes de datos, ya sea en línea u originarios en el mundo real, es una característica muy importante. Esto, a su vez se relaciona con los conceptos de identidad y la seguridad, ya que los datos externos puede ser un "certificado de autenticación" de un tipo u otro.

7 VRML 2.0 con Java CAPÍTULO 7

Apoyar un libre intercambio de información entre los objetos Esto permitiría a los datos de todo tipo que se pasan entre objetos virtuales. Sun Interactive negro, por ejemplo, tiene un concepto de "tarjetas de visita", que caen bajo el título de intercambio de información.

Algunas Cosas Hay mucho de la terminología en el ámbito de entornos virtuales multiusuario. Mundos de vida incluye una especie de glosario para ayudar a especificar lo que cada pieza de la jerga se refiere. La mayoría de las definiciones son bastante sencillos, sin embargo, hay algunos términos que son específicos de los mundos de vida, y estos merecen una mirada más de cerca. Mundos, escenas, y las zonas Mundos de vida se define como una escena continuamente navegables conjunto de objetos VRML. Un mundo es una colección de las escenas que están vinculados entre sí, por ejemplo, los nodos de anclaje. Una zona es una parte de una escena, delimitadas en el espacio, que es un contenedor para SharedObjects (que se definen a continuación). SharedObjects, Pilotos, Drones, Avatares, y 'Bots Mundos de vida considera a todos los objetos que han estado dinámicamente compartida que se SharedObjects. Un SharedObject puede operar en cualquiera de los dos modos: puede ser un piloto, que corre el objeto, o puede ser un zumbido, que refleja el comportamiento y el estado del piloto. En otras palabras, el estado y el comportamiento son compartidas desde el piloto a todos los aviones teledirigidos; típicamente sólo hay un piloto de cualquier SharedObject en un momento dado, y el número de aviones teledirigidos se ejecuta en diferentes clientes en la red. Un avatar es un SharedObject cuyo piloto está siendo operado por un ser humano. Un 'bot es un piloto cuya SharedObject es un proceso autónomo. MUtech Un término clave en los mundos de vida es MUtech, que significa "multitecnología". Se refiere a la parte del sistema multiusuario que se encuentra "debajo" de la especificación de los mundos de vida. La idea es que un número de empresas (incluyendo Negro Domingo, Apartado, y Sony) desarrollará su propio MUtechs, todo lo cual se comunicará a través de los mundos de vida a la interfaz de VRML mundo.

8 VRML 2.0 con Java CAPÍTULO 7

El universo Vida Modelo Conceptual

Figura 7.1 En caso de que los mundos de vida se inscribe en un sistema multiusuario Como puede ver, los mundos de vida es una fina capa de interfaz entre los dos grandes componentes de software: la tecnología multiusuario (o MUtech) y el navegador de VRML. Debajo de la MUtech es la propia red, normalmente Internet. El navegador de VRML, obviamente, también las conversaciones a la red, con el fin de recuperar los archivos VRML a través de HTTP, que hemos dejado fuera de este diagrama de la claridad. Los detalles de lo que se encuentra en el interior de la MUtech no son expuestos en la propuesta de los mundos de vida. Esa es una elección deliberada de diseño, después de todo, de vida sólo se refiere a los mundos VRML lado, y nada debajo de ella, a fin de lograr la máxima flexibilidad y dar cabida a todos los MUtechs. Tenga en cuenta que otras normas, como comunidad abierta y CyberSockets (véase el capítulo 8), describe la API para el MUtech misma. Esto significa que usted podría poner en práctica los mundos de vida por encima de Open Comunidad o CyberSockets. Cada proveedor de tecnología multiusuario es responsable de proporcionar una interfaz de los mundos de vida. Desde el punto de vista de un navegador de VRML VRML o un creador de contenido, la interfaz de los mundos de vida es un conjunto de nodos especiales. Es la descripción de estos nodos que componen la mayor parte de la especificación de los mundos de vida. Todas las propuestas de los mundos de vida nodos (y hay

9 VRML 2.0 con Java CAPÍTULO 7

decenas de ellos) pueden ser creados utilizando el prototipo de mecanismo de VRML 2.0, que se discutió en el Capítulo 3.

Algunos detalles sobre la vida Mundos Nodos Vamos a ampliar en el interfaz entre el navegador VRML y añadido de la Vida Mundos capa. En particular, vamos a examinar los dos mundos de vida más importantes nodos: SharedObject y para la zona. Cada uno de estos tiene un compañero de nodo que se asocia con la MUtech, que se llaman MUtechSharedObject y MUtechZone, respectivamente. Todas estas relaciones se ilustran en la Figura 7.2.

Figura 7.2 Una mirada más cercana a la interfaz de los mundos de vida Como se describe anteriormente, la SharedObject nodo es la representación de un objeto cuyo estado y el comportamiento son compartidas a través de la red. Los objetos que comparten en una escena siempre son hijos de un nodo de la zona. La Zona SharedObject y nodos son MUtech independiente. El nodo es SharedObject escrito por la persona que construye el objeto compartido (como un tercero avatar diseñador), la Zona nodo es escrito por la persona que construye el mundo, que también crea un nodo MUtechZone que es específico de la tecnología multi - que quieren utilizar su mundo. El mundo de autores, por lo tanto, es necesario hacer una elección de la tecnología multi-autoría en el tiempo. El SharedObject nodo tiene un lado público y privado lado. La parte privada que se llama un PrivateSharedObject, y no es accesible a otros SharedObjects en la escena. Esto supone un elemento de seguridad. Lo mismo puede decirse de la Zona de nodo, que tiene un componente PrivateZone además de su imagen pública. Los nodos en Detalle Como se señaló anteriormente, la propuesta incluye los mundos de vida de decenas de diferentes nodos. No vamos a examinar todos los nodos de la utilidad, sino que vamos a tener un acercamiento a las seis de las más importantes. SharedObject

10 VRML 2.0 con Java CAPÍTULO 7

Un SharedObject se divide en tres partes. La primera parte, llamada simplemente SharedObject, es la cara que presenta el objeto con el resto del mundo. Básicamente, la propuesta para el envío de un eventIn a la publicMessages compartidas-Objeto. El nodo es el autor de SharedObject por quien crea el objeto. La descripción de la SharedObject nodo es el siguiente: SharedObject { eventIn SFNode publicMessages exposedField SFNode private NULL eventOut MFNode getCertificates field MFNode certificates NULL eventIn SFBool makePrivate }

El ámbito privado a los puntos correspondientes PrivateSharedObject cuando el archivo VRML se carga por primera vez, pero el MUtech envía un makePrivate caso a la SharedObject, lo que provoca que el puntero que se establece en NULL. Esto permite que el MUtech para acceder a los campos de la PrivateSharedObject (VÍA y que dondequiera que se necesite), mientras que al mismo tiempo la prevención de otros objetos en la escena de la escritura a la PrivateSharedObject del eventIns. También hay un campo de certificados, que sea legible a través de la getCertificates eventOut. Este campo se utiliza para la autenticación, que está fuera del alcance de este libro. Cualquier libro sobre el comercio por Internet o la seguridad debe explicar cómo los certificados de trabajo. PrivateSharedObject El PrivateSharedObject es donde la mayoría de la información sobre el objeto se mantiene. Está escrito por la persona que crea el objeto. El PrivateSharedObject nodo tiene un montón de campos, por lo que vamos a examinar sólo las más importantes aquí. La descripción de la PrivateSharedObject tiene este aspecto: PrivateSharedObject { exposedField SFBool isPilot TRUE exposedField SFNode muTech NULL exposedField SFString alias "" campo MFNode visualDefinition [] exposedField SFNode selector NULL exposedField SFNode pilotSelector NULL exposedField SFNode publicMessages NULL exposedField SFNode privateMessages NULL exposedField SFNode currentState NULL exposedField SFVec3f posición 0 0 0

11 VRML 2.0 con Java CAPÍTULO 7

exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField exposedField

SFRotation orientación 0 0 1 0 SFVec3f toPosition 0 0 0 SFRotation toOrientation 0 0 1 0 SFTime toTime 0 SFBool isVisible TRUE SFBool persistentPilot FALSE MFString url "" SFBool isActive TRUE SFVec3f bboxSize 0 0 0 SFVec3f bboxCenter 0 0 0 SFBool escalable TRUE SFVec3F escala 1 1 1 SFBool reliableMotion TRUE SFBool persistentes TRUE SFBool isAvatar FALSE SFNode zona NULL

} Vamos a examinar los ámbitos en los grupos, sobre la base de sus funciones.

Campos rellenados por el Creador de los objetos El visualDefinition contiene el código de VRML que describe el objeto de la apariencia y el comportamiento. El bboxSize y bboxCenter campos describen el cuadro delimitador del objeto, que puede cambiar con el tiempo, y los cambios realizados por el piloto se envían a los aviones teledirigidos. El campo url contiene la URL del archivo SharedObject (aunque no es claro por qué esto es necesario, ya que el MUtech obviamente tenía que saber que, a fin de cargar el archivo en primer lugar). También hay una serie de banderas: isAvatar se establece para los objetos que se encuentran bajo el control de un ser humano; persistentes se establece para esos objetos que deben permanecer después de que su propietario ha firmado despegue; y persistentPilot se establece para esos objetos cuyo locus de control deben ser entregados a partir de alrededor de un lugar a otro con el fin de mantener vivo el objeto. La escalable bandera indica que el MUtech puede volver a la escala del objeto si es necesario, fiable y de movimiento es un indicio de que el movimiento de datos para este objeto debe ser enviada fiable (por ejemplo, algunos de protocolo se debe utilizar para asegurarse de que obtener las actualizaciones a través de lugar de ser descartadas cuando las cargas son altas). El selector de campo ofrece un menú de acciones que los usuarios pueden realizar en la SharedObject. Por ejemplo, si quiere patear un balón de fútbol, puede seleccionar un "retroceso" del menú de la bola. PilotSelector el campo se utiliza para presentar una acción de menú para el usuario que

12 VRML 2.0 con Java CAPÍTULO 7

está operando este SharedObject. Por ejemplo, podría haber entradas como "caminando", "ejecutar", y "bailar la Macarena".

Este enfoque de la utilización de los menús para el comportamiento ha suscitado gran preocupación entre los que están estudiando la propuesta de los mundos de vida. Los menús están intrínsecamente una interfaz bidimensional metáfora y están mal adaptados a un mundo tridimensional. Es posible que este enfoque puede ser re-pensado por el momento en que la propuesta es Vida Mundos finalizado.

Campos rellenados y / o mantenida por la MUtech Hay una serie de campos en un PrivateSharedObject que se cumplimentará por la MUtech cuando el objeto sea creado. La más obvia es la muTech propio campo, lo que apunta a un nodo MUtechSharedObject (descrito más adelante). La escala de campo se utiliza para aumentar la escala del objeto si es necesario, en el supuesto de que es permitido por la bandera escalable se ha descrito anteriormente. La zona de campo está configurado para apuntar a la zona que pertenece a este SharedObject. El isVisible pabellón podrá ser fijado por el MUtech cuando el objeto está fuera del rango visible o oscurecida por la geometría fija escena. Es típicamente un interruptor de control de nodo que se apaga la visualDefinition del objeto. IsPilot el campo es algo de un caso especial. , El fichero es fijado por el MUtech de la máquina cliente que crea el objeto, pero, en caso de que la máquina se desconecta y persistentPilot la bandera se ha fijado, el MUtech que elegir otro ejemplo de la PrivateSharedObject para asumir como piloto y establecer que la instancia isPilot pabellón. Es hasta el MUtech para garantizar que una y sólo una instancia de un SharedObject tendrá la isPilot pabellón conjunto. Por supuesto, esto plantea una cuestión interesante: ¿Qué pasa si todo el mundo deja el mundo? Bueno, desde el estado de un objeto se mantiene en su totalidad en los nodos gestionados por el navegador, el MUtech que teóricamente tienen que lanzar un navegador de VRML (o el equivalente de uno) sólo para mantener el estado compartido. Se trata de un diseño bastante extraño, pero es requerido por la naturaleza de VRML-céntrico de la Vida Mundos propuesta.

Campos compartidos por la MUtech Hay una serie de campos que cambian dinámicamente con el tiempo. Estos campos se comparten los pilotos de aviones teledirigidos para la MUtech; cuando un piloto cambia uno de estos campos, que el cambio se comunica a

13 VRML 2.0 con Java CAPÍTULO 7

través de la red a los aviones teledirigidos. Los tres campos son más básicos toPosition, toOrientation, y toTime, que dan la ubicación de destino y la orientación para la SharedObject por llegar a un objetivo particular del tiempo. El uso de toTime permite interpolación posición en el extremo receptor. El currentState también es compartida, aunque en el momento en que el diseño de mundos de vida se limita a un conjunto de etiquetas / valor pares. Aun así, es útil para ciertos tipos de comportamiento rudimentario (de onda, la danza, ese tipo de cosas). El apodo de campo también es compartida con los pilotos de aviones teledirigidos, de modo que los usuarios pueden cambiar su apodo en cualquier momento (suponiendo que el MUtech lo permite). MUtechSharedObject El nodo nunca se MUtechSharedObject Autor. En cambio, es creado por la tecnología multiusuario y que se adjunta a la PrivateSharedObject nodo a través de ese nodo de muTech campo. Independientemente de que pueda contener los campos MUtech vendedor exige, sino que debe contener al menos los siguientes elementos:

MUtechSharedObject { eventIn SFNode messageToPilot eventIn SFNode messageToLocalPilot eventIn SFNode replyToDrone eventOut SFTime timeDelta } El campo da timeDelta la diferencia entre el cliente y el reloj del MUtech del reloj. Los demás campos se utilizan para proporcionar un medio de envío de mensajes a los objetos compartidos del piloto (a través de la messageToPilot campo) y para enrutar los mensajes que se envían a los SharedObject del campo a la publicMessage avatar en la máquina local (a través de la messageToLocalPilot campo). El replyToDrone eventIn se utiliza para enviar mensajes a un zumbido. En este capítulo se ha escrito, todo el mecanismo de paso de mensajes en los mundos de vida aún está en evolución. Para obtener más información acerca de pasar el mensaje, se refieren a la especificación de los mundos de vida en sí.

Zona Una zona también está dividido en tres partes: la zona, PrivateZone, y MUtechZone. El nodo de la zona es la única parte que está accesible para el resto de la escena, y que tiene este aspecto: Zone { eventIn MFNode addChildren [] eventIn MFNode removeChildren []

14 VRML 2.0 con Java CAPÍTULO 7

eventOut MFNode getChildren }

Este nodo se crea por el constructor del mundo. Ya que no tiene campos (sólo eventIns y eventOuts) y debe ser llamado de modo que puede enviarse a partir de y dirigida, siempre será por escrito simplemente como: DEF SomeName Zona) { donde "SomeName" es un nombre arbitrario. El AddChildren removeChildren eventIns y se distribuyan a través de un script para el nodo correspondiente acontecimientos en la PrivateZone (descrito más adelante).

PrivateZone El nodo es PrivateZone donde la mayoría de los datos relativos a la zona se almacena. Al igual que el nodo de la zona, es escrito por la persona que construye el mundo. Su descripción es así: PrivateZone { exposedField SFVec3f avatarPosition exposedField SFVec3f avatarOrientation eventIn SFNode avatar campo MFString addChildToZoneScript "Urn: inet: livingworlds.com: scripts / addChildToZone" eventIn MFNode AddChildren eventIn MFNode removeChildren exposedField MFNode niños [] exposedField SFBool isActive TRUE exposedField SFVec3f bboxSize 1e99 1e99 1e99 exposedField SFVec3f bboxCenter 0 0 0 campo SFBool isVisible TRUE exposedField SFString whichTechnology "" campo SFNode MUtech NULL exposedField SFNode navigationInfo NULL eventIn MFString zoneCapabilities eventIn SFNode signAndForward } El constructor del mundo se espera que ponga un ProximitySensor en la escena y su VÍA position_changed y orientation_changed eventOuts a la PrivateZone del avatarPosition y avatarOrientation eventIns, que es la forma en que el MUtech descubre la ubicación actual del usuario. Como se mencionó anteriormente, la AddChildren removeChildren campos y

15 VRML 2.0 con Java CAPÍTULO 7

se dirigen a los campos correspondientes de la Zona nodo. Los niños de campo almacena la SharedObject nodos, y addChildToZone la secuencia de comandos se utiliza para filtrar las solicitudes de añadir y eliminar SharedObject nodos. El avatar de campo a los puntos SharedObject que corresponde al usuario del avatar. El PrivateZone del bboxcenter y bboxsize campos son constantemente actualizados por la MUtech definir una caja alrededor de todos los nodos de la Zona SharedObject contiene. Este cuadro suele ser enviado a la ProximitySensor que el mundo constructor de Autor. Cuando el usuario entra en que ProximitySensor, que incluye la zona, el evento isActive informa a la zona (que informa a la MUtechZone) el hecho de que esta zona está actualmente activa-en otras palabras, ocupados por el usuario. El isVisible campo indica si la zona es en realidad una colección de objetos visibles que se dictarán (isVisible es cierto) o una colección de nodos que están dispersos por todo el escenario gráfico (isVisible es FALSE). El whichTechnology campo es rellenado por el MUtech y puede ser usado por los nodos para averiguar qué multiusuario tecnología está en uso. MUtechZone el nodo que la contenida en (o utilizado en) MUtech el campo de la zona es donde la realidad MUtech "vidas".

MUtechZone El nodo MUtechZone realmente ser diferentes para cada tecnología multiusuario. Por ejemplo, una empresa denominada "Tecnologías de Waterloo" podría ofrecer un nodo llamado WaterlooZone. Nodo que normalmente contienen una secuencia de comandos que se aplica la MUtech (o una interfaz con un MUtech). No hay mucho más que decir sobre MUtechZone, ya que cada vendedor se apliquen de manera diferente. Normalmente, el MUtechZone se referencia el nodo de la zona. También es responsable de instanciar el avatar del usuario cuando el usuario entra en la cámara de la zona. El ejemplo de la Vida Mundos proyecto de propuesta se ve algo como esto: DEF Zona Z {} DEF PZ PrivateZone { whichTechnology "urn: inet: waterloo.com" MUtech WaterlooZone { SFNode USO zona campo Z

16 VRML 2.0 con Java CAPÍTULO 7

campo SFNode privateZone USO PZ } } El nodo WaterlooZone se define utilizando una EXTERNPROTO. No es necesario que tenga una zona de campo o un campo privateZone; estos son sólo algunos ejemplos. Sin embargo, la secuencia de comandos en el interior del nodo PrivateZone por lo general, quieren tener acceso a la zona y la PrivateZone nodos, y esta es la manera de hacerlo. Tenga en cuenta que el nodo es MUtechZone escrito por la persona que construye el mundo. Esto requiere que el mundo-constructor seleccionar una tecnología multiusuario. Por supuesto, que no se opone a la reutilización de los mundos con diferentes tecnologías, el fragmento de código anterior podría haber tenido: "Inline" (url "http://somehost.somewhere.com/someworld.wrl") añadido a la misma. El archivo resultante VRML simplemente sirven para vincular el lugar especificado por la geometría en línea con el nodo de la tecnología multi-especificada por el MUtechZone nodo.

¿Cómo funciona todo Vamos a trazar la secuencia de los acontecimientos que se producirían en un período de sesiones típico multiusuario en el universo de vida modelo. Cuando el mundo se carga por primera vez, el nodo PrivateZone mundo creado por el autor sea procesado. Como parte de esa transformación, los MUtechZone nodo MUtech se hace referencia en su campo es inicializado. Este nodo contiene un archivo de comandos, generalmente escrito en Java, que se aplica la tecnología multiusuario. Cuando el nodo está cargado, su código de inicialización que se llama y una serie de cosas. Muchos de ellos son MUtech específica, pero algunos no son, por ejemplo, la MUtech querrá RUTA de los campos de la zona y PrivateZone nodos, como isActive. Además, el MUtech se iniciará la actualización de la bboxsize y bboxcenter campos de la zona, los cuales controlan la ubicación y el tamaño de la ProximitySensor que rastrea la ubicación del usuario. El usuario navega por el mundo y en algún momento entra en el ProximitySensor que rodea la zona. El isActive eventOut del ProximitySensor

17 VRML 2.0 con Java CAPÍTULO 7

se dirige a la entrada en el isActive PrivateZone, lo que permite a la MUtech notar y hacer lo que tiene que hacer mientras el usuario está presente. También recibe actualizaciones sobre la avatarPosition y avatarOrientation (que eran dirigidas desde la ProximitySensor a la zona) y pasa a la tecnología multiusuario. La instancia de usuario de su avatar y se lo pasa a la AddChildren-En caso de la Zona. El avatar es típicamente tratados por la zona del addChildrenToZone escritura, puede hacer que algunos de validación definidos por el autor mundo. El MUtech avisos de que un niño se ha añadido y envía una actualización apropiada. Cuando llega una actualización de algunos SharedObjects cuyo piloto se está ejecutando en otro anfitrión, el toPosition, toOrientation, toTime y campos para el nodo correspondiente PrivateSharedObject se establecen. La aplicación de la PrivateSharedObject se espera que tome las medidas apropiadas, tales como el establecimiento de los valores apropiados en un nodo de transformación o ajuste de los valores de PositionInterpolator y nodos OrientationInterpolator a causa de la entidad para pasar sin problemas a su ubicación de destino y la orientación.