mat["ambient"]->setFloat(0.f, 0.f, 0.f);
t["ambient"]->setFloat(0.f, 0.f, 0.f);
sphereGI["ambient"]->setFloat(0.f, 0.f, 0.f);
These code lines mean you’re creating the same variable on different scopes (material and geometry instance).
The old OptiX API will resolve that with specific variable scope lookup ordering explained in this chapter 4.1.5 of the OptiX 6.5 Programming Guide.
For this case you should only get the ambient colors declared at the geometry instance level.
If that doesn’t happen, more information would be required.
For performance reasons, it’s recommended to only declare variables ones in a scope hierarchy. You can remove the ambient variable on the material in that case.
But, for the sphere I always get a single color, it can either be the first or the last one in my sphere vector container.
If you want to have a different color per sphere in an acceleration structure with a vector of spheres, that color would need to be defined per primitive, which means you would need to return the primitive ID or the color as an attribute from the sphere intersection program and use that instead of the “ambient” variable attached to the geometry instance or material, because the latter both would be uniform for all primitives in the geometry below.
To see what happens in your code, the resp. sphere intersection and closest hit programs would need to be provided.
I suspected on the struct alignment for my sphere and added padding to be 128bytes, my triangle struct has also the same size, no luck with it.
That’s not adding any information when not showing the structures and how they are used.
A sphere primitive can be expressed with a float4 for the center position and radius. Means a buffer of floa4 will be able to represent millions of spheres in a single acceleration structure. If each of them should have a different color, you would also need to store another float4 array (faster load than float3!) for the color per primitive.
I really need to get the 6.5 working first, after that I can move to the 7th version.
The only reason to learn the 10 year old OptiX API today would be, if you need to port existing OptiX code to the new OptiX 7 API and don’t know either.
If that is not the case, it’s seriously recommended to start with the more modern OptiX 7 API for new projects.
It has been changed for a reason. It’s always faster, more flexible, and explicit.