class StelVertexBuffer< V >
Vertex buffer interface.
Each StelRenderer backend might have a different vertex buffer buffer implementation. StelVertexBuffer, created by the StelRenderer's createVertexBuffer() function wraps this backend.
StelVertexBuffer supports basic operations such as adding, getting and modifying vertices. It can be locked to allow uploading the data to the GPU, and unlocked to modify the buffer.
For drawing (by a StelRenderer), the vertex buffer must be locked. To access/modify vertices, it must be unlocked. A newly created vertex buffer is always unlocked.
- Template Parameters
|V||Vertex type. The addVertex(), getVertex() and setVertex() functions work with this type. This allows the API to be minimal and safe at the same time (no way to mess up vertex format).|
The vertex type is defined by the user. Some commonly used vertex types are in the file GenericVertexTypes.hpp.
Example vertex type:
- There are some requirements for a vertex type. These are verified at run time. The requirements are:
- A position attribute is required.
- Any texture coordinates must be 2D. There is no 1D or 3D texture support right now.
- Any normals must be 3D.
- When drawing with a custom StelProjector (using StelRenderer::drawVertexBuffer), only 3D vertex positions are supported.
Currently, the GL2 backend only supports some combinations of attribute interpretations (e.g. just position, position-color, etc.). This is because every such combination needs a custom shader. If you get an assertion error about an unimplemented shader for vertex format, feel free to add it (in StelQGL2Renderer). All vertex formats currently used in Stellarium are already covered.
- See Also
- AttributeType, AttributeInterpretation, StelVertexAttribute, StelRenderer
API design notes
Currently, vertices must be accessed individually through functions that might have considerable overhead (at least due to indirect call through the virtual function table).
If vertex processing turns out to be too slow, the solution is not to allow direct access to data through the pointer, as that ties us to a particular implementation (array in memory) and might be completely unusable with e.g. VBO based backends.
Rather, considerable speedup could be achieved by adding member functions to add, get and set ranges of vertices.
- void addVertexRange(const QVector<V>& vertices)
- void getVertexRange(QVector<V>& outVertices, uint start, uint end)
- void setVertexRange(const QVector<V> vertices, uint start, uint end)
Note that end might be unnecessary in setVertexRange.
This is still not the same speedup as direct access (due to copying in get/set), but should allow for considerably faster implementations than accessing vertices individually, without forcing backends to store vertices in a particular way.
An alternative, possibly better (especially with C++11) option for modifying vertices would be to use a function pointer / function object to process each vertex.
Vertex buffer backend
VertexBuffer is currently separated into frontend (StelVertexBuffer), which allows type-safe vertex buffer construction thanks to templates, and backend, which doesn't know the vertex type and works on raw data described by metadata generated by the VERTEX_ATTRIBUTES macro in the vertex type.
This is because virtual methods can't be templated. There might be a workaround for this, but I'm not aware of any at the moment.
Definition at line 171 of file StelVertexBuffer.hpp.