Double precision Embree?

[iraytrace]

Imagine needing mm accuracy for rays that traverse several km. Has anyone looked at using double-precision numbers in Embree? How much code would have to (or want to) change if we were to convert all "float" to "double"?

[svenwoop]

Double precision is more challenging to add. Just changing float->double will not do the job, as we use intrinsics at various places.

[0joshuaolson1]

Could one kludge together some sort of proxy/render target system that renders far away objects as if they were scaled and translated closer?

[iraytrace]

Alas, it isn't the "far away" (like earth-sun) that makes me want double precision. It is the "grains of sand all packed in a can" effect. For example, If the ray passes through a 10m cube I'd like sub-millimeter (actually um) accuracy on all hit locations and distances in that area.

Lee

On 10/3/2015 2:38 AM, Joshua Olson wrote:

Could one kludge together some sort of proxy/render target system that renders far away objects as if they were scaled and translated closer?

— Reply to this email directly or view it on GitHub https://github.com/embree/embree/issues/45#issuecomment-145210040.

[0joshuaolson1]

Same concept, though. Render big scene to small area. This is looking like it'll take some sort of scene graph solution, which may be beyond the scope they're tackling.

[jeremyherbert]

+1 would love to see this for scientific applications, float doesn't quite cut it

[0joshuaolson1]

Would OpenVDB be a better alternative for cases such as this that benefit from scene graphs?

[svenwoop]

OpenVDB is for volumes not triangles.

[0joshuaolson1]

So the recommendation here is to create a scene graph on top of Embree?

[jeffamstutz]

The discussion surrounding a scene graph solution may be more appropriate for an entire rendering solution, such as OSPRay (http://www.ospray.org/). Embree is targeted at quickly building BVHs and traversing ray(s) through them. While this gives you enough to build your own rendering (or simulation) engine on top of it, anything beyond BVHs and ray traversal is outside the scope of the Embree project.

On the contrary, OSPRay is a rendering solution which builds on top of Embree. While the renderers we develop are targeted at scientific visualization, the API is built to be extended any other ray-based problem domain. It is at the level of a rendering engine that something like a scene graph makes sense to implement.

I would like to suggest that you at least take a look at OSPRay and consider if it better fits your needs. Keep in mind that it builds on top of Embree (the projects are developed under the same management team at Intel), so any of the benefits you see in using Embree are/can be directly leveraged in OSPRay. We use ISPC as a shading language, similar to how the ISPC Embree tutorials are built. We have an example scene graph in our "Qt Viewer" sample application, which may be a reasonable starting point for adding features to solve some domain specific problems.

Anyway, if you end up building a scene graph on top of OSPRay or Embree to solve some of the precision issues discussed in this thread, please share if you can. :)

[cstatz]

If you use Embree to implement a rt-based simulation (and explicitly not for rendering) a scene graph won't cut it. Especially when you are nor dealing with smaller object in a large "scene", but with a single large triangular mesh where you want to obtain a solution at global scale. Has there been any further effort or consideration on implementing double precision in Embree?

[jeremyherbert]

Fwiw, I did end up using embree for non-rendering raytracing simulations, and I used double precision maths as well. I was simulating the path/phase change of light propagating through transparent materials (actually a fair bit more, but that isn't relevant.

I used embree to build a conservative BVH, and then wrote custom traversal routines which walked the tree at double precision. As long as the bounding boxes enclose the double precision tris it works fine (which makes sense; the data type has no effect on the "bounding" predicate and could even be int, it just changes the efficiency at which you can traverse). I tested this for a while against a brute force approach, and I never found a case where the results differed.

[Gjacquenot]

I am not an expert in ray tracing, but does this quick and dirty solution would give accurate results:

• use Embree to identify intersected triangles with float precision (32-bit) (meaning down casting inputs (geometry and rays) from 64 bits to 32)
• run a double precision ray intersection algorithm (64-bit) on the id intersected triangle (with 64 bit geometry) to find dimensionless intersection coordinates (u,v)

I guess the error could be on the id of the intersected triangle (wrong id, or missed intersection or possible intersection that should not be)

@jeremyherbert : is your work public domain? It could give some hints on how to implement a better solution.

[jeremyherbert]

@Gjacquenot unfortunately that doesn't work in all cases (I tried it first). Essentially the problem is that depending on the complexity of the geometry, you can miss an intersection due to quantisation of the ray properties like angle. The error becomes more prevalent when the dynamic range in your variables becomes larger. As with all problems of this nature, there are also a bunch of edge cases where you would register an intersection with the wrong triangle due to rounding. Rather than chasing down every last edge case, I just opted to rewrite the tracing part.

My code isn't public; I'm in the process of publishing a paper which uses it in combination with some laser experimental work. I intend to release the tracing parts of the code once that is sorted, under MIT or GPL or something like that. Unfortunately it runs all of the tracing via CUDA, so I doubt Intel would ever be interested in using it. Nvidia makes OptiX which performs a similar purpose but is binary only, single precision only and they definitely didn't seem to care about anything but rendering scenes for Pixar (and the like) when I was writing my code. Nobody seems to really care about scientific ray tracing except for the specialist optical design tool companies like ZEMAX, etc and those tools are cost prohibitive even for small to medium size businesses. So I think in this area writing your own is basically the only option.

PS Kudos to Intel and the embree team for releasing your code as open source! I specifically turfed OptiX because it was too much of a pain working with such an opaque system.

[brainsandwich]

Hi,

I'm bumping this thread a little ; Are there any news regarding double support since January 2018 ? We'd really like to use Embree in the Ocean renderer but we don't want to jump in because of the lack of double precision ...

Cheers

[svenwoop]

Sorry no progress on this. This feature is still on our radar, but it is more complex as a lot of code changes would be required for make this happen. Thus do not expect this feature to come soon.

[a-jp]

Hi,

Could I ask if this still on your radar, or has moved on?

Cheers

[svenwoop]

This is a longer term feature which I would not expect to come soon. Problem is that a seamless implementation of this touches almost all lines of code.

[a-jp]

For debugging only, in cases where I've previously shown that double precision makes a difference (not always by any means, but edge cases) can you recommend (a possibly much slower) open source library that I can fall back on that is able to perform the whole process in full double precision? It would be good for problem cases to run it through something like that just to confirm precision is/isn't the cause. Thanks

[svenwoop]

Maybe have a look at NanoRT.

[wjakob]

I am really eager for this feature as well, if it's possible at some point. We still ship a slow homebrew KDTree as part of Mitsuba/Mitsuba 2 because it turns out there are quite a few people who really need double precision intersection computation (these are scientific applications rather than typical graphics-y workloads: atmospheric simulations, giant forests seen from huge distances, etc.). Would be so nice to get rid of it at some point, since Embree is just way faster.

[starseeker]

@jeremyherbert Did you ever end up publishing your work on the double precision traversal of a conservative embree tree?