That ain’t working. You cannot simply mix and match programs from examples with different rendering implementations.
geometry_group[0] should have gis.size() GeometryInstance children.
maingroup->setChild(0, geometry_group[0]->getChild(0)); only attaches the first GeometryInstance of that to your GeometryGroup maingroup.
There need to be two intersection programs, one for the parallelogram and one for the triangles of the OBJ.
There is no triangle_mesh_iterative.cu used inside the path_tracer example unless you added it.
Otherwise there should be an error that createProgramFromPTXFile() failed if you didn’t add it there.
The glass example has that but it’s generating different attributes than required for the path_tracer.
You would basically need to write an intersection program which handles triangles and generates the attributes required inside the path_tracer.
Then you use the diffuse material of the path_tracer which sources the diffuse_color variable for lighting calculations, but the OBJLoader generates texture samplers for the Ka, Kd, Ks values, see ObjLoader::createMaterialParams().
You’d need to implement a closest hit program which uses the variables generated by the OBJLoader in a way required for the path_tracing diffuse BRDF calculations and use the correct intersection program and attributes.
Actually I’d recommend to try to generate own triangle mesh geometry as an exercise in the beginning instead of using the loaders to get a better understanding how things underneath fit together before abstracting them again.