I don’t think the topic has been derailed. Even if the original poster does not need such a complicated system, there is a lot of useful information here from many people.
CombatWombat, read
this.
You should definitely submit information for a render queue to sort, but keep it minimal to avoid transfer overload. If you use the sorting method I proposed there, sorting will be the same speed regardless of how large the render queue data is, but still you do have the initial upload of render data, and in that area bigger = slower.
So you don’t want to send whole matrices to the render queue. Some people offload the entire render to the render queue. It helps them to avoid a virtual function call which is costly on PlayStation 3, but they have to send more data which is slower.
In my implementation, I felt that sending matrices would be slower than invoking the wrath of a virtual function, so the render queue does not receive a matrix and instead delegates the final render task to the object that submitted the render queue packet.
Since the submitter of the packet will be responsible for the final render anyway, I can reduce the amount of data I send to the render queue even further by not sending pointers to index buffers and vertex buffers.
So what
do I submit? Well, logically I submit only what is important for the actual sorting process. That is the whole point of the render queue after all.
As mentioned in my article, texture uploads, shader swaps, and render states need to be kept to a minimum, so this is the type of information I send to the render queue. I send a shader ID, a set of texture ID’s, and some render states.
After the render queue sorts these packets, it runs over objects in sorted order and calls a virtual function on the objects that sent the packets to perform the final render. This means of course that I also submit a pointer to the object that sent the packet.
L. Spiro