GL_NV_vertex_array_range2

Hi everyone. I’m having a strange problem when using GL_NV_vertex_array_range2 and I’m not sure where I’m going wrong.

Basically what happens is that my scene can sometimes go crazy when mixing VAR and non-VAR vertex arrays. By crazy, I mean that my vertices, normals, and texture coordinates are screwed up. It isn’t always completely random, though sometimes it is.

So, here’s how I’m setting things up:

  1. Check for the extension string “GL_NV_vertex_array_range2”. My function does find that this extension string exists.

  2. Get pointers for the relevant functions.

  3. Allocate some VAR memory wglAllocateMemoryNV(maxVARMemory, 0.0f, 0.0f, 1.0f), check that I got it, and fill it in with my data.

  4. Enable my vertex and normal array client states.

  5. Loop over objects, drawing their geometry (mixed VAR and not) using glDrawElements() and calling glEnableClientState(GL_VERTEX_ARRAY_RANGE_WITHOUT_FLUSH_NV); and glDisableClientState(GL_VERTEX_ARRAY_RANGE_WITHOUT_FLUSH_NV); as appropriate to enable and disable VAR. Obviously, I’m also changing glVertexPointer() and glNormalPointer() as needed.

If anyone has some ideas about where I’m going wrong, I’d definitely like to hear them . No OpenGL errors are being produced. I’m using a Geforce4 Ti4600 with the 28.32 drivers.

Thanks,
Zeno

[This message has been edited by Zeno (edited 07-26-2002).]

Did you remember to call glVertexArrayRangeNV(…) on the allocated memory ? Other than that you steps match my own.

Yes, I call it each time the application asks for more VAR memory, like this:

glVertexArrayRangeNV(usedVARMemory, VARPointer);

Hmm, is it better practice to only call this once with “usedVARMemory” being the total size of the memory I allocated instead of the current amount being used?

– Zeno

[This message has been edited by Zeno (edited 07-26-2002).]

glVertexArrayRangeNV(…) should be called once on the entire range if I remember right.

Try glGetBooleanv( GL_VERTEX_ARRAY_RANGE_VALID_NV, &Result ) after glVertexArrayRangeNV(…), is it valid ?

I just looked through the paper on VAR+Fence and found this,

From “Using GL_NV_vertex_array_range and GL_NV_fence”
Call glVertexArrayRangeNV on the entire allocated memory buffer. Calling it upon a
subset of the memory buffer will result in an invalid range, and will not work.

Thanks, that was a problem with my program, but apparently not the problem. I’m still getting the occasional crazy geometry. Doing more checking now…

Do you write over a section of the buffer that was previously used for rendering without checking a fence?

Gorg - yes, probably.

I am rendering a multi-LOD terrain grid. The tiles in this grid are re-used, so at any time, the geometry of a given tile may change.

However, I don’t think I need fences because I pull tiles out of the rendering loop before I change their geometry, and don’t put them back in until I am done. Also, these geometry errors can appear even with a stationary viewpoint (so that no tiles are in flux).

Am I wrong here? Maybe I am misunderstanding the purpose of fences?

– Zeno

I am pretty sure it is your problem.

Even you finished your rendering code, there is no way to know when the commands will be executed.

So changing the data after you have done all your rendering command for a frame is not a strong enough condition to know that the data has been fetched.

So, to make sure that it is really your problem. Simply call SetFenceNV(fenceId, GL_ALL_COMPLETED_NV) at the of your Render function and when you try to update your tiles just do glFinishFence(fenceId).

The symptoms you are describing really sounds like you are ovewriting data that is being fetched.

Zeno, as a quick test try calling glFlushVertexArrayRange(…). If your errors disappear, then you probably need fences ( I would recommend this anyway ).

[This message has been edited by PH (edited 07-27-2002).]