Overview: Database
Transactions / Scopes
The neuray database supports the concept of multiple hierarchical scopes which can be used to store different scenes or different versions of the same scene at the same time. In the latter case identical parts of the data can be shared between the different versions of the scene with the potential to drastically reduce the amount of memory needed. See [ NRTP ] documentation for details.
The neuray database supports transactions. Each usage of the database including editing the scene and rendering is done using a transaction. It is possible to have different versions of objects in the database at the same time. The transaction is used by the database to select which of the versions is returned when a renderer or an application accesses the object. A transaction is also used to keep the database consistent. Open transactions are isolated from each other. This means that changes done in one transaction are never visible to other open transactions.
You can commit a transactions in which case all changes in that transaction become visible at once for subsequently started transactions. You can also abort a transaction in which case all changes are discarded.
Database Operations
The neuray system uses an internal distributed database to store scene objects. Using scopes, you can have many scenes in the database at the same time which do not interfere with each other.
You can create, retrieve and modify scene objects in the database, such as cameras, options, groups, instances, objects, meshes, and functions. Any thread which has access to an open transaction can at any time create and edit database objects. The database API is written to support multithreaded accesses. It is the applications responsibility to synchronize concurrent changes to single database objects, though. It is also the applications responsibility that concurrent changes from different threads result in an overall consistent database content.
In addition to creating scenes using the neuray API, you can also use the built-in or custom importers to load scenes from files. The content read from those files will be loaded in addition to already existing objects. This is useful when using assemblies. An assembly is a self-contained part of a scene that can be loaded on demand when a renderer finds that the assembly would be visible. In that case the appropriate importer from the set of built-in or custom importers will be called to load the assembly into the system.