mesh loaders into vbo formats...

[ninogenio]

this is a little post too share what i have learned up too this point.

all my troubles came in when trying too format an obj file into a glsl vbo format reason being typical wavefront obj files have three index buffers..

1 for vertex buffer indexing
2 for uv coord buffer indexing
3 for normal buffer indexing

big problem being that glsl only accepts a single element_array buffer.. i then started too scratch my head and thought fml this is never going too work 

however.. i found.

http://www.nvidia.com/object/nvtristrip_library.html

and this..

https://github.com/OpenGLInsights/OpenGLInsightsCode/tree/master/Chapter%2026%20Indexing%20Multiple%20Vertex%20Arrays/article..

using the lib and reading the code from the other link. i was able too rejig my vertex normal uv and index buffer in such a way that my single index buffer indexes all other buffers correctly.

the nvstrip lib also lets me interleave all my buffers into a single buffer or optimize my meshes for quite a speed boost. ill post a little example of the lib in action very soon.. ive also managed too parse the mtl and dynamically load associated textures.. then load multiple meshes from single obj file into different vbo's and skin them with the correct textures from the mtl file..

[ninogenio]

right here we go guys heres a little example of loading obj mesh files into vbo's based on info from above links..

this example loads each obj and mtl file parses them loads the textures for each models body part then splits the models up into how ever many meshes is required, fixes the faces of each mesh/part creates an new index buffer for each mesh/part then vbo's them and finally renders them and skins them..

the good thing is i load the models into vbo's a body part at a time so later i should be able too fully animate them, maybe using a little bit of lua scripting or something too map the transitions.

you wouldn't begin too imagine how hard i found this but it was well worth the effort.

[hellfire]

typical wavefront obj files have three index buffers..
big problem being that glsl only accepts a single element_array buffer

There's nothing wrong with using the tristrip lib, but for the .obj to vbo conversion you just need to remap from <int,int,int> to <int>, like this:

Code: [Select]

struct Vector3d { float x,y,z; }
struct UV { float u,v; }
struct VertexIndices { int pos, nrm, uv; }
struct Triangle { VertexIndices vtx[3]; }

// the original data using 3 individual indices per triangle
vector<Vector3d> vertices;
vector<Vector3d> normals;
vector<UV> texcoords;
vector<Triangle> triangles;

// resulting data with interleaved vertex-data and unique indices
struct Vertex { Vector pos; Vector nrm; UV uv; }
vector<int> indexBuffer;
vector<Vertex> vertexBuffer;

map<VertexIndices, int> indexMap;

// loop through all 3 vertices of each triangle
foreach (const Triangle& triangle, triangles) {
   for (int tri=0; tri<3; tri++)  {
   {
      const VertexIndices& vtxIndex= triangle[tri];
      int index= -1;
     
      if ( indexMap.contains( vtxIndex ) ) {
         // if this <int,int,int> already has an index: use it
         index= indexMap[ vtxIndex ];
      }
      else {
         // ...otherwise add new vertex and index
         index= vertexBuffer.size();
         vertexBuffer.append(
            Vertex(
               vertices[vtxIndex.pos],
               normals[vtxIndex.nrm],
               texcoords[vtxIndex.uv] ) );

         indexMap.insert( vtxIndex, index );
      }

      // add new index
      indexBuffer.append( index );
   }
}

Triangle strips usually don't give best cache-usage for index buffers.
Strips introduce one new vertex per triangle.
Two-manifold meshes (with uniform normals and texture) typically have twice as much triangles as vertices.
So an ideal index buffers would require about 0.5 new vertices per triangle (which is only half as much as strips do).
This theoretical best-case is rarely achievable, though. And it's only relevant if you're heading for really immense amounts of vertices anyway...

[ninogenio]

haha.. that's awesome hellfire  k++,

i actually had something along the same lines coded up but gave up on it thinking it was a dead end.. just tryed that code snippet though and it works lovely, ill actually probably just stick with your idea and ditch the nv lib for now as i am trying too keep this as lib independent as possible..

on a slight side not.. is the .x file format still viable for mesh animations? i can rig models with bones in blender and export the animations too the .x format.

it does pretty much what i need but is rather complex and before going down that rabbit hole id like too make sure im not going too waist time when something better is out there. i think i can code it without any directx gear so they would work anywhere.

[hellfire]

ill actually probably just stick with your idea and ditch the nv lib for now as i am trying too keep this as lib independent as possible..

You can easily improve the cache-usage of the data in the index buffer by reordering the triangles in a second pass.
Just put the indices of each triangle into a fifo to simulate the gpu's vertex cache.
For the next triangle pick one which has the best match with the fifo.
A fifo with 16 entries should work fine, although newer hardware has larger caches.

is the .x file format still viable for mesh animations?
i can rig models with bones in blender and export the animations too the .x format.

I've never really touched .x except when looking at some directX/XNA-samples, so I can't tell any specific pros and cons.
But when it comes to 3d export, there are generally two groups of file formats:
- those that only export what's relevant for some specific use-case (and show you the finger if you want anything else)
- those that try to export *everything* and leave you with a bloated mess of data (which usually requires another pass of parsing and exporting)
I don't think it makes much of a difference which one you pick as long as it works and does what you need.

[ninogenio]

cheers hellfire, i must admit i wasn't fully up too speed on vertex caching but i stumbled on this..

http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html

is this along the same lines as what you proposed?. it looks quite similar apart from this doc using a 32x first in first out cache buffer. i find it fascinating how far optimizations can go. these are things i would never have thought about doing.

as for the .x i think i almost have a gl compatible loader working its very case sensitive atm if the model isnt 100% perfectly skinned in blender the whole thing explodes.. but hopefully as it matures it will gain flexibility. i had too modify the export script from blender as it had quite a few bugs, between the blender script bugs and my code bugs its been an absolute nightmare lol.

[hellfire]

i must admit i wasn't fully up too speed on vertex caching but i stumbled on this..
http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html
is this along the same lines as what you proposed?

Exactly.
The problem with finding the best solution is that you would have to check all possible combination (basically a TSP problem) - which is impractically for thousands of triangles.
So it's all about finding some clever heuristics to get a reasonably good solution in linear time.

[mziskandar]

How about this one?
http://digitalspine.blogspot.com/2009/06/custom-3d-loader-and-viewer.html