Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Annotation with debug_utils example #277

Merged
merged 2 commits into from
Nov 29, 2023
Merged

Conversation

timoore
Copy link
Contributor

@timoore timoore commented Nov 29, 2023

This example shows how to insert nodes in the scene graph with annotations that can be used by debugging programs like RenderDoc. A screenshot of the RenderDoc display is included.

@robertosfield
Copy link
Collaborator

I have merged as a timoore-annotation branch:

https:/vsg-dev/vsgExamples/tree/timoore-annotation

I'll now get things compiling and have a bash at use RenderDoc with it. I did wonder about naming the example vsgrendrdoc if it's mainly about enabling high quality RenderDoc usage.

@robertosfield
Copy link
Collaborator

I have got it working with qrenderdoc, found out that ~ doesn't work for paths in RenderDoc which lots me few minutes trying to figure out why things weren't starting up...

I can see the annotation, it's a bit limited though, so I'm thinking that it might be nice to have a visitor that goes through the scene graph and insert annotation nodes. Can this extension handle nesting?

I am also thinking about whether we need the EXT at the end of the function names. I presume at some point Vulkan will move these from EXT.

@timoore
Copy link
Contributor Author

timoore commented Nov 29, 2023

I have got it working with qrenderdoc, found out that ~ doesn't work for paths in RenderDoc which lots me few minutes trying to figure out why things weren't starting up...

I admit that I've never used an animation path, which I presume you mean?

Renderdoc does define an in-application interface, so an application could make a capture on a specific frame, among other things.

I can see the annotation, it's a bit limited though, so I'm thinking that it might be nice to have a visitor that goes through the scene graph and insert annotation nodes. Can this extension handle nesting?

Yes, my screenshot shows the output from a nested use of annotation nodes. It also shows a limitation; the transparent lenses on the flight helmet end up without any annotation because they are rendered in a bin.

I am also thinking about whether we need the EXT at the end of the function names. I presume at some point Vulkan will move these from EXT.

I don't know.

@robertosfield
Copy link
Collaborator

Oooh, just tried:

 vsgannotation models/lz.vsgt models/teapot.vsgt -a

And if I search for the EXT I find:

Thread 0, Frame 0:
vkCmdBeginDebugUtilsLabelEXT(commandBuffer, pLabelInfo) returns void:
    commandBuffer:                  VkCommandBuffer = 0x564788659c10
    pLabelInfo:                     const VkDebugUtilsLabelEXT* = 0x7ffe5cb102b0:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT (1000128002)
        pNext:                          const void* = NULL
        pLabelName:                     const char* = "Scene"
        color:                          float[4] = 0x7ffe5cb102c8
            color[0]:                       float = 0.8
            color[1]:                       float = 0.8
            color[2]:                       float = 0.8
            color[3]:                       float = 1

Thread 0, Frame 0:
vkCmdBeginDebugUtilsLabelEXT(commandBuffer, pLabelInfo) returns void:
    commandBuffer:                  VkCommandBuffer = 0x564788659c10
    pLabelInfo:                     const VkDebugUtilsLabelEXT* = 0x7ffe5cb10230:
        sType:                          VkStructureType = VK_STRUCTURE_TYPE_DEBUG_UTILS_LABEL_EXT (1000128002)
        pNext:                          const void* = NULL
        pLabelName:                     const char* = "/home/robert/Dev/vsgExamples/data/models/lz.vsgt"
        color:                          float[4] = 0x7ffe5cb10248
            color[0]:                       float = 1
            color[1]:                       float = 1
            color[2]:                       float = 1
            color[3]:                       float = 1

Which is cool :-)

@robertosfield
Copy link
Collaborator

@timoore I am curious why you added the following definitions as I don't think they are necessary, and if they are the a using should be sufficient to make sure they are still available. Just commenting them out things still work fine for me.

#if 0
        // ParentClass::accept() is hidden by overriding accept(RecordTraversal&), so we need to
        // reimplement the other variations too in order to be able to call them directly.
        void accept(vsg::Visitor& visitor) override
        {
            ParentClass::accept(visitor);
        }

        void accept(vsg::ConstVisitor& visitor) const override
        {
            ParentClass::accept(visitor);
        }
#endif

@robertosfield
Copy link
Collaborator

I have got it working with qrenderdoc, found out that ~ doesn't work for paths in RenderDoc which lots me few minutes trying to figure out why things weren't starting up...

I admit that I've never used an animation path, which I presume you mean?

No, it was the command line paths to the files I was trying to load, I copy and pasted command line parameters that worked in bash but I didn't think about the ~ that bash automatically expands. Unfortunately RenderDoc was quietly failing without information when nothing was happening so I looked in all the wrong places to fix things.

Renderdoc does define an in-application interface, so an application could make a capture on a specific frame, among other things.

I have only started tinkering with RenderDoc and am pretty amazed by it.

Yes, my screenshot shows the output from a nested use of annotation nodes. It also shows a limitation; the transparent lenses on the flight helmet end up without any annotation because they are rendered in a bin.

I noticed the the Scene is coming from the annotation too, but didn't realize this at first.

I am also thinking about whether we need the EXT at the end of the function names. I presume at some point Vulkan will move these from EXT.

I don't know.

I will do another code review of the PR to the VSG and make decision. Without EXT is more readable so I'm drawn in that direction.

@robertosfield
Copy link
Collaborator

If I'm reading this correct it looks like this extension is part of Vulkan 1.3:

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_tooling_info.html

@timoore
Copy link
Contributor Author

timoore commented Nov 29, 2023

@timoore I am curious why you added the following definitions as I don't think they are necessary, and if they are the a using should be sufficient to make sure they are still available. Just commenting them out things still work fine for me.

#if 0
        // ParentClass::accept() is hidden by overriding accept(RecordTraversal&), so we need to
        // reimplement the other variations too in order to be able to call them directly.
        void accept(vsg::Visitor& visitor) override
        {
            ParentClass::accept(visitor);
        }

        void accept(vsg::ConstVisitor& visitor) const override
        {
            ParentClass::accept(visitor);
        }
#endif

It doesn't make any difference in the example. I put it in there as just as for good pratice. You are write that using Annotation::accept; works well and is probably better style. I was stuck in C++98 land.

@timoore
Copy link
Contributor Author

timoore commented Nov 29, 2023

If I'm reading this correct it looks like this extension is part of Vulkan 1.3:

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_tooling_info.html

The tooling info extension has been promoted, but I don't think that debug_utils has been.

@robertosfield
Copy link
Collaborator

On the tooling info page I says "Interacts with VK_EXT_debug_utils == Deprecation State" which makes me wonder if the VK_EXT_debug_utils is being subsumed into something else.

@robertosfield
Copy link
Collaborator

I have replaced the extra void accept(..) methods with using: 7f05b1a

Save for the decision about EXT suffix I think we are good to go.

@robertosfield
Copy link
Collaborator

Reviewing the code, I find the line:

std::copy(&debugColor.value[0], &debugColor.value[4], &markerInfo.color[0]);

rather more cryptic than I'd like. I have tried a couple variations of help functions but not come up with anything that I'm happy with yet. Perhaps a helper function in include/vsg/maths/color,h? A copy member function of vsg::vec4?

I'm open to suggestions about what might be more expressive than a std::copy() that you have closely read to know for sure it's doing something intended.

This needn't hold up merging this branch though.

@robertosfield robertosfield merged commit 9c60737 into vsg-dev:master Nov 29, 2023
@robertosfield
Copy link
Collaborator

Forgot to mention, if we want to annotate stuff that goes into the transpent bin then subclassing from vsg::Bin and then assigning this to the View at the appropriate slot would be the way to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants