I have builded assimp (debug) and when I use the lib to load models in my program (debug) everything works, except for .fbx-files. Im getting "Assertion Failed" when I run Assimp::Importer::ReadFile.

Here is a print: http://i.imgur.com/17L42VF.png

When i build assimp (release) and building my program (release) .fbx-models works fine.

STLLoader don't support multi solid body
A STL file can containe multi solid/endsolid tags, assimp read only the first solid/endsolid tag

See: https://sourceforge.net/p/assimp/bugs/115/

The visual studio solution file (workspaces/vc9/assimp.vcproj) is still searching for M3Importer.cpp, which was deleted 6 days ago.

I think you just need to delete this file in the solution, ie the following lines in workspaces/vc9/assimp.vcproj.

<Filter
    Name="m3"
    >
    <File
        RelativePath="..\..\code\M3Importer.cpp"
        >
    </File>
    <File
        RelativePath="..\..\code\M3Importer.h"
        >
    </File>
</Filter>

I found a problem building assimp. Don't know if it is in my machine.

Steps

1. Run CMake to generate Visual Studio 10 solution
2. Open Visual Studio 10 and build assimp debug target
3. Build assimp release target.

Errors:

assimp\code\3DSLoader.cpp : error C2855: command-line option '/Z7' inconsistent with precompiled header

among others.

Seems assimp is using precompiled headers from one target in another.

If the first line containe blanck caracters befor solid, it is considered as a binary file: it's not true

See: https://sourceforge.net/p/assimp/bugs/117/

dae_fbx(2014.1) is correctly export light's intensity(1.5452 - 2.3654 - 8.1024- 9.0021 ...).
but assimp always export light's intensity 1 0 0(constant_attenuation, linear_attenuation , quadratic_attenuation)

The COLLADA parser does not support the <ph> element.

It looks like "polygons with holes" has been added to IFC using Clipper - perhaps this could be applied to COLLADA as well?

(Might be good to update Clipper too - 5.1.6 looks like it fixes some bugs. The one included with assimp is 4.8.8.)

I've tried to use blender files but it didn't work so i was forced to use 3ds format :|

Hi,

In the following zip file you will find several '.obj' file that assimp cannot read.

https://dl.dropboxusercontent.com/u/65787026/Laguna%20v1.1.zip

I got the following message :

"Error[invalid vector subscript]"

I don't know what it mean !!!

Hi,

I've developed custom IOSystem / IOStream for Android Asset Manager.

since I'm new to C/C++ I placed some logging to check everything was being performed correctly and I noticed the Close method in IOSystem is never called.

I looked in the code for the Collada parser (and many other have the same issues). Close is never called.

The only 2 parsers calling close (at least in the code) are OBJ and 3DS parsers.

This leave opened resources and probably cause memory leaks.

The IOStream is also never deleted.

Hi,

With the following model, some parts are missing (maybe due to instances or something like that).

http://animium.com/2012/11/quadbot-free-3d-model/

Thanks

When I build assimp with -DCMAKE_BUILD_TYPE=Debug, it produces libassimpD.dylib. When I use find_package(ASSIMP) to use assimp in my project, assimp-config.cmake sets include dirs and lib dirs correctly, but sets ASSIMP_LIBRARIES to "assimp" instead of "assimpD". That causes my link to fail, because it can't find anything for "-lassimp".

While linking "libassimp.dylib", the version given on command line as "-current_version 3.0.1264" is invalid for ld:

ld: malformed 64-bit a.b.c.d.e version number: 3.0.1264

A quick fix could be:

set(ASSIMP_VERSION ${ASSIMP_VERSION_MAJOR}.${ASSIMP_VERSION_MINOR})

  const aiScene* scene = importer->ReadFile( pFile,
        aiProcess_CalcTangentSpace       |
        aiProcess_Triangulate            |
        aiProcess_JoinIdenticalVertices  |
        aiProcess_SortByPType);

my .dae file reference an external texture image (png):

  <library_images>
    <image id="file2" name="file2">
      <init_from>collada/BBJ94_Y7707_13_Wishes_Doll_Asst.png</init_from>
      <extra>
        <technique profile="OpenCOLLADAMaya">
          <dgnode_type>kFile</dgnode_type>
          <image_sequence>0</image_sequence>
          <originalMayaNodeId>file2</originalMayaNodeId>
        </technique>
      </extra>
    </image>
  </library_images>

the importer load the aiScene but scene->HasTextures() return false.

When a mesh has faces with more than 4 vertices, heap corruption may occur due to always allocating (4 * number of faces) vertices.

Here's a patch to fix it:
https://gist.github.com/cadaver/5505659

The obj exporter does not support vertex sharing between faces. Also, to my knowledge, mesh vertices are duplicated on import. That is, every face gets its own copy of each vertex it uses.

Can the original topology be preserved? Some mesh processing algorithms require the original topology.

The model in question is here, it's a biplane:
https://www.dropbox.com/s/7hhroi6jgst6mmg/airplane.zip

There is 1 mesh and 8 materials in this model (but Assimp splits up the mesh into 8 meshes, one for each material). Assimp seems to think that each mesh has the exact same material (mMaterialIndex is 7 for every single mesh). This results in the same texture being applied everywhere.

Here is what assimp viewer shows:

Notice how the wings have the same texture as the hull.

And here is what the DirectX viewer shows:

Assimp compiles fine on VC10, but on VC 11 there's a missing

include

in AssimpPCH.h, line 121

Hi,
I have a .dae file which contains reference to a texture called "file://C:\My Folder\diffuse.png". When i import the file with Assimp, it works fine, and when i export it (also to .dae), the path is changed to "C%3a\My%20Folder\diffuse.png".
The issue is, if i try to re-import this new .dae file into Assimp, there is an error because the texture cannot be found. The error doesn't occur if there is no spaces in the texture path. Is there a way to make it work, or is this a know issue ? The only way i found to get around this is to post-process the file and change back every "%20" to " ".
Thanks in advance.
Martin
ps: by the way, this is a great lib !

see: https://sourceforge.net/p/assimp/bugs/110/

We need to fix this example.

Hi,

I've compiled assimp using the tutorial here:
http://jazzyjester.wordpress.com/2013/02/02/test

Actually with a little modification that I detailed on a comments of that article; but I can reproduce with the precompiled library of that guide too.

My code do something like this:

aiScene* currentScene = importer.GetOrphanedScene();

then later I have:
delete currentScene;

And I get this error:
/home/mastro/usr/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: ./obj/local/armeabi-v7a/objs-debug/FrameMarkers/assimp.o: in function DoTheSceneProcessing(aiScene*):jni/assimp.cpp:22: error: undefined reference to 'aiScene::~aiScene()'
collect2: ld returned 1 exit status

on delete currentScene;

Seems like the deconstructor aiScene::~aiScene is not linked in the libassimp.so library

Is this a bug?

Assimp from Github compiled without Boost (Mingw win7).

If I import a model (tested with .m5d and .dae) with aiProcess_PreTransformVertices (with or without aiProcess_TransformUVCoords) the UV are ok.

But if I don't use aiProcess_PreTransformVertices the UV are useless. I tried using aiProcess_TransformUVCoords without success.

I also tried to manually transform the UV, but I don't know how retrieve the aiUVTransform from the material...

LWSLoader.h:

std::list children;

This does not work on Xcode's compiler. It mentions that Element is an incomplete type.

This would be resolved if it used pointers instead - or some other standard this codebase has incorporated elsewhere.

For whatever reason my dev tools live under /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer, not /Developer/....

There are several hard-coded locations that cause this to fail.

Furthermore, there are sections of the script that assume that it is being run from port/iOS and the makefile assumes that it is running from the root directory (complete with hardcoded paths beginning with port/iOS) which also ensures that it will never succeed.

I've since given up on this script and have had success with the Xcode3 project in the workspace directory. Appreciate that being there.

Using any of the NDK flavors of gcc (4.4, 4.6 and 4.7) for Android, with both STLport and libstdc++, I get a crash in one of ParseTokenAsID or ParseTokenAsFloat during binary FBX import. Below is a typical crash dump.

I/DEBUG ( 124): signal 7 (SIGBUS), code 128 (?), fault addr 00000000
I/DEBUG ( 124): r0 5d59a4d8 r1 6200d7d0 r2 0000004c r3 624114fd
I/DEBUG ( 124): r4 5d5bcc38 r5 5d5b7640 r6 5d5b7678 r7 623263e8
I/DEBUG ( 124): r8 5d59a4d8 r9 623263f0 sl 00000000 fp 62326960
I/DEBUG ( 124): ip 0000004f sp 623262e8 lr 61f5176f pc 61f3a228 cpsr 00000030
I/DEBUG ( 124): d0 697463656e6e6f43 d1 636146656c616362
I/DEBUG ( 124): d2 5d59a4a85d59a46a d3 5d59a4d85d59a465
I/DEBUG ( 124): d4 5d59a3885d59a370 d5 5d59a3b85d59a3a0
I/DEBUG ( 124): d6 5d59a3e85d59a3d0 d7 5d59a4185d59a400
I/DEBUG ( 124): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 124): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 124): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 124): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 124): d16 415c9c3800000000 d17 7e37e43c8800759c
I/DEBUG ( 124): d18 0000000000000002 d19 0000000000000000
I/DEBUG ( 124): d20 0000000000000000 d21 00000000bca237c3
I/DEBUG ( 124): d22 3f800000bf7fffe0 d23 3f800000bf7aee42
I/DEBUG ( 124): d24 000000003b360b61 d25 0000000000000000
I/DEBUG ( 124): d26 bae72ae400000000 d27 0000000000000000
I/DEBUG ( 124): d28 0000000000000000 d29 00000000bca237c3
I/DEBUG ( 124): d30 3f800000bf7fffe0 d31 3f800000bf7aee42
I/DEBUG ( 124): scr 80000096
I/DEBUG ( 124):
I/DEBUG ( 124): backtrace:
I/DEBUG ( 124): #00 pc 0029e228 /data/app-lib//libassimp.so (Assimp::FBX::ParseTokenAsID(Assimp::FBX::Token const&)+139)
I/DEBUG ( 124): #1 pc 002b576b /data/app-lib//libassimp.so (Assimp::FBX::Document::ReadConnections()+194)
I/DEBUG ( 124):
I/DEBUG ( 124): stack:
I/DEBUG ( 124): 623262a8 00000002
I/DEBUG ( 124): 623262ac 61f90c7c /data/app-lib//libassimp.so (std::string::Rep::S_create(unsigned int, unsigned int, std::allocator const&)+100)
I/DEBUG ( 124): 623262b0 5d5bcc44
I/DEBUG ( 124): 623262b4 61f91b88 /data/app-lib//libassimp.so (char* std::string::S_construct<char const*>(char const, char const, std::allocator const&, std::forward_iterator_tag)+76)
I/DEBUG ( 124): 623262b8 00000000
I/DEBUG ( 124): 623262bc 623262f8
I/DEBUG ( 124): 623262c0 00000000
I/DEBUG ( 124): 623262c4 5d59a4a8
I/DEBUG ( 124): 623262c8 623263e8
I/DEBUG ( 124): 623262cc 61f91c20 /data/app-lib//libassimp.so (std::basic_string<char, std::char_traits, std::allocator >::basic_string(char const_, unsigned int, std::allocator const&)+28)
I/DEBUG ( 124): 623262d0 623262f8
I/DEBUG ( 124): 623262d4 61f3a0f5 /data/app-lib//libassimp.so (Assimp::FBX::ParseTokenAsString(Assimp::FBX::Token const&, char const&)+144)
I/DEBUG ( 124): 623262d8 c0000000
I/DEBUG ( 124): 623262dc 5d5bcc38
I/DEBUG ( 124): 623262e0 e3a070ad
I/DEBUG ( 124): 623262e4 ef9000ad
I/DEBUG ( 124): #00 623262e8 62326350
I/DEBUG ( 124): 623262ec 61f3a149 /data/app-lib//libassimp.so (Assimp::FBX::ParseTokenAsString(Assimp::FBX::Token const&)+32)
I/DEBUG ( 124): 623262f0 5d5bcc38
I/DEBUG ( 124): 623262f4 5d5b7640
I/DEBUG ( 124): 623262f8 5d5b7678
I/DEBUG ( 124): 623262fc 623263e
I/DEBUG ( 124): 62326300 623263ec
I/DEBUG ( 124): 62326304 623263f0
I/DEBUG ( 124): 62326308 00000000
I/DEBUG ( 124): 6232630c 61f5176f /data/app-lib//libassimp.so (Assimp::FBX::Document::ReadConnections()+198)
I/DEBUG ( 124): 62326310 00000008
I/DEBUG ( 124): 62326314 5d5b76a8
I/DEBUG ( 124): 62326318 00000000
I/DEBUG ( 124): 6232631c 00000000
I/DEBUG ( 124): 62326320 5d5b7e28
I/DEBUG ( 124): 62326324 62086adc

(reported by Jeremy Statz [email protected])

Test script:

import logging
logging.basicConfig(level=logging.DEBUG)
import pyassimp
in_filename = "plane.dae"
scene = pyassimp.load( in_filename )

Trace:

DEBUG:pyassimp:Try C:\android\projects\tools\pyassimp\assimp64.dll
DEBUG:pyassimp:Using assimp library located at C:\android\projects\tools\pyassimp\assimp64.dll
DEBUG:pyassimp:<pyassimp.structs.Scene object at 0x0000000004079548>: animations is an empty list.
DEBUG:pyassimp:<pyassimp.structs.Scene object at 0x0000000004079548>: cameras is an empty list.
DEBUG:pyassimp:Added flags as self.flags (type: <class 'int'>)
DEBUG:pyassimp:<pyassimp.structs.Scene object at 0x0000000004079548>: lights is an empty list.
DEBUG:pyassimp:<pyassimp.structs.Scene object at 0x0000000004079548>: Added list of <pyassimp.structs.LP_LP_Material object at 0x00000000040795C8> materials as self.materials (type: <class 'pyassimp.structs.LP_LP_Material'>)
DEBUG:pyassimp:Added numallocated as self.numallocated (type: <class 'int'>)
DEBUG:pyassimp:<pyassimp.structs.Scene object at 0x0000000004079548>: Added list of <pyassimp.structs.LP_LP_Mesh object at 0x0000000004079648> meshes as self.meshes (type: <class 'pyassimp.structs.LP_LP_Mesh'>)
DEBUG:pyassimp:Added bitangents as self.bitangents (type: <class 'pyassimp.structs.LP_Vector3D'>)
ERROR:pyassimp:In <pyassimp.structs.Scene object at 0x0000000004079548>->meshes: NULL pointer access. Quitting now.
Traceback (most recent call last):
  File "C:\android\projects\tools\test_assimp.py", line 23, in <module>
    scene = pyassimp.load( in_filename )
  File "C:\android\projects\tools\pyassimp\core.py", line 284, in load
    scene = model.contents._init()
  File "C:\android\projects\tools\pyassimp\core.py", line 170, in _init
    sys.exit(1)
SystemExit: 1

File plane.dae:
https://gist.github.com/severin-lemaignan/5485162

Hello !

I've found some problems with FBX format. I've just compiled newest source of Assimp and tried tons of fbx'es with differetn versions. Problems occure both in binary and ascii types of file :

Versions that doesn't work ( tested ):

• FBX60_MB60 (6.1.0)
• FBX200508_MB70 (6.1.0)
• FBX200602_MB75 (6.1.0)
• FBX200608 (6.1.0)
• FBX200611 (6.1.0)
• FBX200900 (6.1.0)

Version that works propertly :

• FBX2011.3.1+ (7.1.0)

Reason previous version doesn't work: declaration of ID for object.
assimp GetErrorString : FBX-DOM (TOK_KEY, line 2381, col 19) expected ID after object key

In version before 2011.3.1 file looks like :

---------------------------------
Model: "Model::Box01", "Mesh" {
    Version: 232
    Properties60:  {
---------------------------------   


and since 2011.3.1:

---------------------------------
Model: 483724560, "Model::Box01", "Mesh" {
    Version: 232
    Properties70:  {
---------------------------------

Its just a simple version check, but it will solve maaany problems :)

This project is becoming more and more important and interest is generally growing because it finally unfucks the whole 3D model situation a bit. As a result, I think releases should be made more often. The last release was over a year ago.

Many fixes have gone into assimp since then. Don't you think it's about time to make a new release and after that maybe make one every 2 months?

AssImp was throwing an exception when loading meshes because it thought that the binormal and tangent sections were missing. The following patch resolves this issue, this probably isn't the right place for this patch but I'm new to git hub and don't know the proper protocol for this type of thing. This is a patch for FBXMeshGeometry.cpp.

Putting the patch here doesn't seem to work very well becuase the patch gets interpreted as mark-up, let me know how best to submit this patch and I will.

@@ -467,7 +467,7 @@ void MeshGeometry::ReadVertexDataTangents(std::vector& tangents_out,
const std::string& ReferenceInformationType)
{
ResolveVertexDataArray(tangents_out,source,MappingInformationType,ReferenceInformationType,

•   "Tangent",
  

•   "Tangents",
  "TangentIndex",
  vertices.size(),
  mapping_counts,
  

  @@ -482,7 +482,7 @@ void MeshGeometry::ReadVertexDataBinormals(std::vector& binormals_ou
  const std::string& ReferenceInformationType)
  {
  ResolveVertexDataArray(binormals_out,source,MappingInformationType,ReferenceInformationType,

•   "Binormal",
  

•   "Binormals",
  "BinormalIndex",
  vertices.size(),
  mapping_counts,
  

Hi.
assimp is great library!

I made test program with VS2012 on Windows8.
I set Debug build option ''/Ob2"
I start program with Debug.

Error:
Run-Time Check Failure #2 - Stack around the variable 'res' was corrupted.

or

Error:
Run-Time Check Failure #2 - Stack around the variable 'it' was corrupted.

What's happen?

https://www.dropbox.com/s/ss9ktt7k2ar7mft/assimp_sample.zip

zlib-1.2.8/zlib.sln
assimp/assimp.sln
assimp_sample/assimp_sample.sln

Thank you.

http://stackoverflow.com/questions/17895776/cant-export-models-with-assimp-by-using-exporter-class

i am using assimp libary to load models to my ios app. but for some large model files loading times are too long for an mobil app.

considering the convert process time. i decided to convert my models by a tool before run time.

my main goal is writing this scene to file.

i have very basic c++ experience. First i tried assimp::expoerter class.

i complied assimp libary with export settings on.

But when i try to use export method i am getting this error message.

No matching member function for call to 'Export'
error capture

method is there but i can't use it.

scene = (aiScene*) aiImportFile([[openPanel filename] cStringUsingEncoding:[NSString defaultCStringEncoding]], aiPostProccesFlags | aiProcess_Triangulate | aiProcess_FlipUVs | aiProcess_PreTransformVertices | 0 );

if (scene) {

    NSString *pPath = [openPanel filename];
    pPath =[NSString stringWithFormat:@"%@%@", pPath, @"_new"];
    NSLog(@"New file Path : %@", pPath);

    Assimp::Exporter *exporter = new Assimp::Exporter();
    exportFormatDesc = exporter->GetExportFormatDescription(0);

    exporter->Export(scene, exportFormatDesc->id, pPath);

    const aiExportDataBlob *blob = exporter->ExportToBlob(scene, exportFormatDesc->id);
    size_t blobSize = blob->size;
    aiString blobName = blob->name;

}

then by reading Assimp::Exporter Class Reference gives me the idea of using aiExportDataBlob to create file.

"ExportToBlob which returns a linked list of memory buffers (blob), each referring to one output file (in most cases there will be only one output file of course, but this extra complexity is needed since Assimp aims at supporting a wide range of file formats).

ExportToBlob is especially useful if you intend to work with the data in-memory."

const aiExportDataBlob *blob = exporter->ExportToBlob(scene, exportFormatDesc->id);
size_t blobSize = blob->size;
aiString blobName = blob->name;

But i have no idea to write this blob to a file.

Any advice or help appreciated.

Clor are not taken into account
when using :
#13107= IFCPROPERTYSET('3JggUyNavBNPl9m7W9mkch',#1426,'Pset_Draughting','Colour (RGB): (0,0,255), 0361 DuctWork',(#13112,#13129));

or
#19=IFCPROPERTYSINGLEVALUE('Red',$,IFCINTEGER(255),$);
#20=IFCPROPERTYSINGLEVALUE('Green',$,IFCINTEGER(255),$);
#21=IFCPROPERTYSINGLEVALUE('Blue',$,IFCINTEGER(255),$);
#22=IFCCOMPLEXPROPERTY('Color',$,'Color',(#19,#20,#21));

see: https://sourceforge.net/p/assimp/bugs/119/

Assimp tends to use std::vector<>s and other containers with size_t sizes internally, and size_t seems to closely match the platform's limits on 32-bit and 64-bit platforms. Storing size_t variables in member variables like aiScene's mNumMeshes is one of the major sources for compiler warnings in the codebase.

Can you consider moving the mNum* member variables to size_t? In addition to the potential future-proofing for really large data sets possible on 64-bit systems a lot of potential conversion-related bugs and corresponding compiler warnings can be removed.

I wouldn't mind doing the majority of the work, but I need to make sure it would potentially be accepted into the mainline branch before I proceed.

When I was importing .md5mesh and .md5anim files that share the same name ( "test2.md5mesh" and "test2.md5anim"), bone nodes weren't being add to Scene graph. Walking through 'scene->mRootNode' childrens yielded following list:

• <MD5_Root>
• <MD5_Mesh>
• <MD5_Hierarchy>
  I can assume that bones should be childrens of the '<MD5_Hierarchy>' node ( at least when importing Collada .dae file they were).
  I've fixed the problem by adding following lines ( between '//@@@@@@@@@@@@' markers):

// If we didn't build the hierarchy yet (== we didn't load a MD5MESH),
// construct it now from the data given in the MD5ANIM.
if (!pScene->mRootNode) {
pScene->mRootNode = new aiNode();
pScene->mRootNode->mName.Set("<MD5_Hierarchy>");
AttachChilds_Anim(-1,pScene->mRootNode,animParser.mAnimatedBones,(const aiNodeAnim**)anim->mChannels);
// Call SkeletonMeshBuilder to construct a mesh to represent the shape
if (pScene->mRootNode->mNumChildren) {
SkeletonMeshBuilder skeleton_maker(pScene,pScene->mRootNode->mChildren[0]);
}
}
// here ends original Assimp code, following lines are my fix:
//@@@@@@@@@@@@
else{
std::cout << "NODE EXIST !!!!!!! Custom add nodes";
aiNode* root = pScene->mRootNode, hierarchy = NULL;
for( int i = 0; i < root->mNumChildren ; i++){
std::string name( root->mChildren[i]->mName.data);
if( name.compare("<MD5_Hierarchy>") == 0 ){
hierarchy = root->mChildren[i];
break;
}
}
if( hierarchy==NULL){
// not found
hierarchy = new aiNode();
hierarchy->mName.Set("<MD5_Hierarchy>");
root->mChildren[ root->mNumChildren] = hierarchy;
root->mNumChildren += 1;
}
AttachChilds_Anim( -1, hierarchy, animParser.mAnimatedBones, (const aiNodeAnim*)anim->mChannels);
std::cout << "NODE EXIST !!!!!!! Custom add nodes EEEENDDDDD";
}
//@@@@@@@@@@@@
FILE: MD5Loader.cpp
FIX_LINE_NUMBER: 670
Probable cause: when loading the mesh, the '<MD5_Root>' node is being created, causing the 'if (!pScene->mRootNode) {' to fail when loading animation.
Compiler: VC++ 10
MD5 Exporter: Blender unofficial plugin ( I've double checked - file was 100% correct)
Assimp version: 3.0.1270
cmake version: 2.8.10.2

Currently aiVector3D stores its data as {float x,y,z;}. This is a little bit inconvenient, but acceptable. However, aiMatrix4x4 is stored as { float a1,a2,a3,a4,b1,b2,b3,b4,c1,c2,c3,c4,d1,d2,d3,d4;}, which is just ridiculous...

Please, please, please make that a float[3] and a float[4_4] and instead provide an indexing macro like #define AI_M4X4(m,i,j) (m[(i)_4+(j)]), because it leads to insane code like devurandom/lua-assimp@e2d2194.

I'm trying to automate some lib dependency builds for a project and was hoping I could do the following to specify a 32 bit build on OSX:

cmake -G 'Unix Makefiles' -DASSIMP_BUILD_ARCHITECTURE=i386

However, this results in a 64 bit build.

If I set ASSIMP_BUILD_ARCHITECTURE manually in CMakeLists.txt, I can get a 32 bit build (line 135):

SET ( ASSIMP_BUILD_ARCHITECTURE "i386" CACHE STRING 
"describe the current architecture."
)

Am I just "doing it wrong" or is this an issue of overwriting the user var?

What steps will reproduce the problem?
assimp/code/DefaultIOSystem.cpp: In function ‘void MakeAbsolutePath(const char_, char_)’:
/assimp/code/DefaultIOSystem.cpp:136:8: error: ‘::_fullpath’ has not been declared
/assimp/code/DefaultIOSystem.o] Error 1
What is the expected output? build success
What do you see instead? build error
Assimp was building perfectly with previous version of Assimp. Perhaps a IFDEF CYGWIN could resolve the issue

see: https://sourceforge.net/p/assimp/bugs/111/

There doesn't seem to be built-in support for custom allocators in assimp. Is there any existing infrastructure, future plan or interest in doing so? I could work on that in a branch but I'd like to have a roadmap for inclusion in mainline laid out first.

Assimp fails to compile for me on Win7 with VS 2011 using CMake and the Boost-Workaround with the following errors.

3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2039: 'plus' : is not a member of 'std'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2065: 'plus' : undeclared identifier
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2974: 'Assimp::Vertex::BinaryOp' : invalid template argument for 'op', type expected
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(235) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(215) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(195) : see declaration of 'Assimp::Vertex::BinaryOp'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2039: 'minus' : is not a member of 'std'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2065: 'minus' : undeclared identifier
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2974: 'Assimp::Vertex::BinaryOp' : invalid template argument for 'op', type expected
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(235) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(215) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(195) : see declaration of 'Assimp::Vertex::BinaryOp'
3> LWOAnimation.cpp
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(159): error C2039: 'bind1st' : is not a member of 'std'
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(159): error C2039: 'greater' : is not a member of 'std'
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(159): error C2065: 'greater' : undeclared identifier
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(159): error C2062: type 'double' unexpected
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(159): error C3861: 'bind1st': identifier not found
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(177): error C2065: 'm' : undeclared identifier
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(178): error C2065: 'm' : undeclared identifier
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(181): error C2065: 'm' : undeclared identifier
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(189): error C2065: 'm' : undeclared identifier
3>C:\Users\kiepmad\Documents\shader_programming\src\lib\assimp\code\LWOAnimation.cpp(190): error C2065: 'm' : undeclared identifier

3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2039: 'plus' : is not a member of 'std'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2065: 'plus' : undeclared identifier
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(267): error C2974: 'Assimp::Vertex::BinaryOp' : invalid template argument for 'op', type expected
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(235) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(215) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(195) : see declaration of 'Assimp::Vertex::BinaryOp'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2039: 'minus' : is not a member of 'std'
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2065: 'minus' : undeclared identifier
3>c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(271): error C2974: 'Assimp::Vertex::BinaryOp' : invalid template argument for 'op', type expected
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(235) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(215) : see declaration of 'Assimp::Vertex::BinaryOp'
3> c:\users\kiepmad\documents\shader_programming\src\lib\assimp\code\Vertex.h(195) : see declaration of 'Assimp::Vertex::BinaryOp'

Adding #include to both Vertex.h and LWOAnimation.cpp fixes the compile issue.

Originally filed here with attached fbx file: http://sourceforge.net/p/assimp/bugs/126/

I exported the attached fbx from blender. It opens successfully in the AutoDesk QT viewer and a few other 3D viewers I found on Google. Both assimp and assimp viewer fail to read it, and neither prints why it fails. I stepped through it and it looks like we're failing in FBXDocument.cpp:

// id=0 is normally implicit
if(id == 0L) {
    DOMError(\"encountered object with implicitly defined id 0\",el.second);
}

I'm not familiar with the format, so I'm not sure what this means.

Just what it says on the can. See Collada Spec 1.4 page 48. A sample file can be found at https://dl.dropboxusercontent.com/u/24735880/TurbochiFromXSI.dae .

I exported the attached fbx from blender. It opens successfully in the AutoDesk QT viewer and a few other 3D viewers I found on Google. Both assimp and assimp viewer fail to read it, and neither prints why it fails. I stepped through it and it looks like we're failing in FBXDocument.cpp:
// id=0 is normally implicit
if(id == 0L) {
DOMError("encountered object with implicitly defined id 0",el.second);
}
I'm not familiar with the format, so I'm not sure what this means.

There are lots of compilation warnings when compiled with GCC 4.7 with -Wall -pedantic. Examples:

• A lot of warnings about unused parameters
• BlenderScene.cpp:62:44: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
• tuple.hpp:145:3: warning: extra ‘;’
• IFCLoader.cpp:553:26: warning: ‘auto_ptr’ is deprecated (declared at /usr/include/c++/4.7/backward/auto_ptr.h:87)
• IFCGeometry.cpp:175:6: warning: ‘best_ofs’ may be used uninitialized in this function
• XGLLoader.cpp:404:39: warning: comparison between signed and unsigned integer expressions
• unzip.c:1177:24: warning: assignment from incompatible pointer type
• shapes.cc:122:10: warning: variable ‘x’ set but not used

When building assimp we get the following error on Mac OSX 10.8.
Linking CXX shared library ../lib/libassimp.dylib
ld: malformed 64-bit a.b.c.d.e version number: 3.0.1264
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Changing the SV revision number in the build script from 1264 to 255 solves the problem.

see: https://sourceforge.net/p/assimp/bugs/112/

mesh name(pSphereShape1) and its transformation name(pSphere1) are different so assimp is crash.

crash:
aiMatrix4x4 m = scene->mRootNode->FindNode(scene->mMeshes[index]->mName)->mTransformation;

so we must change all transformation name in maya...

Can I just hide it so it doesn't appear? I've mistakenly applied it a few times and it obviously does nothing useful.

A switch between ASCII or binary mode is made if we found the word "solid" on the first 5 caracters ..
In a binary file the header can began by solid and if we switch to ASCII we cannot read the file

see: https://sourceforge.net/p/assimp/bugs/118/

The FBX loader doesn't seem to detect the presence of embedded textures in FBX files.

It looks like non assigned fields in an mtl file, such as "map_Kd ", lead to "String too long" error.
Enclosed is an obj+mtl sample demonstrating the issue.

see: https://sourceforge.net/p/assimp/bugs/124/

Either a triangulation bug, or triangulation is never called because the POLYGON mesh flag is not set.