Jump to content


glDrawElements Index Array destroying itself


6 replies to this topic

#1 Hydrael

    Member

  • Members
  • PipPip
  • 34 posts

Posted 24 June 2005 - 04:30 AM

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

#2 codemonkey

    New Member

  • Members
  • Pip
  • 3 posts

Posted 24 June 2005 - 08: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)

#3 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 24 June 2005 - 08:14 AM

use the debugger luke ! use the debugger !
If Prolog is the answer, what is the question ?

#4 Hydrael

    Member

  • Members
  • PipPip
  • 34 posts

Posted 24 June 2005 - 09:04 AM

I've debugged the source over and over, but I can't find anything unnatural, that might screw up the array :(

#5 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 24 June 2005 - 09:18 AM

can you pinpoint where exactly the address changes ?
If Prolog is the answer, what is the question ?

#6 Hydrael

    Member

  • Members
  • PipPip
  • 34 posts

Posted 24 June 2005 - 10: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:

#7 anubis

    Senior Member

  • Members
  • PipPipPipPip
  • 2225 posts

Posted 24 June 2005 - 12:24 PM

it happens to the best... c has a bad reputation for exactly this kind of error
If Prolog is the answer, what is the question ?





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users