Method to skip intersection calculation for the object occlusion?

I found this paper:
https://kola.opus.hbz-nrw.de/opus45-kola/frontdoor/deliver/index/docId/1438/file/BA_fschroeder_online.pdf

to the best of my knowledge, the performance devouring part is in the path tracing method
the intersection calculation for the object occlusion.

I found this paper and i ask me if that could help to make cycles faster. A technik called line space is in this paper is described. The space is describ as a voxelgrid that check when a object ocllusion are possible.

The document is unfortunately German but if you use deepl it is possible to to understand.

You can scroll throuh the text it is very interresting.

Have a good day!

I found a paper in english: http://wscg.zcu.cz/wscg2016/full/B19-full.pdf

The paper does not include comparisons with other raytracing implementations, so it’s difficult to judge what kind of performance improvement this would give for Cycles.

It’s interesting research, and there are many related papers like this that may be worth trying. For Cycles we’re more likely to wait and see what libraries like Embree do, if they find ways to make such research papers practical.

The English version shows performance against uniform grid and octree. N-tree is faster than octree in all demos, and sometimes also than uniform grid. N-tree with line space is faster in all examples. Memory goes up for n-tree, and linear space adds a bit more; the examples range from bit more to over 5x.

Brecht is right. . . Researching this right without knowing how much effort the integration would take is not praiseworthy. If you let other companies go first then you can at least estimate it and avoid the realy advantage.

The program can be 100% optimized for this model, so there could be some drawbacks that we can’t guess.

But I am also a beginner in terms of programming, so I can understand the implementation even less.