Can not load OSG model by version 1.1.3

[x1244]

When I use vsgconv by vsgXchange version 1.1.3 against vsg version 1.1.8, can not convert a osg model to vsg model. Like vsgconv axes.osgt axes.vsgt, there has nothing output file. There was no error occured.

But When I use vsgconv by vsgXchange version 1.1.2 against vsg version 1.1.4, I got the vsg model. vsgconv.bk axes.osgt axes.vsgt, there has the axes.vsgt model.

Where vsgconv --features has the OSG Features.

features.txt

vsgXchange version 1.1.3

> vsgconv --version
VulkanSceneGraph version = 1.1.8, so = 14
vsgXchange version = 1.1.3, so = 1
vsgXchange built as static library
> vsgconv axes.osgt axes.vsgt
> ls axes.vsgt
Get-ChildItem: Cannot find path 'C:\Users\x1244\Documents\axes.vsgt' because it does not exist.

vsgXchange version 1.1.2

> vsgconv.bk --version
VulkanSceneGraph version = 1.1.4, so = 14
vsgXchange version = 1.1.2, so = 1
vsgXchange built as static library
> vsgconv.bk axes.osgt axes.vsgt
> ls axes.vsgt

    Directory: C:\Users\x1244\Documents

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2024/8/15    12:58         104855 axes.vsgt

Using vsgviewer build against vsgXchange version 1.1.3 load osg model get an error

> vsgviewer axes.osgt
error: execv(D:\laboratory\vsg\vsgviewer\build\windows\x64\release\vsgviewer.exe axes.osgt) failed(-1073741819)

Do you think the problem is with vsg 1.1.8 or vsgXchange 1.1.3 or osg2vsg ?

[robertosfield]

The console error you list isn't an error that the VSG/vsgXchange will have emitted, my guess this is the OS reporting an issue with attempting to run the application.

What happens when you try to load a standard VSG model such as the ones in vsgExamples/data?

vsgviewer models/lz.vsgt

[x1244]

Yes, it's the OS report exception, in vsgviewer.cpp with viewer->compile(); abort. I can load lz.vsgt and get desired viewer. Also can load axes.vsgt convert by vsgconv against vsgXchange by version 1.1.2. Just can't load OSG model like axex.osgt in vsgviewer against vsgXchange by version 1.1.3. And can't convert OSG model to vsg model by vsgconv against vsgXchange by version 1.1.3.

[robertosfield]

What happens if you use vsgconv to convert the .osgt to .vsgt and then load in vsgviewer?

[x1244]

When use vsgconv version 1.1.3 to convert .osgt to .vsgt, the output file was not exist.

> ls axes.vsgt
Get-ChildItem: Cannot find path 'C:\Users\x1244\Documents\axes.vsgt' because it does not exist.

[x1244]

The vsgconv version 1.1.2 can convert .osgt to .vsgt, and the .vsgt model load are normal.

[robertosfield]

That would suggest vsgconv isn't successfully loading and converting the OSG file, in this situation I'd expect vsgviewer to exit gracefully not attempt to rendering the scene.

I will build the latest VSG/vsgXchange/vsgExamples to see if I come across any problems. I'm working under Kubuntu 22.04 though so it won't be a direct recreation.

Very little has changed with osg2vsg over recent VSG versions so at this point my best guess is that is a build issue with various versions of the OSG/VSG/osg2vsg/vsgXchange on your system, possibly compiling against one version but at runtime linking to another. If this is the case make sure you just have one version of OSG/VSG etc. on your paths.

[x1244]

Yes, I just have one OSG/VSG/osg2vsg/vsgXchange version in my dev path, and can be sure that my link library is correct. I compiled it with the latest vsg/osg2vsg/vsgXchange code.

When all environment variables and runtimes are unchanged, vsgconv 1.1.2 will correctly convert OSG models to VSG models, while vsgconv 1.1.3 will not.

[robertosfield]

I have just tried a VSG branch that is very close to VSG-1.1.7 release with vsgXchange master which is very close to 1.1.3 release and osg2vsg master which is close to 0.2.0, and vsgviewer axis.osgt works fine for me.

I don't think there is underlying problem to do with the VSG/osg2vsg/vsgXchange rather it looks more likely there is an build issue/runtime on your system. The best I can suggest is doing a clean build of VSG, then osg2vsg, then vsgXchange then vsgExamples making sure that no other VSG libraries or headers are on your path.

[x1244]

I will try to rebuild VSG osg2vsg and vsgXchange. Thanks a lot.

[x1244]

I have rebuilded vsg commit 27ae0a46b9c102b07c7a9cc504f72d409bd975dc osg2vsg commit d14c4d5f26dd4c1ddcbf8cd6b62cfc54d17fe0cb vsgXchange commit cf3e506c28bb2bcd39fec10203c734fc3bd7c8a5 vsgExample/vsgviewer But can not load the axes.osgt model. I will try it again.

[robertosfield]

If there is a bug I am not able to reproduce it so not in a position to investigate it. Compiling the VSG, osg2vsg and vsgXchange in debug then running to see if you can pinpoint what might be going on.

[x1244]

I compiled VSG1.1.4 and 1.1.5, the main difference between the two versions is whether or not to use external glslang. After compiling VSG, the latest versions of osg2vsg and vsgXchange were compiled. The result is that VSG 1.1.4 vsgconv converts OSG models to VSG models, while VSG 1.1.5 vsgconv does not. Is it because glslang's dependencies are converted from in source to external? I noticed that when VSG 1.1.4 was compiled, the relevant files under VulkanSceneGraph/src/glslang were added to the source file and compiled together. When VSG 1.1.5 was compiled, the glslang package was found and added the relevant library link to the cmake, but I didn't find the relevant configuration in the link parameters. How do I set up and compile dependencies between vsg and glslang? I'm not very familiar with cmake. Also, can you show me your 'vsgconv --version' result?

[x1244]

This is the cmake result of VSG 1.1.5

>cmake -G "Visual Studio 17 2022" -DENABLE_OPT=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/dev/vs2022 ..
-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.19045.
-- Reading 'vsg_...' macros from D:/pkg/Vulkan/VulkanSceneGraph/cmake/vsgMacros.cmake - look there for documentation
--  GLSL package:
-- glsl config: find_package(glslang 14 CONFIG REQUIRED)
-- The following OPTIONAL packages have been found:

 * glslang (required version >= 14)

-- The following REQUIRED packages have been found:

 * Vulkan (required version >= 1.1.70.0)
 * Threads

-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: D:/pkg/Vulkan/VulkanSceneGraph/build.glsl

[x1244]

The impact of vsgXchange is now largely ruled out. I use osg2vsg/applications/vsgwithosg in VSG1.1.4 to load axes.osgt models fine, but VSG1.1.5 not to load axes.osgt models.

[robertosfield]

glslang was previously built as part of the VSG itself, but this was causing problems for some sets of users as required internet access in order to clone the glslang repo. There is a discussion of this change in this VSG thread.

It may be that you aren't successfully building against glslang with recent versions of VSG. Do you have glslang installed? Is is a static or shared library build? If the later is the dll on your library path? What version of gslang? Do you build it yourself or from vcpkg?

[Mikalai]

@x1244 As you are on windows, can it be the case that you've confronted similar issue with glslang header files, when libraries were taken (in my case from vcpkg in your case maybe from some your location) and header files were taken from vulkan sdk? https://github.com/vsg-dev/VulkanSceneGraph/discussions/1199#discussioncomment-9852080

[x1244]

I built glslang myself from the srouce, built it as a shard library(windows dll), and installed it in my working directory dev/vs2022. The glslang version is 14.3.0 2024-06-25, which is consistent with version > 14 found by VSG. I also feel like this might be a link issue with the glslang library, which may conflict with the glslang with Vulkan , and am also trying to find a solution.

Do you think it's a problem with VSG linking to glslang, or is it a problem with osg2vsg linking glslang? I can see models like lz.vsgt with VSG compiled with external link glslang, so I think it might be an issue with osg2vsg there. What do you think?

[Mikalai]

@x1244 To be sure there were no interference with vulkan sdk, I've renamed glslang folder in vulkan sdk like C:\VulkanSDK\1.3.250.1\Include\glslang.old. You can try the same to be sure that all glslang files are taken from one location.

[robertosfield]

What does cmake report for the settings it's using for glslang when building the VSG?

There are tools under Windows for checking the dependencies of applications and libraries, but as I'm on occasional use Windows I can say what they are off the top of my head. These might be worth trying.

When I have used Windows recently I've used the glslang provided by vcpkg and this works fine with the VSG. Others have compiled gslang from source under Windows and got things to work, so there must be something different in how you are setting things up. What this might be I can't say which is why I suggest checking what headers and libs being used are during compile of VSG etc and when running the applications.

[x1244]

Yes, this is due to the conflict of the external glslang with the glslang of the Vulkan belt. The way I took was to rename the Vulan glslang include folder and library file names to avoid using Vulkan glslang. This way, after recompiling VSG osg2vsg vsgXchange, you can convert the OSG model to the VSG model. It is also possible to load OSG models directly in vsgviewer. Thank you for your help.