Hi all,
i am just starting to experiment with Optix Prime and i am a little bit confused about the include files. I’ve included “…/include/optix_prime/optix_primepp.h”, giving me “Context” and “Model”, but e.g. no “Ray” or “Buffer”. I’ve looked at the SimplePrimepp example, but i seem unable to figure out the include path for these.
Are there recommendations what to include?
Also, in the include directory, what is “include/optixu/" as compared to "include/”?
I have Optix 3.6.3.
“Find in Files” is your friend.
Just search for Ray and Buffer in the simplePrimepp example folder files and you’ll see that they are example-local definitions inside simplePrimeCommon.h. Means these are custom types and you can implement your own as needed, e.g. when using one of the other OptiX Prime ray or hit formats.
Then why does the Optix (Prime) API specification 3.6.3, page 279 state that “During C++ compilation, the Ray struct is contained within the optix:: namespace” if i have to design my own ray?
Also, the definition in simplePrimeCommon.h lists the members “origin”, “direction”, “ray_type”, “tmin” and “tmax” in that order, whereas the specs (page 324) simply give ray formats like “RTP_BUFFER_FORMAT_RAY_ORIGIN_TMIN_DIRECTION_TMAX” (another order). How am i to deduce the correct struct order from that - or am i on the completely wrong path here?
What good is a PrimePP (-wrapper) if i have to do search in files all the time and write my own classes/structs/definitions for things like Buffer or Ray, which are always needed when using PrimePP?
I am still lost here…
You got the OptiX Prime buffer formatting definitions all figured out correctly, but seem to look at the wrong structure. optix::Ray is not in OptiX Prime.
OptiX Prime supports only the buffer formats defined by RTPbufferformat (see OptiX API Reference 4.13.2.1 for the exact layout).
The struct Ray in OptiX 3.6.3 simplePrimepp\simplePrimeCommon.h is this:
//------------------------------------------------------------------------------
//
// Ray and hit structures for query input and output
//
struct Ray
{
static const RTPbufferformat format = RTP_BUFFER_FORMAT_RAY_ORIGIN_TMIN_DIRECTION_TMAX;
float3 origin;
float tmin;
float3 dir;
float tmax;
};
struct Hit
{
static const RTPbufferformat format = RTP_BUFFER_FORMAT_HIT_T_TRIID_U_V;
float t;
int triId;
float u;
float v;
};
which matches the RTP_BUFFER_FORMAT_RAY_ORIGIN_TMIN_DIRECTION_TMAX layout it uses.
The OptiX optix::Ray format is different as you found. There is no “ray_type” inside OptiX Prime, that is handled with different queries (closest, any) there.
There are no predefined structs for these buffer formats in the OptiX Prime core headers. That’s just how the examples have been implemented.
How you get the data into the buffers is completely left open for you to implement. You just need to make sure the layout matches the ones defined by the enums in RTPbufferformat.
I was indeed looking at the wrong place, intellisense took me there following the “Ray” - thank you very much for the clarification.
This brings up the question how Optix and Optix Prime are related?
…
I always thought (at least for a day or two since i’ve started looking at this ;) ) that Prime was a specialization of Optix’ general approach internally using the correct ray types, hit etc. programs and acceleration structure type to expose a simpler collision detection only api. Is this the case?
I am asking, because if they are related that way it seems a little odd that the rays in both parts have different member orders for the members they share (though i know its technically okay and they might be both mapped to the same order internally).
Consider OptiX and OptiX Prime as two separate SDKs.
OptiX is a programmable ray casting SDK with high user programmability for the exposed program domains with a single ray programming model, flexible scene hierarchy, and user defined geometric primitive types.
OptiX Prime is a low-level ray intersection SDK with a wavefront ray tracing approach (send many rays per query, get the same number of hit results) and a reduced support for scene hierarchy, geometric primitive, and acceleration structure. All shading and data management is your responsibility. Due to the restricted flexibility the bare intersection speed in OptiX Prime is higher.
You need to decide which programming model fits better to your application.
Okay, then its Prime for me atm. Thank you very much for these insights.
We actually think of OptiX Prime as being a low-level API upon which parts of OptiX are based. For example, OptiX’s Trbvh builder simply calls into the OptiX Prime code base to do the heavy lifting. In the future, we expect the same will be true with common ray tracing tasks. This is one hopeful outcome of a huge rewrite that we’re doing right now in the core of OptiX. We’ll tell you about it at GTC in March.