Multi-textured files broken.

[GoogleCodeExporter]

1. Attempt to load a 3ds file with multiple meshes, each with their own texture.
(There seems to be a similar, but not identical issue with OBJ files.)

Result : None of the textures render properly.  They all show up completely 
un-textured. 

It looks like the code is _supposed_ to work with this sort of thing, but I 
can't quite make myself understand how it's keeping track of textures.

Probably a simple fix, but I can't for the life of me figure out why it's not 
working. 

For the moment, a usable work-around seems to be to split the file into a bunch 
of smaller 3ds files. This will get tedious, but so far it works.

Any help would be appreciated, thanks.

Original issue reported on code.google.com by Andrew.L...@gmail.com on 4 Jun 2011 at 7:08

[GoogleCodeExporter]

I was having similar problems.  After digging around for a while, I think I've 
diagnosed the issue, but the fix seems to be pretty far-reaching.

It seems to me the heart of the problem is a misunderstanding in the Min3d code 
of how OpenGL handles multiple textures.  In Renderer.drawObject_textures(), it 
attempts to iterate through multiple textures using 
RenderCaps.maxTextureUnits()... but that's not where multiple textures are 
stored-- that's where multiple _simultaneous_ textures can be stored (on 
Android, the limit is 2).  Because of that, it basically only ever uses a 
single texture for any Object3d.

That's not always obvious, because of a neat trick in Min3d- the texture atlas. 
 It looks like what that does is combine all your textures into a single large 
bitmap, adjusting your texture coordinates to compensate.  That's a neat trick 
which probably accomplishes some optimization, and covers up the bug in the 
renderer.

...Unless you need to use repeating textures, with texture coordinates < 0 or > 
1.  In that case, it doesn't map those coordinates correctly in the texture 
atlas, and it can end up repeating the full, generated bitmap (all your 
textures) across the surface instead of just the one you want.

This _sounds_ like a different problem that what you're seeing, but I suspect 
it's related.

The fix, as far as I can tell, it pretty complicated.  For one thing, each 
object (ie group of faces) needs to have only a single texture, not a list.  
And the parsers need to build up ParseObjectData items that correspond to a 
list of faces per texture/material.  This has a pretty big impact on the data 
structures currently in use, as well as the parsing algorithms.

Despite this bug, Min3d has helped me tremendously.  I'd like to take a stab at 
contributing a fix, but it seems like it might be too sweeping, and might be 
something a core developer would want to take a look at.

Original comment by perplexi...@gmail.com on 11 Jun 2011 at 8:22

[GoogleCodeExporter]

I may been able to work around this bug by simply exporting a new OBJ for every 
new texture that is used and going through the loading methods for each OBJ.    
It has worked for two textures for me so far... to simplify the number of 
textures required I have exported UV map layouts and filled them in.

Original comment by erek.and...@gmail.com on 1 Nov 2011 at 1:23