I''ve currently got shader and VBO support in a SA system I am prototyping. My system is organized so that each vertex has an index into an array of bones which transforms it (currently, no weighting from multiple bones).

The way it works is I loop through each of the bones and calculate the transformation matrix for that bone. All of the bone matrices are fed to the vertex program (I use ARB_vertex_program right now, and no Cg/GLSL etc... Using a high-level shader language would probably be a better idea, since I have no clue as to optimizing for pipeline architecture) as local parameters using glProgramLocalParameter4fARB(). Typically, I send only the first three rows of each transformation matrix, to save space and allow more bones. Given a minimum of 96 local parameter vectors, and allowing for some in-program usage, I can do up to 27 bones, easily enough to handle even my most complicated models. Your mileage may vary; if you need more bones than that (with 96 parameter units and 3 vectors per bone matrix, that''s a max of 32 bones assuming no other bindings are used for other parameters or temporaries), you''ll have to send them in batches and structure your render code accordingly.

I pass each vertex bone index as a generic attribute to the shader, which is used to reference the bone table, acquire the correct transformation, and apply it.

My vertex data is organized as indexed triangles and drawn using glDrawElements(). All vertices are pre-transformed by the inverse of the skeleton''s rest pose matrix when loaded, to avoid having to redundantly perform this transformation step every frame.

As for the VBO''s, that''s simple. Since you are already using arrays, it is a simple matter to generate vertex buffers and bind the vertex/normal/bone index/UV array(s) to the buffers. Once you pre-transform the model vertices by the rest post and put them in the VBO, you don''t need to access or modify them again, since all transformations thereafter are done in the shader. Just bind the shader and the vertex buffer object(s), and call your glDrawElements() (or glDrawArrays(), whichever you use) as normal, though skipping, of course, the phase where you iterate through the vertices and transform them by hand.

I currently have VBOs disabled in my code, since I get worse performance with them than without. (36-byte vertex structure, I heard somewhere that a 32-byte alignment is preferred; I could be wrong. Plus, it''s a GeForce 2; what can you really expect? )

Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller

I use a very similar approach to VertexNormal, with a fallback to software skinning if hardware is not available, or if the number of bones exceeds 30. Even though the sw skinning route uses SSE instructions to do vector ops, the drop in frame rate is pretty significant (probably because I''m having to update the VBO each frame). As a real-world example, to render 100 flocking 121 vertex birds, each skinned individually, gives me a frame rate of 51 fps with software skinning. With hardware skinning enabled, I get 129 fps. There''s almost no overhead with the hardware skinning route.

BTW, This page gives a very good overview with an example implementation in Cg.

quote:Original post by klajntib

Ok, i''ve been doing some reading - weighted skinning is basicly used to prevent artifacts at joints points (ie: knees, shoulders..) right?

[edited by - klajntib on February 21, 2004 10:04:58 AM]

Pretty much, yes. Especially in the case where a joint flexes sharply, single-matrix skinning causes serious artifacts. Elbow and knees flatten off to sharp angles and so on. Weighted skinning is a little more complicated than single bone skinning, due to the necessity of having to combine multiple matrices. I haven''t implemented this yet, but there are plenty of generic vertex attributes available for sending multiple bone indices and weighting values, and it could still all be performed in the shader.

quote:
another thing - Do I gain much if i use glDrawElements and draw from and indexed array instead of glDrawArrays? Except a few KB of memory?

Logic tells me that glDrawElements is just a kind of a for loop which loops through all indices and sends appropriate vertices, normals and texcoords to the GPU right?

Which is what I do beforehand (due to problems with different normals for same vertices - shared data in ms3d format) and then just use glDrawArrays.

I think the biggest difference is memory usage. With glDrawElements(), you supply a list of indices which are used to pick and choose vertex data from locations within the vertex data arrays just as you guessed. glDrawArrays() starts at the beginning and works through to the end.

With glDrawArrays(), you store one set of vertex data for every face vertex in the mesh, regardless of whether that vertex data is exactly duplicated somewhere else in the mesh. With indexed arrays, a single vertex data set can be reused for multiple faces, without physical duplication of the data. Of course, not all vertices with the same (x,y,z) location are the same vertex--normal or UV information may be different.

Performance-wise, I personally have never seen much difference between the two methods, not enough to bother about. You are still drawing the same number of vertices, it''s just that they are chosen from different places. I prefer, however, to use indexed arrays and save a little space--especially since I went through all the work and trouble of writing a Blender Python script to crunch the mesh and merge duplicate vertices before exporting to file.

Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller