Assimp Loader : "Chunk is too large" problem


I’m having trouble using the ofxAssimpModelLoader, in fact it is exactly the same problem as here, but since this topic didn’t get any response and is one year old…

I found out that on my Windows 7, 64 bits, the Assimp loader fails at loading my 3D model, showing in the console an error like “loadModel: Chunk is too large”. It’s very embarrassing since on linux (I usually work on Ubuntu and only check once in a while it still works on windows), using the same version, everything works fine :frowning:

Then I tried to run the example in addons/assimpExample and just like in the topic I linked before, the example with the squirrel (NewSquirrel.3ds) doesn’t work and immediately makes the example crash with the same error message. Probably not the 3DS file’s problem, since it is also used by the 3DModelLoaderExample, which works well.

So I guess I’m pointing the bug and asking for help at the same time :smiley:

My configuration : Win7 64 bits, CodeBlocks 12.11, openFrameworks 0.8.0. I’m working exactly on the same versions on Ubuntu, and I don’t have the issue.

For your information I’m testing with this mesh (edit: doesn’t allow direct links, but when you go to download meshes, it’s the first mesh called “USS Enterprise-D”), download the 3DS file and textures to reproduce the bug. Also, assimp is really my only option here, since 3DModelLoader only accepts .jpg, .bmp or .png textures, and the textures going with this mesh are GIFs… And converting the images type and tweaking the raw .3ds file (don’t have 3DS Max here to modify it the right way …) doesn’t work.

Thanks for any help :wink:

I’ve been fighting with this one myself for a few days, but I haven’t figured it out yet.

It seems to be related to this:

And of course, it only affects gcc-type toolchains, which isn’t one of the Assimp team’s priorities.

I think that to resolve the issue, you need to build “libassimp.dll” for yourself, using a newer version of the Assimp repo. The assimp team does not provide pre-built binaries for MinGW, so you’ll have to delve into CMake and a bunch of other stuff.

I am not allowed to post more than one link (I’m a new user), so you’ll have to look that up yourself.

Personally, I’ve been able to build a new Assimp library, but it’s very large (23mb), and it doesn’t work.

Also, the OF devs are aware of the issue: (again, I am not allowed to post the link that’s supposed to go here)

Would really like to solve this ASAP…

Someone in this thread:

mentioned that assimp was still working with OF0.73. I tried downloading OF0.73, and it’s still using the same “libassimp.dll” which is distributed with OF0.80. That more or less rules out the possibility of the library being the issue, I think.

Also, some people are mentioning that there’s an issue with MSVC builds showing the same “chunk too large” error with 3ds files, so the issue may not be limited to just gcc/MinGW.

According to the OF changelog, Assimp was overhauled in OF0.74. Maybe that’s where it went wrong.

Still working on this one…

I tried seeing how much ofxAssimpModelLoader has changed between OF0.73 and OF0.80.

It actually hasn’t changed at all. So, I’m left wondering: if it used to work before, and nothing has changed, what could possibly be the problem?

AFAIK, the only difference is the GCC compiler, which I pointed out in an earlier post.

I’m going to try compiling Assimp directly into my project and see if I can just trace through it line by line.

EDIT: I’ve managed to compile a new version of libassimp.dll, finally. It works, but unfortunately, now ofxAssimpModelLoader has to be updated (the headers are outdated). So, I’ll test that next week, I guess.

JSYK, I’m porting an OSX app over to Windows, and it needs to be done soon. So that’s why I’m working on this like a madman.


oh ok, I was just wondering if there was some sort of quick fix or if I was just doing something wrong. :open_mouth:

I have this problem in a project that is due for Sunday, but portability of this specific feature isn’t very important, so I’ve just kind of given up for now.

Thanks for keeping us informed about what you try :smile:

I hope too it will be soon fixed in OF ! Maybe your progress will be helpful to the team ?

someone tried to port assimp addon to 3.0 version but i don’t know if it solve this issue you encounter and if it works properly…

That might help a bit with the cleanup, when I get it working. Thanks kalwalt! But it does look like Jeremy was mainly targeting OSX.

I’ve just hacked together a small project to see if I can at least load a file without updating all of Assimp. Guess what, same problem with my new Library. BUT - I can pull debug info from my Library.

When reading the Main Chunk of the file (really, the entire file, I think):

In 3DSLoader.cpp: Discreet3DSImporter::ReadChunk

pcOut->Size = 6125 (this is the exact size of my 3DS file in bytes, so this value is correct)
stream->GetRemainingSize = 2949

The ‘stream’ variable leads back to “StreamReader”, which is Assimp’s wrapper for iostream. This must be the culprit, because it’s reporting the remaining size as being too small.

If anyone knows why iostream might fail, be sure to help me out.

There is an easy workaround: go into ‘ofxAssimpModelLoader.cpp’ and mess around with it a little bit, so that it uses:

aiImportFile(“pathToYour3DSFile”, flags);

instead of


The libassimp library is having issues reading 3DS files from memory, so we’re just working around it altogether. This way you don’t have to update any libraries or upgrade assimp.

That sucked.