rtuCreateClusteredMeshExt material indices

Hello good people,

Since I am working with large triangles meshes, I am using the utility function rtuCreateClusteredMeshExt to restructure my datasets into a more paging-friendly manner.

Unfortunately, I am having trouble getting the intersector program associated with the resulting mesh to call the closest hit program belonging to any material other than that with index 0.

As an example, consider ObjLoader.cpp in the Optix SDK sutil library. The call to rtuCreateClusteredMeshExt looks like this:

if (_large_geom) {
// ... 
           rtuCreateClusteredMeshExt( _context->get(), usePTX32InHost64, &geometry, 
                                (unsigned int)nverts, vertex_buffer_data, 
                                 num_triangles, (const unsigned int*)vindex_buffer_data,
                                 mbuffer_data,
                                 _nbuffer->get(), 
                                (const unsigned int*)nindex_buffer_data,
                                _tbuffer->get(), 
                                (const unsigned int*)tindex_buffer_data);
      mesh = optix::Geometry::take(geometry); 
/// ...
}

Where the parameter mbuffer_data refers to a buffer that associates each triangle ID with a material index.

Originally, mbuffer_data[i] == 0 for all triangle IDs. However, when I modify mbuffer_data to refer to additional materials (which naturally add to the geometry instance), the only closest_hit program being called is that of Material 0.

When I repeat similar experiments using the simpler function rtuCreateClusteredMesh, the material programs are called correctly.

I have the same problem with both OptiX 2.5.1 and OptiX 3.0.0. Is this a known issue?

Cheers.

Thanks for the report. That’s a defect in the rtuCreateClusteredMeshExt() function. I’ll file a bug report against it.

Good to know, thanks Detlef.

I have run into the same bug. Is there a bugfix available or some workaround that is possible to use in the meantime?