Backing up a bit, I was incorrect on the "offset" in the
array, so thanks for clearing this up for me. I was getting it confused with the "offset" in the accessor. We have been using an exporter that produces unified indices and had completely missed non-unified!
Oh i'm stuck with this duck(http://www.collada.org/owl/browse.ph...0&sortname=ASC)
Vertices and normals play well, but not textures.
I checked, texture is not corrupted.
Here is how i create trianles, normals and texcoords(nvm cocoa :P):
DAEModelTexCoordsReconstructed is mutable array there texture coordinates are stored
A lot of stuff is hardcoded, it's because i'm just trying it out.
Please point out if You can see some fundamental mistake.
Big thanks for earlier help.
I can't find anything obviously wrong with your code. One thing that might help is to make a test model with a single textured triangle and manually inspect all the texture coordinates before you send them to OpenGL.
I'll ask if somebody could write a small app to render duck.
It i find what was wrong i'll inform about that.
The number of vertex is always bigger or equal than the number of any other attribute stream right?
It is OK, 8 positions and 6 normals, but our guy have 8 positions and 12 normals. And I don`t understand what does you explain? Could you write a simple pseudo code about convertation? And when I use indecies , I also need just 8 positions and 6 normals for a cube (not 24 positions and 24 normals).
Originally Posted by sthomas
Re: please clarify <triangles> and <p>
A cube has eight unique positions and six face normals where each face is a quad. Each position belongs to three faces making a total of 24 unique vertices (8 positions x 3 face normals). If your data has more then six unique normals then at least one of the faces is not a flat (shaded) quad.
Since you have 12 normals it might be a low resolution sphere as the number implies there are two normals per face.