I've made a simpler demonstration of the issue I think we have.
So currently a texture makes a descriptor, creates a set using that descriptor then creates a bindDescriptorSets using that set. The textures are using a different bindingindex
However when you add another texture with a different binding index you end up eliminating the fist because each texture makes another bindDescriptorSets that only contains one set.
I'm pretty sure the call to vkCmdBindDescriptorSets will replace any exisitng set in the same index/setnumber.
To have multiple descriptors within a single set we must bind them in the same call. If we want multiple sets each with it's own BindDescriptorSets then I think we need to change the vkCmdBindDescriptorSets call to account for firstSet index. Currently if we have two BindDescriptorSets with one set in each one will replace the other. If we allowed a firstSet index for the BindDescriptorSets then one texture could bind to set 0, another to set 1 etc.
The example just creates a ShareBindDescriptorSets, that is passed to the texture and it's descriptor is added to a list during compile. We then add the ShareBindDescriptorSets to the stateset after the textures so once the textures have compiled and added their descriptors the ShareBindDescriptorSets can compile all the descriptors into DescriptorSets and bind them.
It's still a hack but i think it gets the idea across. Hope that makes sense, think how this gets handled is gonna be pretty critical. Perhaps we should even try adding in a more generic uniform before we commit to anything, try and understand all the requirements.
Note the ShareBindDescriptorSets is currently active, to disable it just change line 456 of GeometryUtils.cpp so that there isn't a vaild ShareBindDescriptorSets.
I've made a simpler demonstration of the issue I think we have.
So currently a texture makes a descriptor, creates a set using that descriptor then creates a bindDescriptorSets using that set. The textures are using a different bindingindex
However when you add another texture with a different binding index you end up eliminating the fist because each texture makes another bindDescriptorSets that only contains one set.
I'm pretty sure the call to vkCmdBindDescriptorSets will replace any exisitng set in the same index/setnumber.
To have multiple descriptors within a single set we must bind them in the same call. If we want multiple sets each with it's own BindDescriptorSets then I think we need to change the vkCmdBindDescriptorSets call to account for firstSet index. Currently if we have two BindDescriptorSets with one set in each one will replace the other. If we allowed a firstSet index for the BindDescriptorSets then one texture could bind to set 0, another to set 1 etc. The example just creates a ShareBindDescriptorSets, that is passed to the texture and it's descriptor is added to a list during compile. We then add the ShareBindDescriptorSets to the stateset after the textures so once the textures have compiled and added their descriptors the ShareBindDescriptorSets can compile all the descriptors into DescriptorSets and bind them.
It's still a hack but i think it gets the idea across. Hope that makes sense, think how this gets handled is gonna be pretty critical. Perhaps we should even try adding in a more generic uniform before we commit to anything, try and understand all the requirements.
Note the ShareBindDescriptorSets is currently active, to disable it just change line 456 of GeometryUtils.cpp so that there isn't a vaild ShareBindDescriptorSets.