Page MenuHome

Cycles: Implement watertight ray/triangle intersection
ClosedPublic

Authored by Sergey Sharybin (sergey) on Oct 8 2014, 3:02 PM.

Details

Summary

Using this paper: Sven Woop, Watertight Ray/Triangle Intersection

http://jcgt.org/published/0002/01/05/paper.pdf

Main purpose of this change is to reduce the memory footprint by getting rid of
pre-computed storage. And in the BMV scene it's about 25% less memory, in the
secret agent walk cycle it's about 14% less memory and with the sheep test files
it's about 10% less memory usage.

Unfortunately, it's currently about 10% slower than the previous solution with
pre-computed triangle plane equations, but maybe with some smart tweaks to the
code (tests reshuffle, using SIMD in a nice way or so) we can avoid the speed
regression.

But perhaps smartest thing to do here would be to change single triangle / ray
intersection with multiple triangles / ray intersections. That's how Enbree does
this and it's watertight single ray intersection is not any faster that this.

Currently only triangle intersection is modified accordingly to the paper, in
the future we would also want to modify the node / ray intersection.

Diff Detail

Repository
rB Blender

Event Timeline

Sergey Sharybin (sergey) retitled this revision from to Cycles: Implement watertight ray/triangle intersection.
Sergey Sharybin (sergey) updated this object.

Nice work. :)

I would look into intersecting multiple triangles at the same time as well, this will probably give a speedup and compensate for the performance loss.
Also SIMD is of course an option, although we cannot use this on GPU.

For the CPU there is still the possibility of a QBVH, in fact Embree only uses QBVHs in the 2.x releases.

QBVH is a different aspect. It would only help to do more efficient node traversal, but once you reached a leaf node it's no longer a help. You would still need to have more efficient intersection of nodes from the leaf node. Embree has code for this using sse3f, but i'm not sure how good SIMDed it is -- it's just a Vec3<ssef> and i don't see some specific vectorization for it. It still possible that better memory localization helps here.

This also fixes some precision issues, e.g T34094. It was to be expected, but noting down for the record.

@Thomas Dinges (dingto), did you actually run tests with the current state of the patch?

@Sergey Sharybin (sergey): Only rendered BMW to check on slowdown, and then remembered some precision bug reports we got in the past, so I checked that one^^. :)

@Thomas Dinges (dingto), so that precision bug report is fine with the watertight triangle intersection now (even without the watertight nodes intersection)?

The blend file from T34094 is fine now with the watertight intersection, not a single white spot on the sphere. :)

That's quite a result then :)

Reshuffled some checks to perform better early output, reduces slowdown from 12% to 7% with BMW scene.

Run some benchmarks with latest patch.

There's still unclear thing -- does this help fighting with fireflies? In theory it's possible that in interior scene some ray used to hit triangle edge and not being registered as an intersection, leading to fireflies. I'm not yet sue if the patch helps in that regard.

Right, in theory this can avoid some fireflies, although I think that the majority of fireflies comes from other error sources, such as wrong material setup. I can run some heavier interior scenes later and see.

Ronny G (nutel) added a comment.EditedOct 9 2014, 7:57 PM

my tests...

bmw master
00:51.13
404 MB

bmw patch
00:57.16
378 MB

head bench frame 62 (multires 4 - 1.9 mio faces) master
06:52.54
2820 MB

head bench frame 62 (multires 4 - 1.9 mio faces) patch
07:08.30
2627 MB

cornell box master
00:32.05
91.6 MB

cornell box patch
00:36.38
91.5 MB

This revision was automatically updated to reflect the committed changes.