- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Thank you very much for your clarification!

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page