setMatrix doesn't work correctly in OptiX 6.0


As documented in setMatrix function that “If both are valid, the matrices will be used as-is”, but it seems a41, a42, a43 and a44 are reseted to 0, 0, 0, 1 anyway in 6.0. I have some specific matrices where a41, a42, a43 and a44 are assigned. Now it doesn’t work any more. You know, transformation node doesn’t allow any device variables, so I don’t know how to work around this.

It is reproducible in optixInstancing example. You simply need to setMatrix with both matrices, then read a41, a42, a43 and a44 from the device side. In OptiX 5.1 it works, but not in OptiX 6.0.


Thanks, I filed a bug report for analysis.

Unfortunately the answer is that only the affine part of the matrix is considered in OptiX 6, means the matrix is ignoring the fourth row and assumes (0, 0, 0, 1).

This change was missing from the documentation and that will be updated accordingly.

There is no good workaround for this because the GeometryTriangles don’t have a bounding box or intersection program to do this transform manually.

Actually the documentation of the rtTransformSetMatrix was always defining the behavour like this:
“The provided transformation matrix results in a corresponding affine transformation of all geometry contained in the sub-tree with transform as root.”
Means using a non-affine transformation matrix was actually an undefined behaviour.

We use transformation nodes for drawing instances. Imaging we have a really big scene, without using transformation nodes, it can easily run out of memory. The scene is supposed to be editable in our use case, we should be able to pick a pixel and select an instance then do something like translation. Previously, we store id into matrices, so we can use hit function to get which instance is selected. In fact, we just need a way to indicate different transformation nodes. Do you have any suggestions to achieve that with this new limitation?


Yes, if the non-affine portion of the matrix was ever respected, it was a bug. However, your use case of translation is fully supported by affine matrices. So are rotations, scales, reflections, and shears.