Behold our latest creation! The marking between a before and after in the life of Ogre!

But it’s a bit… disappointing, isn’t it? Just two static triangles and a moving one.

What’s the deal about those green triangles anyway?

There is a story flying around the net about a black triangle. If you don’t care about reading the link, it’s about a startup called SingleTrac (i.e. the company behind Twisted Metal & Jet Moto) which in 1994 showcased the Financial Controller & HR lady the results of a month of work, and all they had to show was… a black triangle.
To quote the site “It wasn’t just that we’d managed to get a triangle onto the screen. (…) It was the journey the triangle had taken to get up on the screen.”

Now back to Ogre, let’s analyze what’s going on with two of the triangles:

1. A memory manager asked OpenGL for a full chunk 128MB (configurable) that we’ll entirely manage on our own.
2. On uploading, the system will automatically use preallocated staging buffers and transfer them into the 128MB chunk. Both the vertex and index buffers go into this Buffer Element.
3. The manager uses memory fences to control both hazards and avoid stalling. The memory manager can and will select staging buffers that are not currently in use by the GPU so that we have no stalls.
4. The manager creates a VAO (Vertex Array Object) that will be the same for all Meshes sharing the same vertex format. This reduces VAO switching tremendously. There are wars where some claim that people should use one VAO per object, where others claim people should use one global VAO and respecify the array state. But do you know what’s better than those two? Not switching VAOs. At all. We do neither of the two. We have one VAO per vertex format. And since vertex formats rarely change (and we’re in a position to enforce a standard vertex format) this approach works. If we never (rarely) change the array state or Vao, we won’t incur those API overheads they talk about.
5. Because the two triangles share the same VAO and BO (Buffer Object), MultiDraw* family of functions can be used for an even lower overhead. However we are not showcasing this yet.

As for the dynamic triangle:

1. The vertex data is being updated every frame through a persistently mapped buffer. This one has huge performance benefits. Systems that do not support persistent mapping automatically fallback to unsynchronized buffer mapping.
2. The memory manager explicitly fences the frames and dynamic buffers to avoid hazards.

So what’s next?

We’re hardly done. There is notable work that remains to be done:

1. Implement an Entity class that takes vertex & index buffers from this new Memory System, rather than the old one.
2. Use this same system for constant buffers (uniform objects in GL jargon).
3. Lots more stuff. This is just the tip of the iceberg.