🔒 Locked

Rendering Design

Started by aqez Jun 9, 2010 at 10:03 PM 2 replies 1.7k views

Original Post

Jun 9, 2010 at 10:03 PM

So a little backstory.. I was having problems with class relationships and such, trying to keep my code clean. The topic can be found here. I also came across someone else with a similar problem here. So I borrowed a bit of an idea from Noggs:

Quote:
Original post by Noggs
Do some research on a command buffer approach. Essentially you submit rendering jobs (e.g. "render mesh" including shader params, materials, etc) to a command queue. This queue can then be sorted and grouped by material etc to optimize the draw calls. One advantage of this approach is that multiple processes can submit to the queue at the same time.

Then I did what all half decent software developers do, I tried to expand on it:

I posted this in a new thread as I forsee there will be some problems with the concept.. Namely:

std::Vector<std::Stack<IRenderable*>> renderVector;

Because I've never tried that before.. who knows. So anyway the point of the post.. I have a few questions: How expensive will the virtual calls be because of the IRenderable interface and dynamic binding of the objects in the vector/stack? Will allocating new stacks and adding them to the vector be a costly operation? I've not worked too much with the STL I've usually rolled my own data structures but now I've become a bit more wise in not re-inventing the wheel - thats for the masochists out there, although I am glad I've done it at least for the experience and knowledge of how they work.

[Edited by - aqez on June 9, 2010 10:22:08 PM]

Shanee

Jun 10, 2010 at 7:35 AM

You can use an std::queue. That is what I did :)

You might want to add another structure though, to filter by shaders.

It is better to call Shader->Begin (or BeginScene) and switch between shaders the least amount of times.

My system sorts all 3D objects by their shader/technique too (and planning to add another level of sorting then by material/texture to minimize the information sent to the GPU)

Later you might want to add the option for instancing (sending the same model to the GPU just once, but with multiple transformations so you render it several times in one call.

Ariste

Jun 10, 2010 at 9:25 AM

Quote:
Original post by aqez
Because I've never tried that before.. who knows. So anyway the point of the post.. I have a few questions: How expensive will the virtual calls be because of the IRenderable interface and dynamic binding of the objects in the vector/stack? Will allocating new stacks and adding them to the vector be a costly operation? I've not worked too much with the STL I've usually rolled my own data structures but now I've become a bit more wise in not re-inventing the wheel - thats for the masochists out there, although I am glad I've done it at least for the experience and knowledge of how they work.

My guess it that the overhead will be pretty negligible compared to the cost of actually rendering the objects and other operations, like physics or AI. Of course, there's really only one way to find out :)

In general, aim first to get it working, then to get it right. You can always optimize if you find it's too slow. Someone famous once said that premature optimization is the root of all evil, and I think that's pretty good advice.

Noggs

Jun 10, 2010 at 6:09 PM

I think in this example the overhead of dynamic binding will be negligible compared to the bottlenecks of creating these stacks! In order to have multiple writers each one will have to lock the queue before examining it to find out where to put the command. This is bad.

If you can summarise each render command in a structure you can throw them into either a lockless queue, or each writer could have its own queue that are then all combined at the end of the submit stage. Another advantage is that the task doing the sorting has all the information locally to sort the queue, instead of having to go to each IRenderable and requesting material information.

I still don't see what the advantage of having an IRenderable base class is. These things don't need a common interface.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.