Should I use Embree or OpenVDB for my raytraced game?

[Joshua_O_]

An expert on sparse voxel octree raytracing suggested to me that Embree may be a better choice than OpenVDB (used in RenderMan, Houdini, and Arnold) for my 3D game idea. The thing is, I want to make a (coherent) raytracing game engine with an almost unlimited size AND resolution (think nanoscale) world. My targets are 32 bit and 64 bit desktops and laptops, so Embree's Intel chip vendor locking (debatable) isn't a problem.

What could be problems are:

• reliance (for best performance) on LLVM (version 3 and still receiving breaking changes) and ICC (non-students must pay to recompile with different flags)
• the BVH implementation hasn't stabilized, right?
• why only single-instance embedding? (I want portals)

OpenVDB is a class of constant depth sparse voxel-like trees with branching factors that decrease closer to the leaves. They allow constant time local and random traversals and modifications and support linear or frustum mappings between (unsigned 32 bit) integral index space and floating point world space. The other half of the design/C++ implementation is about allowing fast flood fills, level sets, CSG, point cloud particle simulations, etc., but those associated functions aren't that important to me.

I haven't thought much about how to implement multi-resolution worlds and portals, but I assume both OpenVDB and Embree's raytracing-aware designs will make performant code easier to write if I can think in pixels and rays rather than hacks with oblique frustums and stencil buffers.

I'd appreciate some advice!
Josh

[SvenW_Intel]

Hi Joshua, I would recommend to use a traditional triangle based representation for your game and Embree can help you to get this fast. The performance when compiling Embree with Clang is good (10% off ICC performance). The internal BVH implementation is something you do not have to worry about when using Embree through the API, as it is entirely hidden (and even changes depending on the platform you are running on). Using the User Geometry feature you can also implement multi-level instancing using Embree, Embree does NOT have Intel vendor chip locking, but runs on all CPUs that support the Intel Architecture (at least SSE2 is required). 

[Joshua_O_]

runs on all CPUs that support the Intel Architecture (at least SSE2 is required)

Which in addition to different BVH implementations makes this rather unportable and Intel dependent.

However, thanks for the advice. Is there anything novel about Embree's BVH implementations besides aggressive SIMD etc? Are there alternative good CPU triangle BVH libraries out there? I've read that OpenSCAD beats CGAL.
EDIT: Not OpenSCAD, OpenCASCADE I think.

[Keymaster · Accepted solution]

embree is not intel-locked, it works just fine on AMD. In fact, speed(amd)/speed(intel) is higher for embree than for my code written without any intent to favor intel.

I am not aware of any library that would guarantee how it is implemented inside. Knowing everything about insides of a library kinda defeats the purpose of actually using a library to save some work.

[BenthinC_Intel]

Hi,

I don't think the internal BVH layout(s) can be considered "Intel" dependent in any way (leaving little vs. big-endian issues aside), however, the ray traversal kernels use Intel-specific SIMD instructions so they will only run architectures which support the x86 SIMD extensions (e.g. SSE2).

OpenSCAD seems to be software for creating 3D CAD objects, and that is quite different from the features that Embree provides.

[Joshua_O_]

embree is not intel-locked, it works just fine on AMD. In fact, speed(amd)/speed(intel) is higher for embree than for my code written without any intent to favor intel.

That's surprising and may have just changed my mind. Also, I thought AVX and all that stuff was Intel specific.

Keymaster wrote:
I am not aware of any library that would guarantee how it is implemented inside. Knowing everything about insides of a library kinda defeats the purpose of actually using a library to save some work.

I suppose I was vague about my usage of the term 'implementation.' Optimizations are fine, but different algorithms altogether is a code smell to me. My real question I guess is where the implementation(s) fall along that spectrum, e.g. in terms of ease of porting the source.

[Keymaster]

Joshua O. wrote:

I suppose I was vague about my usage of the term 'implementation.' Optimizations are fine, but different algorithms altogether is a code smell to me. My real question I guess is where the implementation(s) fall along that spectrum, e.g. in terms of ease of porting the source.

Well... yes. But that is what happens when you hunt for speed. Either way, the API is stench-proof. It shields you from the nasty details with a wall of regression tests and high-level API. Unless you need to touch the implementation directly (which is usually not necessary, the API is highly customizable via custom callbacks), you will be fine.

[Joshua_O_]

Carsten Benthin (Intel) wrote:

OpenSCAD seems to be software for creating 3D CAD objects, and that is quite different from the features that Embree provides.

Whoops, I meant OpenCASCADE.

[Joshua_O_]

Keymaster wrote:

the API is stench-proof. It shields you from the nasty details with a wall of regression tests and high-level API. Unless you need to touch the implementation directly (which is usually not necessary, the API is highly customizable via custom callbacks), you will be fine.

That's fair. As long as the devs are doing their best, then! What's the evidence like about others outside Intel getting involved with source development? I may get into this alongside my game development one day as long as nothing biased-rendering-friendly and better publicized comes along.

[Joshua_O_]

Sven Woop (Intel) wrote:

performance when compiling Embree with Clang is good (10% off ICC performance)

I realized this means Clang needs improvements that have to be reverse engineered from the proprietary competitor. I'm too nooby and unmotivated to do that and doubt Apple will be happy with such shady LLVM efforts.

[Joshua_O_]

One last note. In the end, I chose to port OpenVDB to Nim(rod). Embree, while not stuck with Intel, is stuck with Intel+AMD. Plus without more information I believe noone outside Intel has been able to tackle the source successfully (and the API while awesome discourages contributing?).

I'm still subscribed here, though! Please correct me in time.
Josh