Once you’ve read through the OptiX Programming Guide to see what’s possible with the the OptiX host API and the CUDA device code and have worked through the optixPathTracer SDK example which is still using a single hardcoded geometry acceleration structure (GAS) for its very simple scene, you can find the more advanced OptiX 7 examples in this sticky post at the top of this OptiX sub-forum:
https://forums.developer.nvidia.com/t/optix-advanced-samples-on-github/48410/4
All these examples implement viewer-like applications which either generate some simple hardcoded scene geometry (plane, box, sphere, torus) or later load system and scene description text files which define what geometry should be generated or loaded and placed into the world.
These are all global illumination path tracers with increasing complexity described in the README.md there, starting with rather simple materials and then adding more OptiX features with increasingly complex system configuration setups for CUDA-OpenGL interoperability, multi-GPU and CUDA peer-to-peer sharing of resources.
The newest example MDL_renderer is showing what is possible with an advanced material system using the NVIDIA Material Definition Language.
To help with your current questions, there are only two optixTrace calls in any of these path tracer examples, one inside the ray generation program implementing the iterative path tracing through the scene itself and one inside the closest hit program(s) shooting a shadow/visibility ray.
Note that there are two different implementations for shadow rays shown in these examples which depend on the support for cutout opacity.
rtigo10 shows the maximum performance implementation when not supporting cutout opacity which would apply to your scene setup above. It only needs a miss program for the shadow ray type and terminates shadow rays on first hit via ray flags.
rtigo9_omm uses a variation of that because it supports the Opacity Micromap feature added in OptiX 7.6.0.
All other examples implement shadow/visibility rays via anyhit programs which is more costly but required esp. when supporting arbitrary procedural opacity values.
You’ll see that the vector of OptixProgramGroupDesc which define what device programs build the OptixPipeline for the resp. renderer is setup differently in these cases.