osg2vsg, vsgXchange and OpenSceneGraph/VulkaSceneGraph integration.

[Robert Osfield]

Hi All,

As part of the VulkanSceneGraph-1.0 release I will tag the 1.0 release of vsgXchange, so will need to resolve all the outstanding Issues with vsgXchange.   There are currently 4 Issues on the vsgXchange github Issue tracker all of which relate the the vsgXchange::OSG loader, so all these need resolve in some form before VSG-1.0.

The Issues themselves all need addressing and I'll tackle them soon, but how best to about it is something I haven't settled upon yet.  There are wider issues at play that affect how best to go about resolve them, which is why I started this thread.

The big question I am pondering right now is whether vsgXchange should have vsgXchange::OSG at all, and if not then should it be provided by a dedicated library like the original osg2vsg or integrated into future versions of the OpenSceneGraph.

With formats like .jpg, .obj, .gltf etc. we just need to read or write the 3rd party formats, and there is little need to worry about the implementation details, these can be encapsulated very naturally within a standard ReaderWriter interface as is done in vsgXchange.

GDAL support is a little different as GDAL itself can be useful for image processing, so being able to use GDAL and get the image/DEM data from it in VSG compatible form is helpful.  I did originally have vsgGIS provide this, but in the end decided that the integration was so lightweight that I could put the GDAL integration code directly into the vsgXchange.  I'm happy with how this integration turned out as there is little additional bloat or awkwardness.

For existing OSG application developers the needs may be as simple as converting data from OSG to VSG and then loading them into a pure VSG application that need not know anything further about the OSG.  This type of usage is attempted by the current vsgXchange::OSG loader, but as we have 4 issues reported about it clearly it needs some more work :-)

There are also OSG application developers that will want to keep OSG parts of their application and add VSG usage for performance of functionality reasons.  This class of OSG/VSG user will likely want ways of moving data from OSG to VSG, and from VSG to OSG.  There may well also want to move GPU resources from OpenGL to Vulkan, and Vulkan to OpenGL.

For this class of user the current vsgXchange::OSG user is very poorly served.  This type of integration is also far more extensive than just writing minimal wrappers like has been possible with vsgXchange::GDAL, we'd need OSG and VSG nodes that have be used in OSG or VSG scene graphs, and means of converting/adapting data. 

Re-instating osg2vsg or a similar library would natural way to provide this deeper OSG/VSG integration.

Another route might be for a future OSG version to have VSG support as a library that sits alongside osgUtil etc.  One might even envisage the OSG adopting parts of the VSG directly to replace existing functionality in the OSG, as the VSG counterparts are just more modern, cleaner, perform better and are more flexible.

VSG integration into future versions of the OSG is kinda out there, and is not something that will happen in the VSG-1.0 time frame, but thinking about these possibilities can help us frame what needs to be done right now to vsgXchange so that it's 1.0 is a natural stepping stone to future work.

My current feeling is that a osg2vsg like library is probably the best interim step, and one that should be done prior to VSG/vsgXchange-1.0.

I don't think having a vsgXchange::OSG that is independent from a osg2vsg library so we either drop vsgXchange::OSG from vsgXchange completely or have vsgXchange check for osg2vsg's OSG ReaderWriter and assigns that to vsgXchange::all so it would behave similar to current functionality.

This is how vsgXchange::OSG was originally integrated - prior to me merging osg2vsg into vsgXchange, so the changes I'm currently thinking of we be kinda a re-wind.  The vsgXhange::OSG has developed a long way since the original osg2vsg so it'd be a case of porting all the functionality back.

Last week I had bash at doing this backport but it ended up giving up after two attempts.

It may be just better to start from scratch.  The VSG can come a very long way since the early days when osg2vsg was written, we now have vsg::ShaderSet, lighting etc.

Thoughts?

Robert.

[Robert Osfield]

As an experiment I've had scrubbed all the OSG->VSG code form vsgXchange, and all the OSG->VSG conversion code from the old osg2vsg library, replacing the code with placeholders for future work.

With the vsgXchange library I have created a use_osg2vsg branch that uses the osg2vsg library to provided it's osg2vsg::OSG implementation to read using OSG and automatically converts to VSG just like the previous vsgXchange::OSG implementation (that is still in vsgXchnage master), the branch is:

    https://github.com/vsg-dev/vsgXchange/tree/use_osg2vsg

The osg2vsg library now has a refactor branch which removes all the original OSG->VSG code and has a osg2vsg::OSG loader that is simply a placeholder.

    https://github.com/robertosfield/osg2vsg/tree/refactor

What I'll do is start fleshing out some basic code for mapping between OSG nodes and VSG nodes and images, then bit by bit fill it out so we have a functional loader.  If you have OSG models that you'd like to make sure can be loaded, then I am happy to use them as reference, and where required sign NDAs.

Really thorough OSG <-> VSG integration is potentially quite a bit of work, and is beyond what I can really do self funding it, so it would be helpful if companies using the OSG and wanting VSG integration support to help fund this work.

Cheers,

Robert.

[andreykod]

Hi Robert,

When I opened issue #91, then it was supposed to use VirtualPlanetBuilder to create databases. Now I am developing a simple application for creating VSG databases using prepared data.

https://github.com/asafran/DatabaseCreator

GDAL Retile is used for preprocessing. It was impossible to work with VirtualPlanetBuilder on Ubuntu 20.04 due to incompatibility with the GDAL version. I don't think I will use VPB in the future.

P.s. the source data was unfortunately lost, I don't think I can help with VPB in any way, because it works for me only through Docker (Ubuntu 18.04).

понедельник, 11 июля 2022 г. в 15:18:10 UTC+3, robert....@gmail.com:

[Robert Osfield]

Hi Andrey.

On Fri, 15 Jul 2022 at 19:55, andreykod <as...@yandex.ru> wrote:

When I opened issue #91, then it was supposed to use VirtualPlanetBuilder to create databases. Now I am developing a simple application for creating VSG databases using prepared data.

https://github.com/asafran/DatabaseCreator

GDAL Retile is used for preprocessing. It was impossible to work with VirtualPlanetBuilder on Ubuntu 20.04 due to incompatibility with the GDAL version. I don't think I will use VPB in the future.

P.s. the source data was unfortunately lost, I don't think I can help with VPB in any way, because it works for me only through Docker (Ubuntu 18.04).

Interesting tool. 

I have been wondering about a rewrite of VirtualPlanetBuilder that uses the VSG+GDAL combo to build a tiled + lod'd set of images/DEMS that can be read in rendering systems agnostic way like the online ReadyTile/OpenStreetMap etc. databases.

GDAL would be used for reading/writing image+DEM data rather than image processing. I think that reprojection and downsampling could be handled by Vulkan more efficiently than using GDAL to do it on the CPU.  Writing data using ktx might also offer some interesting opportunities for compression the data in a form that's efficient to read and download to the GPU.

I'm not familiar with GDAL Retle could do some of this albeit with the Vulkan/GPU leverage - can you read a set of input images and DEMS and generate a hierarchy on disk that could be read using the VSG's vsg::Tile ReaderWriter?

An example of this the vsg::tile ReaderWriter action is:

    vsgviewer models/openstreetmap.vsgt

Writing a similar ReaderWriter for the OSG shouldn't be hard, and potentially even parsing the same .vsgt would be possible using a future rev of osg2vsg.

The openstreetmap.vsgt file is a small ascii file that sets up where to load the database and how it's arranged, it looks like:

#vsga 0.4.3
Root id=1 vsg::TileDatabase
{
  userObjects 1
  key "EllipsoidModel"
  object id=2 vsg::EllipsoidModel
  {
    userObjects 0
    radiusEquator 6.37814e+06
    radiusPolar 6.35675e+06
  }
  settings id=3 vsg::TileDatabaseSettings
  {
    extents -180 -90 0 180 90 1
    noX 1
    noY 1
    maxLevel 19
    originTopLeft 1
    lodTransitionScreenHeightRatio 0.25
    projection "EPSG:3857"
    ellipsoidModel id=2
    imageLayer "https://a.tile.openstreetmap.org/{z}/{x}/{y}.png"
    terrainLayer ""
    mipmapLevelsHint 16
  }
}

This is very early days for this functionality, so treat it as proof of concept of where we could take things. My preference is towards being agnostic about the renderer with the database generation. Cheers, Robert.

[Robert Osfield]

Hi All,

I have completed my changes to vsgXchange, osg2vsg and vsgExamles and checked them in the respective masters, and have move osg2vsg back into vsg-dev github account.

    https://github.com/vsg-dev/osg2vsg

These changes mean that to include OpenSceneGraph support into vsgXchange you now need to build and install OSG and VSG, then build and install osg2vsg, then build and install vsgXchange and finally vsgExamples if you need it.

My goal with these changes is to open the door to applications using osg2vsg directly within their existing OpenSceneGraph application that they wish to add VulkanSceneGraph capabilities.  I haven't yet put method to convert data between OSG and VSG, or between OpenGL and Vulkan but that's my plan.  For now osg2vsg just has a osg2vsg::OSG ReaderWriter to reads data using the OSG's readNodeFile/readImageFile() and converts to VSG then returns this to the VSG application - essentially just the same functionality as you will have been used with the previous vsgXchange::OSG implementation.

I have moved the vsgwithosg example from vsgExamples gl_integration branch directly into osg2vsg/applications, with the intention of this example being refactored so more of it's GL<->Vulkan functionality is available via the osg2vsg library.

I have also moved the Issues relating to OSG->VSG model conversion from vsgXchange/Issue to osg2vsg/Issue:

    https://github.com/vsg-dev/osg2vsg/issues

The elevation of osg2vsg back into part of the vsg-dev family is reflection on my expectation of a greater role that OpenSceneGraph/VulkanSceneGraph integration will play in a continual integration within user applications rather than just a one off conversion of OSG files in order to port to a pure VSG application.

For members of the OSG/VSG communities that will need to integration functionality I would greatly appreciate community help in improving osg2vsg - so if there are features you'd like to see then let us know, even better if you can pitch in help make this happen :-)

Cheers,

Robert.

[Robert Osfield]

I have add a include/osg2vsg/convert.h header with various convert() functions to help map OSG data to VSG equivalents:

  https://github.com/vsg-dev/osg2vsg/pull/64/files

I am not attempting to cover the whole of the OSG, but give a few basic functions that the OSG community can get started with and add to as they require other classes to be mapped across.

[Hamid]

Hi Robert,

Thanks for the useful  osg2vsg plugin.

Have you tested a model that includes textures?

There seems to be a problem reading the images.

When I want to convert skydome.osgt with vsgwithosg I got this error:

       InputStream::readImage(): file not handled, filename: Images/skymap.jpg

Regards,

Hamid

[Robert Osfield]

On Monday, 1 August 2022 at 11:27:35 UTC+1 hamidas...@gmail.com wrote:

Hi Robert,

Thanks for the useful  osg2vsg plugin.

To clarify:

   osg2vsg It's a project that contains the libosg2vsg library, a VSG writer plugin for the OSG and examples.

 

Have you tested a model that includes textures?

There seems to be a problem reading the images.

When I want to convert skydome.osgt with vsgwithosg I got this error:

       InputStream::readImage(): file not handled, filename: Images/skymap.jpg

When doing the refactor of vsgXchange and osg2vsg to use osg2vsg I have been testing against various OSG loaded models that contain textures.  I just tried:

   vsgviewer skydome.osgt

and

   vsgwthosg skydome.osgt

And both work fine. InputStream is an osgDB class so it would seem like that's where the error is coming from in your case.

What OSG version are you using?  Could you update VSG, vsgXchange and osg2vsg to make sure you have the latest of all these.

Cheers,

Robert.

[Hamid]

Thanks Robert for your quick response.

I'm using OSG 3.7.0. I also updated all  VSG, vsgXchange and osg2vsg.

If you haven't had any problem, I have to check the steps again.

Regards,

Hamid

[Robert Osfield]

On Mon, 1 Aug 2022 at 12:03, Hamid <hamidas...@gmail.com> wrote:

I'm using OSG 3.7.0.

I presume you are using OSG master then.  I have been using the OSG-3.6 branch in recent testing, I'll build OSG master and see if it works fine.

 

I also updated all  VSG, vsgXchange and osg2vsg.

If you haven't had any problem, I have to check the steps again.

Did you have any problems with vsgXchange::OSG prior to my refactoring to use osg2vsg once more?

What OS are you using?

[Hamid]

Yes, I got OSG master branch.

I had same problem and result with vsgXchange::OSG

I'm using a 64bit Windows and visul studio 2019.