assimp 3.1.1

[GoogleCodeExporter]

This is not really an issue, more of an FYI, about v3.1.1

I committed a few things on the assimp repo (mostly about FBX and metadata) and 
wherever appropriate i did the necessary additions in my assimpNet fork in 
github.

You can see them here and use whatever you find usefull.
https://github.com/VirusFree/AssimpNet/commits/master

A problem i found and was not able to fix correctly,but had to result in an 
ugly workaround, was with aistrings.. i think this is a .net marshaling bug 
were it would only fetch a byte from the buffer and leave the rest zero.
(even though when checking with the memory viewer in visual studio i could see 
the source/native buffer was ok)

Anyway, this is just an FYI and if you need any help with moving to v3.1.1 let 
me know :)

Original issue reported on code.google.com by virusfre...@gmail.com on 25 Jun 2014 at 8:04

[GoogleCodeExporter]

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.

Original comment by nicholas.woodfield on 27 Jun 2014 at 2:40

[GoogleCodeExporter]

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

Original comment by virusfre...@gmail.com on 27 Jun 2014 at 11:14

Attachments:

• skin_test.zip

[GoogleCodeExporter]

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.

Original comment by nicholas.woodfield on 1 Jul 2014 at 7:40

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by nicholas.woodfield on 1 Jul 2014 at 11:52

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by virusfre...@gmail.com on 2 Jul 2014 at 1:09

[GoogleCodeExporter]

Ok i fixed it.

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

Original comment by virusfre...@gmail.com on 2 Jul 2014 at 1:12

[GoogleCodeExporter]

and here it is as a patch :)

Original comment by virusfre...@gmail.com on 2 Jul 2014 at 1:16

Attachments:

• alignment_fix.patch

[GoogleCodeExporter]

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

Original comment by nicholas.woodfield on 3 Jul 2014 at 1:29

• Changed state: Fixed