Destruction Schemas

The Destruction schemas are designed to allow a 3rd-party tool to easily define a destructible as a hierarchically fractured mesh, as well as instances of the destructible placed throughout the scene. These may be consumed by a destruction-enable application, for example an Omniverse Kit application with the omni.blast extension enabled.

Any meshes of type UsdGeomMesh may be combined to form a Destructible by giving each a DestructibleChunkAPI and placing them under a container prim. The container prim type must derive from UsdGeomXformable and have a DestructibleBaseAPI applied to it.

Note, for fracturing to work well, the meshes should be water-tight and without self-penetrating geometry. It is allowed for the meshes to have multiple disjoint components.

A description of this type is merely a collection of pieces, and this may be sufficient for some applications. In this case the user is defining a “combined” destructible in which the pieces will hold together until the bonds between them are broken, at which point the user-defined pieces will begin to break apart. In order to describe a fracture hierarchy (parent pieces which break down into smaller child pieces), the destruct:parentChunk property must be set for every chunk with a parent. Chunks without this property set are top-level, “root” chunks.

A destructible application may have a way of bonding chunks together to form conglomerates which are all part of one physical body. This may be automatic, or could require explicit definition using primitives with the DestructibleBondAPI. The omni.blast extension does both, generating bonds automatically, and using bond primitives to add, modify, or remove the generated bonds.

The plan for versioning for all schemas is to use the proposal of putting a version number and documentation link for the schema module in the layer metadata for any layer that contains prim(s) with any of the schemas contained in the module. As prims are loaded in a scene we will check for the applied APIs, grab the version from the layer metadata, and run patch code to update to the latest version by going from version N to N+1 repeatedly until we reach the current version. This is how we have been doing versioning with the destruction system pre-schema and it has worked very well, we are still able to load v1 files and bring them up to the current schema format.