vsgconv cannot read 3d files (obj, gltf,..) on Windows

Question

vsgconv cannot read 3d files (obj, gltf,..) on Windows

rainergericke opened this issue 2 years ago · 19 comments

While writing to cpp files is possible again, this error remains on Windows.

vsgconv Helmet.glb Helmet.vsgb

does nothing, no file is generated. The example is from gltf repository.

Answer 1 · 2023-02-01T18:53:53.000Z

Is vsgXchange compiled successfully against Assimp? You can look at the include.vsgXchange/Version.h to see what #define are enabled, there should be a vsgXchange_assimp defined if you have it built.

You can also run vsgconv --features to list all the supported formats, it should like the ones from assimp if it's supported.

Answer 2 · 2023-02-02T06:13:27.000Z

Yes, it is correctly linked against Assimp (as dll on my machine).

Test1 Version.h:
Version_h.txt

Test 2 vsgconv --features:
vsgconv_feat.txt

Test 3 dumpbin /dependents vsgconv.exe
vsgconv_deps.txt

Answer 3 · 2023-02-02T09:41:10.000Z

Thanks for the files. vsgXchange sure looks like it should have assimp available.

I had a look into the official glTF-Sample-Models repoistitory but can't find a Helmet.glb but I did find a DamagedHelmet.glb which worked fine for me, both loading in osgviewer and with:

vsgconv DamagedHelmet.glb test.vsgb

As I can't reproduce the problem you'll need to investigate it further yourself. The place I'd start would be the assimp::Implementation::read(const vsg::Path&, vsg::ref_ptr) method:

https://github.com/vsg-dev/vsgXchange/blob/master/src/assimp/assimp.cpp#L994

In particular the I'd check the result of the line:

vsg::Path ext = (options && options->extensionHint) ? options->extensionHint : vsg::lowerCaseFileExtension(filename);

I changed this recently to standardize the optional use of the extensionHint and make it possible to alias a file with one extension to be treated as it has the specified extensionHint extension. In normal usage extensionHint should be empty and return false in the above check, so ext should end up with the value of vsg::lowerCaseFileExtension(filename) which is what was used previously.

Checking the filename and ext value would be the first sanity test - they should match for the vsgconv test you've been doing.

It looks like you are using dll's of the dependencies, it might be worth trying static build of these and the VSG libs to see if that has an influence.

Finally, I presume this has been working for you previously? If so do you know when the regression happened?

Answer 4 · 2023-02-02T10:35:11.000Z

Thanks, I will look at it.

I think the problem occured together with *.cpp write issue. Actually I use the official releases, there is no problem like this.

Answer 5 · 2023-02-03T07:44:03.000Z

Filepath and extension seem to be ok. The Windows debugger refuses to continue at line 217 of file assimp.cpp (sounds weird to me):

vsg::ref_ptrvsg::ShaderSet getOrCreatePbrShaderSet()
{
if (!pbrShaderSet)
{
pbrShaderSet = vsg::createPhysicsBasedRenderingShaderSet(options); // line 217 assimp.cpp: unhandled exception
if (sharedObjects) sharedObjects->share(pbrShaderSet);
}
return pbrShaderSet;
}

Actually I only work with static libraries. The problem is the same, but debugging is a bit easier.
Testfiles:
red_teapot_mtl.txt
red_teapot_obj.txt

vsgconvd red_teapot.obj red_teapot.vsgt

Answer 6 · 2023-02-03T07:48:53.000Z

For completeness, the debugger message:

Ausnahmefehler bei 0x00007FFD5CF57CBE (ucrtbased.dll) in vsgconvd.exe: 0xC0000005: Zugriffsverletzung beim Schreiben an Position 0x000000B8C9410FF8

In pidgeon english:
Exception error at 0x00007FFD5CF57CBE (ucrtbased.dll) in vsgconvd.exe: 0xC0000005: Accessviolation at writing on position 0x000000B8C9410FF8

Answer 7 · 2023-02-03T09:02:36.000Z

The line 217 which is through an exception shouldn't be affected by the recent changes to the handling of extensionHint. Is there any chance there is a mismatch between the VSG headers and lib you are building against?

Answer 8 · 2023-02-03T09:19:27.000Z

I also don't understand this exception. It sounds like: don't set a pointer which is publically accessable.

I am quit sure about my setup. The windows compiler and linker are extremely sensitive about link release mode files and debug files, normally it fails. Everything has to fit perfectly.

Answer 9 · 2023-02-03T09:36:13.000Z

Could you put a break point just before the line which throws the exception and then slowly step through the code to see what is throwing the exception?

The VSG code being invoked doesn't throw exceptions itself, so perhaps it's the standard library.

Finding out what the exception is might also gives some clues.

Answer 10 · 2023-02-03T10:35:58.000Z

Sorry for the delay, the microsoft compiler is the slowest I know.

Here is my screen dump:

Answer 11 · 2023-02-03T11:08:05.000Z

The screenshot shows a different block of code to the line 217 which you reported the exception for so I don't know what to make of the info in the screenshot.

I've tested the red_teapot.obj you provided on my Kubuntu system with VSG+vsgXchange master and it loads in vsgviewer and converts correctly with vsgconv. If it crashed I would celebrate as it give me a chance to directly debug the issue.

2 days ago a client got a VSG based lib + application running under Windows using VSG+vsgXchange master and has been successfully loaded models via the vsgXchange::assimp loader, this suggests to me there might be a build specific issue going on, or an uninitialized variable that is at play and causing varying results.

Answer 12 · 2023-02-03T11:09:17.000Z

Refinement of break points shows:

if (getColor(material, AI_MATKEY_BASE_COLOR, pbr.baseColorFactor) || hasPbrSpecularGlossiness)
{
// PBR path
convertedMaterial.shaderSet = getOrCreatePbrShaderSet(); // line 321: SceneConverter::convert() here the crash starts

Answer 13 · 2023-02-03T11:11:18.000Z

If you have a running version for Windows, can you give me some information about its configuration?

Answer 14 · 2023-02-03T11:36:59.000Z

I don't have Windows myself, just Linux systems.

Answer 15 · 2023-02-03T11:42:59.000Z

I've just looked through SceneConverter and I can't see any uninitialized variables.

Answer 16 · 2023-02-03T12:08:04.000Z

That was also my impression. It would be good to know yet, if your windows customer uses a different Visual Studio Version (my version is 2022), It wouldn't be the first time, that certain versions make problems. Actually I have to go back to versions 1.0.x of vsg, because project_chronoe needs it and it is working. I am going to make some further testing and I will keep you informed.
Thanks

Answer 17 · 2023-02-03T13:57:59.000Z

I'll put a call out to the Windows devs on the VSG Discussion forum to see if others are having problems, perhaps we can then figure out a pattern of failure.

Answer 18 · 2023-02-03T14:11:05.000Z

I've created a thread to call for help from Windows devs:
vsg-dev/VulkanSceneGraph#716

Answer 19 · 2023-02-07T16:50:16.000Z

@rainergericke I have checked in a suggested fix to vsgXchange, and updated the built-in shaders in VulkanSceneGraph. Could you checked out VSG and vsgXchange master and let me know if things are working OK once more?