Hi everyone,
Not sure what is the best way to implement the following task.
The goal is to render thousands of spheres; this is currently done by as many calls to a renderSphere() function by the application, but the multiplication of calls tends to slow down the app.
The idea would be to send the sphere vertex data once to a UBO, then have the geometry shader use this data to build the spheres at all the required points.
Is this the correct way to go? Or is an SSBO required?
Thanks in advance for any advice.
It’s a sphere. The points on a (unit) sphere are always the same; the only thing that changes is where it is and how big it is. And those are governed by a matrix which all of the sphere’s vertices share.
Thanks. And yes, that’s the point.
I’ve not used UBOs yet, so my questions were a little more basic: is this what UBOs are meant for, or can be used for?
… is what what they’re meant for?
I suggested that you generate the sphere data within the shader itself, not to read the sphere data from a UBO. So we’re not talking about the same thing.
And no, I would not use a UBO for vertex data, owing to the general size limitations on UBOs. Equally importantly, how you read or even generate the vertex data is (largely) unrelated to the number of draw calls you make.
If you want to reduce the number of draw calls for spheres, you use instancing. This is orthogonal to how you generate your vertex data. Instancing can work just as well for regular VAO data as for pulling from an SSBO or generating the data from gl_VertexID directly.
Thanks, it’s a little more clear now.
I wasn’t aware of the instancing technique which seems to be the appropriate solution.