looking here for a fast solution to render my engine models, which are rather heavy as they come with rigs of 100 bones and more and have independant positions, normals and texture coorinates assigned (including bone weights).
using VBO things already speed up. now i noticed you can also use indexed VBOs. there is one thing though that i’m not sure of. you can only index the vertices of the faces like this, hence, you have not indexes for normals and texture coordinates separatly, correct?
for example a face has individual (and different) indices for ‘position’, ‘normal’ and ‘texture coordinates’ for each face corner. can i somehow index those three entities differently or do i need to collect all possible variations into a ‘corner’ array and index into this?
you can only index the vertices of the faces like this, hence, you have not indexes for normals and texture coordinates separatly, correct?
Correct.
for example a face has individual (and different) indices for ‘position’, ‘normal’ and ‘texture coordinates’ for each face corner. can i somehow index those three entities differently or do i need to collect all possible variations into a ‘corner’ array and index into this?
Vertices with different attributes need to have unique indices to be used with indexed drawing.
You must replicate those vertices and assign the differing attribute.
Example: You can’t render a lit cube as six quads with eight vertices and six normals using vertex arrays.
Each vertex is used three times with three different normals giving you an array of 24 vertices and normals. (There is no real need for indexing in this example because none of the vertices is shared.)
The only requirement is that the relative position of the elements in the enabled arrays are the same. Please note this can include padding if you set stride to a multiple of the elements size.
You could f.ex. have the element array 0,1,2 have OpenGL use vertices 0,1,2 and normals 5,6,7, or vertices 3,4,5 and normals 7,9,11. That’s all handled by glVertexPointer and depends on what offset and stride you set.
You can however not have indices 0,1,2 refer to random elements from the enabled arrays, such as vertices 3,4,6 and normals 7,11,42. All enabled arrays are indexed by the same indices from the single element array.
The actual data (vertices, colors, normals, texture coordinates) can be stored either in their own VBO’s or interleaved.
array of faces: index position, index texture position, index normal, index tangent. (6 times)
now rendering this with indexed VBO is hence not possible. thus i need to duplicate all this.
just a bit stupid as i wanted to try out some h4x on my shadow volume code adding the hidden extrusion quads to the list of faces using only indices to not duplicate the rest of the data.
You need to replicate the data for the rendering which uses all the data.
Nobody said the arrays need to be of the same length. Of course you can append additional data to the vertex array and use those vertices in your shadow volume rendering, which probably doesn’t need normals, textures and tangents. That will give you a separate index array with pretty good vertex reuse if you don’t source the replicated vertex data but only the unique original 8 and the appended ones.
hm… at first i need ‘position’ and ‘normal’ for the shadowing ( i know, it’s a h4x i said, not? ). then i would need an array of original vertices AND one filled up for rendering. with around 3k tris this makes (struct size 94=36) around 108k data. now with original data this give another (struct size 64=24) 24k data that i need to fill each frame.
i assume it would be more speedy to not have this additional 24k to fill just to have two arrays.
this is in fact my major concern here: only transfering the outmost needed data into my VBO and index it as the data transfer bottle necks (and i have to send the data each frame as i have complex skinning that i am forced to do in CPU as i have not found a way yet to get it on GPU).
i guess it would be more speedy to reuse the render VBO but using a static index VBO for shadowing ( using the extrusion h4x i could do this ), or has somebodx a better idea?
this is in fact my major concern here: only transfering the outmost needed data into my VBO and index it as the data transfer bottle necks
You really shouldn’t be “transferring” data from static models to VBOs constantly. A VBO should be the model’s data. IE, you load the mesh and upload it to the VBO as a single step. After that, you delete the representation in main memory because you don’t need it anymore.
). then i would need an array of original vertices AND one filled up for rendering. with around 3k tris this makes (struct size 94=36) around 108k data. now with original data this give another (struct size 64=24) 24k data that i need to fill each frame.