Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm trying to implement a scene graph and in all the articles i've come across there is talk about object sorting. So you'd sort your objects by "material" for example. Now untill i sat down and started implementing it, i kind of took this for granted, because it made sense. But now i'm wondering what does sorting actually change?

In my engine, i have a manager for UBOs, i use those to store data that'll be shared between programs, at the moment that only involves time, camera and projection matrices and lights (i'm not worrying about managing which lights affect which objects ATM).

Now for each model i have to change the model to world matrix uniform, no sorting is going to change that. So is the jump from changing this matrix to also setting a material for each object that bad?

I vaguely remember reading somewhere that each time you change something in the pipeline, it has to get flushed and that can cause performance issues. But for each drawing call i'm setting up a model to world matrix anyway, so what sense does it make to ever be concerned about this?

BTW is there any information about whether changing a uniform and calling glBufferSubData is more (or less) expensive.

share|improve this question
3  
Quick answer, yes the jump from changing a matrix to also setting materials at each object is that bad. At this point I'd suggest taking a side trip to find out about OpenGL performance measuring tools for your platform before continuing. With perf tools you can easily measure different techniques and find out what works best for your renderer's needs. Plus those tools will last you your entire career forwards while this one renderer... not so much ;-) –  Patrick Hughes May 27 '12 at 17:50
    
@PatrickHughes awesome, thanks, i'll definetly check those out –  dreta May 27 '12 at 17:52

2 Answers 2

Sorting objects purely by depth has a huge value, especially on binning or tiled rendering architectures.

Sort solids front to back, transparencies from back to front.

When rendering, the stuff that's closest to the camera and solid gets rendered first, and anything else that occupies the same space will be rejected by an early z-buffer check.

If the graphics architecture has some kind of hierarchial or low resolution z-buffer, the geometry may get culled even before anything gets rendered.

share|improve this answer

You definitely want to sort to batch together materials. If you can, you can also use instancing to batch together geometry (e.g. If you have X number of the same objects).

There's also still value in sorting by depth, too. You must sort back to front for transparent objects (ignoring several advanced techniques that remove that need, in limited circumstances).

There's also value in sorting opaque objects front to back, as that allows early-Z to greatly reduce the fragment shader overhead of your scene.

share|improve this answer
3  
Ordering the opaque/transparent objects is not easy for complex situations (to the point of being impossible without arbitrary rules). You could also group by texture for the same purpose of reducing gl calls. –  Darkwings May 27 '12 at 18:42
    
Ordering by texture is necessary for batching calls and reducing draw calls. Sorting has nothing to do with reducing draw calls. Sorting has to do with actually getting correct rendering (for transparent objects) or to minimize the fragment processor overhead (for opaque objects). Being "complex" is a problem, yes, but that's what game engine graphics programmers get paid to deal with to make games actually playable on commodity hardware. The hardware efficiency between sorted and unsorted opaque objects alone can be quite massive. –  Sean Middleditch May 27 '12 at 22:03
    
opengl.org/wiki/Transparency_Sorting That's what I meant by 'arbitrary rules'. There is no objective 'correct' sorting for complex cases. About 'sorting' and 'ordering' the OP clearly stated 'sorting by material' (regardless of transparency), and I meant the same for texture since both targets performance impact. –  Darkwings May 27 '12 at 22:40
    
To be honest, I've never once seen those kinds of issues come into play in real games. Those examples don't really reflect how one actually does things, where transparent objects are generally of roughly niform size and have fairly "boxy" collision boundaries, both of which prevent crazy overlaps. In either case, the fact that "it's hard" doesn't change its necessity. I also did of course point out that batching by material is important, and mentioned instancing to counterpoint the "no sorting can help" assertion, so I'm not sure if there's something concrete you found wrong in my answer. –  Sean Middleditch May 28 '12 at 3:48
    
Look, a comment doesn't mean I found something wrong in your answer, and I never said 'no sorting can help'. I've stated that there are cases where no objective correct solution exist, so obviously a solution must be found using arbitrary rules. Those are 2 completely different statement. –  Darkwings May 28 '12 at 10:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.