Three.js: ColladaLoader fails with objects containing mixture of textured and non-textured materials

[peterderivaz]

STEPS TO REPRODUCE

1) Launch Google sketchup
2) Draw rectangle
3) Texture just the top surface
4) Export as DAE
5) Load into three.js editor (drag file to http://mrdoob.github.io/three.js/editor/)

The object is not displayed and firebug stops on an error:

WebGL: DrawElements: bound vertex attribute buffers do not have sufficient size for given indices from the bound element array

Line 450

DEBUGGING

The problem may be related to the UV coordinates.

In SetMeshBuffers there is the code:

if ( dirtyUvs && obj_uvs && uvType ) {
        for ( f = 0, fl = chunk_faces3.length; f < fl; f ++ ) {
            fi = chunk_faces3[ f ];
            uv = obj_uvs[ fi ];
            if ( uv === undefined ) continue;

The code spots that obj_uvs is an array with 2 entries, but fi is the number 2, so accesses the array out of bounds and the uv==undefined condition is triggered.

I suspect the problem is actually in ColladaLoader. My suspicion is that faceVertexUvs are only written for faces using a textured material and so the obj_uvs array is too short but I can't quite understand the details.

WORKAROUND

Using textures for all sides of a model fixes the problem.

[peterderivaz]

Here is an example of a failing file.

https://gist.github.com/peterderivaz/6327140

[crobi]

I think you're right - it's a problem with ColladaLoader.

In function Mesh.prototype.handlePrimitive, the loader collects all texture coordinate channels in the variable ts, and then writes this data to geom.faceVertexUvs.

However, the above procedure is called for each primitive set independently and does not consider that different primitive sets within a single mesh can contain a different number of texture coordinate sets.

If anyone wants to fix this: our alternative collada loader solves this by filling up the missing UV coordinates with zeros whenever a new primitive set has a different number of texture coordinates (see here). This loader does not support non-triangle geometries however, so you won't be able to use it for your file as is.

[mrdoob]

Yup. I can reproduce this. Hopefully some kind soul will take a stab at it.

[mrdoob]

Seems like the file loads with the current version of ColladaLoader.

Not sure if it looks as it should though.

/ping @Mugen87

[Mugen87]

I'll have a look.

@peterderivaz I know this is an old issue but can you please provide the corresponding texture house3/Carpet_Berber_Multi.jpg? :innocent:

[Mugen87]

The current version of ColladaLoader does not parse the file correctly. It is able to setup the multiple materials and the respective groups of the buffer geometry but it can handle the definition of uv coordinates of the dae file.

That's the problematic section:

<polylist count="1" material="Material2">
     <input offset="0" semantic="VERTEX" source="#ID7" />
     <vcount>4</vcount>
     <p>0 1 2 3</p>
</polylist>
<polylist count="1" material="Material3">
     <input offset="0" semantic="VERTEX" source="#ID7" />
     <input offset="1" semantic="TEXCOORD" source="#ID13" />
     <vcount>4</vcount>
     <p>4 0 5 1 6 2 7 3</p>
</polylist>

Each polylist results in a group with the respective material index. The first polylist has no uv-coordinate (TEXCOORD) definition. But the second one. And that's the problem. As @crobi suggested, we need to fill default values to the uv buffer for the first polylist.

@mrdoob Unfortunately, it looks like we need a more comprehensive refactoring to enable this feature. I'll try to code something so we can better see the scope of this change.

[peterderivaz]

As requested, the carpet jpg

[Mugen87]

Thx! Looks like the PR fixes the problem. The texture is displayed without any warnings.