A new project for VSG extensions and possiblities

[xarray]

I've just created a new repo at:
https://github.com/xarray/vsgRecipes

I also upload a GLTF reader which depends on TinyGltf instead of assimp. That's becuase TinyGltf (https://github.com/syoyo/tinygltf) is much easier to be integrated with vsgRecipes, and later with vsgXchange. At present it is tested to be worked with simple and complex .gltf/.glb models. Animation and joint/skinning supports will be added later.

I'm considering adding more useful extensions to the great VSG project, like lightweight fbx support and so on.

[xarray]

Some snapshots. :)

[robertosfield]

Welcome to planet Vulkan :-)

Looks like you've made some good progress already on the GLTF front. A native GLTF loader would be a great addition to the VSG as it should make it make straight forward to map GTLF scene structure across the VSG.

With tinygltf is it possible to take ownership of the memory used for storing arrays, uniforms and textures? The vsg::Data allows you to use another vsg::Data object as storage so my thought is if the data is loaded into memory blocks we could wrap these with a vsg::ubyteArray and then have the vsg::Data associated with arrays just uses these shared vsg::Data.

Potentially one could also map the shared vsg::Data to a vsg::Buffer and then set up the vsg::BufferInfo assigned to the vsg::VertexIndexDraw etc.

With a more native GLTF support is should be easier to map the animation support in GLTF to the VSG, as Assimp has it's particular ways of doing things that you have to workaround.

On the FBX front and OSG support front how do you plan on tackling these?

[xarray]

I took assimp/SceneConverter as reference so arrays and textures are copied and stored in vsg::ubyteArray/vsg::vec3Array, and also managed by a SharedObject. I will check later to see if the sharing mechanism works.

As I've already done in osgverse, I would like to choose OpenFBX (https://github.com/nem0/OpenFBX) to help parse FBX files. It contains only one cpp file and is with friendly license.

For the osgb support, I'm considering to strip serialization-related code and rewrite the macros (original in osgDB/Serializer), to redirect setter/getter functions to a specified dispatcher. The osg wrappers could be re-generate without original headers to help the deserializing work. For example, the following wrapper code:

REGISTER_OBJECT_WRAPPER( Node,
new osg::Node,
osg::Node,
"osg::Object osg::Node" )
{
ADD_OBJECT_SERIALIZER( ComputeBoundingSphereCallback,
osg::Node::ComputeBoundingSphereCallback, NULL );
ADD_OBJECT_SERIALIZER( UpdateCallback, osg::Callback, NULL );
ADD_OBJECT_SERIALIZER( EventCallback, osg::Callback, NULL );
ADD_OBJECT_SERIALIZER( CullCallback, osg::Callback, NULL );
ADD_BOOL_SERIALIZER( CullingActive, true );
ADD_HEXINT_SERIALIZER( NodeMask, 0xffffffff );
ADD_OBJECT_SERIALIZER( StateSet, osg::StateSet, NULL );
}

will be translated as:

dispatcher->start("osg::Node", "osg::Object osg::Node");
dispatcher->add_object("ComputeBoundingSphereCallback", "osg::Node::ComputeBoundingSphereCallback");
...
dispatcher->add_bool("CullingActive");
dispatcher->add_int("NodeMask");
dispatcher->add_object("StateSet", "osg::StateSet");
dispatcher->end();

And the Vulkan plugin may use the dispatcher to decide what to serialize and convert, and what to discard. Of course there are still many UserSerializers to be manually rewritten, but most of the work are wished to be done automatically.

[robertosfield]

One approach that might be possible to loading .vsgt/,.vsgb files would be to load the OSG serializers and then use this to generate an OSG agnostic version of these serializers then use these to direct how to read data. This could possibly be put in osg2vsg as a utility that is run when needed to update the serializers.

Alternatively perhaps use the OSG serializers could be to automatically generate your dispatcher code, then have just compile the dispatcher code.

These two approach would avoid the need for trying to replicate the format specs manually in code.