crazy idea...

i was thinking of using vertex indices as pointers into the virtual address space, instead of using them in the traditional way of indexing a vertex array. This would save me a lot of memory and save time updating a huge vertex array everytime my level is geomoded.

I would set the vertex pointer to 1 (0 means that VBOs are to be used) for example, set the stride to 1, and then build up an index array containing pointers to each vertex (subtracted by 1). I am assuming here that GL calculates the addresses of each vertex by “base + stride * index[i]”

Would this work? Are there any problems with it apart from no vbos ?

I wouldn´t rely on any assumptions on how gfx-card in general do anything. Maybe it´s possible to do that, but that can change and it might be very different on different models.

I don´t know how far gfx-cards are yet, but there was some talking about using a virtual memory layout. Certainly that would make stuff like that impossible.

Jan.

Originally posted by imr1984:

I would set the vertex pointer to 1 (0 means that VBOs are to be used)

Not sure what you meant there. 0 does not mean anything regarding vbos. Whether or not a vbo is used is controlled by a non-zero vbo bound to ARRAY_BUFFER at the time you set the pointer.

Originally posted by imr1984:
[b]
for example, set the stride to 1, and then build up an index array containing pointers to each vertex (subtracted by 1). I am assuming here that GL calculates the addresses of each vertex by “base + stride * index[i]”

Would this work? Are there any problems with it apart from no vbos ?[/b]
According to the spec, this should work.
But I would not rely on it in the implementations. I would expect an implementation to try and be smart about transferring the vertex data from client (your virtual cpu memory) to server (what the video card can address) without transfering vertices one by one depending on the indices.
I am wondering what this type of smart transfer ends up doing in your proposed usage of indices. I would probably bet for an OUT_OF_MEMORY error, because your indices are huge.

Note that some cards can only index up to 65535 vertices off the base pointer, and will either not work, or fall back to software, if you use index values of greater range.

You’re not clear what you are up to. If you want to open a memory mapped file to let the GL source vertex data from, it should work. You don’t need the 1 offset for that.

If I understood correctly, I would go with the impossible response even if and when possible. the idea if as I said I understood correctly, is the object equivalent of culling or object culling and using a single module with segmented access doesnt allow it to be protected giving you an extremely high chance of crashing after the first(second) pointer addressing. theoretically it’s a speed increase, but with alot of objects this could crash early. :slight_smile: .