We should keep games built against older NVAPI working, so instead of failing when encountering unexpected geometryDescStrideInBytes (like, when using NVAPI headers from before 535 in which DMMs were added causing the union to grow) this will try to access array members by manually calculating their address (and this will now keep working without rebuilding or updating headers if another union member is added in the future).
Adding tests this led me to discover a bug where we assume that after NvAPI_D3D12_GetRaytracingAccelerationStructurePrebuildInfoEx / NvAPI_D3D12_BuildRaytracingAccelerationStructureEx returns, we can still read values from pointer passed in pGeometryDescs which is not the case (because it points to data of a std::vector living on the stack of called function). To avoid this issue, the content of this array is now copied to another local std::vector as a side effect.
We should keep games built against older NVAPI working, so instead of failing when encountering unexpected
geometryDescStrideInBytes(like, when using NVAPI headers from before 535 in which DMMs were added causing the union to grow) this will try to access array members by manually calculating their address (and this will now keep working without rebuilding or updating headers if another union member is added in the future).Adding tests this led me to discover a bug where we assume that after
NvAPI_D3D12_GetRaytracingAccelerationStructurePrebuildInfoEx/NvAPI_D3D12_BuildRaytracingAccelerationStructureExreturns, we can still read values from pointer passed inpGeometryDescswhich is not the case (because it points to data of astd::vectorliving on the stack of called function). To avoid this issue, the content of this array is now copied to another localstd::vectoras a side effect.