I am using osgmaxexp for large databases, I noticed some problems with wrong textures attached in wrong places of database. It is easy to check, try to export the same model few times, than compare exported files. I can see differences each time I export file. I debug sources and I think I found the problem, in method MtlKeeper::createTexture2D _bmpList map is searched for cached osg::Texture. Here we have wrong mapping - I think using pointer as map key is bad idea, although I am not 3DS Max expert so it would be great if some other developer could confirm that.
That's strange. A new instance of the MtlKeeper class should be created for each export. Can you try adding some debugging code that checks whether MtlKeeper ::_bmpList is empty at the beginning of the OSGExp::DoExport method? Which version of 3ds Max are you running?
I just checked that, MtlKeeper ::_bmpList map is empty each time we enter OSGExp::DoExport.
My max version is 12.
Here is what I did to find the problem, I just wrote some output to log file to check if name of searched Bitmap is the same as osg::Texture we found in map. In few cases name of the file was different.
I presume BitmapWrapPair::Bitmap* pointing 3D Max allocated memory, is it ? If so than how can we be sure that 3DS Max won't reallocate that ? I just made some hack to avoid the problem and it works for now but I think it is not a good solution. Let me know if you need some more debugging, I'll do my best to help.
I'm not sure what would cause Max to change the contents of a Bitmap pointer in the middle of an export process. Do you have a simple model that recreates this?
Either way, I don't think caching textures based on bitmap pointers is even needed anymore. I've since added a caching mechanism that is based on the original filename, so the bmp cache is most likely redundant. I'll perform some tests on my models here and remove the bmp cache if I find that it's not necessary.
Unfortunately I can't send you any of those files because it is property of company I am work for :(, sorry, but the problem seems to be quite easy to recreate. Model I used to catch the problem is 10MB large and it uses 300 textures, if you have any similar maybe you could do some output and check if problem appear.