Issue with glb2 export

[Greg Kasapidis]

I'm experimenting with glb2 export for scenes with skeletal animations. I did try to import and re-export a sample file that I found in khronos's examples and it worked like a charm. However, when I work in a more complicated mesh of mine, my app simply closes without any warning or even the known "Access Violation exception". I've been experimenting and I think I have traced that the issue is related with the existence of bones in the mesh. When I remove all of the bones, export works. Even with a single bone with no vertex weights it still crashes. FYI, the same assimp.scene exports successfully when using fbx, or collada.

[Nicholas Woodfield]

Are you seeing this in the 5.0 beta? Can you link the sample file you used?

[Greg Kasapidis]

Yes I’m using the 5.0 beta. In fact, I just cloned and built the project with the very latest updates. Unfortunately I don’t have any sample to share. Its a custom scene that I assemble from scratch in my app. I can provide the exports to collada or fbx though. Is there any way to trace such exceptions?

[Nicholas Woodfield]

Although tedious and annoying, you can turn on unmanaged debugging and get a debug native DLL built locally (e.g. build native assimp from the 5.0 github release tag).

‌

I just tweaked my azure pipelines to also build a winx64-debug, may help so you can avoid building yourself:

‌

https://dev.azure.com/nicholaswoodfield/a3489586-6382-428d-b47e-d10bd4b96337/_apis/build/builds/95/artifacts?artifactName=win-x64-debug&api-version=5.1&%24format=zip

(you’ll still need to pull down the native sources and point the debugger to them. I build the native library from a github fork here => https://github.com/Starnick/assimp/tree/AssimpNet-5.0.1)

[Greg Kasapidis]

Thanks. I downloaded the assimp sources from your fork, so I think I’ll make a local build as well. Is the assimp.dll embedded in the assimpNet.dll? I don’t see it anywhere in the output folder and to be honest I’m not so sure how am I going to use the dll that I’ll build.

[Greg Kasapidis]

Doh, I am blind. I think I found the native dll location, I added my built dll with debug symbols, but after running my application it now triggers when loading the sample gltf file… The sample that i use is "SimpleSkin.gltf"

[Greg Kasapidis]

Regarding the issue with the import using the latest native dll, I think I traced the issue (Still couldn’t manage to dive into the c++ code). I took a look at the memory It seems like the structure is kinda different. Then I took a look on the assimp code and I found that the aiBone class of the main assimp project contains two extra pointer members namely bone->armature and bone->node. I also noticed that there is a ASSIMP_BUILD_NO_ARMATUREPOPULATE_PROCESS preprocessor flags that enables these members. I’m working my way through the code to disable these members and build a compatible assimp.dll Do you use the assimp releases for building assimp-net or are you building with some specific configuration. Am I doing something wrong in the process?

[Nicholas Woodfield]

Well that looks like an annoying change (usually they just ifdef the c++ parts of the common data types).

‌

It looks like you're either looking at the wrong version, I see that change on the latest master of assimp (didn't look at master of my fork). I do not see it on the AssimpNet 5.0.1 branch on my fork:

https://github.com/Starnick/assimp/blob/AssimpNet-5.0.1/include/assimp/mesh.h

‌

I build my own releases via azure pipelines (can go to it via the build status badge on the home page of this repo. For the most part there are just small build configurations to support all the platforms I build for or to minimize deps (e.g. the windows DLL used to require a vc runtime to be installed but I statically link that since managed users do not expect it)

‌

There are a number of paths the library probes for the native DLL, which is documented in the changelog. The native libs are loaded from the nuget cache folder (generally) when developing locally, but it depends on what version of .net you're targeting. You can also override the behavior by providing your own paths to the DLL before creating an assimp context.

[Greg Kasapidis]

Ah I didnt know that I could set the paths through the context. For now I’m using the default runtimes\win-x86\native folder which seems to work and load my dlls. Also you are right, I think I grabbed the main branch of assimp and not your fork, I guess I’ll fetch your version just to make sure.

After some investigation the issue seems to be indeed related to the GLTF2Exporter of asimp. I currently have some hard time compiling using the address sanitizer flag from visual studio, hoping to detect the source of the leak, because I still don’t see anything suspicious in the relevant part of the code.

Thanks for your feedback.

[Greg Kasapidis]

Indeed the error is related with heap corruption. The error triggers within the ExportSkin method of the GLTF2 Exporter. In fact when I comment out buf->ReplaceData_joint(offset, bytesLen, arrys, bytesLen); the error doesn’t trigger any more. I think that its related with the .reset method of the underlying mData shared_ptr but honestly I didn't manage to find what is causing the crash.

In any case https://www.dropbox.com/s/x8sj1ubnsl3jbjr/test.fbx?dl=0 this is the link to a successfully exported fbx file. Using the assimp_cmd tool trying to convert it to glb the error triggers so I guess it can serve as a testbed for the issue.

[Nicholas Woodfield]

Hmm if assimp_cmd is crashing, it sounds like you removed the managed wrapper as a variable. Please open an issue for the crash at the native assimp repo:

https://github.com/assimp/assimp