ttsiodras
commented
5 years ago Hi, Erich.
It's been almost a decade since I wrote this code! So, fair warning - I may be wrong :-)
With step = (stop-start)/(1024.f/(depth+1.f)); you'd get...
- at depth level 0, the code steps in
(stop-start) / 1024increments - that is, a small enough step to partition the box's range into 1024 pieces... and try to split the triangles inside it along planes aligned to these 1024 options (per axis) - then at depth level 1, a step small enough to partition the now half-size'd box range into
(stop-start) / 512pieces - so basically, adapt to the correspondingly smaller "range" of the bounding boxes, to perform more or less the same number of "tries" as you did at level 0
etc. So my take on what I had in mind when I wrote this, was to attempt - at each recursion level - to keep the computational effort in splitting the triangles more or less "stable".
erichlof
Hi @ttsiodras
I have enjoyed working through your code - quite excellent! I am also following the real time ray/path tracing dream: My Pathtracing project Could you please clarify the intended behavior of the 'step' variable as the recursion depth increases in the BVH.cc file? https://github.com/ttsiodras/renderer/blob/master/src/BVH.cc#L148
It seems to me that as depth increases, the grid size gets smaller, 1024, 512, 256, 128, etc. I can follow that. But if you divide the range (start to stop) by that ever decreasing number, won't step be increasing? I would have thought that you wanted step to get smaller and smaller as we work our way from the biggest root node all the way down to the smallest nodes.
Maybe I've misunderstood something, but if you could clarify, that would help a lot. Thank you! -Erich
p.s. one more question: why the grid starting size of 1024? Is it an arbitrary number or is there a reason you chose that value? Thanks!