1) I have been investigating a bit around the problem i had posted in (Opinions/Bugs/Suggestions) topic and i have found that there is no support for .dae models that have some submeshes with texture coords and some others without texture coords.
I have solved that inserting the following code just after the BOOST_FOREACH calls near line 1976:
<code>
// In case any previous mesh had tex coords we will provide fake texture coordinates from now and on.
if ( pMesh->mPositions.size() != pMesh->mTexCoords[0].size() )
pMesh->mTexCoords[0].insert( pMesh->mTexCoords[0].end(), aiVector3D(0.f) );
Anyway, this is just a workaround to get these models working, but it would be preferrably to have separate sub-meshes or just to pass some extra information in the SubMesh struct.
2) On the other hand, there is another problem that has arisen when trying to load a bit more complex model. It seems that some of the matrices applied to some instances are not correct.
Thanks. I'll investigate the problems. Not sure about the mixed textured/non-textured models, though. I was quite angry back when I wrote the corresponding part for some reason... But well - I was angry most of the time I had to deal with the Collada loader, because the Collada specification is two steps short of turing completeness and an over-engineered mess of indirections.
I'll check. Thanks for pointing out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i have been looking around a bit more to be able to load these models and i would like to share some of my thoughts about:
I have tried a couple of models coming from http://sketchup.google.com/3dwarehouse/ and seem that they usually only have texture coordinates for the meshes that will be used with textured materials. They also tend to use instanced nodes that assimp's Collada parser doesn't handle correctly. I think i have found possible solutions (although i don't know if that could have indirect implications in others parts of the loader, but i wonder they don't).
2) There is a bug in ColladaParser.cpp that excludes some nodes from the <library_nodes> tag. I solved that (not sure if that implies anything else...) with the following change:
The original code makes the first node in <library_nodes> tag the parent of the following nodes and that is not correct for the models i have tested. With original code only the first node was inserted in mNodeLibrary and so later use with instances couldn't find the node and so it was not resolved.
Hope it can help you a bit. If you need some models to test i can send you by mail or so, just contact me :)
Oh..I have posted the same qüestion on "bug tracker", "opinions, bugs and suggestions" topic and here...i am sorry for being so redundant but it didn't know where to post them..so..
Thanks for your work Thomas,
Marcos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Half of your bug report - the mixed textured/non-textured meshes - should be fixed now. I left the corresponding entry in the bugtracker open, though, because I still haven't found a cure for the second half, concerning the transformations. The instance_node bug is investigated at the moment as well. You did help a lot with this fix proposal, thank you very much for that! But we have to check it against our library of test models before actually calling it a "fix" :-)
Bye, Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tested some model coming from the FCOLLADA exporter for 3DS Max and it seems to have different names for tangents and binormals:
TEXTANGENTS for tangents
TEXBINORMALS for binormals
It is easy to rename them on the .dae but..maybe you want to give some feedback or simply add an alias for tangents and binormals. Not sure if that should be considered a valid Collada model :)
Marcos.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have temporarily (it seems to work for me until assimp guys find a full patch and/or test this change for correctness) "resolved" the problem of instances with the following change:
<2) There is a bug that excludes some nodes from the <library_nodes> tag. I
<solved that (not sure if that implies anything else...) with the following
<change in colladaParser.cpp:
I have tried that change, but it seems my problem might be somewhere else. Actually, most of the Collada files I have tried (from Google Warehouse) don't import correctly. Some faces are missing or some pieces are at different places...
While all the other file formats I have tried work perfectly...
It might be that this format would need some further tests.
Anyway, thanks for all your great work !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I have been investigating a bit around the problem i had posted in (Opinions/Bugs/Suggestions) topic and i have found that there is no support for .dae models that have some submeshes with texture coords and some others without texture coords.
I have solved that inserting the following code just after the BOOST_FOREACH calls near line 1976:
<code>
// In case any previous mesh had tex coords we will provide fake texture coordinates from now and on.
if ( pMesh->mPositions.size() != pMesh->mTexCoords[0].size() )
pMesh->mTexCoords[0].insert( pMesh->mTexCoords[0].end(), aiVector3D(0.f) );
if ( !pMesh->mTexCoords[0].empty() && pMesh->mPositions.size() != pMesh->mTexCoords[0].size() )
{
std::vector<aiVector3D> fakeTexCoords( pMesh->mPositions.size() - pMesh->mTexCoords[0].size(), aiVector3D(0.) );
pMesh->mTexCoords[0].insert( pMesh->mTexCoords[0].begin(), fakeTexCoords.begin(), fakeTexCoords.end() );
}
</code>
Anyway, this is just a workaround to get these models working, but it would be preferrably to have separate sub-meshes or just to pass some extra information in the SubMesh struct.
This is a simple model that exposes the texture coordinates problem mentioned above:
http://sketchup.google.com/3dwarehouse/details?mid=a05042f57365ba647286f8e497b4d32c&prevstart=0
2) On the other hand, there is another problem that has arisen when trying to load a bit more complex model. It seems that some of the matrices applied to some instances are not correct.
This model represents Saint Basil's Cathedral and it shows local transformation errors in some of its towers.
http://sketchup.google.com/3dwarehouse/details?mid=c5fa9fa9f209780aaa261f49f4209a7d&prevstart=0
Thanx,
Marcos.
Thanks. I'll investigate the problems. Not sure about the mixed textured/non-textured models, though. I was quite angry back when I wrote the corresponding part for some reason... But well - I was angry most of the time I had to deal with the Collada loader, because the Collada specification is two steps short of turing completeness and an over-engineered mess of indirections.
I'll check. Thanks for pointing out.
Hello again,
i have been looking around a bit more to be able to load these models and i would like to share some of my thoughts about:
I have tried a couple of models coming from http://sketchup.google.com/3dwarehouse/ and seem that they usually only have texture coordinates for the meshes that will be used with textured materials. They also tend to use instanced nodes that assimp's Collada parser doesn't handle correctly. I think i have found possible solutions (although i don't know if that could have indirect implications in others parts of the loader, but i wonder they don't).
2) There is a bug in ColladaParser.cpp that excludes some nodes from the <library_nodes> tag. I solved that (not sure if that implies anything else...) with the following change:
ORIGINAL CODE: mNodeLibrary[child->mID] = pNode = child;
MODIFIED CODE: mNodeLibrary[child->mID] = child;
The original code makes the first node in <library_nodes> tag the parent of the following nodes and that is not correct for the models i have tested. With original code only the first node was inserted in mNodeLibrary and so later use with instances couldn't find the node and so it was not resolved.
Hope it can help you a bit. If you need some models to test i can send you by mail or so, just contact me :)
Oh..I have posted the same qüestion on "bug tracker", "opinions, bugs and suggestions" topic and here...i am sorry for being so redundant but it didn't know where to post them..so..
Thanks for your work Thomas,
Marcos
Half of your bug report - the mixed textured/non-textured meshes - should be fixed now. I left the corresponding entry in the bugtracker open, though, because I still haven't found a cure for the second half, concerning the transformations. The instance_node bug is investigated at the moment as well. You did help a lot with this fix proposal, thank you very much for that! But we have to check it against our library of test models before actually calling it a "fix" :-)
Bye, Thomas
It's good to be able to give back something :) for your great job guys.
I have tested new version with most of my test models and texture problems seem to have been fixed.
Thanks,
Marcos.
I have tested some model coming from the FCOLLADA exporter for 3DS Max and it seems to have different names for tangents and binormals:
TEXTANGENTS for tangents
TEXBINORMALS for binormals
It is easy to rename them on the .dae but..maybe you want to give some feedback or simply add an alias for tangents and binormals. Not sure if that should be considered a valid Collada model :)
Marcos.
I have noticed the same issue (the second one).
Have you had any chance to have a look at it and fix it ?
Cheers,
Gregory
I have temporarily (it seems to work for me until assimp guys find a full patch and/or test this change for correctness) "resolved" the problem of instances with the following change:
<2) There is a bug that excludes some nodes from the <library_nodes> tag. I
<solved that (not sure if that implies anything else...) with the following
<change in colladaParser.cpp:
<ORIGINAL CODE: mNodeLibrary[child->mID] = pNode = child;
<MODIFIED CODE: mNodeLibrary[child->mID] = child;
Hope it works for you too,
Marcos.
I have tried that change, but it seems my problem might be somewhere else. Actually, most of the Collada files I have tried (from Google Warehouse) don't import correctly. Some faces are missing or some pieces are at different places...
While all the other file formats I have tried work perfectly...
It might be that this format would need some further tests.
Anyway, thanks for all your great work !