Reported problems with volume asset duplication.

[David Williams]

A VolumeData asset is a very thin wrapper around a Cubiquity voxel database (it just holds a path to one), and so when a volume data asset is duplicated it still points to the same voxel database. This might be tricky to fix as it's not clear that we can catch the asset duplication event.

The AssetModificationProcesor class may give a chance here but it seems it requires team license. Otherwise we might need to check when a voxel database is already open and give a warning to the user.

[David Williams]

Just some additional notes and thoughts here.

The underlying Cubiquity library is being modified so that a VDB can be opened as read only. In this mode it is still possible to modify voxels (they get written to a temporary table/database) but it is not possible to commit/accept them into the main .vdb file.

I am expecting this will help with the volume duplication scenario because multiple volumes may be able to share a single read-only VDB, provided they use different temporary databases. It may even solve the problem of duplicating in play mode, because in play mode we should probably assume that the game could be running off a read-only filesystem anyway and so should open the database as read-only.

In edit-mode, it might also be desirable to allow the user to flag volumes or volume assets as being read-only for the same reason. If the volume data has been exported from elsewhere and the developer is not planning to modify it in the Unity editor then this could be useful (it could still be edited in play-mode using the temp database).

[David Williams]

Many changes have been made to detect volume/asset duplication, and the current situation is now documented in the user manual.