PDA

View Full Version : glDrawElements Index Array destroying itself


Hydrael
06-23-2005, 09:30 PM
Hello everyone,

I have a very confusing problem regarding the index array of glDrawElements.

The project I'm working on, is a world editor, which imports heightmaps - therefore I have a huge polygon count (50.000 to 3.000.000, depending on size) stored in a Vertex Buffer.
You probably can imagine, that performance ain't all too good, when trying to render the whole thing at once.
So I implemented frustum culling and checked every polygon for visibility. Things got better, but due to the high polygon count, checking every poly if it is within the frustum or not also takes way too much time.
So I had to reduce the amount of visibility checks.
That's why I came up with the idea to subdivide my world into logical units (with every LU being 4096 polys).
Those logical units I generate using an array of unsigned ints, each representing an element within my vertex buffer (LUPointer). That's the index array I use for glDrawElements.
To make things easier, I created another array with each element pointing to the first element of a logical unit within LUPointer.

I hope it is understandable.

Now, let's come up to my problem:
Rendering the world works perfectly with really good performance.
But when trying to include the logical unit algorithm in my picking routine (rendering to the selection buffer to find out, which poly the mouse is floating over), the index array (LUPointer) is being destroyed for some reason I just can't understand.

Down below is the critical piece of code.
When coming to glLoadName, the program always crashes at i=1704 and the debugger shows, that LUPointer has the adress 0x00000ca2.
I just don't get it, why it does that. I don't do anything else with LUPointer than reading its values throughout the whole program (except for the initialization routine of course)

The small loop in the beginning of the code snippet I included to see if element 1704 is ok before going into the real code - and it is.


for(int x=0;x<BufferCount;x++)
{
* if(x==1704)
* * *GLuint z=LUPointer[x];
}
if(LU)
{
* for(int x=0;x<LUCount*LUCount;x++)
* {
* * *if(Frustum->SphereInFrustum(LUMid[x].GetX(),LUMid[x].GetY(),LUMid[x].GetZ(),LURadius))
* * *{
* * * * size=LUSpecificSize[x];
* * * * from=LUArray[x];
* * * * for(GLuint i=0;i<size;i+=6)
* * * * {
* * * * * *glLoadName(LUPointer[from+i]/6);
* * * * * *glDrawElements(GL_TRIANGLES,6,GL_UNSIGNED_INT,&LUPointer[from+i]);
* * * *}
* * }
* }
}




Since size is way larger than 1704 it can't be a buffer overflow.

Any help would be really appreciated - I'm working on this error for days now and I just don't get it.

Thanks in advance

codemonkey
06-24-2005, 01:07 AM
From the details you have given, and from looking at what looks like innocuous code, I would hazard a guess that you should be looking elsewhere for the problem. Something outside of this code could be stomping over the LUPointer, or possibly the ShereInFrustum call is corrupting the stack.

When I get problems similar to this, those are what I mostly find to be the culprits

CodeMonkey(12s)

anubis
06-24-2005, 01:14 AM
use the debugger luke ! use the debugger !

Hydrael
06-24-2005, 02:04 AM
I've debugged the source over and over, but I can't find anything unnatural, that might screw up the array :(

anubis
06-24-2005, 02:18 AM
can you pinpoint where exactly the address changes ?

Hydrael
06-24-2005, 03:40 AM
Oh my god, that's so embarrassing :blush:

Thank you Anubis, your last post actually solved my problem:
Within the inner for-loop was this statement

VisibleUnderMouse[a++]=LUPointer[from+i];


which I didn't post, because I thought it is not relevant and might confuse.
Well - in fact it was exactly this statement screwing everything up because I just copy/pasted it from elsewhere and forgot to increase the array size for VisibleUnderMouse - it simply was too small, so it overwrote LUPointer.

Please excuse me for wasting your time while I go study "C++ for dummies" once again :lol:

anubis
06-24-2005, 05:24 AM
it happens to the best... c has a bad reputation for exactly this kind of error