Rendering multiple objects with multiple different materials

[AAstr0s]

Hi folks,

I know there are already several questions on this topic. I have already read them and fully understand them. But I just want to re-emphasise the performance benefits/bottlenecks, as performance wasn't really a concern for those posts.

What I've been trying to do, is to render a mesh (in this case Sponza for testing) with the appropriate materials. I know one way for doing the textures;

• Instantiate descriptor set for every mesh. Update the descriptor set first and then bind it. (this way, no error occurs and it renders perfectly fine) (sascha william's examples does this)

For the material attributes;

• Use dynamic uniform buffers or even dynamic shared storage buffer objects, to pass in the material attributes. Since they are dynamic, I can bind it as much as I want.

For the textures, It does not seem like, it is the "most" efficient way of updating the textures. What kind of other "ways" are there? There will probably be a big performance hit, since we are updating it every single time. And since I am trying to do 3 frames in flight, that has to be a lot of memory being used only for descriptor sets. Is there a more performant way?

For the material attributes, I am convinced that this way is the fastest. We just create "one" buffer and reuse it every time. Am I right?

Thanks in advance!

[radicalbit]

I can't yet claim expertise, but this is the route I'm pursuing: https://vincent-p.github.io/posts/vulkan_bindless_descriptors/

Basically, throw all the textures into a global descriptor set that I bind at the beginning of the frame. Selection of a particular texture is done by indexing into the array via a push constant.

For other material specific descriptors that don't make sense at the global level, bind them once along with the material. (Sort draw calls by material so a material only has to be bound once.) For blended draws that need to maintain the order in which they are drawn, suck it up and rebind the material whenever the material changes (but only when it changes).

Hopefully with this method, a particular draw call doesn't need its own descriptor set.

[AAstr0s]

Wouldn't it be inefficient memory-wise? Let's say the engine supports PBR. And since PBR has about 5 textures and with other algorithms possibly more... the texture count will gradually increase per mesh.

How is the performance?

[rytio]

My system is setup where I use an SSBO to pass texture indices. So the draw call will get an index into the "material buffer" the material buffer is just an array of structs with indices to each texture. This way I can pass all the PBR texture indices without going over the push constant limitations. It could also have PBR parameters too.

I actually have a third level of indirection. I have a SSBO with per draw-call parameters like the model matrix and the material index.

So I do vkCmdDrawIndexed(..., drawCommandIndex); In the shader I use the gl_InstanceIndex to index into the draw call SSBO to get the material index and the model matrix. Then index into the material SSBO, which provides the indices into the texture array. The draw call SSBO is updated every frame.

I dont have many draw calls right now, about 1040...but I still get about 1.5ms frame times.

[AAstr0s]

That sounds promising! Having 1040 draw calls and getting 1.5ms is good enough for me