VulkanSceneGraph: Difference between revisions
(create placeholder and add stub using contents from the devel list) |
m (→Motivation: https://sourceforge.net/p/flightgear/mailman/message/37041937/) |
||
| Line 33: | Line 33: | ||
VulkanSceneGraph requires C++17. If we | |||
adopt VSG, and I believe we should, that will impose a second disruption | |||
further down the road. Better to adopt C++17 now to avoid a double hop.<ref>https://sourceforge.net/p/flightgear/mailman/message/37041937/</ref> | |||
== References == | == References == | ||
{{Appendix}} | {{Appendix}} | ||
Revision as of 10:52, 28 June 2020
| This article is a stub. You can help the wiki by expanding it. |
Intro
VulkanSceneGraph was just announced. Something to watch as it develops. Potentially a disruptor down the road, and perhaps a good design option to consider as it matures.[1]
https://github.com/openscenegraph/VulkanSceneGraph
Background
Unfortunately, OSG is still largely dependent on the old openGL fix-function pipeline. Some folks have been working toward a working OSG build without it, but you need to deal with several non-functional features (e.g. osgText).
I doubt the situation improves until VSG becomes a viable option.[2]
Vulkan would be nice but OpenSceneGraph suits us fine right now. And changing that would really be an involved process.[3]
Motivation
We shouldn't expect using HLA to improve performance. The big "win" would be to decouple the simulation from the rendering. That would mean that graphical frame-rates would be more consistent, even if the simulation underneath wasn't. It would also allow different renderers to be used - e.g. you could plug in a a completely separate renderer based on VulkanSceneGraph as opposed to OpenSceneGraph.
To be honest, many of these advantages are not going to make a huge difference for home-simulator enthusiasts with a single PC and display. But for larger more complex applications in, say, industry where having a guaranteed 30fps is critical, there are benefits.[4]
VulkanSceneGraph requires C++17. If we
adopt VSG, and I believe we should, that will impose a second disruption
further down the road. Better to adopt C++17 now to avoid a double hop.[5]