0

I've been reading up on how some OpenGL-based architectures manage their objects in an effort to create my own light weight engine based on my application's specific needs (please no "why don't you just use this existing product" responses). One architecture I've been studying is Qt's Quick Scene Graph, and while it makes a lot of sense I'm confused about something.

According to their documentation, opaque primitives are ordered front-to-back and non-opaque primitives are ordered back-to-front. The ordering is to do early z-killing by hopefully eliminating the need to process pixels that appear behind others. This seems to be a fairly common practice and I get it. It makes sense.

Their documentation also talks about how items that use the same Material can be batched together to reduce the number of state changes. That is, a shared shader program can be bound once and then multiple items rendered using the same shader. This also makes sense and I'm good with it.

What I don't get is how these two techniques work together. Say I have 3 different materials (let's just say they are all opaque for simplification) and 100 items that each use one of the 3 materials, then I could theoretically create 3 batches based off the materials. But what if my 100 items are at different depths in the scene? Would I then need to create more than 3 batches so that I can properly sort the items and render them front-to-back?

Based on what I've read of other engines, like Ogre 3D, both techniques seem to be used pretty regularly, I just don't understand how they are used together.

Moohasha
  • 245
  • 1
  • 13

1 Answers1

1

If you really have 3 materials, you can only batch objects that are rendered in a group according to their sorting. At times the sorting can be optimized for objects that do not overlap each other to minimize the material switches.

The real "trick" behind all that how ever is to combine the materials. If the engine is able to create one single material out of the 3 source materials and use the shaders to properly apply the material settings to the different objects (mostly that is transforming the texture coordinates), everything can be batched and ordered at the same time. But if that is not possible the engine can't optimize it further and has to switch the material every now and then.

You don't have to group every material in your scene together. But if it's possible to group those materials that often switch with each other, it can already improve the performance a lot.

Nitram
  • 6,486
  • 2
  • 21
  • 32
  • And it's up to profiling to see if the overdraw penalty exceeds the switching penalty. If overdraw penalty is smaller then batching materials is more important than ordering the entire scene. – ratchet freak Aug 03 '15 at 14:20
  • Are you saying that the sorting is done per material? As in, you don't sort everything in the scene with everything in the scene, but rather you just sort things that use the same material and accept that some overdraws will still occur? Or are you saying the opposite, that you sort things and then batch objects that get rendered together that share the same material? – Moohasha Aug 03 '15 at 15:52
  • btw, when I say different "materials" I'm referring to different shaders. That is, things that can't be combined, not just different states (like colors) that can be combined into the same material. – Moohasha Aug 03 '15 at 15:53
  • Well the sorting has to be done by material. The first sorting is done my the order of the primitives. But by doing so you get some objects without strictly defined sort orders. Those objects are then sorted by the material to improve the batching capabilities. Regarding the shaders: I think it is possible to attach multiple vertex and fragment shaders to one shader program. Possibily some additional material merging can by done this way? But in the end: If the materials can't be merged, then they have to be sorted the way they are set. – Nitram Aug 03 '15 at 15:57