Basic question - world and object coordinates

Not sure I understand the question.

Let’s start with the terminology. The launch parameter block is a single structure in constant memory per optixLaunch call.
The size of available constant memory is limited! Means you cannot have arbitrary many fields in that structure.
But if you store CUdeviceptr to global memory in there, that indirection allows using as much memory as the GPU can address.

That launch parameter block doesn’t need to be passed to shaders. That block of constant memory is accessible in all OptiX device modules directly if the necessary extern declaration is present.

Everything else depends on the connection between your texture objects and data arrays to the shaders.
For that to answer it depends on how the material system works. For example:
1.) Are the texture objects and data arrays constant per shader?
2.) Are different instances using the same shader but with different texture objects and data arrays?

The SBT is very flexible. Possible layouts for the cases above would be:

  • For 1: The SBT contains as many hit group records as there are different shaders.
    The instance sbtOffset defines which shader is applied to which instance.
    Each shader knows exactly (offset hardcoded inside the code) where its texture objects and data arrays are stored inside global memory pointed to by CUdeviceptrs inside the launch parameters.

  • For 1: Same thing as above but instead of hardcoded offsets the texture objects and CUdeviceptr to the data arrays are stored inside additional data fields of the SBT record, behind the 32 bytes of the shader header. That would allow changing these parameters between launches without recompiling the shaders.

  • For 2: The SBT contains as many hit groups as there are different shaders.
    The instance sbtOffset defines which shader is applied to which instance.
    The instanceId defines which particular texture object and data arrays are used inside the shader.
    (This would require less memory than the following case.)

  • For 2: The SBT contains as many hit record groups as there are instances.
    Means the shader header is set per instance and texture objects and data arrays are stored in additional data of the hit record. Benefit would be that assining different shaders wouldn’t require rebuilding the IAS because the sbtOffset doesn’t change and the instanceId isn’t used, resp. could be used for something else.

SBT entries are comparably small. They are at least OPTIX_SBT_RECORD_HEADER_SIZE (32) bytes for the shader header with an alignment of OPTIX_SBT_RECORD_ALIGNMENT (16).

There are more options (e.g. parameter indexing could even be per primitive per instance, per ray, etc.), but you get the idea.
It’s all your choice and depends on how you need to connect data to shaders.