Vulkan tutorial tests

[DaveAllerton]

Having built and run the vsgExamples, I have tried to build the vsgTutorial examples (particularly Hello_World) but I get a screenful of compilation errors (attached) with cmake, whereas I don't with vsgExamples. I notice that CMakeLists.txt in vsgTutorial and sub-directories is much simple than the one in vsgExamples. Are there additional exports I should be using for vsgTutorial examples?
temp.txt

[robertosfield]

The compile errors looks to be a C++ version issue:

/home/pi/Install/include/vsg/maths/vec2.h:121:32: error: ‘is_floating_point_v’ is not a member of ‘std’; did you mean ‘is_floating_point’?
  121 |             if constexpr (std::is_floating_point_v<value_type>)
      |                                ^~~~~~~~~~~~~~~~~~~
      |                                is_floating_point

What compiler version are you using?

Looking at the vsgTutorial/1_SettingTheScene/01_hello_world/CMakeLists.txt:

cmake_minimum_required(VERSION 3.7)

project(hello_world)

find_package(vsg REQUIRED)
find_package(vsgXchange REQUIRED)

add_executable(hello_world hello_world.cpp)

target_link_libraries(hello_world vsg::vsg vsgXchange::vsgXchange)

There isn't an explicit setting of C++17 compiler, could you try adding a:

# set the use of C++17 globally as all examples require it
set(CMAKE_CXX_STANDARD 17)

If this works for you then I'll go through the vsgTutorila CMakeLists.txt files and add the setting.

[DaveAllerton]

Thanks, that fixed the problem. I am hoping the examples in vsgExamples will provide insight to enable me to upgrade my flight simulation renderer from OSG to VSG and that it will run fast enough (50 fps) on an RPi with VSG - possibly over ambitious.

[robertosfield]

Is your flight sim open sourced?

Is your OSG version already ported to the RPi? What frame rate do you get with your scenes with the OSG on various platforms?

[DaveAllerton]

Yes, I have written two textbooks Principles of Flight Simulation, ISBN-978-1-60086-703-3 and Flight Simulation Software - Design, Development and Testing, ISBN 978-1-11973-767-4. The source code can be downloaded from free from John Wiley & Sons or from me via email [email protected]. The flight displays are written in OpenGL V4 and run on a low-end PC with a low-end nVidia card at 50 fps, taking about 3ms of the 20ms frame and on RPi4B also taking <4ms per frame. The OSG IG runs on a PC with a low-end nVidia card at 50 fps (two images attached). On the RPi4B the display exhibits a few discontinuities and struggles to make 50 Hz. But if Vulkan is 2-3 times faster than OSG I should be able to run my renderer at 50 fps. I have 3 OpenFlight databases of airfields and surrounding terrain. The OSG IG (2000 lines of c++) provides fogging, time of day, Head-Up Display overlays and a UDP socket interface to the flight simulator.

My hope is that mapping from OSG data structures and functions to SVG will turn out to be mostly straightforward.

[robertosfield]

Thanks for the explanation. From your description it sounds like you have a sim running in one application that sends UDP packets to an IG application. Do these both run on the same machine or do you run it across the network? While it won't affect your efforts, I wrote a vsgcluster in vsgExamples that distributes control of a network of viewers from a main viewer via UDP. It's more an example of customizing the VSG's serialization than anything else. On the performance front, OSG+OpenGL have much higher CPU overhead than VSG/Vulkan so if this is the bottleneck in your IG then you could see significant performance improvements, if the IG is fill limited then the potential performance gains will be lower. It will be interesting to see where things end up.

…

-- One of the development items I have been considering for the future has been the development of vsgIG library that becomes part of the vsg-dev family. This library would provide more vis-sim specific capabilities. I would also like to see osg2vsg rewritten using vsg::ShaderSet/GraphicsPipeline. A native OpenFLight loader is also on my wish list, I don't know whether a dedicated library or for it to be part of vsgXchange or vsgIG would be the best place for it. Sky, water and ephemeris, atmospheric effects are also features that could potentially be part of an vsgIG library, or perhaps separate libraries. These are all personal wish-list items that I'm sure others will have as well. I don't have clients that have requirested these items right now so these items are aspirational and don't have timeline/development plan behind. If there are companies out there that want these features, or if there are members of the OSG/VSG community that want to help make them happen then let me know as we can coordinate.

[DaveAllerton]

The flight simulator is based on 5 RPis plus an IG where the IG reads broadcast UDPs (see the book), Currently, the IG is a PC with OSG but I can also run the IG on an RPi but it struggles to make 50 fps. I have an article coming out in January or February in Linux Magazine describing the simulator (tbc). I also have a desktop version where the software on the 5 RPis runs on a single RPi and still makes 50 fps. Let me know separately if you would like any screenshots.

For me, the advantage of OSG is that it is open and free and supports OpenFlight databases. However, Unity and Unreal are impressive. I have used the IG in X-Plane12 with my simulator software and the SDK is very straightforward, the number of databases availabe for $30 or so is remarkable and it has been rewritten in Vulkan (ditto MS flight simulator but with DirectX). However, X-Plane12 still struggles to make 50 fps even with a high-end PC and high-end nVidia card, as they traded off scene content for frame rate. So I think it would be a lot of work to expand SVG for the features you mention and even so, you would still be fourth or fifth in the race.

Flight simulation IGs have two problems that are not relevant to games IGs. Firstly, the distances are fairly long so that shadows are not needed but fogging and atmospheric effects (sky, rain, snow) are important. Also 2D HUD overlays are required. Secondly, there is a wide range of visual databases and very limited support to convert/read these databases, some of which are protected. The market for games renderers is large, whereas the market for flight simulator renderers is small.

[timoore]

Is it fair to say that your system is intended as a pedagogic version of commercial flight simulation architecture? That's very cool. I used to be heavily involved with FlightGear, with which I'm sure you're familiar.

I think I've found the source code to your simulator as a list of zip files on the John Wiley & Sons website. Is that the public copy of the source?

I have a particular interest in your OpenFlight airfield / terrain databases. How do you generate these (or do I need to buy the book?) I'm the author of vsgCs, a companion project to VSG (can I say that @robertosfield ?) which renders 3D Tiles using VSG, doing everything from local terrain to the whole-earth datasets offered by Google and Cesium. The open-source ecosystem around OpenFlight seems pretty limited to me.

[DaveAllerton]

Yes, it is pedagogic in the sense that it was developed and has mostly been used in a university environment for teaching and research. The main aim was to provide a high accuracy, real-time, nonlinear simulator using open access(free) software. I have models for Boeing 747-100, Cessna-172, Cranfield A1, F-16, F-18, Piper PA-28, Piper PA-30, Jetstream-100 in various states of completion and displays for EFIS and classic flight instruments. This software runs on PCs under msys and Linux and also on RPis. The IG originally ran on SGI Performer then moved to OSG. The RPi IG OSG version struggles to make 50 fps, hence my interest in Vulkan.

The software for Principles of Flight Simulations is about 10 years old. The software for Flight Simulation - Design, Development and Testing is about 2 years old. Let me know ([email protected]) if you would like an up-to-date copy of the software.

I have OpenFlight databases for Bristol and Hong Kong which were gifts from industry and strictly, I can't pass these on. I also have an OpenFlight database for Manchester which was developed on Blender. I agree that OSG has disadvantages but it also has features which are ideal for application. Generally, I have no real need for whole world terrain as the simulators are normally used in research projects, and I map the airfield in the IG to the nearest airfield data in the navigation database, if that makes sense. The case for tiling in games and airline IGs is very different and has been tackled by X-Plane and MS, to a limited degree.

[robertosfield]

Disappointing to hear IG's struggling to hit 50fps. Hitting sync at a minimum of 60fps really should be entry level with modern hardware, one of course needs to manage scene complexity/effects to hit this. As Tim mentions, vsgCs opens the door to using 3D Tiles databases. This provides another option. I'd love to get the VSG ecosystem to a point where users can quickly put together visually compelling whole earth visualization applications. This isn't something you can just do in a day though, so bit by bit we're building the components of this.

[DaveAllerton]

You asked about the OSG frame rate on my RPi4B. I have attached 3 images which show approx 30 fps, 40 fps and 50 fps. The 50 fps one runs at 120 fps on my PC with an nVidia GTX-1060 card. I am hoping that VSG will achieve at least 2x the speed.

Is there a beginner's guide to vsgXconv and osg2vsg? Where will I find representative shaders for terrain, 3D object rendering and fogging?

[robertosfield]

From the performance and scene stats it looks like the RPi is coping pretty well with the scene.  The number of nodes/drawables is very low for sim so the CPU overhead doesn't seem to be stressing the OSG/OpenGL's Achilles heel.

The draw dispatch/draw GPU looks to be the big bottleneck, from the info it's not possible to know how much this can be lowered by the VSG/Vulkan.

The small test program that you ran and got low FPS suggests the driver might not be accelerated.

---

On the shader front, osg2vsg has basic shaders built-in that provide a basic mapping of the GL style fixed function pipeline to shaders, but isn't support for fog right now.

My plan is for osg2vsg to be rewritten to use vsg::ShaderSet which will be more flexible. The vsg::ShaderSet scheme allows users to extend that rendering to encompass things like fog.  The new vsgcustomshaderset example illustrates how to add OpenGL style fog for instance, I wrote up details about this in the thread #1026.