Incorrect mesh skeleton node randomly given DAE output

[Former user]

Issue occurs in Nuget preview 5.0.0 Beta 1 as well as 4.1.0

There's an issue in which DAE exports will be inconsistent with the node they place in the skeleton tag for a given mesh. In one particular model, it will go between 3 or so. This happens when exporting multiple times separately and when exporting multiple times from the same scene + context pair in a loop without any changes.

Repro steps: Use the below commit of my tool and comment the block for my ghetto fix on lines 1166-1179. Extract and open the provided PSO2 .aqp file with the provided .aqn in the same directory. Effect on the skeleton tags in the mesh node tags should be noticeable within 10 exports or so for sure, often less. AquaModelTool/AquaModelToolUI.cs https://github.com/Shadowth117/PSO2-Aqua-Library/tree/3e207f42ccd4088f28a5eedcf35ec2809d85a6fd

[Nicholas Woodfield]

“Effect on the skeleton tags in the mesh node tags should be noticeable within 10 exports or so for sure, often less.”

So it works for the first 9 times you export the same model, but the 10th time it’s wrong? Without making any changes to the scene objects?

Is it consistently the wrong node name, or something more random?

‌

[Shadowth117]

Issue is rather random. As stated, the very same instance of a scene + context will export with a different node in the skeleton tags for this model and others. Perhaps some sort of threading issue? The rest of the file exports consistently. I had some friends who’d worked with it before review the issue and they were rather surprised as well.

Edit: I should note that the issue does happen at a fairly consistent rate. Something like 1/n times with n being some number of nodes it finds it can settle on. For the particular model I linked, there are 3 or so nodes it can be. 3 of the 4 mesh nodes in the example provided will have the same mystery node while the 4th is consistent.

‌

[Nicholas Woodfield]

"Perhaps some sort of threading issue?”

Have you tried forcing your code to run synchronously? If you don’t see this behavior synchronously then there is a good chance the native DAE exporter may be using some global state then.

The interop layer is basically copying the scene data to unmanaged memory every time export is called, and the native APIs the context calls are creating a new exporter/importer for every call, so there shouldn’t be any global state mutating and being accessed at that step, if each thread has it’s own context.

[Shadowth117]

I think I need to be more clear. I do not have any parallelism running within my code for this process. I believe the parralelism issue may be within Assimp or AssimpNet itself somehow.

For example, let’s say I’ve built the context up and provided a scene as I have in the linked code. I can create a loop of AssimpContext ExportFile functions for that AssimpContext instance or duplicate the AssimpContext ExportFile function at the end of my own export function from my instance of it and this will occur. So no changes can go on since everything is built, just the very Context that has been built and the scene provided in a situation where there can’t be any alterations to them on my end. At that point, it’s only possible for the Context to change itself if anything, via running ExportFile from itself.

The wrong node(s) may show up on the first run or a few runs in, and to reiterate, it is exclusively those tags. Nothing else is changing. Every other write aside from the created/modified date is consistent.