AABBs for custom primitives in OptiX 7

Gaming and Visualization Technologies Visualization OptiX
1

Hi,

in my app I have one OptiX 7.0.0 IAS which contains all subsets instances of GASes.

I wonder how the AABB bounding boxes must be defined for custom primitives in the GAS and IAS,
when a transform matrix is applied in IAS and no other transform nodes are used between IAS and GAS.

OptixInstance* optix_instances = ...
optix_instances[index].transform  =   transform matrix

The AABB of the GAS (in primitive_input.aabbArray.aabbBuffers) then seems to be a local AABB around that transformed location, right?

In my example I have a sphere at location 11.0, 4.0, -7.0 with radius 8.0
optix_instances[index].transform looks like:
1.000000 0.000000 0.000000 11.000000
0.000000 1.000000 0.000000 4.000000
0.000000 0.000000 1.000000 -7.000000
And the bounding box in the GAS:
AABB min= -8.000000 -8.000000 -8.000000 max= 8.000000 8.000000 8.000000
(I yet ignore rotations/shearing/scaling)

// in the GAS:
OptixBuildInput primitive_input = {};
primitive_input.type = OPTIX_BUILD_INPUT_TYPE_CUSTOM_PRIMITIVES;
primitive_input.aabbArray.aabbBuffers = &d_aabb_buffer;
primitive_input.aabbArray.numPrimitives = primitives;
...

Additionally in the IAS I then add an AABB, which is required when using custom primitves.

in my example that then also looks like this:
AABB min= -8.000000 -8.000000 -8.000000 max= 8.000000 8.000000 8.000000
Cause if I transform it, wrong output is present; so obviously the transform in the IAS is applied also there on the AABB; and no additional action is requried, or do I miss something?

So all the AABB’s need to be defined locally when a transform matrix is used in the IAS?
The final location then is ensured by the optix_instances[index].transform in the IAS?

Is that correct?

In my example the primitive is a sphere using a “constant medium”, implemented similar to:
https://devtalk.nvidia.com/default/topic/1057855/optix/-solved-constant-medium-sphere/post/5364617
The center of the sphere (translation part of the transform matrix) simply is directly present in world space in the intersection program.
Maybe this is the reason, why I need local AABBs ?

Thank you!

My system: OptiX 7.0.0 SDK CUDA 10.1.243 GTX 1050 2GB Win10PRO 64bit (version 1809; build 17763.107) device driver: 436.48 VS2019 v16.4.2 (toolkit v140 of VS2015)

2

Yes, the AABBs for custom primitives inside a GAS are in object space coordinates (you define what space that is!), one AABB per primitive.
Generate them exactly as you would have with the bounding box program in earlier OptiX versions.

No, that isn’t even possible. An IAS is only an array of OptixInstance structs or pointers to such.
https://raytracing-docs.nvidia.com/optix7/guide/index.html#acceleration_structures#instance-build-inputs

Normally yes (but you can do with your coordinate spaces what you want. See below *1 ), and Yes.

If you define your primitives in world space, then object space == world space. Means your AABBs per primitive are built in world space coordinates (means for parametric sphere primitives that the translation is the center point) and your IAS matrices would remain identity because no transformation would be required.
(*1 You could still transform things with the IAS matrix on top. That’s what I meant above.)

If you have many parametric sphere primitives inside the scene, putting them all in one GAS using world coordinates would be faster than defining them as one shared sphere primitive around the object space origin and use many OptixInstance matrices to place them individually.
See links in this post: https://devtalk.nvidia.com/default/topic/1036468/optix/the-best-way-to-represent-10m-spherical-particles-/post/5265343

3

Thank you very much for your fast answer!

Ok, so it seems I misunderstood the optixSimpleMotionBlur sample (OptiX 7.0.0) line 662 / 692
where “IAS with expanded AABBs” is described:

OptixBuildInput instance_input = {};
instance_input.instanceArray.aabbs = d_aabbs;
instance_input.instanceArray.numAabbs =  InstanceType::COUNT;

So is that only for motion-blur? I understood it in a way, that any custom primitives require that.

Thanx!

4

Oh, yes, that is only relevant for motion blur. I assumed static geometry in your case.

https://raytracing-docs.nvidia.com/optix7/api/html/struct_optix_build_input_instance_array.html

[i]"Optional AABBs. In OptixAabb format.

Required for traversables (OptixMatrixMotionTransform, OptixSRTMotionTransform, OptixStaticTransform) and certain configurations of motion AS as instance. Will be ignored for non-motion AS, since no AABBs are required. May be NULL in that case."[/i]

1 Like
5

Thanks for clarification.