vsg-dev
commented
5 years ago Is VSG just a SceneGraph, or is it a Framework? From the looks of it, it's actually a framework that's structured as a SceneGraph.
It's principally a general purpose scene graph and is not intended to be a high level framework.
The library does include basic viewer+windowing support to make it easier to create basic graphics applications. Support for extensible IO also exists, as does maths and other classes that use of and manipulation of the scene graph.
These extra features are focused on supporting use of the scene graph in wide range of applications rather than support a specific domain like you might see with a game engine.
The background from the VSG is vis-sim, just like the OpenSceneGraph that is it's predecessor (I'm the project lead and principle author the OSG project) so this will colour the design and features encompassed. I am aiming for the VSG to a professional grade scene graph for the modern era. If we achieve this then many of the next generation of professional flight/marine/automotive simulators will use the VSG.
It's my expectation that once the VSG is feature complete enough other developers with create Frameworks ontop the VSG that add domain specific features and slick art path routes that suit particular market domains.
Does VSG handle Vulkan initialization, or does the host application?
The VSG typically will handle all the Vulkan work, though it should be possible to use it alongside applications that do some of the Vulkan work themselves. A significant chunk of the VSG is a scene graph friendly, lightweight C++ wrapper around Vulkan C library.
Vulkan is really verbose to work with, one of the aims for the VSG is to be able to do all the awkward setup and management for users so they can just focus on setting up there scenes and rendering them.
Does Does VSG expose Vulkan objects, or does it hide them?
VSG C++ objects encapsulates Vulkan objects and does the necessary calls for you, but if you really need to get to the underlying Vulkan objects there are directly accessible.
Does VSG only handle SceneGraph related stuff, or does it do the whole framework stuff?
I guess it depends upon what your interpretation of what a scene graph and framework is. Some might see the range of the features already in the VSG and see this as a framework, but compare it to something like Unity and you'd be like, errr where is all my high level editors and off the shelf features?
A slight tangent though, currently @tomhog is working on a Unity exporter to VSG so that we can pull in datasets from Unity. It'll be just a subset of data for now, so just basic things like transforms, meshes, textures. The VSG is so fast that I'm struggling to find models big enough to really challenge it so have been keen to see if we can use Unity to generate big datasets.
Does VSG or the App owns the memory?
The application will use smart pointers and intrusive reference counting for VSG objects, once all external references to VSG objects are removed (it's reference count goes to zero) the object will be deleted and any objects that it has references will be removed - they may in turn be deleted. The VSG encapsulates Vulkan objects so once all the references to them are removed the Vulkan objects will also be removed automatically, and do in correct order to avoid any destruction order issues.
The VSG has a Allocator API that allows you to customize memory allocation and deletion. I've written the API for it, but so far haven't had a chance to test it out as there have been lots of other tasks to get on with. It's something I might touch upon soon though. For most users they won't ever need to use custom Allocators, so consider this an advanced feature that you only deploy if you really have to.
What is outside of the Scope of VSG which the Application is expected to implement?
That all depends upon the type of application you are trying to develop. If you just want to load some models and render them then you'll need little more than the VSG itself - see the vsgviewer example in vsgExamples. If we want physics, AI, networking, UI, scripting, specific high level rendering techniques etc. then you'll need to implement these.
Perhaps this info is located in different places, but I haven't been able to find concise answers to them. A 'Scope' type of document would be ideal.
Have you read all the docs in VulkanSceneGraph/docs? I've tried to write up quite a bit already but different people have different perspectives and questions so I can only answer the questions I think they might have.
As a general note, my expectation is that existing users of the OpenSceneGraph will be often be the early adopters to the VSG, for them they will probably already have an idea of what VSG will provide, and this probably colours what questions I think need answering.
Finally, is the project far enough that developers (thinking of myself) could start playing around with it, or is it in the "mostly broken/ever changing api" state that it's typical for projects at the beginning? I'm interested in starting to develop a toy game engine with it.
Tom and I are funded to work on VSG close to fulltime so it's very much in development with the API evolving as it gets developed. While I have the OSG as prior art to learn from, it's an OpenGL scene graph rather than a Vulkan one, there haven't been Vulkan specific scene graph that we can learn from. This means some areas are real unknowns and liable to more churn in the API and implementation. For instance the bottlenecks you get with the Vulkan are very different from OpenGL so how you manage the scene graph needs to reflect this to get the best out of Vulkan. To know how best to do this requires testing of different approaches and lots of benchmark to make sure that results take you in the right direction.
Finally, is the project far enough that developers (thinking of myself) could start playing around with it, or is it in the "mostly broken/ever changing api" state that it's typical for projects at the beginning? I'm interested in starting to develop a toy game engine with it.
Whether it makes sense for you personally I can't say. There are advantages and disadvantages with being an early adopter. Advantage is that you see the project evolve and potentially contribute to it in ways that benefit your own project. If you the type to isn't intimidated by having to roll your own or put up with an API and implementations changing then it might be appropriate. If you want ready made, high level stable solutions and need lots of documentation to lead your through it then the VSG in it's current alpha state wont be for you.
If you are considering rolling your own Vulkan based game then you might be best just adopting the VSG, even with it's alpha status, it'll likely lead you to get things up and running a lot quicker than learning Vulkan and how best to use it.
gamagan
Hi,
This project is very interesting; I've been following it for some time. One thing I'd like to point out is that the scope of the project, in relation to Vulkan and the host application, is not very clear. By that, I mean:
Basically, for an application such as a game engine, what parts does VSG handle and which parts are the responsibility of the host application?
Perhaps this info is located in different places, but I haven't been able to find concise answers to them. A 'Scope' type of document would be ideal.
Finally, is the project far enough that developers (thinking of myself) could start playing around with it, or is it in the "mostly broken/ever changing api" state that it's typical for projects at the beginning? I'm interested in starting to develop a toy game engine with it.
Regards