Issues with Unity3d

Community Forums AssimpNet Issues with Unity3d

This topic contains 5 replies, has 2 voices, and was last updated by  Starnick 8 years, 11 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #414


    Hey Starnik, how’s it going? I’m trying to get AssImp.Net working within Unity3d. So I grabbed a copy from the trunk. I’m using Mono as my development environment. I had to comment out references to GetHRForLastWin32Error in AssimpLibrary.cs as it’s not supported in Mono. I then recompiled against Mono 3.5 to get around an issue with System.Type.op_Equality. Thereafter I dropped Assimp.dll and AssimpNet.dll into the unity/assets/plugins/ directory.

    Calling the importer from unity is a case of:

    Assimp.AssimpContext context = new Assimp.AssimpContext();
    Assimp.Scene house = context.ImportFile ("D:/Duplex_A_20110907.ifc");

    On the second line there unity crashes with the error:

    Object reference not set to an instance of an object
    Assimp.Unmanaged.AssimpLibrary.CreatePropertyStore () ...

    I’m finding bits and pieces of information online where people are trying to get this going. If you had an idea or could point me in any particular direction I’d greatly appreciate it. I’ll get back to you if I figure it out myself.





    Of course as I posted it I tried something else. It appears putting the assimp dll in the root directory of the unity project solves this problem. Now I’m a little further and get:

    The requested feature is not implemented.
    Assimp.InternalInterop.ReadInline[AiScene] (System.Void* pSrc)

    So it looks like Mono.Cecil isn’t being loaded properly now and the ReadInline is subsequently throwing it’s not implemented exception. I’ll try to download Cecil source and compile to Mono 3.5 and stick that in the project root to see if it helps. Let me know if you’ve gotten this working in the past.

    • This reply was modified 8 years, 11 months ago by  leydar.
    • This reply was modified 8 years, 11 months ago by  Starnick.


    Hmm yes, I don’t yet have a build procedure for Mono yet (I’m under the impression that GetHRForLastWin32Error is there, but just not implemented, so even on a Windows desktop you’ll run into an exception there?)

    The location of the unmanaged DLL (Assimp.dll) by default needs to be in the same directory as the managed one, but you can override this by passing a path to AssimpLibrary to where the unmanged DLL is located. It gets loaded dynamically, either implicitly by the AssimpContext  when first needed or explicitly by you.

    The second error you’re running into is because during compilation the post-process AssimpNet.Interop.Generator is not being run. What is on the trunk is radically different than the last release. After the main project is compiled, the assembly is patched with IL generated by Mono.Cecil, which is included in the “libs” folder on the trunk. So if you’re not using the visual studio solution, you have to be aware of this two-step process to get AssimpNet compiled correctly.

    InternalInterop is a static class full of stubs that get replaced by this generation process, functionality to support marshalling of data to/from unmanaged memory.



    Hey Starnick,
    I’m very much obliged for the clarifications. So last night I got as far as compiling the generator. I ran it against the assimpnet dll and that worked. For assimpnet to work with unity I have to compile it against mono 3.5. When I subsequently try to import a file with ImportFile I get a litany of errors. They are of the type:

    NullReferenceException: Object reference not set to an instance of an object
    at System.StringComparer.GetHashCode (System.Object obj) [0x00011] in /Applications/buildAgent/work/3df08680c6f85295/mcs/class/corlib/System/StringComparer.cs:138   at
    System.Collections.Hashtable.GetHash (System.Object key) [0x0000b] in /Applications/buildAgent/work/3df08680c6f85295/mcs/class/corlib/System.Collections/Hashtable.cs:658   at
    System.Collections.Hashtable.get_Item (System.Object key) [0x00028] in /Applications/buildAgent/work/3df08680c6f85295/mcs/class/corlib/System.Collections/Hashtable.cs:395   at
    UnityEngine.GUISkin.FindStyle (System.String styleName) [0x00029] in C:\BuildAgent\work\812c4f5049264fad\Runtime\ExportGenerated\Editor\GUISkinBindings.cs:188   at UnityEngine.GUISkin.GetStyle
    (System.String styleName) [0x00000] in C:\BuildAgent\work\812c4f5049264fad\Runtime\ExportGenerated\Editor\GUISkinBindings.cs:175   at UnityEngine.GUIStyle.op_Implicit (System.String str) [0x00020]
    in C:\BuildAgent\work\812c4f5049264fad\Runtime\ExportGenerated\Editor\GUIStyleBindings.cs:617   at UnityEditor.Toolbar.DoLayersDropDown () [0x00006] in C:\BuildAgent\work\812c4f5049264fad\Editor\Mono\GUI\Toolbar.cs:307   at UnityEditor.Toolbar.OnGUI () [0x00130] in C:\BuildAgent\work\812c4f5049264fad\Editor\Mono\GUI\Toolbar.cs:220

    I’d imagine it’s caused by disparity between the version of the framework I’m compiling against and what was originally intended. I was thinking about trying the older versions of the wrapper. Which would you recommend that would compile to Mono 3.5? This is the first hump as I’ll have to subsequently get it working with Android/iOS. In any case thank you for the software, it’s an erstwhile endeavor and I appreciate your work.




    Just to report back. I reverted to the 3.0 version of the wrapper. After compilation it seems to be working fine. I haven’t figured out an easy way to convert the Assimp Scene object to a unity object yet but I can access the in memory model’s properties correctly.



    FYI, I split the topic into its own thread.

    I keep every release tagged in the SVN, so reverting to a release to recompile should be fairly painless. This isn’t the first issue with Unity that has been reported, but some users have been successful in getting the library up and running on that platform. I’m not familiar with that exception, so I can’t be much help in diagnosing how to integrate into Unity I’m afraid, as I don’t use it. What I do know that has been reported is there will be issues with later versions of AssimpNet (post-v 3.0 after the P/Invoke went to a dynamic loading scheme rather than static DLLImports) with iOS as its a platform limitation. Something with iOS only allowing for static linking. I’m not sure if this is the cause or if there are other issues at play.

    But let’s take a step back for a moment, Assimp is squarely a “tool pipeline” library, which generally means the target is the developer’s PC. There are some exceptions of course (e.g. a model viewer for android), but that’s largely the intended audience. A la the XNA Framework Content Pipeline is not intended for consumption by Xbox 360 or Windows phone. It is quite possible to use the library to convert to whatever internal format you use off-line.

    Here’s a superb write up about the Assimp data structure (geared for animation, but I’m sure that’s where you probably will be heading with Unity as it has support for that):

    And I suggest the official Assimp docs as well. The managed scene structure is more or less a 1 to 1 mapping of it.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.