Jump to content

  • Log In with Google      Sign In   
  • Create Account

Improve performance: Render 100000+ objects


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 TeamPerformance   Members   -  Reputation: 100

Like
0Likes
Like

Posted 12 March 2012 - 07:25 AM

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.

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.

Attached Files



Sponsor:

#2 Hodgman   Moderators   -  Reputation: 31798

Like
0Likes
Like

Posted 12 March 2012 - 07:51 AM

* The Cube and Pyramid classes seem to be exact duplicates of each other? These classes seem like they shouldn't exist, and you should just use Shape 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 Fish, Rock, BiggerRock, FencePost, GreenFencePost, Tree01, Tree02, etc... You should be able to add new "shapes" to a game without writing new code.

* The use of virtual 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).

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

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

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.


#3 TeamPerformance   Members   -  Reputation: 100

Like
0Likes
Like

Posted 12 March 2012 - 09:24 AM

* The Cube and Pyramid classes seem to be exact duplicates of each other? These classes seem like they shouldn't exist, and you should just use Shape 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 Fish, Rock, BiggerRock, FencePost, GreenFencePost, Tree01, Tree02, etc... You should be able to add new "shapes" to a game without writing new code.

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

* The use of virtual 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).

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.
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 gl calls during rendering -- e.g. if several cubes were rendered after one another, then only the first would have to call glBindVertexArray, every following cube could skip that call.

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:

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);
}


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 gl calls, you can greatly reduce the number of gl calls that need to be made (as above).

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.

Thanks for this, we will implement it.

#4 RobinsonUK   Members   -  Reputation: 108

Like
0Likes
Like

Posted 12 March 2012 - 03:03 PM

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.

#5 Hodgman   Moderators   -  Reputation: 31798

Like
0Likes
Like

Posted 13 March 2012 - 09:53 PM

This might provide some insight: http://origin-developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf?q=docs/IO/8230/BatchBatchBatch.pdf

As mentioned above, it's not feasible to be submitting 100,000 different draw-calls per frame. You need to merge draw-calls together in order to reduce the CPU load.
If instancing is not an option, there's many "pseudo instancing" techniques - such as storing the same vertex data several times back-to-back in the same VBO, which lets you draw the same object multiple times with one draw-call.

In this example you are right, but for us it is essential that different objects have different render methods.
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.

Your low-level rendering classes, which make gl calls, do not need to have polymorphic render functions. At this level, you should be working with simple objects which can be composed into complex objects.
At a higher level, you can have polymorphic classes which submit different combinations of these simple compositions.

This is a good idea, but in the tests we have made we didnt see any relevant improvements.

Have you confirmed weather you are GPU-bound or CPU-bound? e.g. if your CPU loop takes 30ms, but is submitting 60ms worth of work to the GPU, then no amount of CPU-side optimisation is going to improve performance.

* There's no sorting of the data going on. By sorting your (visible) objects each frame before submitting their gl calls, you can greatly reduce the number of gl calls that need to be made (as above).
we do check if objects are visible or not (Frustum method).

Visibility testing is not sorting. After you've culled your scene and determined the visible list of objects, you can re-order the list of objects to be drawn to achieve the most optimal rendering order.
e.g. if you've got expensive pixel shaders, then drawing objects from the closest the the furthest will improve your GPU performance (due to hi-z / early-z pixel rejection).
Or, if you've got many objects that share the same state (e.g. same textures, same shaders, etc) then drawing them at the same time will reduce the number of gl calls, which will improve CPU performance.

Also, have you run your program through any kind of profiler to see where the hot spots are?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS