Qt example

213 views
Skip to first unread message

Andre Normann

unread,
Dec 28, 2020, 2:01:35 PM12/28/20
to vsg-...@googlegroups.com
Hello all,

I am currently working on a Qt example.

What steps need to be taken, after the presentation of the file dialog?

vsg::read(filename) is clear, but how do I attach the newly loaded node to the scenegraph? Is there any example available?

Best regards,
André

Roland Hill

unread,
Dec 28, 2020, 5:57:26 PM12/28/20
to vsg-...@googlegroups.com
Hi Andre,

It's probably best to use MyFirstVsgApplication as a template from there. 


Look forward to seeing how you get on.

Regards,
Roland


--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFKnD9z9bCReasu_icfXDt0wOGJ6mDLd3iXwvd7GRpMjkN6Txg%40mail.gmail.com.

Robert Osfield

unread,
Dec 28, 2020, 6:03:12 PM12/28/20
to vsg-...@googlegroups.com
HI Andre,

I'm away from my dev system so will just answer off the top of my head right now.  When I'm back at my dev system tomorow I should be able to provide more detail.

On Mon, 28 Dec 2020 at 19:01, Andre Normann <andre....@gmail.com> wrote:
I am currently working on a Qt example.

Cool.  Do you have anything available for others to review already?

 
What steps need to be taken, after the presentation of the file dialog?

vsg::read(filename) is clear, but how do I attach the newly loaded node to the scenegraph? Is there any example available?

There isn't yet an example that does this specific usage case.

If you have a VSG window already setup for rendering so it has a CommandGraph with a RenderGraph within it, then adding the newly loaded node to RenderGraph would be appropriate.  The newly loaded subgraph will need to be compiled - with all the Vulkan objects created prior to it being added to the RenderGraph.  

Another approach would be to create a vsg::Group that you add to the CommandGraph/RenderGraph on viewer setup then add to this Group.  You'll still need to do the Vulkan object compile traversal.

Another complication is that Vulkan requires a set up of sufficient DescriptorSet pools, you can tell the VSG to preallocate a sufficient number of the needs of the newly loaded subgraph.  

The vsg::Viewer::compile() traversal contains the work that needs to be done, potentially this could be used, but I haven't used in this context so far - just used it prior to the start of the main loop.

Making tasks like this easier is something I want to do before we get to 1.0, so your example might be a good testbed for what works right now, what needs streamlining.

Cheers,
Robert.

Andre Normann

unread,
Dec 29, 2020, 3:58:22 AM12/29/20
to vsg-...@googlegroups.com
Hi Robert,

That helped a lot. Thank you. 

I have uploaded the code into a public repository: https://github.com/anormann1974/vsgQtViewer

Currently it is a qmake base project and only tested on windows. Perhaps others can test it on Linux etc. It is a starting point and there is a lot of work to be done.

Best regards,
André


--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Robert Osfield

unread,
Dec 29, 2020, 6:16:11 AM12/29/20
to vsg-...@googlegroups.com
Hi Andre,

Thanks for posting the example.  I've had a quick bash at getting things to compile under Linux.  The first issue I had was due to case sensitivity of Linux filesystem so I had to tweak the includes in two places.  I've applied a fix and generated a PR for this change:


I'm not a Qt user so am not familiar with qmake so don't know immediately how to fix the next issue:

g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui
-isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o VulkanWindow.o src/VulkanWindow.cpp
src/VulkanWindow.cpp:7:10: fatal error: vsg/all.h: No such file or directory
#include <vsg/all.h>

I haven't installed the VSG into system directory, instead I have it installed it in my local /home/robert/Install directory and normally point Cmake build systems at this location using CMAKE_INSTALL_PREFIX=/home/robert/Install when I run cmake. I could install in the system directory, but would rather see if we can get things to build with my existing VSG set up - having this flexibility will be useful for others as well.

Cheers,
Robert

Andre Normann

unread,
Dec 29, 2020, 7:08:14 AM12/29/20
to vsg-...@googlegroups.com
Hi Robert,

I merged your fix and created a unix section inside the .pro file. You can now set an environment variable VSG_ROOT to point to your vsg install dir. The VULKAN_SDK environment variable is also needed, but this one is set automatically on my system.

Best regards,
André

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Robert Osfield

unread,
Dec 29, 2020, 12:02:42 PM12/29/20
to vsg-...@googlegroups.com
On Tue, 29 Dec 2020 at 12:08, Andre Normann <andre....@gmail.com> wrote:
I merged your fix and created a unix section inside the .pro file. You can now set an environment variable VSG_ROOT to point to your vsg install dir. The VULKAN_SDK environment variable is also needed, but this one is set automatically on my system.

Thanks.  I've merged your changes into my fork and got a bit further with the build once I added the VULKAN_SDK/include.  I've generated a PR for this fix:


I now get the following compile error:

g++ -c -pipe -O2 -Wall -W -D_REENTRANT -fPIC -DVK_USE_PLATFORM_XLIB_KHR -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../Install/include -I../../3rdParty/VulkanSDK/1.2.162.0/x86_64/include -isystem /usr/include/x86_64-linux-gnu/qt

5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I. -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o VulkanW
indow.o src/VulkanWindow.cpp
In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qdebug.h:49:0,
                from /usr/include/x86_64-linux-gnu/qt5/QtCore/QDebug:1,
                from src/VulkanWindow.cpp:10:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qtextstream.h:52:2: error: #error qtextstream.h must be included before any header file that defines Status
#error qtextstream.h must be included before any header file that defines Status
 ^~~~~
src/VulkanWindow.cpp:11:10: fatal error: QVulkanInstance: No such file or directory
#include <QVulkanInstance>
         ^~~~~~~~~~~~~~~~~

I am afraid my lack of familiarity with Qt isn't helping us much at this point :-)

Andre Normann

unread,
Dec 29, 2020, 12:13:15 PM12/29/20
to vsg-...@googlegroups.com
What Qt5 version are you using, Robert? It seems to me that your version doesn't support Vulkan.

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Robert Osfield

unread,
Dec 29, 2020, 12:19:48 PM12/29/20
to vsg-...@googlegroups.com
On Tue, 29 Dec 2020 at 17:13, Andre Normann <andre....@gmail.com> wrote:
What Qt5 version are you using, Robert? It seems to me that your version doesn't support Vulkan.

$ qmake --version
QMake version 3.1
Using Qt version 5.9.5 in /usr/lib/x86_64-linux-gnu

I'm using Xubuntu 18.04 right now.

Andre Normann

unread,
Dec 29, 2020, 12:41:30 PM12/29/20
to vsg-...@googlegroups.com
You need at least Qt 5.10 to have vulkan support. 

I have setup a virtual machine with Ubuntu 20.04 and try to compile it. 

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Robert Osfield

unread,
Dec 29, 2020, 12:42:10 PM12/29/20
to vsg-...@googlegroups.com
On Tue, 29 Dec 2020 at 17:19, Robert Osfield <robert....@gmail.com> wrote:
On Tue, 29 Dec 2020 at 17:13, Andre Normann <andre....@gmail.com> wrote:
What Qt5 version are you using, Robert? It seems to me that your version doesn't support Vulkan.

$ qmake --version
QMake version 3.1
Using Qt version 5.9.5 in /usr/lib/x86_64-linux-gnu


According to Qt docs QVulkanInstance exists in 5.10 onwards:


So I won't be able to test without installing another version of Qt.

The other route would be for the VSG to add the Vulkan support to a native window i.e. X11 Window.  I don't know how easy it would be to go this route with modern Qt versions.

Personally I don't think Qt is really the place for doing OpenGL or Vulkan, they've really not had a good track record over the years of not screwing up support for GL in clean ways over the years - in the early days of the OSG project we quite quickly got decent OSG support but they kept moving the goalposts and breaking things requiring updates to the OSG integration.  Even now I don't think OSG/Qt integration is elegant or as functional as it should be simply because Qt tries to force "it's way" on how you manage the graphics context, 

This all makes me a bit wary of Qt providing Vulkan integration.  The VSG is fully Vulkan centric, it's not an optional add-on feature, it's all about exposing Vulkan in a way that doesn't hide or constrain Vulkan functionality - that's the principal I'm aiming for.  Qt has it's own focus but it's far higher and broader, but also adds it's own constraints.

An ideal integration with Qt for me would be one that lets the VSG do the Vulkan functionality to the best of ability, and for Qt to just do Windowing to the best of it's ability.



Steve Rainwater

unread,
Dec 29, 2020, 1:11:44 PM12/29/20
to vsg-...@googlegroups.com
One other potential problem to watch out for is that VSG relies on X windows but, at least on Fedora, the OS, GTK, Qt, WxWidgets, etc all use Wayland instead of X. So using any of the distro provided libs with VSG won't work. It's necessary to compile your own version of Qt using the legacy X libraries and link to it rather to the Distro provided Qt libs. Fedora was an early adopter of Wayland; I'm not certain when Ubuntu made the switch, Ubuntu 18 may still be using X but I bet 20 is using Wayland. Fedora has X compatibility, so the VSG examples all run fine, it's only if you link against distro provided UI libs using Wayland that you run into problems. Maybe adding a platform / unix file for Wayland support in VSG should be on the ToDo list as more distros make the switch from X.

-Steve


--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Andre Normann

unread,
Dec 29, 2020, 1:32:02 PM12/29/20
to vsg-...@googlegroups.com
Am Di., 29. Dez. 2020 um 18:42 Uhr schrieb Robert Osfield <robert....@gmail.com>:
According to Qt docs QVulkanInstance exists in 5.10 onwards:


So I won't be able to test without installing another version of Qt.

The other route would be for the VSG to add the Vulkan support to a native window i.e. X11 Window.  I don't know how easy it would be to go this route with modern Qt versions.

Personally I don't think Qt is really the place for doing OpenGL or Vulkan, they've really not had a good track record over the years of not screwing up support for GL in clean ways over the years - in the early days of the OSG project we quite quickly got decent OSG support but they kept moving the goalposts and breaking things requiring updates to the OSG integration.  Even now I don't think OSG/Qt integration is elegant or as functional as it should be simply because Qt tries to force "it's way" on how you manage the graphics context, 

This all makes me a bit wary of Qt providing Vulkan integration.  The VSG is fully Vulkan centric, it's not an optional add-on feature, it's all about exposing Vulkan in a way that doesn't hide or constrain Vulkan functionality - that's the principal I'm aiming for.  Qt has it's own focus but it's far higher and broader, but also adds it's own constraints.

An ideal integration with Qt for me would be one that lets the VSG do the Vulkan functionality to the best of ability, and for Qt to just do Windowing to the best of it's ability.

This is how my example works. Qt does not create the vulkan instance. It is using the instance created by vsg. Qt is only managing the surface part. QVulkanInstance::surfaceForWindow is used for creating a VkSurfaceKHR instance. So I only use a few QVulkan* components. 

One word about Qt and OSG: I have been using Qt and OSG in my software for a long time. With the latest versions everything is working very well (even multithreading support). So Qt is not so bad and with Vulkan it is very easy to use. 

Robert Osfield

unread,
Dec 29, 2020, 2:34:16 PM12/29/20
to vsg-...@googlegroups.com
On Tue, 29 Dec 2020 at 18:11, Steve Rainwater <steev...@gmail.com> wrote:
One other potential problem to watch out for is that VSG relies on X windows but, at least on Fedora, the OS, GTK, Qt, WxWidgets, etc all use Wayland instead of X. So using any of the distro provided libs with VSG won't work. It's necessary to compile your own version of Qt using the legacy X libraries and link to it rather to the Distro provided Qt libs. Fedora was an early adopter of Wayland; I'm not certain when Ubuntu made the switch, Ubuntu 18 may still be using X but I bet 20 is using Wayland. Fedora has X compatibility, so the VSG examples all run fine, it's only if you link against distro provided UI libs using Wayland that you run into problems. Maybe adding a platform / unix file for Wayland support in VSG should be on the ToDo list as more distros make the switch from X.

I would like to see a Wayland_Window implementation to be an alternative to the current Xcb_Window implementation.  A  straight X11 version would also be welcome.  I chose Xcb as a starting place simply because the main Vulkan examples I used in the early days of the VSG project used Xcb. I see it as a starting place rather than the be all and end of native Windowing under unices.

I built the VSG under Ubuntu and Kubuntu 20.04 without problems so support for Xcb/X11 is maintained OK.  I think I had to install xcb_dev package and Vulkan but it was pretty straight forward.  If the time comes that Xcb or X11 is no longer the default build for the VSG under Linux then I'd be fine for that.  My main priority is that users can get a Vulkan/VSG window up quickly with good functionality out of the box.

If folk want to dive into implementing Wayland or X11 integration then please do.  For now my focus will be on getting the general VSG functionality up to a place that it's ready for 1.0.

Robert Osfield

unread,
Dec 29, 2020, 2:44:41 PM12/29/20
to vsg-...@googlegroups.com
On Tue, 29 Dec 2020 at 18:32, Andre Normann <andre....@gmail.com> wrote
Am Di., 29. Dez. 2020 um 18:42 Uhr schrieb Robert Osfield <robert....@gmail.com>:
This is how my example works. Qt does not create the vulkan instance. It is using the instance created by vsg. Qt is only managing the surface part. QVulkanInstance::surfaceForWindow is used for creating a VkSurfaceKHR instance. So I only use a few QVulkan* components. 

Does this mean both Qt and the VSG are independently creating a vkInstance?  I don't know of whether it's OK to utilize Vulkan objects across different vkInstance, I wouldn't be surprised if this could be sensitive to what drivers support.  The Vulkan debug layer would hopefully flag issues like this even if the drivers handle it.

It may make sense to pass the Qt vulkan instance to the VSG, or visa-versa.  This would introduce the thorny issue of who is responsible for cleaning up the VkInstance.  The VSG has a specific Vulkan object scheme that avoids the vkInstance getting deleted while it's still in use, so if Qt deleted it then this ibuilt safety could be undermined.   

Andre Normann

unread,
Dec 30, 2020, 2:29:20 AM12/30/20
to vsg-...@googlegroups.com
Am Di., 29. Dez. 2020 um 20:44 Uhr schrieb Robert Osfield <robert....@gmail.com>:
Does this mean both Qt and the VSG are independently creating a vkInstance?  I don't know of whether it's OK to utilize Vulkan objects across different vkInstance, I wouldn't be surprised if this could be sensitive to what drivers support.  The Vulkan debug layer would hopefully flag issues like this even if the drivers handle it.

No, vsg is creating the vkInstance via vsg::Instance::create(). QVulkanInstance is then using the vkInstance from vsg and is not owning them (Qt will not destroy the vkInstance). 
 

Robert Osfield

unread,
Dec 30, 2020, 6:11:46 AM12/30/20
to vsg-...@googlegroups.com
Great, that resolves my worry about possible complications.

I have a Kubuntu 20.04 install that should build vsgQtViewer OK, but unfortunately I broke that install a while back when messing around with different kernel versions and nvidia drivers.  I will need to reinstall or figure out how to fix my over enthusiastic hacking.  I should probably be able to do a local install of a later version of Qt.

I don't have time right away to tinker though as I have some OSG client work to get on with before the end of year.  It'll be 2021 before I can tinker to my heart's content :-)

Do you have the viewer displaying models?

Andre Normann

unread,
Dec 30, 2020, 7:21:26 AM12/30/20
to vsg-...@googlegroups.com
Yes, it can display models. But I still have some problems when loading the files after the first viewer->compile() call. I have to learn Vulkan more, to understand everything. It is so different compared with OpenGL/OSG ;-)

Here is screenshot:

image.png

And I need to compile vsgXchange so that I can import all my models from my OSG application.


--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

Raymond de Vries

unread,
Dec 30, 2020, 7:25:56 AM12/30/20
to vsg-...@googlegroups.com
Hi Andre,

Fwiw, I have been following your work with great interest. Nice job, have fun!

Cheers,
Raymond
Reply all
Reply to author
Forward
0 new messages