Using PVRAssets#

The PVRAssets library contains very detailed, carefully crafted classes to allow handling of all kinds of assets.

Models, meshes, cameras, lights, animation#

The top-level class for models is the pvr::assets::Model class. The model contains an entire description of a scene, including a number of:

  • Meshes

  • Cameras

  • Lights

  • Materials

  • Animations

  • Nodes

In general, these objects are found both in raw lists, and bound to Node objects. Each Node contains a reference to an item in the list of meshes that is stored in the model. The lists describe the objects that are present. Call model->getMesh(meshIndex) to get the list.

Nodes#

Nodes are the building blocks of the scene and describe its hierarchy. Each node is part of a tree structure, with parent nodes (except the root node), and carries a transformation, and a reference to an object such as a mesh, camera or light. The transformations are applied hierarchically. The transformations, in general, are animated and dependent on the current frame of the scene.

Nodes are usually accessed through their indices. To make accessing objects easier, the nodes are sorted by object types, in the order:

  1. Mesh

  2. Camera

  3. Light

Always be wary when trying to access a node or its underlying object. When trying to iterate the meshes, for example, to get VBOs, attributes, textures, and so on, always call getMesh(…), but when trying to display the scene, iterate MeshNodes(). This is a subtle difference, but it pays to consider the mesh like a blueprint of an object, while the mesh node is referencing an instance of that object.

Note

Some useful methods:

  • getMesh(meshIndex) - returns the Mesh with id meshIndex.

  • getMeshNode(nodeIndex) - returns the Node with id nodeIndex (which may point to any Mesh).

  • getMeshNode(nodeIndex)->getObjectId() - returns the Mesh that is referenced by the node with index nodeIndex.

  • getCamera(id, [output camera parameters]) - returns the parameters of the camera with Camera ID id.

  • getLight… - returns the parameters of the light with Light ID id.

Models as mesh libraries – shared pointers between models/meshes#

Sometimes a model is only used as a library, and not as a scene definition. In such a case, it is preferable to deal with the meshes as objects in their own right, and not deal with or even hold the model. For example, the position and animation of objects might come from application logic and not the model.

The Framework deals with this using the std::shared_ptr’s shared refcounting feature. Call Model->getMeshHandle() to get a s<Mesh> that will be functional for any use. Feel free to discard the pointer to the model if it is not needed – the new pointer will deal with its lifecycle management.

POD & GLTF#

To load models, there are readers available for Imagination’s .pod (PVRGeoPOD) and Khronos’ .gltf files.

Semantics#

Semantics were first introduced as part of PVRShaman (PVR Shader Manager) and the original PFX format. It is a way to signify to an implementation (for example PVRShaman, or now the RenderManager class) what kind of information is required by a shader. In other words, which data from a model needs to be uploaded to which variable in the shader.

For example, in the PFX format it is possible to annotate the attribute myVertex with the semantic POSITION, so that PVRShaman knows to funnel the position vertex data from the POD file into this attribute and display the file. Semantics have been simplified and expanded since then.

Currently, semantics in the Model class have been made completely flexible, allowing any vertex attribute or material attribute to be annotated with any semantic, allowing the reader (POD or GLTF currently) to define semantics, and then it is up to the application to use these semantics.

In the PowerVR SDK, the convenient PVRShaman semantics are still being used, but it is up to the two sides (the model and the renderer) to decide on the semantics and what they mean.