tut3, tut6 run, but don't render anything other than a black screen

Hi

Is there any possible to support more primitives such as particles, volume, and implicit surface ? That would be cool, thanks !

Once again would like to thank you guys for the amazing library!

We're having issues with the recent 2.4 update on Mac Pro with Xeon processors. Embree crashes somewhere in background threads on that computer, but runs just fine on other non-Xeon Macs and PCs.

Replacing 2.4 with 2.3.3 immediately fixes the issue, so I believe something went wrong between these two releases.

The Mac Pro has model number A1186 and has two Intel Xeon 5150 processors. We don't have access to that Mac, as it is our customer's one, so can't do more tests. You have also changed the way debug symbols are stored in 2.4, so Google Breakpad can't parse it anymore, so we don't have a lot of information about the crashes. Here's what we have:

Operating system: Mac OS X
                  10.10.1 14B25
CPU: amd64
     family 6 model 15 stepping 11
     8 CPUs

Crash reason:  EXC_BAD_INSTRUCTION / 0x00000001
Crash address: 0x111623639

Thread 25 (crashed)
 0  libembree.2.4.0.dylib + 0x1c6639
    rbx = 0x0b0a0c90   r12 = 0x0b0a0db0   r13 = 0x0b0a0da0   r14 = 0x057763f8
    r15 = 0x0b0a0c90   rip = 0x11623639   rsp = 0x0b09ed70   rbp = 0x0b0a0740
    Found by: given as instruction pointer in context 

There are other threads at the same address, so this looks like a worker thread waiting for something.

If this is not enough, we can provide the application and instructions on reproducing the issue.

Thank you.

My processor is an Intel i5 2500k, which reportedly supports the AVX instruction set but not the AVX2 instruction set. I encounter the following errors when building on 64-bit Linux:

$ cd build && cmake .. # same results with -DTARGET_AVX=on -DTARGET_AVX2=off
$ make
...
Scanning dependencies of target embree_avx
[ 10%] Building CXX object kernels/xeon/CMakeFiles/embree_avx.dir/bvh4hair/bvh4hair.o
In file included from /home/tom/github/embree/common/simd/avx.h:34:0,
             from /home/tom/github/embree/common/math/vec3.h:27,
             from /home/tom/github/embree/kernels/common/default.h:30,
             from /home/tom/github/embree/kernels/common/accel.h:19,
             from /home/tom/github/embree/kernels/xeon/bvh4hair/bvh4hair.h:21,
             from /home/tom/github/embree/kernels/xeon/bvh4hair/bvh4hair.cpp:17:
/home/tom/github/embree/common/simd/avxf.h: In function ‘embree::ssei embree::convert_to_hf16(const embree::avxf&)’:
/home/tom/github/embree/common/simd/avxf.h:300:34: error: there are no arguments to ‘_mm256_cvtps_ph’ that depend on a template parameter, so a declaration of ‘_mm256_cvtps_ph’ must be available [-fpermissive]
 return _mm256_cvtps_ph(a,mode);
                              ^
/home/tom/github/embree/common/simd/avxf.h:300:34: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/tom/github/embree/common/simd/avxf.h: In function ‘embree::avxf embree::convert_from_hf16(const embree::ssei&)’:
/home/tom/github/embree/common/simd/avxf.h:304:29: error: ‘_mm256_cvtph_ps’ was not declared in this scope
 return _mm256_cvtph_ps(a);
                         ^
make[2]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/bvh4hair/bvh4hair.o] Error 1
make[1]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/all] Error 2
make: *** [all] Error 2

With gcc 4.8.2 x86_64-linux-gnu. Same results with clang 3.2-11 x86_64-linux-gnu.

After some research, the _mm256_cvtph_ps intrinsic depends on the FP16C feature set. Is this a requirement for the AVX code path, and, if so, could it be documented for the interest of people encountering the same problem in the future? Thanks!

Using the precompiled binaries it looks like Embree can trace packets of 8 rays just fine on my processor, so it appears to be a software problem (or maybe the offending instructions are never called).

We have stumbled on the unfortunate situation where two versions of embree are used within the same application (a plugin also uses embree). In that case the two versions of embree clash already at the instant that rtcInit() is called for the second time. We worked around this by renaming our dlls/so files, which is an ugly hack.

We would prefer to have a solution where embree provides an execution context and can thus be initialized multiple times.

What's the best way to encode videos based on embree output?

Are there any ispc libraries which provide the usual helper functions like cross, dot, noise, etc.?

Hi guys, there are no code-related issues below, just the installation and integration related ones.

• (Windows) please bring back the ZIP files, installers are pain and I believe that in most cases the DLLs and headers end up somewhere in the project subfolder, controlled by VCS. Let us simply unpack the new version there;
• (Windows) please, bundle a proper TBB dlls, or provide at least an URL where to get them. I had to Google for them and hope the one I've downloaded will work fine in all the possible scenarios;
• (Mac) both libtbb.dylib and libtbbmalloc.dylib that you provided require mac64/libcilkrts.5.dylib which is not provided, so the files cannot be loaded. I had to replace both files with the other ones from the TBB for OSX I've downloaded, but again - will they work just fine on all the CPUs? Not sure.
• (Mac) It would be really nice to see the file names instead of full paths to TBB dylibs, when you do otool -L libembree.2.5.0.dylib - the reason is that all three files will most likely end up in the same folder of a bundle and will hardly be installed in the /opt/ folder.

Implementing the above will definitely save some time and nerves to the library users.

Thanks for the great library!

Hi guys,

this line in sys/platform.h

define align(...) __attribute((aligned(VA_ARGS)))

breaks std::vector on OSX 10.9.1, Xcode 5.0.2

The reason is vector has a __align in it.

_LIBCPP_INLINE_VISIBILITY
static size_type __align(size_type __new_size) _NOEXCEPT
    {return __new_size + (__bits_per_word-1) & ~(__bits_per_word-1);};

A simple workaround is to #include at the top of sys/platform.h, but that seems clumsy. I'd say the __align macro needs to be something else.

Without this operator any
Ref t = ...;
T* ptr = ....;
t = ptr;
will require a temporary const Ref(t) in the 't=ptr' assignment, requiring an extraneous incRef/decRef int he constructors/destructors of that temporary.

First of all, thanks for the amazing library guys!

We're having an issue with embree 2.3.3 on 32-bit windows configuration in the low-memory conditions. We basically allocate some large buffers, load large textures and there's no much memory left for embree's internal structures, so when we call rtcCommit() we get the std::bad_alloc exception somewhere inside the embree worker thread.

Unfortunately, there is no way for us to catch it somehow to handle and report to the user. Application simply crashes. rtcSetErrorFunction() doesn't help, as the callback doesn't get called at all.

It would be really nice if you somehow handled this inside the rtcCommit() call and simply return an error code.

First of all, I want to let your team know that this ray tracer is excellent.

I've been using embree 2.3.3 on Linux to accelerate the ray tracing operations in an electromagnetics solver, which uses static scenes with triangles (using RTC_SCENE_STATIC) for world geometry. Execution of the solver returns slightly different results between runs.

I've tracked this down to the intersection tests for a handful of pixels (using rtcIntersect()) returning different primIDs between runs. Using a small test program I experimented with ray tracing the same scene multiple times. If the same scene object was used, it did not yield different results. Destroying the object and rebuilding the scene between ray traces causes the primIDs to occasionally differ. Digging a little further I forced the scene build to use a single CPU thread with rtcCommitThread(), and the primIDs are again consistent between runs. Is that the intended behavior?

Host system CPU is Intel Core i7-3770 (with avx).

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"?

In issue #42 Sven indicated:

We skip all geometry with values greater than 1.844E18

Can we get a constant (eg, #define RTC_MAX_BOUND 1.844E18) in the embree headers for this?

Additionally, if embree could somehow signal that the bounds had been exceeded that would be good.

I downloaded embree-2.2.zip from the main website and have been trying to get it to build in Windows. I've been struggling with it for a couple hours and still can't get a functional build.

Using VS2010:

• The debug build, either 32-bit or 64-bit, fails with a bunch of errors that look like this:

  libcpmt.lib(cout.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in acceln.obj
  

  This type of error is usually caused by trying to link release-build libs or objs into a debug build, or vice versa. libcpmt.lib here is the CRT, which implies a release CRT is trying to get linked in the debug build. However the project settings appear to have the debug CRT correctly selected, so I'm at a loss as to what is going on here.

• The 32-bit release build compiles and links OK, but then all the tutorial apps crash on startup. It appears the cause of the crash is an attempt to use the movaps instruction on a non-16-byte-aligned address. The callstack is as follows:

  embree.dll!embree::BVH4::BVH4(const embree::PrimitiveType & primTy={...}, void * geometry=0x00000000)  Line 129 + 0x49 bytes    C++
  embree.dll!embree::VirtualAccel::VirtualAccel(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & ty="bvh4", std::vector<embree::AccelSet *,std::allocator<embree::AccelSet *> > & accels=[0x00000000]())  Line 42 + 0x23 bytes    C++
  embree.dll!embree::TwoLevelAccel::TwoLevelAccel(std::basic_string<char,std::char_traits<char>,std::allocator<char> > topAccel="bvh4", embree::Scene * scene=0x03c002c0)  Line 27 + 0x6f bytes   C++
  embree.dll!embree::Scene::Scene(RTCSceneFlags sflags=RTC_SCENE_INCOHERENT, RTCAlgorithmFlags aflags=RTC_INTERSECT1)  Line 128 + 0x3a bytes  C++
  embree.dll!rtcNewScene(RTCSceneFlags flags=0x03c002c0, RTCAlgorithmFlags aflags=RTC_INTERSECT1)  Line 367   C++
  tutorial00.exe!device_init(char * cfg=0x002d100c)  Line 113 C++
  tutorial00.exe!embree::main(int argc=0x00000001, char * * argv=0x01d52608)  Line 101    C++
  tutorial00.exe!main(int argc=0x00000001, char * * argv=0x01d52608)  Line 110 + 0x14 bytes   C++
  

  I'm not sure what is the cause of this. Does the lib assume memory allocations will be 16-byte-aligned, perhaps?

• The 64-bit release build seems to work fine.

A couple of other more minor issues with the Windows build:

• The .sln files have Unix line endings (LF only), which appears to confuse the Visual Studio Version Selector. This is arguably a bug in VS but it would be nice to fix this by switching these files to Windows line endings (CRLF).
• embree.vcxproj contains a reference to the nonexistent file vector3f.h, which causes VS to constantly think the project is out of date (see this StackOverflow question).

Finally, it's worth noting that all I wanted here was a 32-bit Windows build of Embree, which isn't provided on the site. 64-bit-only would be fine for me personally, but I'm hoping to use Embree in a project that will ship for both 32-bit and 64-bit Windows. If Embree doesn't build in 32-bit Windows I'll have to find another raytracing lib.

any embree concept for fpgas coming?

nmadd and nmsub definitions in

• common/math/math.h, common/math/vec3.h, common/math/vec3fa.h, common/simd/ssef.h and common/simd/avxf.h (embree)
• common/math/math.h, common/simd/ssef.h and common/simd/avxf.h, common/simd/mic_f.h and common/simd/ssef_mic.h (embree-renderer)

are incorrect:

• nmadd(a, b, c) should resolve to c-b*a (currently resloves to -a*b-c)
• nmsub(a, b, c) should resolve to - b*a-c (currently resolves to c-a*b)

Reference: https://software.intel.com/sites/landingpage/IntrinsicsGuide/

Hi,

I'm hitting assertions on ObjectPartition::Mapping::bin caused by inf values in scale variable. After small debugging it looks like the root cause is the constructor that calculates the scale value by:
scale = select(diag != 0.0f,rcp(diag) * ssef(0.99f_num),ssef(0.0f));
I can fix it for example by changing previous line to:
scale = select(diag > 0.00001f,rcp(diag) * ssef(0.99f_num),ssef(0.0f));

The problems arise when variable diag gets really small. I can try getting some vertex/triangle data also if you need repro for this.

I'm using VS compiled binaries of version 2.3.1 on windows.

make cmakefile now includes ispc.cmake (no way to turn it off any more), which fails if no ispc is found.

OpenSubDiv and Ptex work great together, very weird to see it being removed. :(

https://github.com/embree/embree/blob/master/include/embree2/rtcore_scene.h#L86

I think it's supposed to read "performance reasons, the rtcIntersect16 function should only get"

/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘void embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::splitFallback(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1616:21: error: ‘prims’ was not declared in this scope
         left.extend(prims[centroids[0][i].a].bounds()); //left.extend(centroids[dim][i]);        
                     ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1621:22: error: ‘prims’ was not declared in this scope
         right.extend(prims[centroids[0][i].a].bounds()); //right.extend(centroids[dim][i]); 
                      ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘void embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::createLeaf_sweep(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::Allocator&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::Allocator&, size_t, size_t)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1633:29: error: ‘minLeafSize’ was not declared in this scope
       if (current.size() <= minLeafSize) {
                             ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1650:25: error: ‘bvh’ was not declared in this scope
       *current.parent = bvh->encodeNode(node);
                         ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘void embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::recurse_sweep(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::Allocator&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::Allocator&, size_t, size_t)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1701:39: error: ‘minLeafSize’ was not declared in this scope
             if (children[i].size() <= minLeafSize)
                                       ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1742:25: error: ‘bvh’ was not declared in this scope
       *current.parent = bvh->encodeNode(node);
                         ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘bool embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::checkCentroids(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1865:23: error: ‘prims’ was not declared in this scope
           if (!subset(prims[index0].bounds(), current.geomBounds)) return false;
                       ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1866:23: error: ‘prims’ was not declared in this scope
           if (!subset(prims[index1].bounds(), current.geomBounds)) return false;
                       ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1867:23: error: ‘prims’ was not declared in this scope
           if (!subset(prims[index2].bounds(), current.geomBounds)) return false;          
                       ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘void embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::splitSequential_sweep(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, size_t, size_t)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1890:74: error: ‘prims’ was not declared in this scope
       getBestSweepSplit(bestSplit,current.begin,current.end,centroids[0],prims,tmp,4,0);
                                                                          ^
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp: In member function ‘virtual void embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::createSmallLeaf(embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::BuildRecord&, embree::avx::BVH4TriangleBuilderFastSweep<Primitive>::Allocator&, size_t)’:
/tmp/yaourt-tmp-root/aur-embree-git/src/embree/kernels/xeon/bvh4/bvh4_builder_fast.cpp:1964:22: error: ‘prims’ was not declared in this scope
           local[i] = prims[index]; //prims[current.begin+i];
                      ^
kernels/xeon/CMakeFiles/embree_avx.dir/build.make:445: recipe for target 'kernels/xeon/CMakeFiles/embree_avx.dir/bvh4/bvh4_builder_fast.cpp.o' failed
make[2]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/bvh4/bvh4_builder_fast.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Linking CXX static library ../../libembree_avx2.a
[ 36%] Built target embree_avx2
CMakeFiles/Makefile2:274: recipe for target 'kernels/xeon/CMakeFiles/embree_avx.dir/all' failed
make[1]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

I'm using arch linux using the embree-git PKGBUILD modified to use the devel branch.
CPU is 4790k. Compiler is gcc 4.9.2. Compiling with march=native. Kernel is 3.19CK

Hello,

I'm using the Embree Ray Tracing Kernels v2.6.1 and believe I've found a bug.

I'm seeing rtcIntersect() return different (u,v) hit coordinates for the same ray depending upon whether or not I created the scene with RTC_SCENE_ROBUST, and when ray.dir contains at least one zero component (and intersects the scene).

When RTC_SCENE_ROBUST not is used, the values are correct and map to a point very close to that calculated via "ray.org + ray.dir * ray.tfar".
However when RTC_SCENE_ROBUST is used, the (u,v) values are too large by a factor of about 2, and so they map to some far away point.

I've duplicated this using both rtcIntersect() and rtcIntersect8().

Details about how / what I'm running:

Embree Ray Tracing Kernels 2.6.1 (Aug 12 2015)
Compiler : GCC 4.9.2
Platform : Linux (64bit)
CPU : Unknown CPU (GenuineIntel)
ISA : SSE SSE2 SSE3 SSSE3 SSE41 SSE42 POPCNT AVX F16C RDRAND AVX2 FMA3 LZCNT BMI1 BMI2
MXCSR : FTZ=1, DAZ=1
Config : Release SSE4.1 SSE4.2 AVX AVX2 internal_tasking_system intersection_filter bufferstride

I'm happy to provide more info if needed.

Thanks!
Lou

This is what I get on a straight forward compilation attempt on OS X.

I went full verbose and got as far as:

Apple LLVM version 6.0 (clang-600.0.45.3) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
 "/Applications/Xcode6-Beta5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.7.0 -o ../../tutorial00 -lcrt1.10.6.o -search_paths_first -headerpad_max_install_names CMakeFiles/tutorial00.dir/tutorial00.cpp.o CMakeFiles/tutorial00.dir/tutorial00_device.cpp.o ../../libembree.2.4.0.dylib ../../libtutorial.a ../../libimage.a ../../libtransport.a ../../libtutorial_device.a ../../libembree_sse41.a ../../libembree_sse42.a ../../libembree_avx.a ../../libembree_avx2.a ../../libsimd.a ../../liblexers.a -framework AGL -framework OpenGL -framework GLUT -framework Cocoa /usr/local/lib/libjpeg.dylib /opt/local/lib/libHalf.dylib /opt/local/lib/libIex.dylib /opt/local/lib/libImath.dylib /opt/local/lib/libIlmImf.dylib /opt/local/lib/libIlmThread.dylib ../../libsys.a -lc++ -lSystem /Applications/Xcode6-Beta5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
  "jpeg_std_error(jpeg_error_mgr*)", referenced from:
      embree::loadJPEG(embree::FileName const&) in libimage.a(jpeg.cpp.o)
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_stdio_src(jpeg_decompress_struct*, __sFILE*)", referenced from:
      embree::loadJPEG(embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_stdio_dest(jpeg_compress_struct*, __sFILE*)", referenced from:
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_read_header(jpeg_decompress_struct*, int)", referenced from:
      embree::loadJPEG(embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_set_defaults(jpeg_compress_struct*)", referenced from:
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_CreateCompress(jpeg_compress_struct*, int, unsigned long)", referenced from:
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_read_scanlines(jpeg_decompress_struct*, unsigned char**, unsigned int)", referenced from:
      embree::decompress(jpeg_decompress_struct*) in libimage.a(jpeg.cpp.o)
  "jpeg_start_compress(jpeg_compress_struct*, int)", referenced from:
      embree::compress(jpeg_compress_struct*, unsigned char*) in libimage.a(jpeg.cpp.o)
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_finish_compress(jpeg_compress_struct*)", referenced from:
      embree::compress(jpeg_compress_struct*, unsigned char*) in libimage.a(jpeg.cpp.o)
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_write_scanlines(jpeg_compress_struct*, unsigned char**, unsigned int)", referenced from:
      embree::compress(jpeg_compress_struct*, unsigned char*) in libimage.a(jpeg.cpp.o)
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_CreateDecompress(jpeg_decompress_struct*, int, unsigned long)", referenced from:
      embree::loadJPEG(embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_destroy_compress(jpeg_compress_struct*)", referenced from:
      embree::storeJPEG(embree::Ref<embree::Image> const&, embree::FileName const&) in libimage.a(jpeg.cpp.o)
  "jpeg_start_decompress(jpeg_decompress_struct*)", referenced from:
      embree::decompress(jpeg_decompress_struct*) in libimage.a(jpeg.cpp.o)
  "jpeg_finish_decompress(jpeg_decompress_struct*)", referenced from:
      embree::decompress(jpeg_decompress_struct*) in libimage.a(jpeg.cpp.o)
  "jpeg_destroy_decompress(jpeg_decompress_struct*)", referenced from:
      embree::loadJPEG(embree::FileName const&) in libimage.a(jpeg.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I use homebrew, I also checked my libjpeg.dylib:

nm /usr/local/lib/libjpeg.dylib | grep jpeg_std_error
0000000000017884 T _jpeg_std_error

I was able to compile ospray with no issue, which means that I must have the correct dependencies.

I also checked that the arch is correct, even if it wasn't the error would be different.

I can't tell for sure that I don't have an issue on my environment, but I'm running out of ideas on what to test, I mean, the lib is there and it has the symbols, why won't it link? Is there maybe a mangling issue with ispc or something?

When initializing embree with for example "isa=avx", embree will happily assume the system has avx and crash while executing an illigal instruction. It would be nice to prevent such an initialization with something like

void setCPUFeatures(int features) {
  cpu_features = features & getCPUFeatures();
}

in common/sys/sysinfo.cpp. Right now we end up doing the same on our side, although we would just like to limit the system to avx (not use avx2).

In order to build with custom TBB libraries, the cmake FindTBB.cmake script has the variables TBB_INCLUDE_DIR TBB_LIBRARY and TBB_LIBRARY_MALLOC that previously allowed users to build with a different version of TBB. Now, however, they are always overwritten with *-NOTFOUND strings. Removing the SET(TBB_LIBRARY TBB_LIBRARY-NOTFOUND) command from the cmake script works around the problem. I'm not sure if it is a good solution in general though..

apparently auto-created by cmake, but should in this case by protected by some '#ifdef' - else the header files work only when build from within the embree build system, not when included from other projects.

Pulling from latest and rendering cornell_box_spheres.ecs, I see some odd triangular artifacts on the spheres near the transition from light to dark. Is this expected?

During our testing we noticed that embree 2.6.1 (but also 2.5.0 before that) has different results on systems with avx2 support. Is this expected behavior? The differences may be small (didn't inspect in detail), but lead to large image differences especially in our photon maps with relatively large photons. For us this is, at the moment, sufficient reason to switch off avx2 entirely, which is a shame.

Hey guys,

I am trying to compile on Mac OS X 10.10 (Yosemite) using CMake 2.8.12.2 and am getting this error when compiling for Unix Makefiles as well as when I generate XCode project files and try and compile it there.

clang: error: unsupported argument '-q' to option 'Wa,'

This is the full command I get when I use a verbose makefile:

cd /Users/gerardsimons/Documents/embree/build/common/sys && g++ -D__BUFFER_STRIDE__ -D__INTERSECTION_FILTER__ -D__TARGET_AVX2__ -D__TARGET_AVX__ -fPIC -fvisibility-inlines-hidden -fvisibility=hidden -mmacosx-version-min=10.7 -Wa,-q -DNDEBUG -O3 -Wstrict-aliasing=0 -I/Users/gerardsimons/Documents/embree -I/Users/gerardsimons/Documents/embree/common -I/Users/gerardsimons/Documents/embree/include -o CMakeFiles/sys.dir/platform.o -c /Users/gerardsimons/Documents/embree/common/sys/platform.cpp

Is there something I am doing wrong or is it the new Mac OS version that is causing the trouble?

CMake Warning (dev):
Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake
--help-policy CMP0042" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.

MACOSX_RPATH is not specified for the following targets:

embree

This warning is for project developers. Use -Wno-dev to suppress it.

bvh2hair files are referred to in the MSVC2010 solution but missing in the master/devel branches

In https://embree.github.io/api.html under user defined geometry it indicates that the user should:

unsigned geomID = rtcNewUserGeometry(scene, 2);
rtcSetUserData(scene, geomID, userGeom);
rtcSetBounds(scene, geomID, userBoundsFunction);
rtcSetIntersectFunction(scene, geomID, userIntersectFunction);
rtcSetOccludedFunction(scene, geomID, userOccludedFunction);

The word "Function" is missing from the rtcSetBounds call.

Hi guys, we've just crashed version 2.6.1, but as I see no word about similar issues in the changelog for 2.7, I guess you might want to have a look.

This happened in the middle of a very long rendering, when the scene tree is already built and hasn't changed by us for a while. The rendering worked for two hours, then it crashed:

Thread 26 Crashed:
0   libembree.2.dylib               0x00000001094eb85f embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 175
1   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
2   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
3   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
4   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
5   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
6   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
7   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
8   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
9   libembree.2.dylib               0x00000001094ec27c embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 2764
10  libembree.2.dylib               0x0000000109517700 tbb::internal::function_task<embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool)::'lambda'()>::execute() + 32
11  libtbb.dylib                    0x0000000109bc0dfb tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 699
12  libembree.2.dylib               0x00000001094ec388 embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >, embree::avx::HeuristicArrayBinningSAH<embree::PrimRef, 32ul>, unsigned long, embree::FastAllocator::ThreadLocal2*, embree::BVH4::CreateAlloc, embree::BVH4::CreateNode, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda'(embree::BVH4::Node*, unsigned long const*, unsigned long), embree::avx::CreateBVH4Leaf<embree::Object>, embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long)::'lambda0'(unsigned long)>::recurse(embree::avx::GeneralBuildRecord<embree::range<unsigned long>, embree::avx::BinSplit<32ul> >&, embree::FastAllocator::ThreadLocal2*, bool) + 3032
13  libembree.2.dylib               0x00000001094eb1a2 embree::avx::BVH4BuilderSAH<embree::AccelSet, embree::Object>::build(unsigned long, unsigned long) + 3442
14  libembree.2.dylib               0x0000000109254828 embree::AccelInstance::build(unsigned long, unsigned long) + 24
15  libembree.2.dylib               0x000000010916b8ee tbb::interface7::internal::start_for<tbb::blocked_range<unsigned long>, tbb::internal::parallel_for_body<void embree::parallel_for<unsigned long, embree::AccelN::build(unsigned long, unsigned long)::'lambda'(unsigned long)>(unsigned long, embree::AccelN::build(unsigned long, unsigned long)::'lambda'(unsigned long) const&)::'lambda'(unsigned long), unsigned long>, tbb::auto_partitioner const>::execute() + 1454
16  libtbb.dylib                    0x0000000109bc0dfb tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 699
17  libtbb.dylib                    0x0000000109bbf972 tbb::internal::generic_scheduler::local_spawn_root_and_wait(tbb::task&, tbb::task*&) + 258
18  libembree.2.dylib               0x000000010916a033 embree::AccelN::build(unsigned long, unsigned long) + 243
19  libembree.2.dylib               0x000000010919b853 embree::Scene::build_task() + 99
20  libembree.2.dylib               0x000000010919d7df tbb::interface7::internal::start_for<tbb::blocked_range<unsigned long>, tbb::internal::parallel_for_body<embree::Scene::build(unsigned long, unsigned long)::'lambda1'()::operator()() const::'lambda'()::operator()() const::'lambda'(unsigned long), unsigned long>, tbb::auto_partitioner const>::execute() + 1343
21  libtbb.dylib                    0x0000000109bc0dfb tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 699
22  libtbb.dylib                    0x0000000109bbf972 tbb::internal::generic_scheduler::local_spawn_root_and_wait(tbb::task&, tbb::task*&) + 258
23  libembree.2.dylib               0x000000010919d0a4 tbb::internal::function_task<embree::Scene::build(unsigned long, unsigned long)::'lambda1'()::operator()() const::'lambda'()>::execute() + 132
24  libtbb.dylib                    0x0000000109bc0dfb tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) + 699

Thread 26 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x0000000000000001  rcx: 0x0000000000000000  rdx: 0x00007f96d9f61500
  rdi: 0x0000000149ebaa00  rsi: 0x0000000149e50f10  rbp: 0x0000000149e46330  rsp: 0x0000000149e3aa80
   r8: 0x00000000000006c8   r9: 0x00000000000006c9  r10: 0x00000000c0632227  r11: 0x000000003f7437e9
  r12: 0x0000000149ebaa00  r13: 0x0000000000000000  r14: 0x00007f96d9f61500  r15: 0x0000000149e50f10
  rip: 0x00000001094eb85f  rfl: 0x0000000000010246  cr2: 0x0000000149e3aa80

Logical CPU:     6
Error Code:      0x00000006
Trap Number:     14

here are some other details:

Crashed Thread:        26

Exception Type:        EXC_BAD_ACCESS (SIGBUS)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x0000000149e3aa80

and one more:

Binary Images:
       0x10914a000 -        0x1098c6fe7 +libembree.2.dylib (2) <DC1EFD77-B9F7-367D-AC9C-76296BE3CE64> /Users/USER/Documents/*/Rendering.app/Contents/Frameworks/libembree.2.dylib

We'll try to reproduce it and also try to upgrade to the latest Embree, but as the stack contains no our code, it looks like Embree tried to rebuild the scene during the rendering or something like that, and crashed.

Maybe you have some ideas what could go wrong?

Thank you

Hi, when building Embree 2.5.0 under Visual Studio 2013 and running the verify sample I get an access violation error reading address 0xFFFFffffFFFFffff; the stacktrace is

embree.dll!std::allocator<embree::FastAllocator::ThreadLocal2 * __ptr64>::construct(embree::FastAllocator::ThreadLocal2 * * _Ptr, embree::FastAllocator::ThreadLocal2 * const & _Val) Line 593 C++
embree.dll!std::allocator_traits<std::allocator<embree::FastAllocator::ThreadLocal2 * __ptr64> >::construct<embree::FastAllocator::ThreadLocal2 * __ptr64,embree::FastAllocator::ThreadLocal2 * __ptr64 const & __ptr64>(std::allocator<embree::FastAllocator::ThreadLocal2 *> & _Al, embree::FastAllocator::ThreadLocal2 * * _Ptr, embree::FastAllocator::ThreadLocal2 * const & <_Args_0>) Line 724 C++
embree.dll!std::_Wrap_alloc<std::allocator<embree::FastAllocator::ThreadLocal2 * __ptr64> >::construct<embree::FastAllocator::ThreadLocal2 * __ptr64,embree::FastAllocator::ThreadLocal2 * __ptr64 const & __ptr64>(embree::FastAllocator::ThreadLocal2 * * _Ptr, embree::FastAllocator::ThreadLocal2 * const & <_Args_0>) Line 873 C++
embree.dll!std::vector<embree::FastAllocator::ThreadLocal2 * __ptr64,std::allocator<embree::FastAllocator::ThreadLocal2 * __ptr64> >::push_back(embree::FastAllocator::ThreadLocal2 * const & _Val) Line 1261 C++
embree.dll!embree::ThreadLocalDataembree::FastAllocator::ThreadLocal2::get() Line 101 C++
embree.dll!embree::FastAllocator::threadLocal2() Line 187 C++
embree.dll!embree::avx::CreateAlloc::operator()() Line 47 C++
embree.dll!embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range,embree::avx::BinSplit<32> >,embree::avx::HeuristicArrayBinningSAHembree::PrimRef,32,int,embree::FastAllocator::ThreadLocal2 * __ptr64,embree::avx::CreateAlloc,embree::avx::CreateBVH8Node,int (int, int *, unsigned __int64),embree::avx::CreateLeafembree::Triangle4,void (unsigned __int64) >::recurse(embree::avx::GeneralBuildRecord<embree::range,embree::avx::BinSplit<32> > & current, embree::FastAllocator::ThreadLocal2 * alloc, bool toplevel) Line 165 C++
embree.dll!embree::avx::GeneralBVHBuilder<embree::avx::GeneralBuildRecord<embree::range,embree::avx::BinSplit<32> >,embree::avx::HeuristicArrayBinningSAHembree::PrimRef,32,int,embree::FastAllocator::ThreadLocal2 * __ptr64,embree::avx::CreateAlloc,embree::avx::CreateBVH8Node,int (int, int *, unsigned __int64),embree::avx::CreateLeafembree::Triangle4,void (unsigned __int64) >::operator()(embree::avx::GeneralBuildRecord<embree::range,embree::avx::BinSplit<32> > & record) Line 255 C++
embree.dll!embree::avx::BVHBuilderBinnedSAH::build_reduce<embree::BVH8::NodeRef,embree::avx::CreateAlloc,int,embree::avx::CreateBVH8Node,int (int, int *, unsigned __int64),embree::avx::CreateLeafembree::Triangle4,void (unsigned __int64) >(embree::BVH8::NodeRef & root, embree::avx::CreateAlloc createAlloc, const int & identity, embree::avx::CreateBVH8Node createNode, embree::avx::BVHBuilderBinnedSAH::build::__l3::int (int, int *, unsigned __int64) updateNode, embree::avx::CreateLeafembree::Triangle4 createLeaf, embree::avx::BVH8BuilderSAHembree::TriangleMesh,embree::Triangle4::build::__l10::void (unsigned __int64) progressMonitor, embree::PrimRef * prims, const embree::avx::PrimInfo & pinfo, const unsigned __int64 branchingFactor, const unsigned __int64 maxDepth, const unsigned __int64 blockSize, const unsigned __int64 minLeafSize, const unsigned __int64 maxLeafSize, const float travCost, const float intCost) Line 371 C++
embree.dll!embree::avx::BVHBuilderBinnedSAH::buildembree::BVH8::NodeRef,embree::avx::CreateAlloc,embree::avx::CreateBVH8Node,embree::avx::CreateLeaf<embree::Triangle4,void (unsigned __int64) >(embree::BVH8::NodeRef & root, embree::avx::CreateAlloc createAlloc, embree::avx::CreateBVH8Node createNode, embree::avx::CreateLeafembree::Triangle4 createLeaf, embree::avx::BVH8BuilderSAHembree::TriangleMesh,embree::Triangle4::build::__l10::void (unsigned __int64) progressMonitor, embree::PrimRef * prims, const embree::avx::PrimInfo & pinfo, const unsigned __int64 branchingFactor, const unsigned __int64 maxDepth, const unsigned __int64 blockSize, const unsigned __int64 minLeafSize, const unsigned __int64 maxLeafSize, const float travCost, const float intCost) Line 317 C++
embree.dll!embree::avx::BVH8BuilderSAHembree::TriangleMesh,embree::Triangle4::build(unsigned __int64 __formal, unsigned __int64 __formal) Line 150 C++
embree.dll!embree::AccelInstance::build(unsigned __int64 threadIndex, unsigned __int64 threadCount) Line 42 C++
embree.dll!embree::AccelN::build(unsigned __int64 threadIndex, unsigned __int64 threadCount) Line 142 C++
embree.dll!embree::Scene::build_task() Line 359 C++
embree.dll!embree::Scene::build::__l21::() Line 546 C++
embree.dll!tbb::internal::function_task<void (void) >::execute() Line 895 C++
tbb.dll!000007fef92c544e() Unknown
embree.dll!tbb::task::wait_for_all() Line 733 C++
embree.dll!tbb::internal::task_group_base::wait() Line 140 C++
embree.dll!embree::Scene::build(unsigned __int64 threadIndex, unsigned __int64 threadCount) Line 549 C++
embree.dll!rtcCommit(__RTCScene * scene) Line 637 C++
verify.exe!embree::rtcore_static_scene() Line 1097 C++
verify.exe!embree::main(int argc, char * * argv) Line 3011 C++
verify.exe!main(int argc, char * * argv) Line 3126 C++
[External Code]

I am using Embree 2.5.0
TBB 4.3.2015.301
Intel(r) SPMD Program Compiler (ispc), 1.8.1 (build @ Dec 31 2014, LLVM 3.5)
Microsoft Visual Studio Community 2013 Version 12.0.31101.00 Update 4, under Windows 7.
I copied tbb into the embree folder and renamed it to tbb, then used CMake 3.2.1 to generate the build script for Visual Studio 12 2013 Win64, the only change I made was to specify the location of ISPC. Then I built the ALL_BUILD for Debug configuration, copied the TBB DLLs from tbb/bin/intel64/vc12 into the build's Debug folder (tbb.dll, tbb_debug.dll, tbb_preview.dll, tbb_preview_debug.dll, tbbmalloc.dll, tbbmalloc_debug.dll, tbbmalloc_proxy.dll, tbbmalloc_proxy_debug.dll) and ran verify from the VS IDE.
Thanks.

The readme and API documentation mention the rtcModified function in the instanced geometry section, but this function is nowhere to be found (I grepped the entire repository on many branches and did not find any source code references to "rtcModified"). Is it obsolete, and if so, could the documentation be corrected? Thanks.

Can embree run on KVM? If so, are there any drawbacks? (ie can it still detect AVX support, etc.)

We are experiencing a crash due to illegal instraction with Embree 2.5.1, built in-house with clang. Our user has a MacPro with Core Xeon X5365. I sent him an update including the Embree binary available on this website that seems to fix the problem. I'm wondering what's the difference between the two Embree binaries (is the one available here built with the Intel compiler?)

Process: FluidRay RT (64 Bit) [4586]
Path: /Applications/FluidRay RT (64 Bit).app/Contents/MacOS/FluidRay RT (64 Bit)
Identifier: fluidinteractive.fluidrayrt.pro
Version: 1.1.5 (0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: FluidRay RT (64 Bit) [4586]
User ID: 501

Date/Time: 2015-06-17 04:57:35.700 -0300
OS Version: Mac OS X 10.10.4 (14E36b)
Report Version: 11
Anonymous UUID: F98B6917-0333-90EF-0CD7-1EBE20E82F5B

Sleep/Wake UUID: B5ED52CB-2B42-4AD7-9FC9-3495BD3D3848

Time Awake Since Boot: 15000 seconds
Time Since Wake: 150 seconds

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Application Specific Information:
/Applications/FluidRay RT (64 Bit).app/Contents/Resources/libembree.2.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libembree.2.dylib 0x0000000115c9a329 _GLOBAL__I_a + 25
1 dyld 0x00007fff665fbceb ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 265
2 dyld 0x00007fff665fbe78 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
3 dyld 0x00007fff665f8871 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 305
4 dyld 0x00007fff665f8806 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 198
5 dyld 0x00007fff665f86f8 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 138
6 dyld 0x00007fff665f8969 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 75
7 dyld 0x00007fff665ee063 dyld::runInitializers(ImageLoader) + 89
8 dyld 0x00007fff665f51d1 dlopen + 578
9 libdyld.dylib 0x00007fff8d0aa857 dlopen + 59
10 fluidinteractive.fluidrayrt.pro 0x000000010c432c0c sys::openLibrary(std::__1::basic_string, std::__1::allocator >, std::__1::basic_string, std::__1::allocator > const&) + 300
11 fluidinteractive.fluidrayrt.pro 0x000000010c0c82d7 fluidrayapp::app_manager_t::on_init() + 28455
12 fluidinteractive.fluidrayrt.pro 0x000000010c1406ba FluidRayApp::OnInit() + 42
13 fluidinteractive.fluidrayrt.pro 0x000000010b5612c1 wxApp::CallOnInit() + 65
14 fluidinteractive.fluidrayrt.pro 0x000000010b76b39f wxEntry(int&, wchar_t*) + 47
15 fluidinteractive.fluidrayrt.pro 0x000000010b4580b4 main + 20
16 libdyld.dylib 0x00007fff8d0ab5c9 start + 1

When creating user defined geometry I find that objects whose bounding box min/max values exceed about 1.5E18 never get intersected. For example, very large planes don't show up. Is there some expected limit on the size of a bounding box dimension?

Currently embree cannot be built with glibc 2.5 only because it uses the CPU_COUNT() macro introduced in glibc 2.6. The workaround used in https://github.com/rmanzoni/TauHlt/blob/master/HLTrigger/Timer/src/CPUAffinity.cc also works for embree, at least for gcc.

/local/scratch/embree-2.6.1/kernels/xeon/builders/../../algorithms/parallel_for_for_prefix_sum.h:44:29: sorry, unimplemented: non-trivial designated initializers not supported
parallel_for(taskCount, [&](const size_t taskIndex)
^
kernels/xeon/CMakeFiles/embree_avx.dir/build.make:215: recipe for target 'kernels/xeon/CMakeFiles/embree_avx.dir/builders/primrefgen.avx.cpp.o' failed
make[2]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/builders/primrefgen.avx.cpp.o] Error 1
CMakeFiles/Makefile2:359: recipe for target 'kernels/xeon/CMakeFiles/embree_avx.dir/all' failed
make[1]: *** [kernels/xeon/CMakeFiles/embree_avx.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2

what should I do?

Hi,

When compiling embree with gcc 5.1 (default on Fedora 22), I get this kind of errors:
embree/kernels/xeon/builders/../../algorithms/parallel_for_for_prefix_sum.h:47:51: error: redeclaration of ‘const size_t& taskCount’
const size_t k1 = (taskIndex+1)*state.size()/taskCount

embree/kernels/xeon/builders/../../algorithms/parallel_for_for_prefix_sum.h:44:29: sorry, unimplemented: non-trivial designated initializers not supported
parallel_for(taskCount, [&](const size_t taskIndex)

This is compiling fine with older version of GCC and this was reported and will be fixed in gcc 5.2 (see here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843)

I can work fix the problem by explicitly listing the parameters to capture instead of capturing everything, i.e. using "[&state,&taskCount,...]" instead of "[&]". This has to be done in multiple files from the "algorithms" folder.
I know gcc 5 is not officially supported but I figured this could affect other people and might be helpful.

Best,
Romain

The convenient find_package module for CMake appears to not be included in the binary distributions found on http://embree.github.io/downloads.html.

in common/sys/thread.cpp, the function SetAffinity uses some routines that are not supported by all versions of Windows. Here is the updated function that uses GetProcAddress to test the availability of the required features. It's been tested on multiple windows versions.

void setAffinity(HANDLE thread, ssize_t affinity)
{
OSVERSIONINFO osvi;
ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&osvi);
typedef WORD (WINAPI *GetActiveProcessorGroupCountFunc)();
typedef DWORD (WINAPI *GetActiveProcessorCountFunc)(WORD);
typedef BOOL (WINAPI *SetThreadGroupAffinityFunc)(HANDLE, const GROUP_AFFINITY *, PGROUP_AFFINITY);
typedef BOOL (WINAPI *SetThreadIdealProcessorExFunc)(HANDLE, PPROCESSOR_NUMBER, PPROCESSOR_NUMBER);
HMODULE hlib = LoadLibrary(_T("Kernel32"));
GetActiveProcessorGroupCountFunc pGetActiveProcessorGroupCount = (GetActiveProcessorGroupCountFunc)GetProcAddress(hlib, "GetActiveProcessorGroupCount");
GetActiveProcessorCountFunc pGetActiveProcessorCount = (GetActiveProcessorCountFunc)GetProcAddress(hlib, "GetActiveProcessorCount");
SetThreadGroupAffinityFunc pSetThreadGroupAffinity = (SetThreadGroupAffinityFunc)GetProcAddress(hlib, "SetThreadGroupAffinity");
SetThreadIdealProcessorExFunc pSetThreadIdealProcessorEx = (SetThreadIdealProcessorExFunc)GetProcAddress(hlib, "SetThreadIdealProcessorEx");
if(pGetActiveProcessorGroupCount && pGetActiveProcessorCount && pSetThreadGroupAffinity && pSetThreadIdealProcessorEx &&
((osvi.dwMajorVersion > 6) ||
((osvi.dwMajorVersion == 6) && (osvi.dwMinorVersion >= 1)))) {
int groups = pGetActiveProcessorGroupCount();
int totalProcessors = 0, group = 0, number = 0;
for (int i = 0; i<groups; i++) {
int processors = pGetActiveProcessorCount(i);
if (totalProcessors + processors > affinity) {
group = i;
number = (int)affinity - totalProcessors;
break;
}
totalProcessors += processors;
}

  GROUP_AFFINITY groupAffinity;
  groupAffinity.Group = (WORD)group;
  groupAffinity.Mask = (KAFFINITY)(uint64(1) << number);
  groupAffinity.Reserved[0] = 0;
  groupAffinity.Reserved[1] = 0;
  groupAffinity.Reserved[2] = 0;
  if (!pSetThreadGroupAffinity(thread, &groupAffinity, nullptr))
    THROW_RUNTIME_ERROR("cannot set thread group affinity");

  PROCESSOR_NUMBER processorNumber;
  processorNumber.Group = group;
  processorNumber.Number = number;
  processorNumber.Reserved = 0;
  if (!pSetThreadIdealProcessorEx(thread, &processorNumber, nullptr))
    THROW_RUNTIME_ERROR("cannot set ideal processor");
} else {
  if (!SetThreadAffinityMask(thread, DWORD_PTR(uint64(1) << affinity)))
    THROW_RUNTIME_ERROR("cannot set thread affinity mask");
  if (pSetThreadIdealProcessor(thread, (DWORD)affinity) == (DWORD)-1)
    THROW_RUNTIME_ERROR("cannot set ideal processor");
}

}

Hi guys, there's something wrong with libtbb/tbbmalloc files bundled with the latest osx-version of embree (2.6.1). They work fine, but when it comes to various mach-based operations or code-signing, they fail.

Here's what I get when trying install_name_tool on them:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: for architecture x86_64 object: libtbb.dylib truncated or malformed object (LC_SEGMENT_64 command 2 fileoff field plus filesize field extends past the end of the file)

Here's what codesign tells me:

signing libtbb.dylib
libtbb.dylib: replacing existing signature
libtbb.dylib: main executable failed strict validation

Replacing the files with the ones from TBB project solves the issue (I used 4.3 update 6), so I guess all you need is to simply update the files.

I'm trying to use Embree in an application where I want to collect all intersections between a ray and my geometry. From what I understood, I need to specify an intersection filter function for my geometry. And by not setting the ray's geomID member to RTC_INVALID_GEOMETRY_ID, this function should be called for all hits. However, the function seems to be called only once, even though I'm sure that the ray intersects with other faces.

Is there something I'm missing?

gcc flags specify --std=c++11, which gcc 2.4 doesn't recognize.
removing that flags creates compile errors in parallel_for expressiosns.

I'm having some trouble compiling embree with the following error:

...embree/kernels/common/scene.cpp:599:113: error: ‘fp_settings’ is not a member of ‘tbb::task_group_context’

tbb::task_group_context ctx( tbb::task_group_context::isolated, tbb::task_group_context::default_traits | tbb::task_group_context::fp_settings );

I'm running tbb version 4.2 (latest on ubuntu apt-repositories) and can't seem too find the fp_settings flags within the header. Latest version of gcc, ispc, etc.

If I comment that out that flag, it will compile but not link to tbb, forcing me to turn off tbb. Are you able to replicate this on your system?

We use Google Breakpad to track application crashes. It has a dump_syms utillity that processes binaries and fetches all the symbols to a special file, kind of cross-platform PDB-file. It worked just fine until version 2.4 where you have changed something or simply removed the symbols at all.

I see in the logs that you split the built into "release" and "release with symbols". That's fine, but is there a way we can get the second one, please? So far that symbol-less build makes difficult to report bugs like #22, as we have no symbols at all.

Any ideas?

PS: Thanks for the perfect library!

I tried to build embree 2.3.3 with VS2013 but exactly one file is missing: "resource.h" is included in "kernels/xeon/embree.rc" but does not exist within the entire project.