Trucos de persistencia
La persistencia está disponible cuando la plataforma subyacente la admite. Actualmente, esto está limitado a la familia de dispositivos HoloLens, a través de la compatibilidad con VR (XR heredada) integrada de Unity.
Persistencia básica
La persistencia básica de World Locking Tools está habilitada de forma predeterminada. Esta habilitación se divide en dos partes.
Las casillas pertinentes aquí son "AutoLoad" (Carga automática) y "AutoSave" (Autoguardado), que están activadas. Es posible que las vea atenuadas. Esto se debe a que forman parte de la opción "Use Defaults" (Usar valores predeterminados). Al deshabilitar "Use Defaults", se permite seleccionar combinaciones arbitrarias de las opciones de automatización.
Puede consultar más información sobre estas opciones de configuración y su manipulación desde el script.
AutoSave
La opción AutoSave (Autoguardado) le indica a WLT que realice guardados de estado frecuentes mientras se ejecuta la aplicación. En cualquier momento, se puede terminar la aplicación con una pérdida mínima del estado.
AutoLoad
La opción AutoLoad (Carga automática) le indica a WLT que cargue en el inicio cualquier estado guardado previamente. Esto permite que la aplicación reanude una nueva sesión en el punto en el que se desconectó (de WLT) en la última sesión.
Persistencia completa
Con las opciones AutoSave y AutoLoad habilitadas, WLT funciona de forma fluida entre sesiones. Aunque la posición y la orientación del espacio global son arbitrarias en la primera ejecución (puesto que no hay ningún estado previo guardado y se usa la posición de la cabeza en el inicio como origen), las ejecuciones posteriores compartirán ese mismo sistema de coordenadas.
Esto conduce a un comportamiento interesante cuando la aplicación inicia una nueva sesión en un espacio desconectado del espacio de la sesión anterior. Consulte la sección Persistencia por ubicación más adelante para obtener más información.
Nota:
Las opciones AutoSave (Autoguardado) y AutoLoad (Carga automática) también se aplican a los marcadores espaciales globales. Consulte esta sección más adelante para obtener más información.
Control de la aplicación sobre la persistencia
La persistencia completa predeterminada es válida para una amplia gama de aplicaciones.
No obstante, es posible que algunas aplicaciones quieran tener un control más preciso sobre el proceso.
Puede parecer extraño que la habilitación de la persistencia automática en WLT se divida en dos propiedades: AutoSave y AutoLoad. Examinar los casos donde se usan las dos de forma independiente puede aportar información sobre el sistema de persistencia global.
AutoSave sin AutoLoad
Con esta configuración, se establece WLT para que guarde su estado periódicamente. Sin embargo, no carga automáticamente ningún estado persistente en el inicio.
En su lugar, el sistema se inicia con un estado nuevo, como si fuera la primera vez que se ejecuta en este dispositivo. Solo después de una solicitud explícita a Load(), restaura el estado de la sesión anterior.
Esto permite a la aplicación decidir si sería apropiado o no restaurar el estado de la sesión anterior e, incluso, modificar los datos que se restauran si es necesario.
El estado de guardado general de WLT se encuentra en el archivo "LocalState/frozenWorldState.hkfw". Una vez creado por WLT, el archivo se puede copiar en otra ubicación y restaurarlo a discreción de la aplicación.
El nombre predeterminado del archivo de guardado para los datos de alineación (marcador espacial) es "LocalState/Persistence/Alignment.fwb". Sin embargo, la aplicación puede reemplazarlo con la opción SaveFileName del administrador de alineación.
La decisión de cargar el estado de la sesión anterior con esta configuración debe tomarse en el inicio. Una vez que se ejecuta el estado guardado de la sesión anterior, se sobrescribe con el estado de esta sesión. Para obtener una configuración más flexible, consulte la sección Guardado y carga manuales más adelante.
Guardado manual sin AutoLoad
Con esta configuración, WLT carga cualquier estado disponible de una sesión anterior en el inicio. Sin embargo, no guarda el estado automáticamente. Esto permite a la aplicación decidir si merece la pena guardar el estado y cuándo hacerlo, con una llamada a Save().
AutoLoad solo le indica a WLT que cargue cualquier estado disponible en el inicio. La aplicación es libre de restaurar cualquier estado guardado en cualquier momento con una llamada explícita a Load().
Guardado y carga manuales
La aplicación puede optar por mantener el control total sobre el proceso de guardado y carga.
En este caso, el estado se guarda únicamente con una llamada explícita de la aplicación a Save() y solo se carga con una llamada explícita a Load().
Es posible que el estado que se carga con la llamada a Load() se haya guardado antes en esta sesión o en una sesión anterior.
Deshabilitación de la persistencia
Como hemos explicado antes, la persistencia siempre está disponible para la aplicación desde el script. La persistencia automatizada puede habilitarse y deshabilitarse desde el script o a través de WorldLockingContext en el inspector. Si la persistencia automatizada está deshabilitada, WLT no intentará guardar ni cargar el estado sin una solicitud explícita de la aplicación.
Por supuesto, puesto que la directiva AutoLoad solo afecta a si se carga o no el estado en el inicio, si se cambia el valor del script después del inicio, no tiene ningún efecto.
Precaución durante el desarrollo
Como hemos indicado antes, la ubicación de los archivos guardados para todo WLT y la alineación son globales para la aplicación. En concreto, los nodos de alineación, también conocidos como marcadores espaciales, se conservan por nombre (consulte esta sección más adelante). Si una aplicación guarda el estado con un conjunto de marcadores espaciales de una escena y, a continuación, carga el estado con un conjunto de marcadores espaciales de otra escena y los dos conjuntos de marcadores comparten nombres comunes, el comportamiento es indefinido.
Hay varias maneras de resolver este problema. Si es posible, lo mejor es simplemente no reutilizar nombres de marcadores espaciales dentro de un mismo proyecto. Si, después de la reimplementación, ve un comportamiento inesperado de deslizamiento de la escena, pruebe eliminado el estado guardado de WLT. Asimismo, cuando se cambia radicalmente la aplicación, es posible que alguien extremadamente cauteloso quiera eliminar los archivos guardados de WLT del dispositivo o, simplemente, desinstalar la aplicación antes de instalar la nueva versión.
Persistencia por ubicación
El escenario
Hay una clase interesante de aplicaciones que se ejecutan en varias ubicaciones físicas. Puede que se ejecute la aplicación en la sala A, se cierre el dispositivo, se cambie de lugar y se reinicie la aplicación en la sala B. La sala B puede estar a continuación de la sala A o en otro continente. La aplicación y el dispositivo no tienen forma de saberlo.
Para hacerlo más simple, supongamos que la aplicación está configurada para la persistencia manual de WLT.
Una demostración
Imagine estas salas A y B no conectadas.
La aplicación se inicia en la sala A. Después de establecer un espacio de coordenadas inmovilizado contiguo dentro de la sala, se asigna toda la sala al fragmento 1. Se coloca un objeto X de holograma persistente en la sala. A continuación, la aplicación guarda el estado y se cierra.
Se apaga el dispositivo, se lleva a la sala B y se vuelve a iniciar.
El dispositivo reconoce que no es la sala A, por lo que WLT asigna un nuevo identificador de fragmento a su contenido, por ejemplo, ID == 29. ¿Por qué 29? Porque no es 1. Los identificadores de fragmentos tienen un valor arbitrario. Excepto con el uno, el identificador de un fragmento no será FragmentId.Invalid ni FragmentId.Unknown, ni será igual a ningún otro fragmento conocido.
Ahora hay dos fragmentos y no hay forma de combinarlos (ya que no hay información disponible sobre sus ubicaciones relativas).
El desarrollador de la aplicación podría preguntarse con interés: "He puesto un objeto X persistente en la sala A, ¿qué ocurre cuando se carga el objeto X al iniciarse la aplicación en la sala B?".
La respuesta es que se deja al desarrollador de la aplicación que determine el comportamiento. El identificador del fragmento actual cuando se pone el objeto X en la sala A está disponible y se puede conservar. Después, la aplicación puede decidir en el inicio si se muestra el objeto X o no en función de si el fragmento actual es el mismo que cuando se creó o no.
En este caso, el desarrollador decide (e implementa) que el objeto X solo se cargará si el identificador del fragmento actual es uno, y el objeto Y, de la sala B, solo se cargará si el fragmento actual es 29.
La persistencia del identificador de fragmento asociado a un espacio se guarda como parte de la persistencia de World Locking Tools. Sin embargo, la persistencia del identificador de fragmento asociado a un objeto, así como las acciones que se deben realizar en función de él, se dejan en la aplicación.
Junto con el identificador de fragmento asociado al objeto, se puede guardar su posición en el espacio global. Después, si el identificador de fragmento coincide, una vez cargado el objeto, se puede restaurar su posición y devolver el objeto a su posición en el mundo físico durante la última sesión. Con la persistencia de World Locking Tools, una posición permanece fija entre sesiones respecto a las características del mundo físico que la rodean.
Persistencia de los marcadores espaciales
Se puede decir que los marcadores espaciales (SpacePin) son como contenedores del lado de la aplicación para los anclajes de alineación (AlignmentAnchor). Mientras los marcadores espaciales (y las clases derivadas) son componentes de Unity, los anclajes de alineación son puramente conceptuales, no hay ninguna clase ni tipo correspondiente a un anclaje de alineación. Por tanto, en esta explicación, se usará marcadores espaciales y anclajes de alineación indistintamente, con una preferencia general por marcadores espaciales.
Sin embargo, podría resultar confuso que AlignmentManager pueda conservar marcadores espaciales si no tiene ninguna noción de ellos. Esto se debe a que AlignmentManager administra el elemento conceptual AlignmentAnchor, que representa la esencia de un elemento SpacePin y a partir del cual se puede reconstituir un SpacePin.
Hay más controles a nivel de aplicación para la persistencia de los marcadores espaciales que con el sistema de persistencia general de WLT, porque los marcadores espaciales están intrínsecamente más controlados por la entrada de la aplicación que por el resto de las herramientas de World Locking Tools.
Es importante recordar que los marcadores espaciales (SpacePin) y los anclajes de alineación (AlignmentAnchor) se conservan por nombre. Este es un requisito ligeramente más exigente que el general de que no haya dos marcadores espaciales activos en el mismo IAlignmentManager con el mismo nombre. Si se conservan marcadores espaciales, no puede haber dos marcadores espaciales en la misma base de datos con el mismo nombre, tanto si están activos como si no.
Bases de datos del administrador de alineación
Cada IAlignmentManager tiene una base de datos de marcadores espaciales por nombre, según lo indica su implementación de RestoreAlignmentAnchor(string nombreÚnico, Pose posiciónVirtual).
Base de datos de alineaciones global
Hay un IAlignmentManager global, que pertenece a WorldLockingManager.GetInstance(). Como hemos mencionado, la ubicación predeterminada de los archivos guardados viene determinada por la propiedad SaveFileName. Tenga en cuenta que SaveFileName es una propiedad de la clase AlignmentManager, no de la interfaz IAlignmentManager. Una implementación de IAlignmentManager podría implementar la persistencia sin ningún concepto de archivos ni nombres de archivo. SaveFileName es un artefacto de la manera en la que AlignmentManager implementa la persistencia, por lo que está restringido a AlignmentManager.
Bases de datos de alineaciones locales
Puede haber cualquier número de administradores de alineación de subespacios, uno para cada elemento AlignSubtree que aparece como el campo AlignSubtree.alignmentManager. Además, la aplicación puede crear sus propias instancias de AlignmentManager o, incluso, sus propias clases derivadas de IAlignmentManager.
El AlignmentManager de cada componente AlignSubtree tiene su propia ubicación para los archivos guardados, que tiene como valor predeterminado el nombre de GameObject con la extensión ".fwb". Por ejemplo, si el componente AlignSubtree está en un GameObject denominado "MyRoot", el archivo guardado se denominaría "MyRoot.fwb". Se puede usar una barra diagonal (/) para indicar una subcarpeta. Probablemente, no sería bueno que dos componentes AlignSubtree usasen la misma ubicación para los archivos guardados.
Pero, en realidad
Se recomienda encarecidamente dar nombres únicos globales a los marcadores espaciales y los anclajes de alineación, porque, a largo plazo, es más sencillo y sólido que intentar administrar el requisito más ligero de que sean únicos solo localmente. Pero haga lo que prefiera.