Sign in to follow this  
Murdocki

GL_UNSIGNED_BYTE indices

Recommended Posts

Hey,

i'm currently working on some geometry tools and i'm having problems with the first one which should create a cube. The cube it generates uses pos/nor/uv vertex format (interleaved vbo) and uses an IBO to render. The indices are of the type unsigned char and are correct when debugging with MSVC++.
The problem i'm having is that the first cube i'm creating and loading seems to have incorrect index buffer contents when using gDEBugger. When i'm loading the exact same cube a second time that cube has correct index data. I'm wondering if this has anything to do with the GL_UNSIGNED_BYTE index type because when i force the cube's indices to 16bits each the problem seems to be gone.

For completeness here's gDEBugger's output of the indices (incorrect first loaded cube first, correct one second)
[code]244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
244,
222,
[/code]


[code]0,
1,
2,
2,
1,
3,
4,
5,
6,
6,
5,
7,
8,
9,
10,
10,
9,
11,
12,
13,
14,
14,
13,
15,
16,
17,
18,
18,
17,
19,
20,
21,
22,
22,
21,
23,
[/code]


When looking at the incorrect indices it keeps repeating 244 and 222 (is this some super secret error indication or smth?)

I also fo[font="Arial"][size="2"]und "[i]Clients must align data elements consistent with the requirements of the client platform, with an additional base-level requirement that an offset within a buffer to a datum comprising N bytes be a multiple of N.[/i]" in the glBufferData specs. I've got no idea what this means but it might be related?[/size][/font]
[font="Arial"][size="2"]Just asking to see if someone recognizes this problem and knows of a known error or fix.[/size][/font]

[font="Arial"][size="2"]Thanks in advance,[/size][/font]
[font="Arial"][size="2"]Murdocki[/size][/font]

Share this post


Link to post
Share on other sites
How many vertices do you have for the cube?

Does it render incorrectly? (with and without gdebugger?)

How do you handle rendering multiple objects? single vbo/ibo bind then draw each instance or bind and draw each instance?

Share this post


Link to post
Share on other sites
my cubes have 6 sides with 4 vertices each (so 24 total), i'm using the index buffer to access each individual vertex.

previously enabling gDEBugger made the problem go away but now i've isolated the problem so it doesnt get supressed by gDEB anymore.
both cubes have the exact same vertex/index data in ram but that data gets loaded in 2 seperate vbo/ibo combinations ( one vbo and one ibo for each cube)

For reference here are the vertices in a pos/nor/uv format. These get loaded properly when showing loaded data with gDEB.
[code] EEResource::Mesh::LitVertex vertices[ 24 ] =
{
//Negative Z
{ Vector3f( 0.0f, 1.0f, 0.0f ), Vector3f( 0.0f, 0.0f, -1.0f ), 0.0f, 0.0f },
{ Vector3f( 1.0f, 1.0f, 0.0f ), Vector3f( 0.0f, 0.0f, -1.0f ), 1.0f, 0.0f },
{ Vector3f( 0.0f, 0.0f, 0.0f ), Vector3f( 0.0f, 0.0f, -1.0f ), 0.0f, 1.0f },
{ Vector3f( 1.0f, 0.0f, 0.0f ), Vector3f( 0.0f, 0.0f, -1.0f ), 1.0f, 1.0f },
//Positive Z
{ Vector3f( 1.0f, 1.0f, 1.0f ), Vector3f( 0.0f, 0.0f, 1.0f ), 0.0f, 0.0f },
{ Vector3f( 0.0f, 1.0f, 1.0f ), Vector3f( 0.0f, 0.0f, 1.0f ), 1.0f, 0.0f },
{ Vector3f( 1.0f, 0.0f, 1.0f ), Vector3f( 0.0f, 0.0f, 1.0f ), 0.0f, 1.0f },
{ Vector3f( 0.0f, 0.0f, 1.0f ), Vector3f( 0.0f, 0.0f, 1.0f ), 1.0f, 1.0f },
//Negative X
{ Vector3f( 0.0f, 1.0f, 1.0f ), Vector3f( -1.0f, 0.0f, 0.0f ), 0.0f, 0.0f },
{ Vector3f( 0.0f, 1.0f, 0.0f ), Vector3f( -1.0f, 0.0f, 0.0f ), 1.0f, 0.0f },
{ Vector3f( 0.0f, 0.0f, 1.0f ), Vector3f( -1.0f, 0.0f, 0.0f ), 0.0f, 1.0f },
{ Vector3f( 0.0f, 0.0f, 0.0f ), Vector3f( -1.0f, 0.0f, 0.0f ), 1.0f, 1.0f },
//Positive X
{ Vector3f( 1.0f, 1.0f, 0.0f ), Vector3f( 1.0f, 0.0f, 0.0f ), 0.0f, 0.0f },
{ Vector3f( 1.0f, 1.0f, 1.0f ), Vector3f( 1.0f, 0.0f, 0.0f ), 1.0f, 0.0f },
{ Vector3f( 1.0f, 0.0f, 0.0f ), Vector3f( 1.0f, 0.0f, 0.0f ), 0.0f, 1.0f },
{ Vector3f( 1.0f, 0.0f, 1.0f ), Vector3f( 1.0f, 0.0f, 0.0f ), 1.0f, 1.0f },
//Negative Y
{ Vector3f( 0.0f, 0.0f, 0.0f ), Vector3f( 0.0f, -1.0f, 0.0f ), 0.0f, 0.0f },
{ Vector3f( 1.0f, 0.0f, 0.0f ), Vector3f( 0.0f, -1.0f, 0.0f ), 1.0f, 0.0f },
{ Vector3f( 0.0f, 0.0f, 1.0f ), Vector3f( 0.0f, -1.0f, 0.0f ), 0.0f, 1.0f },
{ Vector3f( 1.0f, 0.0f, 1.0f ), Vector3f( 0.0f, -1.0f, 0.0f ), 1.0f, 1.0f },
//Positive Y
{ Vector3f( 0.0f, 1.0f, 1.0f ), Vector3f( 0.0f, 1.0f, 0.0f ), 0.0f, 0.0f },
{ Vector3f( 1.0f, 1.0f, 1.0f ), Vector3f( 0.0f, 1.0f, 0.0f ), 1.0f, 0.0f },
{ Vector3f( 0.0f, 1.0f, 0.0f ), Vector3f( 0.0f, 1.0f, 0.0f ), 0.0f, 1.0f },
{ Vector3f( 1.0f, 1.0f, 0.0f ), Vector3f( 0.0f, 1.0f, 0.0f ), 1.0f, 1.0f },
};[/code]

Share this post


Link to post
Share on other sites
[quote name='Murdocki' timestamp='1318268209' post='4871136']
my cubes have 6 sides with 4 vertices each (so 24 total), i'm using the index buffer to access each individual vertex.
[/quote]
i dont know what I was thinking with my previous statement, a cube will never exceed the index range. :rolleyes: Its monday :rolleyes:

[quote name='Murdocki' timestamp='1318268209' post='4871136']
previously enabling gDEBugger made the problem go away but now i've isolated the problem so it doesnt get supressed by gDEB anymore.
both cubes have the exact same vertex/index data in ram but that data gets loaded in 2 seperate vbo/ibo combinations ( one vbo and one ibo for each cube)
[/quote]

Its seems either the index buffer was loaded with incorrect data or the pointer offsets are incorrect.
The first case might be true if the array being loaded into the ibo, doesnt because initialized until after the first cube init occurs.
The second doesnt seem likley as you most likely have or run the same code for both

Share this post


Link to post
Share on other sites
[code]bool IndexBuffer::Write( unsigned int indexOffset, const void* indexData, unsigned int dataSize )
{
if( iboId == 0 )
return false;

glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, iboId );
uint8* ptr = (uint8*)glMapBuffer( GL_ELEMENT_ARRAY_BUFFER, GL_READ_WRITE );
if( !ptr )
{
glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, 0 );
return false;
}
memcpy( ptr, indexData, dataSize );
for( uint8 index = 0; index < 36; ++index )
{
Logger::Instance().QuickPrint( "%i", ptr[ index ] );
}


GLboolean unmapResult = glUnmapBuffer( GL_ELEMENT_ARRAY_BUFFER );

glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, 0 );
return unmapResult == GL_TRUE && glGetError() == 0;}[/code]

this is the code i'm using to fill the index buffers, the print is to let me know what is actually located in the ibo. Both output the expected index data. What do you mean by this pointer offset? something glVertexPointer vbo's ish i need to use for index buffers? currently i'm binding the indexbuffer with just a glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, iboId ); call

Share this post


Link to post
Share on other sites
yeah that looks fine for populating the ibo.
Do you plan to update the index data? If not you could just use glBufferData. what i mean by pointer offset is the value that is given during the call to glDrawElements:
[code]glDrawElements(GL_QUADS, 24, GL_UNSIGNED_BYTE, 0);[/code]
Where 0 is the offset in the index buffer, if it wasnt 0 in your app the indices could end up being read wrong.


Share this post


Link to post
Share on other sites
I do not plan on updating this particular ibo but this design would allow to do so if this is needed elsewhere, also my driver crashes when providing data to the initial glBufferData call, i've read this is a known bug and should be worked around by allocating first and filling with the map call as i am doing now.


for the indices argument i'm using a pointer offset which results in 0 [like so:(const char*)0 + ( offset * indexSize )], hardcoding this to 0 like in your example seems to have no effect, wouldn't this just change how the data is used and not the data itself(asuming gDEB shows the exact data)?

Share this post


Link to post
Share on other sites
[quote name='Murdocki' timestamp='1318276928' post='4871187']
for the indices argument i'm using a pointer offset which results in 0 [like so:(const char*)0 + ( offset * indexSize )], hardcoding this to 0 like in your example seems to have no effect, wouldn't this just change how the data is used and not the data itself(asuming gDEB shows the exact data)?
[/quote]

Yes the offset would only change where you start in the indices, but its the only other thing I can think to check that relates to using indices. It seems like the data never transfered in the case of the first IBO. I would try and run the code on another vendor as a sanity check.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this