The Scene Database

This section discusses the scene database which is where all scene data is loaded and stored at runtime:

• What a scene database is
• The transaction and scope mechanisms
• Commands to query the scene database or get and retrieve database elements?

What is the Scene Database?

RealityServer is designed for multi-user operation and multiple operations running in parallel. To support these features, the scene database uses transaction and scoping mechanisms.

Transactions

The transaction mechanism enables multiple operations to run in parallel without affecting each other.

Imagine a rendering is running when a user starts to edit a scene and for example moves some geometry. If this change would immediately affect the ongoing render operation then the resulting image would be corrupted; in some parts of the image the geometry would be in the old position and in some parts it would be in the new position.

Isolating transactions: To prevent this situation, the neuray database uses transactions to provide a consistent view on the database for the lifetime of a transaction. Before a rendering operation is started, a new transaction is created and all accesses and changes to the database are done through that transaction. Changes from transactions which were not committed before the rendering transaction was started are not visible to that transaction. In databases this is known as the Isolation property.

Committing and aborting transactions: It is possible to commit or abort a transaction. If a transaction is committed, all changes to the transaction become visible at the same time for all transactions that are created after the commit. If the transaction is aborted, all changes in the transaction are automatically abandoned and are not visible to any other transactions. This is known as the Atomicity property.

The transaction mechanism is designed to work on distributed clustered systems, and each node in a system is able to start and commit transactions and use them for operations.

Storing persistent scene data: The scene database does not support the Durability property of conventional databases. Scene data is stored in main memory for fast operation. In situations where main memory is insufficient, scene data can be offloaded to disk. If your application requires persistent storage, then you need to write external code to support read and write operations for conventional databases or plain files.

Scopes

Essentially, a scope is a container for scene database elements. Each scene database element is stored in a specific scope.

Key characteristics: Scopes have important characteristics:

• Scopes can be nested
• Each scope can have an arbitrary number of child scopes and an arbitrary number of database elements
• Except for the global scope, each scope has exactly one parent scope

File system analogy: In certain respects, the scene database is analogous to a file system with directories and files. A scope is analogous to a directory, while a database element corresponds to a file. The global scope corresponds to the root directory of a file system.

Usage examples: Scopes enable different database elements to be stored using the same key. This feature is useful when you want different versions of the same database element for different users. For example, it would allow two customers to view the same model of a car with different paint colors. The usage of scopes is not limited to different users. You could use scopes for example, for different variants of a car model and let customers switch between them.

Note the following:

• Transactions: Each transaction is started within one specific scope. To carry the file system analogy further, the scope in which a transaction is started corresponds to the current working directory in a file system.
• Search order for keys: When some operation accesses a key for which multiple versions exist in different scopes the database needs to decide which version to return. This is done by first looking inside the current transaction's scope. If the key is found there, the database element stored in that scope is returned. Otherwise, the scope's parent scope is searched for the key. This continues until the "global" scope has been searched. If the key was not found in that scope, the key does not exist or is not accessible from the current transaction's scope.
• Overwriting scene elements: The scope mechanism allows a shared version of a scene element to be individually overwritten for different scopes.
• Scope commands: Scopes can be created and removed using API functions. Removing a scope will automatically remove all contained scene elements.

Scope Commands

To create and use scopes, use the following commands:

• create_scope
• scope_exists
• use_scope