   Front to back rendering?
  I've read, that it is good to render everything front to back, because this results in lesser PixelShader stress. No problem at all, but how do I sort them *fast*? I think it's not good to do something like this each frame:list RenderList;Foreach Mesh{    Foreach RenderListEntry    {   *Put them in the right place*    }}
  In C++ I would use://earlier: ForEach Mesh, put into RenderList...std::sort( RenderList.begin(), RenderList.end(), compareDepthValues );where compareDepthValues is a functor that compares two values (lhs/rhs) and computes:(lhs.pos  - camera.pos).LengthSquared() < (rhs.pos - camera.pos).LengthSquared()Assuming you don't have millions of visible entities, you should be able to generate/sort that list every frame.You can always surround the sorting code with an if statement, so then you can test whether it's actually faster to waste CPU by sorting to save GPU time, or save CPU by not sorting and waste GPU...   ;  Build a quad or oct tree. At each level it's trivial to both cull and also sort the nodes. Sorting the elements within the nodes is then much easier.Exploit frame-to-frame coherency; if your camera has not moved much, your previous sort is likely to be very nearly correct. Bubble sort, despite it's derision in general, can become more efficient than many other sorts for almost ordered data.Bear in mind that actually what you want is the stuff sorted in both depth order AND in surface type order. The former to prevent overdraw, the latter to prevent frequent shader switching. Hence, you can do two draws. First draw renders without lighting, texturing or colour. It just draws plain geometry and only to the depth buffer. Then you sort by material, and draw again. Your shaders will only run for visible pixels because of early Z culling.;  Ah, ok. I have already draw sorting running via ContentGroups. What is faster? Front to back or the sorting of all draw types? And maybe I coulde juse Predicated Rendering (Or so) to cull out everything uhm.. culled. :)Then I don't have to sort them front to back, or is that wrong?   ;  What Katie said, and also think about a compromise where you only sort nodes, but not elements. And if your hierarchy is deep, also try out only sorting inner nodes to some level.   ;  This is missing some context. It's also best to draw back to front and it's also best to draw in whatever order you can that gives the least state changes (shader changes, texture changes, etc)!!!If you're only doing one thing, the sort you should do is by material useage to minimise the state changes, then only change them when you need to. Some people eschew the actual sort altogether and make lists of mesh bits indexed by material (you can sort these front to back) and then just for each list, set the states and render the meshes.Caveat:You can draw front to back beforehand and this can give a win, but this is as well as the above and not instead of. Before you go this route, google away at "z pre pass" and make sure you understand it first else you'll end up losing fps, not gaining them.