Hello,

We prepared a little test project (VS 2010, C++, OpenGl, Freeglut, Glew) to publish our solution to the following main requirements:


- Rendering 100000+ objects at the same time, each one of those independently accessible/seleccionable to be able to change their properties.

- The objects are of a certain type that defines their general shape and properties, which is also changeable during execution.

- Use OF VBOs, Shaders, OpenGl 3.3

- Should work on low-level graphic cards.



This is a very simplified version of our actual project, we are aware of some general methods to improve overall performance such as rendering only the visible objects and not those which are temporarily outside of your frustum.

For this example we took those techniques and other features out to make it smaller and easier to understand.

But please don't hold back with anything that comes to your mind and works for you, we might as well have missed something obvious.

Any constructive criticism, feedback and/or information, tips to improve the performance are welcome.

On our computers (Intel i7-2600, CPU @ 3.40, Ge Force GT 220) we render 100000 objects at about 6-8 frames/sec.
1000000 objects at 3 frames/sec.

It would be nice to improve the performance to get close to 20-25 frames/sec, although it might simply not be possible.


General Info:

Use your left mouse button to rotate the camera and A, D, W, S to move it to the left, right, up or down.

[color=#0000ff]EDIT: What we are looking is a way to improve the performance. Is our approach a proper way to render 100000 objects? We tested a lot of different ways and the reason why we chose this solution is because it gave us the best overall performance, but as I said, maybe we missed the obvious and did not use the "standard" OpenGL way of solving this problem. We couldnt really find a lot information about a project where the requirements were to render this amount of objects.

* The [font=courier new,courier,monospace]Cube[/font] and [font=courier new,courier,monospace]Pyramid[/font] classes seem to be exact duplicates of each other? These classes seem like they shouldn't exist, and you should just use [font=courier new,courier,monospace]Shape[/font] instead for both? I mean, if you've got artists making all sorts of shapes for your game, you don't want a programmer to have to make classes for [font=courier new,courier,monospace]Fish[/font], [font=courier new,courier,monospace]Rock[/font], [font=courier new,courier,monospace]BiggerRock[/font], [font=courier new,courier,monospace]FencePost[/font], [font=courier new,courier,monospace]GreenFencePost[/font], [font=courier new,courier,monospace]Tree01[/font], [font=courier new,courier,monospace]Tree02[/font], etc... You should be able to add new "shapes" to a game without writing new code.

[color=#0000ff]In this example you are right, but for us it is essential that different objects have different render methods.
[color=#0000ff]Maybe we should have explained it better in the post description.

* The use of [font=courier new,courier,monospace]virtual[/font] for drawing pyramids/cubes is an unnecessary idea - especially when every odd/even shape alternates between a pyramid and a cube, as this causes your render loop to alternate between calling two different rendering functions (doubling your icache requirements).

[color=#0000ff]The use of virtual is also necessary to be able to have 1 list of shapes and we need polymorphism for more complex object structures.
[color=#0000ff]The instantiation of shapes in the odd/even way was only done for the purpose of this test project. We will have a list of unsorted objects.

* There's a lot of room to reduce the number of [font=courier new,courier,monospace]gl[/font] calls during rendering -- e.g. if several cubes were rendered after one another, then only the first would have to call [font=courier new,courier,monospace]glBindVertexArray[/font], every following cube could skip that call.

[color=#0000ff]This is a good idea, but in the tests we have made we didnt see any relevant improvements. For instance if create only Cube objects, delete the glBindVertexArray calls in the render method of the cube and put the glBindVertexArray call in the DrawScene method, like this:

[color=#a52a2a][size=2]void DrawScene(void)
{
glUseProgram(ShaderIds[0]);
glBindVertexArray(CubeShapeType->stBufferIds[0]);

for(int id = 0; id < arrShapesSize; id++)
{
arrShapes[id]->Render(globalShapeRenderingCounter, ModelMatrixUniformLocation, ColorUniformLocation, ChangeColorUniformLocation);
}

glUseProgram(0);

globalShapeRenderingCounter++;
if (globalShapeRenderingCounter > arrShapesSize) { globalShapeRenderingCounter = 0; }

glBindVertexArray(0);
}

[color=#0000ff]we couldnt see any essential improvements.

* There's no sorting of the data going on. By sorting your (visible) objects each frame before submitting their [font=courier new,courier,monospace]gl[/font] calls, you can greatly reduce the number of [font=courier new,courier,monospace]gl[/font] calls that need to be made (as above).

[color=#0000ff]we do check if objects are visible or not (Frustum method).

Regarding C++ style - your classes don't follow the rule of three nor implement the non-copyable idiom, which makes them dangerous:
{
ShapeType x(1), y(2);
y = x;
}//Heap corruption: both x and y delete x's resources in their destructor. Also: y's resources are leaked.

[color=#0000ff]Thanks for this, we will implement it.

I agree with Hogman about your class structure, but for slightly different reasons.

I've changed my thinking on class structures over the years and on a relatively large project I now find the base class/derived-class with render method to be unwieldy. It doesn't scale well. The best method is to define a class called shape, and for that class to encapsulate the data needed to draw any shape, i.e. a set of vertices and so on. Then you can separate your data from the rendering of that data, perhaps using a visitor pattern to fetch and render all shapes from a collection of shapes. No virtual functions required and more flexibility in the design. You tend to find with base class/derived class that there are often things that two derived classes need that a third doesn't, that get stuffed into the base class in any case. It just grows into a bit of a mess with the lines of responsibility unclear once you start adding lots of derived classes.

With respect to drawing 100,000 objects, you really need to be instancing.