- what would you advice on another way of sorting, I know fully based it on materialgroup (shader), mesh, instance etc., to reduce state changes, texture changes, shader changes etc. All works pretty good, but I don't do anything yet with distance to camera (front to back might be useful for early-z, but how to combine both sorting options?)

- say I insert or add renderables (for new entities), how can I easily sort them based on one of the variables, with std::sort or something?

(I have a std::vector<int> where I can simply store the indices of the renderables in a specific order)

- could I maybe create some sort of key based on the 7 variables and sort that?

To expand on my previous reply the reason using bits for sorting is useful because you can sort on multiple things at once for the same price and not only that you can very easily change the priorities of various search fields, just shift their positions around.

This enables you to test a scene and at the touch of a key try out different options see which works best for you.

You don’t need “Visible”. If they are not visible, they are not in the bucket render-queue. Don’t waste time sorting invisible objects.

say I insert or add renderables (for new entities), how can I easily sort them based on one of the variables, with std::sort or something?
(I have a std::vector where I can simply store the indices of the renderables in a specific order)

You don’t seem to get the concept of a render-queue.
It is built from scratch every frame. It changes sizes every frame as new objects appear and disappear from the screen. It is sorted every frame after being rebuilt every frame.

There is no “render bucket”.
There is a list of all objects in the scene.
Then that becomes a list of all objects within a frustum (created with the help of a tree structure such as an octree). Notice that this allows different objects to be in the list from one frame to the next.
Then those objects submit “render-queue items” to a render queue (which is reset back to 0 items at the start of each render).
The render-queue sorts. Sorting indices, not actually moving any render-queue items.
The objects are drawn in the order specified by the render-queue.

could I maybe create some sort of key based on the 7 variables and sort that?

@LSpiro: I understand what you, the struct and data you see above is just the base/ layout of the data. I have a index of only the visible renderables which I actually renderable. The same for blended, first I update the index of visible ones (simply pointing to the renderables), afterwards I sort based on the index (not the whole vector).

@BWhiting: I understand the principle, but unfortunately do need some more pointers to get into it.

Let's take a fictive/ simplified example:

I have this data per renderable:

- int mesh ID (max 256)

- int material ID (max 256)

- float dist to cam

Let's say I want to put those tree into one key, I believe I would then need:

meshID = 8 bit

materialID = 8 bit

disttocam = 8 bit (converted to range 0 to 255).

Note: currently I store disttocam squared, being sometimes up to 1.000, so like you said I can convert them into the range of 0 - 255 (and get the correct range using the index to the right 'full' renderable).