   A few questions about my design
  Hi,I want to focus the renderjob idea. Right now I have renderers, renderables and renderjobs. Renderjobs are essentially property sheets, for example containing "diffuseTexture" = <some pointer>. Each renderable has a number of renderjobs, and the renderer interpretes the renderjobs. The advantages of this system is that fallbacks are trivial; simply switch renderers. Also, state sorting is nicely done, and it is easy to insert new tech simply by modifying the renderer.The great disadvantage is crippled flexibility. A renderable cannot render itself; it has to rely on the renderer. This makes inserting new effects quite painful, because you have to modify the renderer for each effect. I tried to insert custom shaders for this (thus letting the renderer see that a shader was specified along the renderjon, and giving the shader control over the rendering) but this further adds levels of complexity. Also, I caught myself working with the _same_ renderer all the time, making the easy switching somewhat useless.So I revisited the whole problem. The core issue is that draw passes have to be batched, preferably by shader/material (and the blended ones by distance). To do so, one has to know about the passes; which shaders/states/textures they use, their distance to the eye. And thats exactly what I want to implement now.There would be two structures: a pass query and a pass descriptor. The pass query is for querying a pass (doh). It includes the pass type, its index (renderables can have several passes per type), and optionally a pointer to one or more lights. The pass descriptor contains information about the pass: used shaders, used states & textures, if its blended, and its distance to the eye. Thus, for example when drawing light contributions, I ask for lighting passes, sort them by descriptor, and tell the renderables to render them, thus reducing the renderer to its core task: sorting & batching.Any opinions? I am now reviewing it to see if (and where) it is unnecessary complex.   
  I think most of it sounds overly complex, but then again,its a real challenge to make something complex turn into something simple.This is how ive structured my "renderables":SceneManager->SceneNode->Mesh->SubMesh->MaterialThe SubMesh contains a vertex and index buffers for any type of renderable object built from these two basic components.The Material assigned to the SubMesh describes how it shall be rendered containing settings for texture id, culling, filtering, if it receives shadows, if it casts shadows and so on.The SceneManager contains a query/sorting/visibility system:SceneManager->SceneRenderQueueWhich, when a SceneNode is added to the SceneManager, is analyzed by the query down to its Mesh->SubMesh(es). These SubMeshes are then sorted into same-material lists so that i can render all SubMeshes containing the same material at once with minimal state changes and with no need of re-sorting each frame.This sorting only has to be done when the SceneNode is added to the SceneManager and/or when the SceneNode switches mesh. When the SceneNode is removed from the SceneManager, its also removed in the SceneRenderQueue.SceneRenderQueue objects can be customly created to incorporate additional  visiblity/sorting systems such as Quadtrees, Octrees etc but currently i only have one that sorts by material.   