Provides the shared buffer for terrain meshes.
Using a mesh buffer involves the following steps:
Create a MeshBuffer object by calling Create. A container for per-vertex CPU data must be given (see VertexArrays). Optionally, updater objects for vertex data or mesh structure data may be specified; these are usually used to populate GPU buffers, for GPU-based rendering and triangulation.
Create terrain meshes by calling MeshCreate. All terrain meshes will use vertices that are stored in the shared mesh buffer.
The mesh buffer has a background refinement thread which periodically traverses all terrain meshes, updates the tessellation and triggers background computation of vertex data. This happens automatically and is not visible to the application.
The mesh buffer is supposed to be accessed by a single dedicated thread in the application (usually the render thread). A separate snapshot of the terrain mesh tessellation is maintained for consistent access by the application thread.
The MeshUpdate and MeshUpdateData will update the terrain snapshot according to the current state of background refinement. This is a write-only access. Subsequently, the application will read from the terrain snapshot (for example, while traversing the MeshTree).
If an application needs to read from the terrain snapshot from another thread than the dedicated one, then the IBeginEnd.Begin and IBeginEnd.End methods must be used to wrap each read access. This will ensure that all accesses are properly synchronized: write-accesses and read-accesses are mutually exclusive, while read-accesses will be performed in parallel.
The following API will read from the terrain snapshot:
Refinement of CLOD meshes is not deterministic by default (i.e. the same input may produce slightly different outputs). To ensure deterministic behaviour, for example in a distributed render environment, the following steps must be performed:
The application may update the refinement parameters at any time: IMeshDynamic.QualityThreshold, IMeshDynamic.VisibleThreshold and IMeshDynamic.Visibility, including the properties of the IVisibleCheck object. Updating the refinement parameter values does not directly affect background refinement.
After updating the refinement parameters, the application calls CycleLimit to resume background refinement for a fixed number of cycles, which will use a snapshot of the current refinement parameter values.
The MeshTree.ComputeSectorHash1 method may be used to check if the shadowed structure of two meshes is equal, in order to verify that refinement is deterministic.
Builds a color-coded image that represents the fragmentation of the shared vertex buffer.
Both width and height of the image are powers of two (but not necessarily the same). Each pixel in the image represent the status of a specific vertex in the shared vertex buffer:
index(x,y) := y * width + x color(x,y) := status
height are the dimensions of the image,
y are pixel coordinates,
index is the mapping from pixel coordinates to zero-based vertex indices and
status if the color-coded vertex status:
The vertex is not used by any terrain mesh.
Dark rainbow color
The vertex is used by a terrain mesh and currently invisible.
Bright rainbow color
The vertex is used by a terrain mesh and currently visible.
The vertex belongs to the skeleton of a terrain mesh.
The hue of the rainbow colors indicates the level of the respective vertex in the mesh structure (i.e, the number of parent vertices, up to the root sector; see XDag).
Creates a new dynamic terrain mesh.
If the given options in are invalid.
The MeshUpdateData method must be called before vertex data is used (e.g. rendering using the GPU vertex buffer). This ensures that the mesh structure is consistent with the vertex or mesh data that has been sent to the IVertexUpdater resp. IMeshStructureUpdater object.
Performs all vertex data and mesh structure updates that have been left out during the last call to MeshUpdate.
This method can be called multiple times, data updates will only be performed once.
Re-initializes the mesh buffer and all meshes, in order to recover from the error state.
This method must be called after MeshUpdate has returned a negative value, in order to recover from the pending error state. Calling this method when there is no error state is allowed, but has no effect.
Allow the refinement thread to sleep for a short period of time when little or no refinement work is necessary?
The default value is
Returns the number of vertices that are currently not exposed to the application by any mesh and that may be re-used for mesh refinement.
Unused vertices may either be recycled for being used elsewhere or they may be reactivated for use in their current mesh. Since only leaf vertices can be re-used for mesh refinement, this count will usually not be equal to the mesh buffer capacity:
Capacity = CountUnused + CountVisible + N
N is the number of unused non-leaf vertices. If this counter drops to zero, mesh refinement will not be able to use new vertices to add detail to the terrain.
Returns the number of visible vertices in all meshes.
As a rule of thumb, the number of visible vertices should be roughly 50% of the mesh buffer capacity, so that vertex caching may contribute to performance.
Returns the refinement cycle counter of this mesh buffer.
The background refinement thread continuously runs refinement cycles and increments the counter for each cycle. This property returns the cycle counter value that corresponds to the state that has been established by the most recent call to MeshUpdate.
- See also
Is the mesh buffer in an error state and needs to be reinitialized?
The mesh buffer can enter the error state in one of the following cases:
An unexpected exception is thrown in one of the components that have been passed to the mesh buffer:
This usually indicates a code bug in the component. In this case, please file a bug report, if the component belongs to the Tinman 3D SDK.
An unexpected internal error has occurred in the mesh buffer, the refinement thread or a compute task. In this case, please file a bug report.
When entering the error state, background mesh refinement stops and all pending compute tasks are cancelled. While in the error state, the application may still use all terrain meshes in their current state. Refinement will be frozen until the mesh buffer recovers from the error state.