Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I was looking in the forum for a topic concerning how geometry instancing was managed with Assimp. I'm loading preminently collada files and I need to manage the case in which for example I have many trees. In that case I would expect for assimp to load just one mesh for a tree and have the possibility to have the number of instances that I can use in turn to load the right world matrix to draw each instance of that tree.
Is there any way to manage this in some way ?
Meshes can be referenced multiple times (i.e. more than node can specify a specific mesh index). Since the actual location of the mesh is specified in the node, this is very similar to instancing.
Of course this will only work if your Collada exporter does a decent job and does not duplicate the meshes in the first place … in this case, the aiProcess_FindInstances postprocessing step might be helpful .. looks for identical meshes and replaces them by references to a single mesh.
Instancing in Assimp is naturally handled by the mesh indices of each node. A node tells which geometries to show in its local coordinate system by the aiNode::mMeshes array. If multiple nodes name the same mesh index in there mesh array, that means that the corresponding mesh is instanced multiple times.
The problem is that the Exporters also need to support instancing. Some exporters generate a separate mesh entry for each and every instance. You can use Assimp's FindInstances post processing step to detect such cases. But beware: the geometry needs to be exactly the same to replace it by an instance. If you use light mapping, for example, the second UV channel will most probably differ. If the exporter did some coordinate transformations on the mesh, rounding errors will most likely fend off the detection.
Thanks I will do some tests to verify on that
Is there any plan to support instancing when the same geometry is used with different materials?
Something like a Node points to a Mesh and a Mesh points to a Material and a Geometry.
Yes, there are "plans". We discussed this topic to death internally :-) From today's point of view, binding the material to the mesh was a mistake. It's better to store the material instance with the instance, in the node. But we can't change that the simple way because it would break all existing code and bindings to other languages.
And it would require some changes in each and every loader, so currently noone found enough spare time to do it.
Hi Thomas, It's great to know that you have this in mind. I discovered this when I saw that in my rendering engine I had the same mistake because I based some design dessisions depending on the Assimp design.
If I wasn't too busy finishing the PhD I would offer some help with this library. You are doing a really great job and for the moment it's the best loader that I've ever seen.