Is it valid to upload an rtBufferId as an int variable on the OptiX context or are rtBufferId’s only valid as elements in an rtBuffer?
I ask because the programming guide only mentions buffers of buffer ID’s as a use case and I’m currently debugging a brutal crash in rtContextLaunch2D that seems to be related to my light sources. Those lightsources were recently refactored from being uploaded as an rtBuffer to be part of a scene struct where the buffer ID is uploaded as an int instead.
I remember a few years ago where we were discouraged from doing pointer arithmetic on buffers because of paging (I think) and I’m wondering if that’s the same thing for buffer IDs, OptiX needs to know which buffer ID’s are used and can’t if its secretly uploaded as an int.
I’ll download that sample later today. Thanks! Originally I wanted to make my struct the same way that you did, but rtBufferId wasn’t declared on the CPU, so I declared it as an int instead to be able to use the same struct on hos and device… Do you have a corresponding struct with ints on the host or how do you upload the IDs?
The C++ host code knows about the rtBufferId<> templates from optixpp_namespace.h.
Look for #define rtBufferId optix::bufferId around line 1717 in OptiX 5.1.0.
In the end it’s just an int underneath.
Fantastic. I found the bug in an environment map default constructor that only initialized half its members and would once in a while cause an invalid environment map ID to be uploaded => buffer access hell.
I can’t include optixpp_namespace.h host side without getting a cascade of compiler errors that start with
error : variable “RTAPI” has already been defined
Must be some order dependent includes. I’ll fix that later.
This should just work if you always put #include <optix.h> before any of the other OptiX includes.
That will define RTAPI via the include optix_host.h only for the host compiler.
There is no real need to use optix_world.h and you should not include optix_host.h or optix_device.h explicitly.