Every paper that I've seen up to date that uses voxels all seem to emphasize real-time voxelization so that it can be ran each frame. this is due to the fact that when an object rotates, the voxel structure can not keep AABBs (axis-aligned bounding boxes) without there being noticeable gaps between voxels, set aside the fact that these will need to snap to a grid if the scene is inside an octree (or some other data structure that is like an octree). Since I do not like the constant voxelization, especially since it can use resources that can be used for other tasks, I came up with a method (I have not tested this yet). The idea is that voxelization will only occur when an object is changed (vertexes moved or changed completely), which generally happens during animations and mesh deformations. The reason that meshes will be voxelized once is that a single matrix can represent the rotation of an object.

     Vertices are stored in local space, no rotation or global position data affects this. when the vertices are passed to the GPU to be rendered, they are sent through a matrix to be transformed into world space (I'm not 100% confident that this is the case). My point here is that the rotation matrices can be applied to voxel rendering where the voxelization of an object is like the local vertices. The only twist is that voxels won't be transformed. This is because there can be voxels ranging from thousands to millions and will be a bad idea to do all these transformations on a single GPU thread. Instead of the voxels being transformed, the ray will be, therefore, saving a lot of time while keeping the voxels in an AABB format with no gaps while also reducing the amount of voxelization drastically.

     If your wondering how these voxel representations will fit in a data structure that is on the scene level, or in other words, all the voxels in the scene are fit onto one tree, There are multiple possibilities that I have come up with. 1: BVH data structures (Bounding Volume Hierarchy). 2: Octree. just surround the rotated bounds of the voxels in an AABB bound that is a square and is snapped to the octree grid I guess.

Thoughts?

Yeah this is fine and dandy as an idea, UE4s signed distance fields (essentially sparse voxel octrees) have a dual global/local model, and only change as minimally as possible in quite the same manner you propose. Anyway, the idea is there's a high level "global" distance field, that only contains a few distance mips to keep updates to the global model cheap. Then there's each models individual voxel tree stored in a separate 3d texture, which offers much higher resolution but doesn't change (no skinned updating/etc.) and can be instanced/etc. It works fairly well, signed distance fields are so fast to trace through you don't even need specialized hardware to do it (heck The Last of Us did it with capsules all the way back on the PS3).

That being said this "updating the acceleration structure" thing is a major area of unsexy research. Everyone wants to "cast rays faster" (what you'll see most raytracing research on) but whether its a bounding volume heirarchy or some voxel structure or other you can quickly get updating that to be the performance bottleneck. It's part of the reason bounding volume heirarchies are being used for realtime raytracing instead, updating distance fields get's progressively more expensive the more detail you have/etc.

Fundamentally though you're on the right track. Ray instersection tests of any kind don't actually need transforms if the object being instersected doesn't change relative to itself, regardless of what sort of structure you're going through. You can throw around static objects all you want and only have to transform the "middle" portion of whatever structure you're updating (where the object is relative to other objects). If you can then come up with a fast way of revoxelizing/etc. smaller scale transforms, eg a tree blowing in the wind/a character animating/etc. then you're relatively good to go.

Looking at voxel engines, both Euclideon and Atomontage transform static voxel meshes to support animation. I remember even some research that extended this to deformations supporting sort of skinning (but do not remember from where).

The downside is the need to have multiple objects and a transform hierarchy. In raytracing, requiring to load a unique 4x4 matrix within each thread increases bandwidth and register pressure a lot. So if this is good or bad always depends, but in general i would say your idea is good for games. (If you drop support for scale you could go down from 4x4 or 4x3 to 8 or 6 numbers for a transform, using quaternions or rotation vectors - i'd certainly do that.)

As an alternative i see also a way in the middle: If you have prevoxelized models, you could transform the voxels and inject them into a global grid. Likley this can be made faster than rasterization based voxelization using compute. But not sure, avoiding too many atomics to global memory will make this complicated, if necessary.

Finally there remains the question if you really want quantized voxels at all, or if a BVH over triangles would not be better in the end. Quantized voxels means artifacts, plus the assumption a cache friendly but brute force algorithm would beat this work efficient alternative. This, and knowing likely all GPU vendors will have HW RT in 1-2 years, makes any decisions here very hard.

7 hours ago, JoeJ said:

 This, and knowing likely all GPU vendors will have HW RT in 1-2 years, makes any decisions here very hard.

 

By next year even, though I'm personally fascinated by how a patent applied for by AMD proposes to do so. Modifying the texturing units to allow an inner raytracing loop to be acclerated could mean it ends up far more programmable than Nvidia's "bounding box only!" solution. One could, potentially, trace through distance fields, mipped texture SVOs, or whatever structure one wanted. And being in what could be both consoles would mean this would become the new standard, and RTX itself could just be a deprecated experiment.

Of course that's a big assumption, which is the trouble of trying to guess anything now before solid information is out.

1 hour ago, Frantic PonE said:

could mean it ends up far more programmable than Nvidia's "bounding box only!" solution. One could, potentially, trace through distance fields, mipped texture SVOs, or whatever structure one wanted.

Yeah, i also like it. Having control over the loop would allow to  to break out early and use some approximation of geometry for LOD / cone tracing maybe? On the other hand i assume it can be slower than NVs solution because shader cores are not free for other tasks. We will see... the patent also mentions the option to add FF logic for the outer loop.

The larger problem i see with current RTX/DXR is the black boxed BVH construction. I would like to use progressive meshes or at least multiple LODs without a need for different low level BVH branches. Maybe that's possible with current hardware already but hidden.

I would prefer flexibility over performance. But that's a topic where software and hardware guys often disagree. (Especially if the latter ones are so awesome, haha )