Understanding of ImTextureID management/maybe bug in context with Vulkan DescriptorSets

[PowerOfNames]

Version/Branch of Dear ImGui:

Using my own ImGUi fork, branch 'docking' (https://github.com/PowerOfNames/imgui/tree/docking)

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_vulkan.cpp
Operating System: Win10

My Issue/Question:

I'm trying to get #914 running -> Vulkan Image/Textures and what not. Im both new to Vulkan and not very experienced with ImGui, but I tried follwing the data flow through it to at least understand the general concept a bit.
The engine creates a VkDescriptorSet handle using (I think) marttys 'VkDescriptorSet ImGui_VulkanImpl_AddTexture(VkSampler sampler, VkImageView imageView, VkImageLayout layout)' implementation to get myself a descSet handle.

Because I dont want to expose any vulkan objects into my actual Engine API, I have a wrapper around Image and Textures.
To use 'ImGui::Image(texID,...)' a texture ID has to be provided.
To, thinkink that both vulkans descriptor set is a void* and ImTextureID also is a void*, I cast the VkDescriptor set I get from the rendering backend into a void* (again, to not expose any vulkan objects), and this void* into an ImTextureID where I need it.

Now for the issue -> I get vulkan error messages, that state I try to bind an invalid descriptor pointer with handle 0x5 <- 5 is important!
So I started printing out the handle everywhere it gets passed on through ImGuis backend using
std::cout<<"DescSet handle:"<<(uint64_t)desc_set<<std::endl;

At first it looks normal (got a random 64bit integer through:

• ImGui::Image() into
• ImGui::Image() { window->DrawList->AddImage() }into
• ImDrawList::AddImage { if(push_texture_id =true )->PushTextureID() } into
• ImDrawList::PushTextureID

And now the point I dont understand happens: When printing in PushTextureID before the _OnChangeTextureID call, both texture_id (the input param) and _CmdHeader.TextureId seem to caontain the 'right' handle, lets say 562156438365374182 or something, as expected after _CmdHeader.TextureId = texture_id;
BUT inside ImDrawList::_OnChangedTextureID, inside the first if statement (which seems to be true as prints inside there get called and it would be logical that curr_cmd differs from the last CmdBuffer.Data entry),
for some reason, when printing both curr_cmd->TextureId and _CmdHeader.TextureID, only curr_cmd->TextureId actually contains '562156438365374182', whereas _CmdHeader.TextureID contains '5'.
How does this work out? The calls should be one after another, so first _CmdHeader.TextureID gets set to be '562156438365374182' in ImDrawList::PushTextureID(), which then immediatly calls ImDrawList::_OnChangedTextureID(), which just checks something without every touching _CmdHeader.TextureID but ImDrawList::_OnChangedTextureID's content changes dispite that.

I assume I did something wrong, but I'd like to understand what exactly.
Also, This whole casting from VkDescriptorSet to void' back to ImTextureID was working in a prior version, cruder version of my implementation (https://github.com/PowerOfNames/Povox/blob/529746c18e3e23c7ae7ada20076c169ebc77d1f3/Povox/src/Platform/Vulkan/VulkanContext.cpp#L386 <- this was before refactoring any vulkan code)

The motivation for now is just to

• Render my scene
• create a texture out of it
• put that into ImGui and create a viewport

My ImGui fork/docker branch should be up to date, so the issue should happen there (maybe)

PS: I've read through several of the Vulkan related issues here in the ImGui github, but couldn't find an easier solution that actually works with my Engine frontend.

[PowerOfNames]

Update: Just found out that _OnChangedTextureID gets fired twice, the first time both if statements get skipped, and just 'curr_cmd->TextureId = _CmdHeader.TextureId' is called.
The next time (which triggered my prints) was during ImDrawList::AddImage()->PopTextureID().

However, using the debugger I found that inside 'ImGui_ImplVulkan_RenderDrawData()' the first entry of draw_data contains the ominous '5' as a TextureID -> where could this 5 come from? It doesn't even seem to be an issue with my casting, cause that handle seems to actually travel to the right position.

[PowerOfNames]

No idea how it happend, but I just found that inside the changed 'ImGui_ImplVulkan_CreateFontsTexture()'->'VkDescriptorSet font_descriptor_set = (VkDescriptorSet)ImGui_VulkanImpl_AddTexture(bd->FontSampler, bd->FontView, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL);' lost its call to the actual function, and only 'VkDescriptorSet font_descriptor_set = (VkDescriptorSet)(bd->FontSampler, bd->FontView, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL);' was left. It did not create any errors, but that was the issue.

Sorry to bother. :=O

[ocornut]

Note that you can use the Metrics/Debugger window to visualize each drawlist and drawcmd and you can see the ImTextureID values in there.

[PowerOfNames]

Note that you can use the Metrics/Debugger window to visualize each drawlist and drawcmd and you can see the ImTextureID values in there.

Oh, I'll have a look into that, thanks! I just used the step by step debuger and took a look inte the field values this way. I only have 2 textures atm that are passed to ImGui. My viewport, whcih was correct, and the fontAtlas -> which had to be the issue. But that was totally my fault, so... !

[ocornut]

Adding a link to the Debug Tools wiki page for good measure :)