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 "multi-

tecnologí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 SFRotation orientación 0 0 1 0

exposedField SFVec3f toPosition 0 0 0
exposedField SFRotation toOrientation 0 0 1 0
exposedField SFTime toTime 0
exposedField SFBool isVisible TRUE
exposedField SFBool persistentPilot FALSE
exposedField MFString url ""
exposedField SFBool isActive TRUE
exposedField SFVec3f bboxSize 0 0 0
exposedField SFVec3f bboxCenter 0 0 0
exposedField SFBool escalable TRUE
exposedField SFVec3F escala 1 1 1
exposedField SFBool reliableMotion TRUE
exposedField SFBool persistentes TRUE
exposedField SFBool isAvatar FALSE
exposedField 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.