How to sort by what

Well this is no means a good way but it is a way.

You could make a linked list and store your textures in there and then just render a shader to a specific linked list. no other ideas at the moment i am sure there other ways but its a though i supose.

Regards Jouei.

Depending on your language of choice you should be able to set up a standard predicate-based sort for a generic container. Use delegates (.NET) or function pointers (C/C++) to abstract out the actual sorting and it's easy enough to interchange different predicates and experiment with the best results.

The biggest win that you'll probably get is by taking advantage of temporal coherancy. For the most part the order will not change on a frame-to-frame basis and even then a very small proportion of the renderable items will change significantly between two frames. Consequently starting from scratch and re-sorting all your renderable items each time is needless extra work. Sort only entities that have changed (a 'dirty' or 'delta' set) and you'll be fine.

hth
Jack

Quote:

Original post by jollyjeffers For the most part the order will not change on a frame-to-frame basis and even then a very small proportion of the renderable items will change significantly between two frames.

Good point. So I guess if I did have a sorting algorithem, it would only be useful to update every second or two, or when there was a drastic change in the scene. One thing I am trying to accomplish with multithreading is to have half of one processor dedicated to pulling work off the GPU and balancing out the workload so one part of the system isn't waiting on the other.

Still though no one has attempted to answer the question I'm trying to ask.

Which is the slowest operation (I'm using a GeForce 7900gs):

Set_Pixel_Shader();

Set_Texture;

rendering with an unsorted Z buffer;

Quote:

Original post by TheKrust So I guess if I did have a sorting algorithem, it would only be useful to update every second or two, or when there was a drastic change in the scene.

The latter case is correct, the former is dangerous. Don't hard-code it to a "every second or two" - maybe, if you wanted to be safe, you force a complete re-sort every N frames. In all cases it really should just be based on delta/change information. Look up things like 'insertion sort' if you're not familiar with it already. Everyone runs from bubble sort, but it can be a reasonable choice here - just run a quick pass over the renderable list and move the few elements that need it.

Quote:

Original post by TheKrust One thing I am trying to accomplish with multithreading is to have half of one processor dedicated to pulling work off the GPU and balancing out the workload so one part of the system isn't waiting on the other.

It's obviously good to partition out work to seperate threads, but don't try to beat the OS's scheduler. Unless you're exceptionally skilled in this area and you have intimate knowledge of the OS then you'll be almost guaranteed to hurt performance rather than improve it.

Whilst the Windows Vista scheduler has been stressing me out a lot lately (damned unresponsive apps [razz]) it is actually a very well designed piece of software!

Quote:

Original post by TheKrust Still though no one has attempted to answer the question I'm trying to ask. Which is the slowest operation (I'm using a GeForce 7900gs): Set_Pixel_Shader(); Set_Texture; rendering with an unsorted Z buffer;

Maybe no one answered it because we can't? The classic doc page says SetPixelShader() is around 2-3x more expensive than SetTexture(), but really it's not that simple in a real-situation. You need to test it with your intended workload on your intended hardware. Hence my original suggestion of a "plugin" architecture for sorting your renderable list - you can so very easily implement different ordering and see what the performance difference is.

hth
Jack