Intel® Embree Ray Tracing Kernels
Discussion forum on the open source ray tracing kernels for fast photo-realistic rendering on Intel® CPU(s)
279 Discussions

Is it advisable to intermix User-defined and Non-user-defined geometries in a scene?

s_schimper
Novice
1,681 Views

Hello,

 

in the past, I have worked on the integration of Embree into our home renderer. Our home renderer supports different geometry types, some of them analytically described (e.g., spheres, cylinders, hyperbolas, etc.), and two of them (triangles and quadrangles) described by an array of vertices and an array of indices.

 

For my integration of Embree, I initialize the analytically described shapes as User-defined geometries, triangles with RTC_GEOMETRY_TYPE_TRIANGLE, and quadrangles with RTC_GEOMETRY_TYPE_QUAD. The reason for this being that I want to profit from the fact that ray tracing Embree-internal shapes is more efficient than ray tracing User-defined geometries.

Although I encountered some problems with this approach (mainly the values of the RTCRayHit struct being overwritten), I managed to work my way around this issue.

 

My question: Our renderer is targeted towards Computer Graphics researchers, who usually render virtual scenes with low geometrical complexity, and my "work-around" works for such scenes. However, I believe this approach may introduce further issues in my case, when rendering, say, production-ready scenes with a huge amount of geometries in the scene (the use case Embree was originally designed for).

Would you generally recommend intermixing User-defined geometry and Non-user-defined geometry in a scene for ray tracing with Embree?

 

Thank you very much in advance for your help and support. Have a nice day!

0 Kudos
1 Solution
BenthinC_Intel
Employee
1,668 Views

Yes, mixing user-defined geometry (for geometries which Embree does not support natively) and supported geometry types is absolutely fine. If Embree natively supports a geometry/primitive type the underlying implementation is typically faster and more efficient than an "emulated implementation" using user-defined geometry. Also Embree will typically intersect "simpler" geometry like triangles/quads first before intersecting more complex primitives like user geometry. This helps with distance-based culling during BVH traversal for the more complex primitive types.

View solution in original post

0 Kudos
2 Replies
BenthinC_Intel
Employee
1,669 Views

Yes, mixing user-defined geometry (for geometries which Embree does not support natively) and supported geometry types is absolutely fine. If Embree natively supports a geometry/primitive type the underlying implementation is typically faster and more efficient than an "emulated implementation" using user-defined geometry. Also Embree will typically intersect "simpler" geometry like triangles/quads first before intersecting more complex primitives like user geometry. This helps with distance-based culling during BVH traversal for the more complex primitive types.

0 Kudos
s_schimper
Novice
1,658 Views

Thank you very much for your clarification!

0 Kudos
Reply