Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

In this Discussion

Tags in this Discussion

Invalid index buffer size
  • Vote Up1Vote Down mcleary
    Posts: 49
    I'm trying to setup an Optix buffer object from a gl buffer in the following way:


    GLuint ebo;
    glGenBuffers( 1, &ebo );
    glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, ebo );
    glBufferData( GL_ELEMENT_ARRAY_BUFFER, 12 * sizeof( GLshort ), 0, GL_STATIC_DRAW );
    glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, 0 );

    ...

    optix::Buffer idxBuffer = this->mContext->createBufferFromGLBO( RT_BUFFER_INPUT, ebo);
    idxBuffer->setFormat( RT_FORMAT_SHORT3 );
    idxBuffer->setSize( 4 );


    But, I get the error: "Invalid value (Details: Function "_rtContextLaunch2D" caught exception: Invalid index buffer size. Possible reasons: incorrect primitive count or stride too large"

    I'm setting up correctly the vertex buffer and the error occurs when I'm trying to set up the indices buffer like above.

    Does Optix supports buffers of format RT_FORMAT_SHORT3?
  • 10 Comments sorted by
  • Vote Up0Vote Down Detlef Roettger
    Posts: 330 Accepted Answer
    The buffer sizes look fine, but how are you using it further down in your code?
    Check all programs accessing that buffer if they declare it the same way and then check the primitive sizes you send.
  • Vote Up0Vote Down mcleary
    Posts: 49
    I'm loading an .obj file with just a plane composed by 6 vertices and 4 faces. Each face has 3 indices. I wrote the code above to show where the error is ocurring. So, after setting ele indices buffer like above, I create a geometry object in the following way:


    optix::Geometry geometry = this->mContext->createGeometry();
    geometry->setPrimitiveCount( mesh->mNumFaces );
    geometry[ "indices" ]->setBuffer( idxBuffer );


    If I understood it correctly, geometry->setPrimitiveCount() will be 4 in my case. Am I correct?

    The programs that use my indices buffer are the Intersection and BoundingBox programs, which are the same as in triangle_mesh.cu that comes with sutil. I just did some modifications to support a buffer of short3, like below:

    rtBuffer<float4> vertex_buffer;
    rtBuffer<float4> normal_buffer;
    rtBuffer<float2> texcoord_buffer;
    rtBuffer<short3> indices;

    In the programs, the only diference is the following:

    RT_PROGRAM void mesh_intersect( int primIdx ) {

    const short3 v_idx = indices[primIdx];

    Is there anything wrong? Anyway, I'll double check the buffer sizes to be sure the sizes are correct.
  • Vote Up0Vote Down Detlef Roettger
    Posts: 330
    Yes, setPrimitiveCount() is number of triangles in your case.
    If you changed both the intersect and bounding box programs the same way, then I wouldn't know.
    In general I would recommend to use unsigned shorts though.
  • Vote Up0Vote Down mcleary
    Posts: 49
    I'll try a simple program to see where the error is.
    About shorts and ushorts, both are 2 bytes long, internally to optix this makes difference when setting the contents of a buffer?
  • Vote Up0Vote Down mcleary
    Posts: 49
    I build another program, just to load a simple buffer and it looks like that there is some problem when using RT_FORMAT_SHORT3 or similar ones. RT_FORMAT_INT works fine. I suspect that this could be a bug. I'll check on that.
  • Vote Up0Vote Down kch86
    Posts: 17
    I assume you're targeting Sbvh? Doesn't Sbvh assume to use 32bit indices?
  • Vote Up0Vote Down mcleary
    Posts: 49
    @kch86 you are correct, I didn't realize that. Just for anyone who might have this problem:

    "The name of the buffer variable holding vertex index data. The entries in this buffer are indices of type int , where each index refers to one entry in the vertex buffer. A sequence of three indices represents one triangle. If no index buffer is given, the vertices in the vertex buffer are assumed to be a list of triangles, i.e. every 3 vertices in a row form a triangle. The default is “index_buffer”."
  • Vote Up0Vote Down mcleary
    Posts: 49
    BTW, I'm trying to accept the answer but the forum seems to not respond to that action (a forum bug? =) )
  • Vote Up0Vote Down Detlef Roettger
    Posts: 330
    The shorts vs. unsigned shorts was just because it's allowing a bigger number of positive indices and because CUDA 4.1 is more finnicky about retaining the sign information of variables in case you used that version.

    Alignment shouldn't be an issue either, short3 and ushort3 both only need to be 2-byte aligned.
  • Vote Up0Vote Down mcleary
    Posts: 49
    Yes, I'm using 4.1. Thanks for the explanation. But, as @kch86 reminds, I'll need to use int types, since Sbvh only accepts this kind of element for its indices buffer.
Add a Comment