dgkoch
commented
4 years ago Hi @Lin20,
Thanks for the feedback and your suggestions. We have briefly talked about some of these ideas in the past but are not planning to address for the initial release of ray tracing extensions. It's not currently a high priority for us, but it is something we are continuing to evaluate. We'll take on board your feedback, and let you know when it progresses. Any other information/feedback/use cases you or anyone else has would be appreciated. Thanks!
First off, thanks for all the hard work in bringing standardized ray tracing to Vulkan. Very excited about it! As part of the call for feedback, one thing that has always bothered me with big ray tracing APIs (OptiX, DXR, Nvidia's Vulkan RT) is that all ray tracing is exact, where the acceleration structure is a black box and only the input primitive tracing is exposed to the user. When used for rendering with lots of detail, severe aliasing can occur or cause extra work to be done when micro geometry is unnecessarily tested. The efficient sparse voxel octrees paper addressed this in detail, and when tracing into something like a point cloud or voxel scene, it can be very useful to feed data into non-leaf nodes and terminate ray tracing early.
I know the spec says the acceleration structure is implementation-defined so for all us devs know, the standard BVH/kd-tree/some-tree might not even be used on the back end (though I don't realistically see that happening). But the possibilities it would open up to somehow introduce a form of geometric "cone" or level-of-detail tracing could be huge. Right now the alternatives are to either implement ray tracing from scratch, or to use some hacks like either storing different levels of detail as different acceleration structures and casting several rays with early termination points, or forcing intersection failures in the intersection test for very fine geometry.
The idea I came up with would be to have the user supply each desired level of detail of their geometry with each downsampled node being supplied as a primitive. In addition to requiring AABBs though, they also supply a detail level and parent node. When dispatching rays, users can specify a min & max detail level to trace against to allow for "culling", or skipping, unneeded levels of geometry. Perhaps the user could specify a "cone aperture" and distance threshold to have automatic level of detail testing based on t. This has the benefit of the user having total control like the intersection test hack above, but allows for some potentially big optimizations.
Additionally, I came up with some ideas to use the raw acceleration structure as I believe that has potential too. Right now they're just for AABBs.
Idea 2) This would be a two-pass system: A) When the acceleration structure is built, the user could call a function that would fill a buffer with data of how the acceleration structure is laid out. Assuming the leaf nodes are level 0, it could be filled with a linear array of data for each node above level 0 containing its location, its bounding volume, and the list of children. This would give the user the chance to downsample their data however they want and fill a buffer for the hierarchy. B) A "node test" shader, similar to the intersection test shader, would be introduced. The implementation could optionally invoke this when a ray passes a ray-node test and supply the level and index of the hit node, which could be used to lookup the data from A) and fill intersection information. The user will have the ability to terminate further testing of child nodes from here. This approach has the benefit of being fully flexible with data downsampling, with the downside being something like a BVH might not downsample the geometry like the user expects.
Idea 3) By introducing the concept of a hierarchical acceleration structure, we are guaranteed that the black box isn't just brute force ray-primitive testing every single leaf node. Input primitives would have a piece of data in the format of a texture (4 floats as RGBA for instance), which the parent nodes would have as well that's simply just a linearly/averaged downsample of the children's data. The node-test shader would also exist here. This approach has the benefit of being straightforward like texture mipmapping, with the downside being the downsample mode is very restricted.
While I doubt ideas 2 and 3 will come to fruition as it's just some brainstorming, I think #1 is doable as it's similar to triangle backface culling. I'd love to know thoughts on the concept as a whole and hopefully be able to get some hardware accelerated SVOs someday.