vsgXchange usage

[Robert Osfield]

Over the couple of weeks I've done a little bit of work on vsgXchange to add support for osg2vsg and streamlined the usage, and have to illustrate how it's used I've added optional use of vsgXchange to the vsgExamples/vsgviewer application.  This means you can load OSG models directly in vsgviewer just like you can with osgviewer.  I.e.

     vsgviewer lz.osgt

Or any of the 3d file formats that the OSG support like OpenFlight supports so you can do:

     vsgviewer model.flt

The changes required to the source code a minor, as illustrated by the changes for the commit required to add the functionality to vsgviewer.

The steps to use vsgXchange in vsgviewer the steps would be:

1. Build and install VulkanSceneGraph
2. Build and install OpenSceneGraph (required by osg2vsg)
   
3. Build and install glslang (required by osg2vsg + vsgXchange) to compile GLSL shaders into SPRIV shaders usable by Vulkan
   
4. Build and install osg2vsg
   
5. Build and install vsgXchange
6. Build and install vsgExamples
   

If you just do step 1 and step 5 then vsgExamples will build but without OSG support, it'll still work fine.

Longer term OSG support may be added directly to vsgXchange rather than using osg2vsg that predates it.  There are other options for adding 3rd party model/image support to vsgXchange as well, this is something members of the community could tackle if they have the itch :-)

Use of vsgXchange in practice is deliberately kept quite orthogonal to the reading calls, all you need to do is assign the general purpose ReaderWriter to the vsg::Options that you pass into the read calls, and then it'll default to using this ReaderWriter to loaded data.   Code simply looks like:

    #include <vsgXchange/ReaderWriter_all.h>

    ....

    // add use of vsgXchange's support for reading and writing 3rd party file formats
    auto options = vsg::Options::create();
    options->readerWriter = vsgXchange::ReaderWriter_all::create();

    auto model = vsg::read_cast<vsg::Node>("model.flt", options);   

    auto image = vsg::read_cast<vsg::Data>("Images/lz.rgb", options);

If you have any questions or suggestions then fire away :-)

[Robert Osfield]

I occurred to me that as vsgXchange's OSG integation just passes filename onto the OSG's plugin mechanism to load an OSG model before converting it to VSG we can also leverage the OSG's libcurl plugin to load HTTP content.  This means we can pull data directly off the web, even github if you use the https://raw.githubusercontent.com/username/project/master/.... form, so we can directly load data from the OpenSsceneGraph-Data up on github thus:

     vsgviewer https://raw.githubusercontent.com/openscenegraph/OpenSceneGraph-Data/master/dumptruck.osgt

OK, it's nothing fancy, but it's still a cool little capability that we can "borrow" from the OSG without lifting a finger on the VSG side :-)

My intention is for vsgXchange to have it's own libcurl functionality so will be able to do this without relying on the OSG to do the heavy lifting.  Until that's written being able to leverage the OSG to do things the like this rather appeals to my affinity for making software flexible enough to be reused in novel ways that it was never originally envisaged to do.

[Scott Giese]

Thanks Robert.  I was able to compile vsgXchange into vsgviewer and it seems to work well.

I ran into a few blockers during the build process that I wanted to make you aware of:

1) In Vulkan 1.2, VK_RAY_TRACING_SHADER_GROUP_TYPE_MAX_ENUM_NV has been upgraded to a Khronos Group extension (VK_RAY_TRACING_SHADER_GROUP_TYPE_MAX_ENUM_KHR)

2) With static libraries, the dependency chain is vsgviewer -> vsgXchange -> osg2vsg.  I was getting a link error due to osg2vsg being missing

3) Related to #2 above, I added a find_package(osg2vsg) to the CMakeLists.txt

4) SPIRV link order was causing issues with gcc-9.  I altered the link order to link SPIRV-Tools-opt.a prior to SPIRV-Tools.a

I've attached some patch files for your review.  Feel free to make adjustments to your liking.

The one issue I've had is it failed to load a LAS point cloud model.  It may be that my OSG build did not include the LAS plugin.  I hoping to get that working as a learning activity to start diving into what VSG can do.

Scott

[Robert Osfield]

Hi Scott,

On Wednesday, 18 March 2020 23:54:12 UTC, Scott Giese wrote:

Thanks Robert.  I was able to compile vsgXchange into vsgviewer and it seems to work well.

Good to hear, thanks for diving in with testing - this is how shake everything down quicker.

 

I ran into a few blockers during the build process that I wanted to make you aware of:

1) In Vulkan 1.2, VK_RAY_TRACING_SHADER_GROUP_TYPE_MAX_ENUM_NV has been upgraded to a Khronos Group extension (VK_RAY_TRACING_SHADER_GROUP_TYPE_MAX_ENUM_KHR)

Where did you source the header from?  I'm using the LunaG's Vulkan_SDK version 1.2.131.1

Khronos have now released the provision version of ray tracing that is based on the NV extensions, my plan is to port the VSG across to this in the next few weeks.

 

2) With static libraries, the dependency chain is vsgviewer -> vsgXchange -> osg2vsg.  I was getting a link error due to osg2vsg being missing

Do you use vsgXchange master or the vsgExamples osg2vsg branch?

Yesterday I merged the vsgExamples osg2vsg branch into master, this adds the ability to insert the osg2vsg depenencies into the vsgExamples cmake configuration file that gets installed along with vsgXchange so that other applications can use cmake to find vsgXchange and all of it's dependencies.

 

3) Related to #2 above, I added a find_package(osg2vsg) to the CMakeLists.txt

This may no be required now.

 

4) SPIRV link order was causing issues with gcc-9.  I altered the link order to link SPIRV-Tools-opt.a prior to SPIRV-Tools.a

I've attached some patch files for your review.  Feel free to make adjustments to your liking.

FYI, i'm using 7.5.0.  Looks like I might need to update it so I can reproduce problems.

What OS and gcc version are you using?

Could you post the commits against your repo, this will allow me to review them online.

 

The one issue I've had is it failed to load a LAS point cloud model.  It may be that my OSG build did not include the LAS plugin.  I hoping to get that working as a learning activity to start diving into what VSG can do.

Have a look in the osgPlugins-vesion directory for an osgdb_las.so, if it's there it should be loadable.  If you you can load the model in osgviewer then it there is reasonable chance it'll load via vsgXchange. The osg2vsg library doesn't support all OSG Node types though, it only maps the most common subsets of OSG scene graphs.  If there are certain scenes that aren't yet loadable then we can look at what the issues are and see about how these might be addressed.

Longer term vsgXchange will have it's own local implementations for plugins, or leverage other file load libs to enable loaded of data not support by the vsgXchange/osg2vsg/OSG.

Cheers,

Robert.

 

[Scott]

Where did you source the header from?

    https://github.com/KhronosGroup/Vulkan-Headers.git
    Header Version: 1.2.135

Do you use vsgXchange master or the vsgExamples osg2vsg branch?

    vsgXchange master

What OS and gcc version are you using?

    Linux Mint 19.3
    gcc version 9.2.1

Update on loading a LAS file...
    Indeed I had not built the LAS plugin for OSG.  After doing so, osgviewer displayed some LAS files, but not others.
    Seems OSG has a dependency on the legacy laslib, so it does not support the newer formats.
    vsgviewer did not load the files, but I wasn't able to research the cause yet.

Scott

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/c0cd76b0-3a9d-4bc6-9768-7ccab82282d5%40googlegroups.com.

[Robert Osfield]

On Thu, 19 Mar 2020 at 15:38, Scott <sct...@gmail.com> wrote:

Where did you source the header from?

    https://github.com/KhronosGroup/Vulkan-Headers.git
    Header Version: 1.2.135

Right on the bleeding edge then :-)

I've just checked the LunarG VulkanSDK and it's on 1.2.131.2.  I'm currently on 1.2.131.1.

This raises the issue of what range of headers we should be aiming to support.  

Do you get a build error with your headers?

Do you use vsgXchange master or the vsgExamples osg2vsg branch?

    vsgXchange master

Could you update VSG, osg2vsg, vsgXchange  and vsgExamples master and see where we are now w.r.t build.

What OS and gcc version are you using?

    Linux Mint 19.3
    gcc version 9.2.1

Update on loading a LAS file...
    Indeed I had not built the LAS plugin for OSG.  After doing so, osgviewer displayed some LAS files, but not others.
    Seems OSG has a dependency on the legacy laslib, so it does not support the newer formats.
    vsgviewer did not load the files, but I wasn't able to research the cause yet.

I'm not the author of the OSG's LAS plugin so can't comment on specifics until I have a look at the data and the OSG's plugin and it's dependency.  Another factor is the conversion from the created OSG scene graph to VSG.

Could you provide a link to some test data that works and some that doesn't?

[Scott]

Right on the bleeding edge then :-)

    That is where the excitement is... you just need to get accustom to hitting walls now and again ;)
    And if I was risk adverse then we wouldn't be chatting right now, given that vsg is pre-release.

Could you update VSG...

    On the road for a few days.  Wouldn't have an opportunity until this weekend.

Don't want to distract you with the LAS issue, and it make a good learning exercise for me.
Just need some guidance... given the current state of the osg plugin, should I focus on updating it or do something new within vsg?  What is your preference?

On 3/19/20 11:15 AM, Robert Osfield wrote:

Could you update VSG, osg2vsg, vsgXchange  and vsgExamples master and see where we are now w.r.t build.

[Robert Osfield]

Right on the bleeding edge then :-)

    That is where the excitement is... you just need to get accustom to hitting walls now and again ;)
    And if I was risk adverse then we wouldn't be chatting right now, given that vsg is pre-release.

Good to hear, especially as I'm just about break the build with a bug/design fix the DescriptorSet API :-)

I'll write a separate post for these changes.

Could you update VSG...

    On the road for a few days.  Wouldn't have an opportunity until this weekend.

No problem.

Don't want to distract you with the LAS issue, and it make a good learning exercise for me.
Just need some guidance... given the current state of the osg plugin, should I focus on updating it or do something new within vsg?  What is your preference?

You probably know more about the current state of the OSG's LAS plugin than I do now as I was under the impression it was still working just fine!

If the liblas lib that the current OSG LAS plugin needs updating, or replacing I have no idea of.  I don't have have LAS data to test with without chasing some down on the web, so happy to defer to others who do to what possible paths forward for the OSG's LAS plugin is.

The other alternative is to just write a LAS reading for vsgXchange :-)

[Voerman, L.]

Hi Scott,

I thought I should chip in with some info about the las plugin. I recently added a bugfix, but the nature of the bug suggests that the plugin is not used a lot.

The current osg plugin depends on liblas and the deprecated laszip library for .laz support, and needs an older version (laszip 2.1.0 or 2.2.0) because of interface changes in later versions before development was stopped.

I read that this combo (liblas - laszip) doesn't support more recent versions of the las file format, but did not find any examples of these newer files, all files I wanted to use did still work.

Anyway, I guess building on an old version of a deprecated library is not the way forward, apparently liblas is replaced by something called pdal, but I did not look into that any further. I think the nice solution would be to replace the current osg las plugin with a new version based on this pdal library.

Laurens.

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/7731c98b-0ef8-91fb-43af-69d35d803904%40gmail.com.

[Robert Osfield]

On Friday, 20 March 2020 11:10:33 UTC, Voerman, L. wrote:

Hi Scott,

I thought I should chip in with some info about the las plugin. I recently added a bugfix, but the nature of the bug suggests that the plugin is not used a lot.

The current osg plugin depends on liblas and the deprecated laszip library for .laz support, and needs an older version (laszip 2.1.0 or 2.2.0) because of interface changes in later versions before development was stopped.

I read that this combo (liblas - laszip) doesn't support more recent versions of the las file format, but did not find any examples of these newer files, all files I wanted to use did still work.

Anyway, I guess building on an old version of a deprecated library is not the way forward, apparently liblas is replaced by something called pdal, but I did not look into that any further. I think the nice solution would be to replace the current osg las plugin with a new version based on this pdal library.

Laurens.

Sounds reasonable to me.  I can test and merge any improvements to the OSG's LAS plugin, just generate a PR for any changes.  Having old and new .las data would be important for getting things working well.

[Scott]

Thanks Laurens and Robert.  I've started working on a upgraded OSG LAS plugin.

Some background information:

libLAS is deprecated, but LASzip is still maintained.
PDAL just delegates the LAS file handling to library LASlib, which is part of the LAStools package.

Approach:

Within CMake, look for LASlib.  If found, compile the OSG LAS plugin with LASlib.  This version would support LAS version 1.0 - 1.4.
    Initial release will only support the same features as the current plugin... i.e. colored points + existing plugin options.
    The verbose option output is likely to change a bit
    I may add a new option to control the point size
If LASlib is not found, look for the older libLAS.  If found, compile the OSG LAS plugin with libLAS.  This version would support LAS version 1.0 - 1.3.
    If the older libLAS is used, display a deprecated message to encourage user to upgrade to LASlib.
    Remove libLAS during a future OSG release.

Scott

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/b53878ee-9a54-4909-af1f-874d5151edb5%40googlegroups.com.

[Scott Giese]

Hi Robert,

Be aware that the latest osgXchange has an issue in the install configuration.

install(FILES "vsgXchangeConfig.cmake" "${CMAKE_BINARY_DIR}/src/vsgXchangeConfigVersion.cmake"
    DESTINATION lib/cmake/vsgXchange
)

vsgXchangeConfig.cmake is generated into the CMAKE_BINARY_DIR, but the above install command is expecting it to exist in the source tree.

Scott

[Robert Osfield]

Hi Scott,

I hadn't done an out of source build so didn't spot this regression that occurred when I adding autogeneration of the vsgXchangeConfig.cmake.

I have fixed this so it now works with in source and out of source builds.  Please update to vsgXchange master.

 

[Donn Mielcarek]

I was able to get vxgXchange/osg2vsg/osg-plugins to compile and working for simple models, but I can't get it to work with our .txp database.  I see the plugin getting loaded but nothing shows up.  I'll continue looking into it, but if anyone has any insight, please pass it along.

[Robert Osfield]

Hi Donn,

On Monday, 30 March 2020 15:02:45 UTC+1, Donn Mielcarek wrote:

I was able to get vxgXchange/osg2vsg/osg-plugins to compile and working for simple models, but I can't get it to work with our .txp database.  I see the plugin getting loaded but nothing shows up.  I'll continue looking into it, but if anyone has any insight, please pass it along.

Txp support for need to be do in a dedicated way as the OSG's txp plugin leverages paging and custom nodes to function, you won't be able to simply convert an OSG subgraph across to a VSG subgraph in the way that osg2vsg supports.

FYI, the osg2vsg project does have Paged Database support for osg::PagedLOD databases like the ones generated using VirtualPlanetBuilder.  There is a pdconv (paged database conv) utility that converts .osgb tiles to .vsgb equivalents.  The VSG has it's own vsg::DatabasePager/vsg::PagedLOD so will be capable loader term to handle the likes of TXP databases.

How important is TXP database to your project?  If critical then we'd need to discuss the practical steps required to add support to vsgXchange.

[Donn Mielcarek]

We have multiple rather large txp databases, populated with buildings and trees and water etc.  I would rather be using VirtualPlanetBuilder, but I don't have the manpower to convert or generate new databases, so yeah, it's kinda critical for me.

[Robert Osfield]

On Mon, 30 Mar 2020 at 18:06, Donn Mielcarek <donn.mi...@gmail.com> wrote:

We have multiple rather large txp databases, populated with buildings and trees and water etc.  I would rather be using VirtualPlanetBuilder, but I don't have the manpower to convert or generate new databases, so yeah, it's kinda critical for me.

I just had a look at the OSG's txp plugin and it's 27437 lines of code, most of this will be TXP code, while a portion will be OSG specific.  A search for osg:: etc. instances would give a an ideal of how code this would be.  The original code from Terrex that the OSG's plugin is based on is not great, we had to fix lots of cross platform issues and bugs along the way so the OSG's TXP codebase is probably a best base to work from.

I'd guess it'd take a couple weeks to convert over to work with VSG, might take up to 4 weeks though as it adds a few oddities like adaptive LOD that avoid inter-tile cracks forming.