Professional Documents
Culture Documents
Contenido CAPÍTULO 7
• Historia y Evolución
• Algunos Filosofía básica
• Algunos Jerga
2
Historia y Evolución
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
aunque usted aún puede encontrar las opciones de sorprender, es útil para
entender el razonamiento detrás de ellos.
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
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
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
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).
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
MUtech
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.
Figura 7.2 Una mirada más cercana a la interfaz de los mundos de vida
SharedObject
10
SharedObject {
eventIn SFNode publicMessages
exposedField SFNode private NULL
eventOut MFNode getCertificates
field MFNode certificates NULL
eventIn SFBool makePrivate
}
PrivateSharedObject
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
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).
está operando este SharedObject. Por ejemplo, podría haber entradas como
"caminando", "ejecutar", y "bailar la Macarena".
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.
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
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.
MUtechSharedObject {
eventIn SFNode messageToPilot
eventIn SFNode messageToLocalPilot
eventIn SFNode replyToDrone
eventOut SFTime timeDelta
}
Zone {
eventIn MFNode addChildren []
eventIn MFNode removeChildren []
14
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:
PrivateZone
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
}
MUtechZone
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