In the obj loading code, I came across a curious comment, the code looks like this:
struct OptixMeshImpl::CreateGeometriesFunctor {
…
…
group_geo_info.mbuffer_data
= static_cast<unsigned int*>( mbuffer->map() );
for( int j = 0; j < group.num_triangles; ++j ) {
group_geo_info.mbuffer_data[j] = 0; // See above TODO
// What TODO? HAS LORE BEEN LOST??
}
mbuffer->unmap();
group_geo_info.mbuffer_data = 0;
…
}
So, the material buffer contains only zeros. What does this mean for the invoking of rtReportIntersection in triangle_mesh.cu, which is used in, for instance, sample 6?
The code says: rtReportIntersection(material_buffer[primIdx]);
I guess that basically there is no need to do the look up, as it will always be 0?
What is missing and what is the consequence of this missing?
Looks like the mesh class and triangle intersection code has been prepared to handle material indices per triangle, just that none of the file formats supported in that demo framework had a need for that.
Most likely remnants from examples which handled it similarly, e.g. whirligig has a material index per sphere.
There is at least one CAD application I know of which uses a hierarchy of materials where the lowest level is per primitive which would require such a material index per primitive.
If the material index is known to always be zero, the indirection inside the intersection code is unnecessary as well as the whole material index buffer. If you don’t need that in your own code, implement it differently.
The intersection program is the most often called program. For optimal rendering performance, make it as efficient as possible!
There is no need to use anything of the samples/sutil code in your own applications. Once you got a feeling for how things in OptiX scenes need to be structured you can quickly establish your own OptiX application code base.
That just means that it’s not filling the material index data with values which would result in different materials per primitive. You could do that if you wanted.
The OBJ loader should be able to generate multiple instances of one material type with different parameters taken from the MTL files used in an OBJ file. It’s normally assigned to all groups with the same usemtl keyword.
You have all the sources doing that. Please take some time to step through the code inside the debugger to see how things work. Take a deep look at void MeshBase::loadInfoFromObj(const std::string& filename) and the code around “mtllib” and “usemtl” comments.
Disclaimer: I’m not using any of the sutil code in my projects and just glossed over the code.