Persisting both anchors and holograms

MarcinK

Hi,

I've been using world anchor store to save information about anchors and recreating them in the next session. What I couldn't figure out is how to determine what holograms were placed on those anchors. Is there any suggested way of persisting holograms for hololens?

Marcin

stepan_stulov

@MarcinK

Correct, world anchor store, just as its name suggests, only provides persistence of world anchors and nothing else. It doesn't care what you do with those anchors metaphorically speaking. You can use them, not use them, do some wild topology calibration with them etc.

You cannot really "save game objects" per se. Unless you use some savegame plugin (of which there are plenty). What you usually save is just enough data that suffices to recreate your game objects on relaunch. For example simply a list of game objects, their origin prefabs and, say, health amounts. Then you simply read those values, instantiate new game objects from the corresponding prefabs and set health values.

By having world anchor store dedicated to anchors only you are trapped to have two sources of persistent information to make up the final runtime state of your game objects. In such case I would always recommend to make one of those sources an authority. In this case PlayerPrefs will store the list of your objects while the anchor store will supplement them with the anchors. If the anchor for the specific object is not there - bad luck, if there are more anchors than needed - clean up.

HoloToolkit, to my knowledge, doesn't have game object saving functionality because it would be the fifth wheel there.

stepan_stulov

Hi, @MarcinK

There are two things to this:

1. How do you know what hologram was placed and whose anchor was saved to the store? Well, when you save a hologram you assign a world anchor id to it. So then later on you can enumerate all the ids form the store and restore you holograms. You simply need to establish a one-to-one correspondence between holograms and ids.
2. To persist the state of the app apart from spatial mapping you can simply use Unity's PlayerPrefs or really any other method of persistence of custom data.

Or did I misunderstand the question? It seem a little bit unclear to me as since you figured how to save and re-load the anchors with their corresponding ids you shouldn't even be asking this question, you already did the job.

MarcinK

@stepan_stulov
Thanks for the reply!

As far as i understand World Anchor Store allows storing only World Anchors without any reference to GameObjects they were attached to. I was wandering if HoloToolKit provides any way of saving GameObjects with their corresponding anchors.

From your post i understand that GameObjects have to be saved separately and then assigned to their Anchors from World Anchor Store when application restarts. Is that right?

stepan_stulov

Correct, world anchor store, just as its name suggests, only stores a table of world anchors (however they're encoded) by their unique string IDs. It doesn't care what exactly you do with it: create game objects with, use for some wild topology calibration or nothing at all.

You can't really "save GameObjects" per se, unless you use some kind of high-level scene serialization plugin. What you usually do is save only that which suffices for restoring. For example game object names, what prefab they're instantiated from and their transforms. Then you can read it back and re-create new game objects from that data. But this is your application-level code. It won't be in any framework. It's on you and it highly depends on your requirements.

Technically, with the world anchor store for anchors and PlayerPrefs for whatever else state you have two sources of data that make up the actual runtime state of your holograms. You can always give one of those sources an "authority". I recommend giving it to PlayerPrefs. So you read a list of you saved holograms and what prefabs they're instances of and instantiate accordingly. Then you supplement those holograms with anchors from the store. If the store doesn't have an anchor there - bad luck, next time. If there are are some excessive anchors, for which no objects exists anymore, - just clean them up.

HoloToolkit doesn't provide any game object persistence as far as I know because it doesn't need to, it already exists in the lower level API: PlayerPrefs.

stepan_stulov

@MarcinK

Correct, world anchor store, just as its name suggests, only provides persistence of world anchors and nothing else. It doesn't care what you do with those anchors metaphorically speaking. You can use them, not use them, do some wild topology calibration with them etc.

You cannot really "save game objects" per se. Unless you use some savegame plugin (of which there are plenty). What you usually save is just enough data that suffices to recreate your game objects on relaunch. For example simply a list of game objects, their origin prefabs and, say, health amounts. Then you simply read those values, instantiate new game objects from the corresponding prefabs and set health values.

By having world anchor store dedicated to anchors only you are trapped to have two sources of persistent information to make up the final runtime state of your game objects. In such case I would always recommend to make one of those sources an authority. In this case PlayerPrefs will store the list of your objects while the anchor store will supplement them with the anchors. If the anchor for the specific object is not there - bad luck, if there are more anchors than needed - clean up.

HoloToolkit, to my knowledge, doesn't have game object saving functionality because it would be the fifth wheel there.