How to configure server-side asset storages.
Jukka Jylänki
asset refs, storages, providers, disk source and the cache works. The new
tree merge brought new features to this system and I doubt anyone knows
this yet too well.
One particularly important feature that has been implemented into Tundra2,
which was missing from Tundra1, is the ability to configure server-side
asset storages which requires zero client configuration. This feature is
documented in doxygen, but it looks like the online docs are still
generated from the old branch, so it doesn't show up online.
When you are hosting your scene on your Tundra2 server, you can associate
a HTTP server with that Tundra2 server. When a client joins the scene, it
will receive the asset storages that the server knows about using a
discovery mechanism, which enables the client to resolve relative asset
references to the HTTP server that is being used. The overall benefit of
this is that scenes can be created in a portable manner without having to
hardcode absolute HTTP addresses to asset references.
This video shows how the configuration is done:
http://80.75.107.153/tundra2/AvatarMenu.wmv
There is no audio, so I will walk through the steps here:
1. The asset storage is configured to be used with the server using a
commandline startup parameter --storage. This parameter is given a value
that is called an Asset Storage Serialization String. Because the online
docs are from the wrong branch, I can only link to this page
https://github.com/realXtend/naali/blob/tundra2_withhistory/src/Core/AssetModule/doc/SettingUpWebdav.dox
.
- The HTTP asset storage can also be added at runtime using a console
command, but it is generally more convenient to create a server start
batch script which contains this configuration data.
2. The client is started. Note that manually specifying the --storage
parameter is not necessary as it was with Tundra1, since the client will
now get the storage from the server.
3. In the video, the HTTP storage has also been configured to enable HTTP
PUT using WebDav. This allows the user to upload content to the Web
storage. The user chooses Import.. for the Web storage, and chooses the
files to add to that storage.
4. The files get uploaded. In this particular scene, there exists a .js
script which displays a toolbar menu that shows all the avatar assets in
the scene.
Additional properties:
- One can use the localDir= attribute of the HttpAssetStorage to tell the
Tundra2 server that the HTTP address is actually being hosted on the same
machine than the Tundra2 server. This enables the server to use a local
path as an alias to the assets, and to perform asset discovery operations
directly on the local filesystem. The client will do directory discovery
operations onto the HTTP server using WebDav.
- Once the client joins the server scene and the server has informed the
client about the asset storages, the client will set as its default
storage the same storage that the server has as its default storage. This
allows both the client and the server to agree how relative asset refs,
like "foo.png" (instead of e.g. "http://server.com/foo.png") are resolved.
- If the server detects an incoming connection from localhost, it will
also transfer all LocalAssetStorages to the client. This ensures the
client will never need to use the --storage specifier, even when
developing locally without a HTTP server.
jj