L Spiro, in your first response you suggest sorting by shader then texture... in this response you're suggesting sorting front to back. So what exactly are you suggesting since the two seem to clash with each other? I'm not following.
#1:
Typically you render opaque objects via matching shaders, then by matching textures, then by depth (nearest-to-farthest).
In other words, for sorting via < and == (not shown for brevity):// If objects have the same shader and texture, render the closer one first. bool CRenderable::operator < ( const CRenderable &_rOther ) const { if ( ui32Shader < _rOther.ui32Shader ) { return true; } if ( ui32Texture0 < _rOther.ui32Texture0 ) { return true; } return fDist < _rOther.fDist; }
Where is the clash? If 2 objects have the same shader and primary texture (which is a good basis for the assumption that all other textures are the same), then draw the closest one first (front-to-back).
Of course this does not necessarily fully minimize overdraw, but instead it fully minimizes state-changes while “decently” minimizing overdraw.
#2: If you ignore my suggestion to use a sort that considers shaders and textures, you should still draw front-to-back.
Even as just the most basic optimization in the universe, you could just sort by depth. At Square Enix our framework prevents the best-possible state-reducing sort, but by sorting just by depth I was at least able to gain some performance.
So there is no clash. You can mix them (probably best) or just sort by depth. It’s always faster except on hardware with deferred tile rendering (in which case the depth sort only wastes CPU cycles).
im actually already using the depth pass to calculate the radiosity
At least this is a valid excuse for having a pass devoted only to depth, but it does not excuse the lack of sorting. Even the depth pass will be faster if you draw front-to-back.
what do you mean by "without the need to submit extra geometry" im not submitting any extera geometry in my depth pass and coz my scene is dynamic and user can add objects I cant sort the objects.
You seem not to understand a lot of terms.
#1:
Submitting Geometry: A draw call used to draw a 3D object (2D objects are not considered “geometry” simply for the sake of clarity).
During the rendering of a 3D scene, every draw call is a geometry submit.
You can’t render the depth or the 3D scene without submitting geometry.
coz my scene is dynamic and user can add objects I cant sort the objects.
if I sort ill have to sort objects every time user adds an other object .
#2:
Sort: The use of a render-queue to sort draw calls by material and depth every frame.
I’m not going to explain the details of a render-queue again as the link I posted not only contains a very detailed explanation but the first post links to yet another post with plenty of information. It is all there waiting for you to read.
You need to understand the very basics in order to ask meaningful questions or to propose meaningful excuses as to why you can’t do this or that.
I suggest you read up and get a better understanding before you post again saying something like, “I can’t sort because my scene is dynamic.” 99% of all games are dynamic and sort every frame. This problem does not exist. Especially if you are only sorting once when a new object is added.
well for deferred rendering I have to redraw the scene into several textures (G buffer) so I have to redraw scene for every pass (1 pass for normal 1 for material and etc.)
Sigh.
Have you done even the most basic research at all?
The depth, normal, albedo, shininess, etc. buffers are all created in a single pass.
Multiple Render Targets.
L. Spiro
