assimp 3.1.1 about assimp-net HOT 8 CLOSED

The trunk has been updated to 3.1.1 for a while now.

I noticed some irregularities with marshaling some strings and made tweaks to 
AssimpLibrary.cs where I was using MarshalStructure<T> rather than Read<T> 
which seemed to clear that up. Perhaps that was what you were seeing? Or is 
this an issue with Export (marshaling back to native?)? 

Please provide an example where AiString marshaling fails with some explanation 
of what should be expected and I'll look into it.

I did a quick check in trunk and the AiString problem is still here.. the same 
problem i had..

I attached a sample model to show this.. the names of the meshes and bones have 
only the first byte correct and the rest is zero.. 

you can use a previous version of assimpNet (not based on v3.1.1 assimp) and it 
will read them ok

Also you should add this
https://github.com/VirusFree/AssimpNet/commit/c04f0cd69fe5b1f46cf6cb61a2c7ff5532
7187a5

Alrighty, after conferring with one Alex on the native Assimp side we got to 
the bottom of this. I'm not exactly sure how this would change with upgrading 
to v3.1.1, but perhaps its because the library has moved to a different .NET 
runtime? Anyways, yes I did observe the same oddity with AiMesh which utilizes 
Marshal::PtrToStructure because it is not a blittable type.

Anyways, that function is rarely used so I have come up with a more elegant 
solution to use custom marshaling for non-blittable types. The changes are in 
the trunk now and I have tested against your model and the mesh names are 
coming in.

BTW, I did not see any issue with bone names.

Re-opening, works in 32 bit but not 64 bit due to an alignment issue. Jumped 
the gun on that one

Yes, i tested the trunk in 32 bit and works ok, in 64 it crahes with acces 
violation..

a quick look i found that there is indeed an alignment problem.
eg in lines (MarshalNativeToManaged.cs line 147)
            mesh.NumFaces = MemoryHelper.Read<uint>(currPos);
            currPos = MemoryHelper.AddIntPtr(currPos, sizeof(uint));

            mesh.Vertices = MemoryHelper.Read<IntPtr>(currPos);
            currPos = MemoryHelper.AddIntPtr(currPos, IntPtr.Size);


i check the pointers and the memory at that locations and i see that the 
correct data for the vertices pointer start with some padding. This is because 
was is before it is not 64-bit aligned.

the struct aimesh from assimp is 
struct aiMesh
{
    unsigned int mPrimitiveTypes;
    unsigned int mNumVertices;
    unsigned int mNumFaces;
    C_STRUCT aiVector3D* mVertices;
...
}
which means mVertices is not 64-bit, since the 3 previous entries add up to 12 
bytes, so with some compiler padding/alignment mVertices should start at 16.

So the problem is that doing it by hand the MemoryHelper.AddIntPtr(currPos, 
xxx); means we are skipping the compiler-added padding for alignemnt.

Ok i fixed it.

here is the commit
https://github.com/VirusFree/AssimpNet/commit/b97f8aebdc6d560b73cdd04fdf92c52d30
6db874

and here it is as a patch :)

Thanks, I'll add the methods to MemoryHelper.

However I went a different direction, ultimately a compromise with creating 
AiMesh/AiAnimMesh blittable and avoiding any use of .NET marshaling. Still 
keeping the option for custom marshaling in the future though. Probably should 
have gone that route in the first place to avoid boxing.

BTW for future reference, the original problem is explained in the comments 
section of the article below:

http://msdn.microsoft.com/en-us/library/zycewsya%28v=vs.100%29.aspx