(L) [2014/03/07] [tby spectral] [SBVH - support of different kind of primitives] Wayback!Hi there,
I use a SBVH to accelerate my current engine (GPU engine), but for now I only support simple triangle... and working on adding sphere, cynlinders, hairs etc...
My problem is that the "leaf" of the SBVH contains a pointer to a set of primitives, but all of the same kind, something like this
BVHLeaf
{
PrimitiveType type;
int primitiveIndex1;
int primitiveIndex2;
}
The problem I have is that I can mix the primitives in the same scene and then to be optimal a leaf should be able to contains a set of "mixed primitives", but for now all the primitives of a leaf are of the same type.
So, what solution do I have ? without memory and performance issue ?
By example, adding several leaf will increase the tree size and will decrease the performances !
Any idea is welcomed ?
Thanks
(L) [2014/03/07] [tby papaboo] [SBVH - support of different kind of primitives] Wayback!You write that it's a GPU engine, so separation of primitives might not be a bad idea. It will decrease tree quality, sure, but it will increase coherence among threads in a warp, which can be a lot more critical.
My personal preference for a GPU raytracer with support for multiple primitives (tris, spheres, volumes) would be separating the hierarchy into two parts.
At the bottom level you would have an acceleration structure for your geometric containers/models/meshes. This means you can optimize the acceleration structure to that very primitive. (BVH for tris/spheres, sparse octrees for volumes, ... whatever you want) At the top level you would then wrap transformations of the geometry, so the leafs in the top level would contain a ray-transformation into the local space of the model and a pointer to the models hierachy.
The wins are obvious. Specialized acceleration structures for primitives and support for arbitrary primitives in the graph (as long as the traverser supports the acceleration structure)
It's easy to test and evaluate new acceleration structures, as they are completely seperated.
Separation of dynamic and static models make it easy to combine several acceleration structure builders: Fast, but low quality for dynamic model and slow, but high quality for static models.
You should have a relatively good code execution coherence across warps. You could even separate traversal into two steps too increase coherence. First traverse the top level, record leafs pr ray / batch of rays, sort with respect to leaf node and leaf node type, traverse the low level hierarchy.
A con is obviously that the leaf nodes in the top level hierarchy can be of arbitrary size, which can hurt your acceleration structure quality. A split/merge preprocess of the (static?) primitives should help you there.
However, if you want to keep a single acceleration structure for all primitives, then I would suggest at least sorting them in the leaf nodes according to type, so as to avoid threads idling.
(L) [2014/03/07] [tby spectral] [SBVH - support of different kind of primitives] Wayback!Thanks,
I already have a multi-level structure, but I'm afraid that seperating every kind of primitive will simply :
a) increase the memory size
b) decrease the performance because we will have multiple structures to traverse
So, I think that I have to put all the primitives kind in the same structure. (Notice that I use SBVH and it seems to me that if I seperate all the structure I can loose some optimization ie. "splits" of the SBVH).
So, sure it seems to me that I have to "group" all the primitives by type... but how to do without increasing the memory usage [SMILEY :-P]
(L) [2014/03/11] [tby ziu] [SBVH - support of different kind of primitives] Wayback!If you want to use the same acceleration structure you can just use a couple of the bits in the primitive index to discriminate between different primitive types. e.g. if you have 4 primitive types you use 2 bits for that. You still would have 30 bits left so you can have scenes with up to 2^30 primitives.
If that is not enough addressing space you just switch from int (32 bits) to long (64 bits).