enhanced index arrays

Yes I know again.

But having an index for each attributes will definately help me in more than a single situation even if that does not speed things up (as long as that does not slow things down).

They were planned in an old release of the GL 2.0 specs but seem no more of actuality. It also seem there must have other things to do before (mainly memory management).

For normals this is not as important since normals could often be different from one vertex of a polygon to the same vertex of an adjacent polygon. But for texture coordinates and others it is really interresting. Also this might help for shadow volume silhouette recognition. There are also plenty of other situations where it is of interrest.

If someone is interrested…

So, do I have to conclude this must be forgotten ?

For another simple example. Just imagine a ‘dynamic’ ground where each vertices can change for each frame. I know that doing space partition would help a bit but with this way changing a height of a vertex would be as simple as changing its height on a single element in the array, not any elements in the array for the same matching vertex, so reducing CPU consumption.
It could also help for LOD (almost dynamic LOD)…

I still wait for some real world example that shows we really need this. Every example brought up by people wanting this extension is an artificial construction.

In your dynamic ground example, why would you need more than one vertex updated with vertex arrays as we have them now?

I didn’t see I had an answer here.

I must admit this is not 100% crucial. This is most of an ease than another thing. This is why I used the verb ‘help’.

In the ground example, I was seeing this kind of thing would be of help under this situations:

a) Dynamic movement of the ground (or you can put anything else than a ground). Let’s say a part of the ground is rising from the bottom to form some kind of a mountain. In the case where there are ten thousands of polygons, the algorithm (even when using some space partitioning) would likely be slow: seeking all the faces sharing the same vertex, and doing this for all the faces that must move without falling into redundancies.

So, for answering your question and if I understood it correctly: I would need to update more than one vertex when index arrays cannot be used (just because normal array does not match the vertex array for example, or the color array).

I know this could be done in software just by doing as if such enhanced arrays exist and then apply an algorithm to upload the arrays into GL with repeating the doubles where needed.

However this will slow things to my point of view:

First, on the CPU side where you need to update each vertices sharing the same geometric position. Or if you use ‘fake enhanced arrays on CPU side as stippled above’, again lost CPU time because of the need to transform them into acceptable arrays for GL (ie form all the polygons from all the vertices, normals, texcoord and the multiple index arrays).

Second: on the transfer side, when you will need to upload more data.
I know this point can be countered. Generally we have to choose between amount of data and speed. However I’m pretty sure this point will allow to put less data into GL (gaining transfer time) and also not slowing things.

b) for lod and more specifically dynamic lod, this will allow under some cirumstancies to do the things more quickly: when subdividing a triangle, this will create only a new single vertex for each new subdivision of a triangle into 3 new triangles.

Anyway, thanks for the care, this will at least make me understand why this will be good or why this won’t be a good thing.

It looks like this is going to be possible in HLSL10. What they’ve added is a generic Buffer object that can be accessed within a shader using bound index buffer IDs and/or vertex/primitive IDs (automatically generated by the Input Assembler). While not multiple index buffers, you can achieve different stream/attribute frequencies by using a scale on the available vertex IDs.

I think that multiple index buffers might be a tad too complex/expensive to optimize at this point. But this is one solution, although perhaps not as pretty as multiple index streams/buffers.