Questions about VSG design around compile and render methods.

[theodoregoetz]

VSG is great and I love it - it's easy to use and easy to extend. However, I've never understood exactly what each of the following methods is doing and it's getting me into trouble.

viewer->compile()
if (viewer->advanceToNextFrame()) {
    viewer->handleEvents();
    viewer->update();
    viewer->recordAndSubmit();
    viewer->present();
}

For example, I've found a few cases where Viewer::advanceToNextFrame() fails and I'm not sure why or what to do about it in my code. I think the community at large would benefit from some explanation of each line in the above snippet from a high-level design perspective and also from a practical error-handling viewpoint - like what should or can be done if any of these operations fail?

[sbrkopac]

Hi John,

You should check out the book here: https://vsg-dev.github.io/vsgTutorial/

It may not answer your question above but is a good starting point. It also is probably is a great place to open an issue for missing content!

[robertosfield]

Did you mean to use a while loop rather than an if statement in your code segment? It's kinda odd to see compile() followed by an if.

When you say "Viewer::advanceToNextFrame() fails" do you mean just return false or do you mean an actual error occurs.

In what circumstances does it "fail"?

As the function of each of the methods, at a high level the naming of the methods explains what is being done by each method, trying to explain what goes into each could take rather a long time with an open ended question.

I'm busy so not keen on trying to guess what end users are struggling with and trying to answer open ended questions that might take me many times to actually answer the question users want answered.

[theodoregoetz]

I did mean if instead of while to highlight that advanceToNextFrame is the only method above that returns anything - presumably so that corrective action can take place? I'm working up a minimal example where Viewer::advanceToNextFrame() is returning false where I'm switching between a Viewer displayed onscreen and another which is offscreen. This operation seems to require a scene traversal with the vsg::UpdateGraphicsPipelines visitor because compile is insufficient - I don't know if this by design or a bug because I don't know the design goals of the compile method. I'll read all the VSG documentation I can find for the nth time to see if I really did miss this information.

[robertosfield]

This is a very special case of usage so general descriptions won't help you much.

The usage case your describe is not one I have tried to do myself before so I will have guess at what the most appropriate approach to take. You may well be the first user to ever want to try specially what you are asking for as I don't recall anyone asking how to do it before.

When you switch from use on screen to offscreen will you ever want to switch back? Will you ever want to have both the Window and the offscreen running at the same time?

The vsg::UpdateGraphicsPipeline class is a visitor that can help refresh the scene graphs GraphicsPipeline when you change viewport related state, such as when resizing a window. Off the top of my head I can't say whether this will be sufficient to use, or even necessary - if your viewport dimensions don't change then you might not need to do this.

One thing to be aware of is the vsg::View has a unique viewID that is automatically managed for you to make sure it's unique, but the values are reused, The viewID is used to index into the cached vkPipeline objects. If you are creating/destroying view's and reusing the same scene graph below you'll need to be careful that the scene graph isn't trying to render to an inappropriate ViewportState - this is why UpdateGraphicsPipeline. helps.

Because what you are asking for is not something I've tried to do before you are working off mapm the best I can suggest is that create a new example for vsgExamples that illustrates what you are wanting to achieve with the steps you currently think are appropriate but can't get it to work, then share this so others can have a look at the code, try it out, and figure out what needs to change to get it work. Then afterwards we'll have an example to illustrate what to do for the next time someone asks for something a bit unusual like this.