Mesh.PrimitiveType not being filled out correctly for GLTF/GLB import

[TinyDev]

Hello. I'm having trouble importing points and lines from a GTLF file.

Attached is a test model that I am importing. This screenshot is created using VSCode with the GLTF extension and three.js renderer. This is the model as it should import, with points and lines intact.

‌

However, when I import this into my toy renderer, all meshes are parsed as Assimp.PrimitiveType.Triangle no matter what post process flags I use or what export options I use from Blender.

‌

For example, the following code will always set the Topology variable to TriangleList.

Topology = aiMesh.PrimitiveType switch
{
    Assimp.PrimitiveType.Point => PointList,
    Assimp.PrimitiveType.Line => LineList,
    Assimp.PrimitiveType.Triangle => TriangleList,
    Assimp.PrimitiveType.Polygon => TriangleList,
    _ => TriangleList
};

I am using the 5.0.0-beta1 build from Nuget. I had tried to clone this repo and build from master to see if that would help, but I've been unable to build it.

In the C++ version of Assimp, I have previously tested a model with these features and it worked correctly, so I know for a fact that Assimp should be able to import these. Here is a C++ based project using AssimpCpp 5.0.1.6 from NuGet. Here is another test model using the C++ Assimp in a C++ project. There is a line above the wedge, and 4 points around the wedge. The axis gizmo is unrelated to the model, however the text is part of the test model.

‌

For reference, if this exact same model is loaded with the 5.0.0-beta1 AssimpNet, it appears as such. Again, ignore the axis gizmo as it’s a built in part of the renderer. (The wedge itself is black because my C++ code handled materials slightly differently.) Important to note is that the points and lines have been converted to triangles.

‌

[Nicholas Woodfield]

Looks like it was missing setting the field when marshalled from AiMesh. Also some recent donated code from a PR did not test for non-netstandard which may have been your compile problem. Just pushed a fix for both.

[TinyDev]

Hello, thank you for addressing this! My project makes heavy use of points and lines, and so would benefit a lot from being able to import them directly.

Has the NuGet package been updated? It doesn’t seem to be, and I’m getting the same behavior as before.

If not, then building (and referencing?) what is on master right now would be my only option. How can I build the AssimpNet solution myself? Whether I use VS2019 or VS2022, I get errors. Is there a step I’m missing? I wasn’t able to find any documentation in the readme for special instructions on how to build it. I cloned the repository with the latest master branch, open the solution, and try to build it, but with no luck. Here are the errors as they appear:

‌

[Nicholas Woodfield]

No nuget build. I’m thinking of doing a (finally) 5.0 release targeting net standard 2.1 and dropping net4/net3.5 support completely. This also means dropping the ILPatcher dependency. The work is on it’s own branch https://bitbucket.org/Starnick/assimpnet/branch/netstandard2.1

For master, it seems updating to the latest ILPatcher is causing problems when the UnityPlugin.targets is referenced (it builds w/o it). I reverted to the previous version and it seems to work as it should on a clean repo pull/build.

[TinyDev]

Excellent, thank you very much! The project builds and GTLF imports are working better than ever.

‌

If anybody else comes across this, the only thing I had to do after adding the AssimpNet C# project to my solution, was to add it as a reference to my main project, and copy the assimp.dll from assimpnet\libs\Assimp\win-x86 into my build’s folder.

I look forward to a future NuGet release, as it’ll make sharing my project simpler.