in ospray/include/ospray/ospray.h

struct box3f { vec2f lower, upper; };

should be

struct box3f { vec3f lower, upper; };

Macbook, SSE target, clang compiler.
Check out master, enable volume viewer and loaders module, then I get:

/Users/wald/Projects/ingowald-ospray/modules/loaders/RawVolumeFile.cpp:98:5: warning: cannot delete expression with
pointer-to-'void' type 'void *'
delete [] voxelData;

Probably appears similarly in other branches.

Currently calling 'rtcGetError' twice; which doesn't make sense since first call to fct clears the error flag, so second call always return 0.
Fix:

diff --git a/ospray/api/LocalDevice.cpp b/ospray/api/LocalDevice.cpp
index 49f48e7..677137f 100644
--- a/ospray/api/LocalDevice.cpp
+++ b/ospray/api/LocalDevice.cpp
@@ -61,9 +61,10 @@ namespace ospray {
embreeConfig << " threads=1,verbose=2";
rtcInit(embreeConfig.str().c_str());

•  if (rtcGetError() != RTC_NO_ERROR) {
  

•  int err;
  

•  if ((err = rtcGetError()) != RTC_NO_ERROR) {
   // why did the error function not get called !?
  

•    std::cerr << "#osp:init: embree internal error number " << (int)rtcGetError() << std::endl;
  

•    std::cerr << "#osp:init: embree internal error number " << err << std::endl;
   assert(rtcGetError() == RTC_NO_ERROR);
  

  }

Reproduce: use modelviewer on arabic_ppm.obj model, then randomly pick vairous points on the model - sometimes it'll work, sometimes it'll return 'no hit' even though it should.

Hi.
It is stated that windows support is experimental.

Is volume rendering working on windows ? Is qt the only reason the volume viewer is excluded from the build ?

My code runs but I get a white background

These are my steps

1. ospInit
2. ospNewCamera, set all properties, ospCommit(camera)
3. ospNewVolume(block_bricked_volume)
4. set volume dimensions
5. set volume voxel type (ushort)
6. ospNewModel
7. ospAddVolume to model
8. ospSetRegion(volume, data, [0,0,0], [128,128,128])
9. ospNewTransferFunction
10. ospSetObject (volume, transferfunction)
11. ospNewRenderer("dvr"), setObject(model), setObject(camera), commit(renderer)
12. commit volume
13. commit world
14. ospNewFrameBuffer
15. ospRenderFrame

Does volume rendering require lights ?
Anything else I can check ? I assume its fine if the camera is inside the volume.

Thanks!

I got a "Illegal instruction: 4" error when I was trying to run the ospVolumeViewer.
If I change cmake option "OSPRAY_BUILD_ISA" to "SSE" then it works fine. Is this a bug of the new runtime ISA selection function? I am using OSX 10.9.5 and my CPU does not have AVX support.

devel branch: 42d8f35
OS: MacOSX 10.8.5
Build: Release build
ISPC: v1.8.0

ospVoluimeViewer sometimes crashes for same input .osp. It looks like there's a memory-related bug in somewhere(near to ospFreeFrameBuffer?).

$ ../ospVolumeViewer input.osp
warning: ospFreeFrameBuffer not yet implemented - ignoring (this means there is a memory hole!)

$ ../ospVolumeViewer input.osp
ospVolumeViewer(48997,0x7fff74c78180) malloc: *** error for object 0x7ff5dbb0e0d8: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

$ gdb ../ospVolumeViewer 
(gdb) b malloc_error_break
(gdb) set args lapP.osp
(gdb) r

…

Breakpoint 1, 0x00007fff8c0a0588 in malloc_error_break ()
(gdb) bt
#0  0x00007fff8c0a0588 in malloc_error_break ()
#1  0x00007fff8c0a9839 in szone_error ()
#2  0x00007fff8c0a7628 in szone_free_definite_size ()
#3  0x00007fff8c0a18c8 in free ()
#4  0x0000000101014ba3 in embree::Scene::build ()
#5  0x000000010100d8bf in rtcCommit ()
#6  0x000000010004e10d in ospCommit ()
#7  0x0000000100015873 in VolumeViewer::VolumeViewer ()
#8  0x0000000100003ba4 in main ()

calls to ospsetregion and dimensions do not seem to have an affect, likely due to the check in blockbricked for ispccode=NULL only updating the ispc code once.

We have to custom modify the epsilon values to not get black speckles. Talking with GregP, this is likely due to our use of instancing not reporting the correct bounding box for the scene.

$ ospModelViewer fiu-groundwater.xml --renderer obj --sun-dir -1.5 -1 -1

ospModelViewer: starting to process cmdline arguments

ospModelViewer: done parsing. found model with

• num meshes : 2 [699706][7682241]
• num instances: 2 [699706][7682241]
• num unique triangles : 8381947
• num instanced triangles: 8381947
  #ospModelViewer: number of instances matches number of meshes, creating single model that contains all meshes
  #ospModelViewer: adding parsed geometries to ospray model
  #ospModelViewer: committing model
  #ospModelViewer: done creating ospray model.
  #ospModelViewer: Adding a hard coded directional light as the sun.
  #ospModelViewer: done creating window. Press 'Q' to quit.
  #ospModelViewer: set world bounds [(-386.703, -228.986, -884.183); (391.012, 227.57, -20.6256)], motion speed 1.24861
  Illegal instruction (core dumped)

Generating and compiling a Visual Studio 2015 project using the latest Intel C++ Compiler 17.0 via:

cmake -T"Intel C++ Compiler 17.0" -G"Visual Studio 14 2015 Win64" -DISPC_EXECUTABLE=C:\Tools\ispc\v1.9.0\ispc.exe -DFREEGLUT_ROOT_PATH=C:\Tools\FreeGLUT\v3.0.0 ..

Generates invalid paths for subproject libraries that are referenced during OSPray linkage:

9>------ Build started: Project: ospray_glut3d, Configuration: Debug x64 ------
9>ipo: : error #11018: Cannot open ..........\Debug\ospray.lib
8>ipo: : error #11018: Cannot open ..........\Debug\ospray.lib
8>ipo: : error #11018: Cannot open ..........\Debug\embree.lib
9>ipo: : error #11018: Cannot open ..........\Debug\embree.lib

Hi,

As it can be seen below the GNU stdc++ headers are colliding with the ones from ospray. I can simply work over for our case but it seems like it will be a long term problem. I think those functions has to be moved into embree space or renamed or put into conditions, but I am not sure about the side effects ( meaning I dont have all the possible hardware to test, especially the MIC ).

/gpfs/bbp.cscs.ch/apps/viz/bbp/dev/ospray/0.8.2/include/ospray/embree/common/sys/intrinsics.h: In function ‘uint64 __rdtsc()’:
/gpfs/bbp.cscs.ch/apps/viz/bbp/dev/ospray/0.8.2/include/ospray/embree/common/sys/intrinsics.h:291:46: error: ‘uint64 __rdtsc()’ redeclared inline without ‘gnu_inline’ attribute
__forceinline uint64 __rdtsc() {
^
In file included from /gpfs/bbp.cscs.ch/apps/viz/bbp/dev/gcc/4.8.3/lib/gcc/x86_64-unknown-linux-gnu/4.8.3/include/x86intrin.h:27:0,
from /gpfs/bbp.cscs.ch/apps/viz/bbp/dev/gcc/4.8.3/include/c++/4.8.3/x86_64-unknown-linux-gnu/bits/opt_random.h:33,
from /gpfs/bbp.cscs.ch/apps/viz/bbp/dev/gcc/4.8.3/include/c++/4.8.3/random:51,
from /gpfs/bbp.cscs.ch/apps/viz/bbp/dev/gcc/4.8.3/include/c++/4.8.3/bits/stl_algo.h:65,
from /gpfs/bbp.cscs.ch/apps/viz/bbp/dev/gcc/4.8.3/include/c++/4.8.3/algorithm:62,

I have a compile problem when building on my Mac 10.9.2 + Apple LLVM version 5.0 (clang-500.2.79).

In ospray/embree-v2.7.1/kernels/xeon/bvh/bvh.cpp, I get the compile error:

  no matching constructor for initialization of 'NodeArea'
lst.push_back(NodeArea(root,empty));

followed by a series of additional (related) errors. I played with the code and put each argument into its own type (to ensure this wasn't an issue of the compiler not being able to figure out which casts to perform) and had no luck ... that is, I believe the compiler has a bug.

I think the compiler is confused because the NodeArea struct is being defined within a routine in bvh.cpp. My fix was to move NodeArea to the class definition in bvh.h. When I did that, everything compiled fine.

I tried the transparency support in the scivis renderer of 0.10 and noticed some strange blocking artifacts on the transparent surfaces. These artifacts only appear on transparent geometry,
it looks fine when they are not transparent. The image has been rendered with accumulation and multiple passes. The more passes, the more evident the block structures become.

Looks like commit ae4890d broke transparency.
Compile vtk master against OSPRay and run ctest -R OSPRayRenderMesh to reproduce.

The gray sphere at 1,2 is too dark now and should look like this:

On develop branch I can't find a way to build the ospray if TBB is not present on the system.

I noticed that the volumes only support "uchar", "float" and "double".
I would like to use it for medical data, which is typically 16bit (or 12bit), so "uint16" would be great to have. Would it be possible to support uint16 as well?

(Currently I convert my data to float, but since that takes 32bits per voxel, I would prefer to stay at uint16).

I did not find a discussion forum, so I write this as an issue instead.

The volume renderer seems to only support a world origin and voxel size, but not a complete
transformation matrix. When dealing with medical data, there is typically a DICOM world coordinate system, into which the volume should be transformed. This includes a translation, rotation and scale.

Does OSPRay support adding such a transformation matrix?
If not, it would be a great feature.

I am not sure if OSPRay already supports multiple volumes. If it does, the transformation matrix would
also be useful for correct rendering of multiple volumes.

I did some tests with transparent meshes and it was unclear to me, which of the different renderer supports transparent meshes. I have transparency in the vertex colors of my meshes, which I pass as "vertex.color" using FLOAT4. None of the renderers seems to use that alpha.
I tested adding a OSPMaterial and added a "d" value of 0.5. This causes the mesh to get transparent in OBJ renderer, but not in the rest of the renderers (AO/SciVis/VolumeRayCaster).

Did I miss something or is this just not implemented?

Look like data is loading correctly, but nothing being drawn. No CPU activity at all.
This was pulled/built from sources today.

(tao:~/local/ospray-data/dragon) > /u/wk/tsandstr/local/ospray/build/ospModelViewer dragon.xml

ospModelViewer: starting to process cmdline arguments

ospModelViewer: done parsing. found model with

• num meshes : 1 [922849]
• num instances: 1 [922849]
• num unique triangles : 922849
• num instanced triangles: 922849
  #ospModelViewer: number of instances matches number of meshes, creating single model that contains all meshes
  #ospModelViewer: adding parsed geometries to ospray model
  #ospModelViewer: committing model
  #osp/trimesh: Verifying index buffer ...
  #osp/trimesh: Verifying vertex buffer ...
  #ospModelViewer: done creating ospray model.
  #ospModelViewer: Adding a hard coded directional light as the sun.
  #ospModelViewer: done creating window. Press 'Q' to quit.
  #ospModelViewer: set world bounds [(-6.83587, -0.431891, -6.93969); (7.11329, 7.60655, 5.10773)], motion speed 0.0201081

Hi,
I downloaded ospray 0.7.1 and installed on a Linux box and ran ospModelViewer with xfrog-forest as shown in http://ospray.github.io/demos.html.
And I got the following segf-fault. I am using ispc 1.8.1

MSG Viewer created. Press 'Q' to quit.
glut3d: setting world bounds [(-6.3012, -5.48216, -5.84341); (303.669, 38.3725, 303.561)], motion speed 0.457437

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5869700 (LWP 37829)]
0x00007ffff76c38e9 in TriangleMesh_postIntersect___un_3C_s[unGeometry]_3E_un_3C_s[unModel]_3E_REFs[vyDifferentialGeometry]REFs[_c_vyRay]unI ()
from /localdisk/wkim3/repo/projects/ospray-0.7.1/build/libospray.so.0
(gdb) bt
#0 0x00007ffff76c38e9 in TriangleMesh_postIntersect___un_3C_s[unGeometry]_3E_un_3C_s[unModel]_3E_REFs[vyDifferentialGeometry]REFs[_c_vyRay]unI ()

from /localdisk/wkim3/repo/projects/ospray-0.7.1/build/libospray.so.0
Backtrace stopped: Cannot access memory at address 0x7f8000007f7fffd8

Interestingly, the debug build ran fine with the model without any issue.

thanks

-wooyoung

I've just downloaded the latest repository and the latest intel ispc.

When i follow the directions, and I try to use ccmake, I get this error:

CMake Error at CMakeLists.txt:20 (CONFIGURE_OSPRAY):
Unknown CMake command "CONFIGURE_OSPRAY".

I don't know how to get around this. Can somebody please help?

Thanks,
Tom T.

OSPRay run on anything older than SSE4.1, but does not currently report an error when executed on older machines, it just core dumps.

The current control is extremely unpredictable and difficult to use. Classic arcball would resolve this issue.

Would be nice to be able to query ospray version during runtime; something like
char *ospGetVersionString();
that returns "release-v0.8.2-osx", "devel--linux" or something like that.

/SharedStructuredVolume.ispc...

const float val110 = accessArrayWithOffset(voxelData,ofs101,voxelOfs); // should be ofs110

self->voxelOfs_dx = bytesPerVoxel;
self->voxelOfs_dy = self->voxelOfs_dx * dimensions.y; // should be dimensions.x
self->voxelOfs_dz = self->voxelOfs_dy * dimensions.z; // should be dimensions.y

The problem is the usage of ftell() in apps/common/XML.cpp, which only support 32 bits.

I am really impressed of the various features that you added to the volume renderer!

I started using the slices geometry with the same volume that I do volume rendering on.
Since the transfer function for volume rendering and the slices is the same, I am somewhat restricted.
I would require an extra transfer function for the slices. Or is there a "cheap" way of copying the volume and setting a different transferfunction?

The same applies to the "isovalus" feature, I think it would be better to provide either an extra transferfunction for it, or to provide a list of colors with the isovalues, one color per isosurface.

Hi,

I am trying to configure OSPRay (master branch) with

cmake -DOSPRAY_ISPC_DIRECTORY:PATH=$ISPC_HOME 
             -DOSPRAY_BUILD_MIC_SUPPORT:BOOL=ON 
             -DCMAKE_CXX_COMPILER:PATH=clang++ 
             -DCMAKE_C_COMPILER:PATH=clang ..

And it keeps saying

CMake Error at ospray/embree-v2.7.1/common/sys/CMakeLists.txt:39 (ADD_LIBRARY):
  add_library cannot create target "sys" because another target with the same
  name already exists.  The existing target is a static library created in
  source directory
  "/export/users/nightly/ospray_test/ospray/ospray/embree-v2.7.1/common/sys".
  See documentation for policy CMP0002 for more details.

And the same for 'simd' and 'lexers' libraries.

I have this problem on master branch and tag v.0.9.0, while I am able to configure and compile tag v.0.9.0RC1.

This bug occurs only if -DOSPRAY_BUILD_MIC_SUPPORT:BOOL=ON flag passed to Cmake, I tried passing in gcc 4.9.1 and clang 3.8 compilers but to no avail. I use ISPC trunk built with LLVM 3.8 if that may be of any importance.

Clang 3.8.0, CMake 3.5.2, Arch Linux.

[ 35%] Building CXX object builddir/ospray/intel64/CMakeFiles/ospray.dir/lights/DirectionalLight.cpp.o
/data/c/ospray-git/ospray/lights/DirectionalLight.cpp:41:28: error: call to 'cos' is ambiguous
const float cosAngle = cos(deg2rad(0.5f_angularDiameter));
^~~
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/cmath:207:3: note: candidate function
cos(float __x)
^
/data/c/ospray-git/ospray/common/../../common/math.h:100:23: note: candidate function
__forceinline float cos ( const float x ) { return ::cosf (x); }
^
/usr/include/bits/mathcalls.h:63:17: note: candidate function
__MATHCALL_VEC (cos,, (Mdouble __x));
^
/data/c/ospray-git/ospray/common/../../common/math.h:123:24: note: candidate function
__forceinline double cos ( const double x ) { return ::cos (x); }
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/cmath:211:3: note: candidate function
cos(long double __x)
^
1 error generated.
make[2]: *_* [builddir/ospray/intel64/CMakeFiles/ospray.dir/build.make:2715: builddir/ospray/intel64/CMakeFiles/ospray.dir/lights/DirectionalLight.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:276: builddir/ospray/intel64/CMakeFiles/ospray.dir/all] Error 2
make: *** [Makefile:150: all] Error 2

In regards to the ospParticle viewer. is the Model class creating a model for each atom that is being created or is it just one model that has all the atoms or particles within it? We are trying to see if there is a way to manipulate the radius of particles independently of others that way we have variety with them. Thank you for any assistance.

Victor Reyes
[email protected]

Some of the examples (Heptane, Forrest, probably more) do not work with 0.9 version. Please update them.

Hi.
I am rendering a volume in OSPRay which I write to a texture and then render on a full screen quad in OpenGL, I then draw other things. I need my OpenGL and OSPRay views to be the same.

I'm having difficulty understanding why my two cameras differ. Should my model view matrix for my OpenGL camera be compatible with OSPRay ?

Thanks!

This is minor but should probably be fixed.

Web page ( http://ospray.github.io/getting_ospray.html ) shows the current directory as "/Projects" instead of "/Projects/ospray/release" (or probably just "release" assuming a typical prompt setting) when running the "ccmake" and "make" commands.

Create a build directory, and go into it

  user@mymachine[~/Projects]: mkdir ospray/release
  user@mymachine[~/Projects]: cd ospray/release

Open the CMake configuration dialog

  user@mymachine[~/Projects]: ccmake ..

Make sure to properly set build mode, desired Instruction set to build for (SSE, AVX, AVX2), enable the components you need, etc; then type ’c’onfigure and ’g’enerate. When back on the command prompt, build it using

  user@mymachine[~/Projects]: make

You should now have libospray.so as well as a set of sample viewers. You can test your version of OSPRay using any of the examples on the OSPRay Demos and Examples page.

Prompts should actually look something like:

  user@mymachine[~/Projects]: mkdir ospray/release
  user@mymachine[~/Projects]: cd ospray/release
  user@mymachine[release]: ccmake ..
  user@mymachine[release]: make

Minor thing, but doc/dox/doxyconfig.in uses a hardcoded version number:

PROJECT_NUMBER = "Version 0.7.2, Mar 12, 2015"

The problem is that rtcSetErrorFunction is called at multiple places before rtcInit() is called,
namely in

Device::Device()
LocalDevice::LocalDevice(int __ac, const char *__av)

This will then run into assert(g_device);

RTCORE_API void rtcSetErrorFunction(RTCErrorFunc func)
{
RTCORE_CATCH_BEGIN;
RTCORE_TRACE(rtcSetErrorFunction);
assert(g_device);
if (g_device) g_device->error_function = func;
RTCORE_CATCH_END(g_device);
}

Hi,

When building OSPRay with MIC support, the compiler (gcc 4.9.1) says that symbol 'usleep' in /ospray/ospray/embree/common/sys/platform.cpp file is undefined. (at least in v0.9.0RC1). When I add '#include <unistd.h>' to this file, the error goes off.

Is it my environment, or it is a bug?

with latest updates of devel release, the shared volume renderer no longer works. bricked volume still works fine though.

Hi.
Great looking project!

I'm trying to get the windows binary to run.

1. I installed the intel redistributable to get libmmd.dll.
2. After that I also need embree.dll, which I got from https://github.com/embree/embree-renderer-bin/tree/v2.1_win
3. ospModelViewer.exe then crashes with "The procedure entry point could not be found" which seems to be related to the embree dll being different to whats expected.

OSPRay also heavily uses Embree; however, OSPRay directly includes its own copy of Embree, so a special installation of Embree is not required.

I assume thats not the case for the windows version ? Please help me to get this running.

Eventually I'd like to use the .lib and .h files and build a windows application with msvc, I don't have access to an intel compiler, I assume that should be possible with your binary windows release ?

Thanks!!

Hello,

I'm able to compile the tutorial doing the following:

g++ ../apps/ospTutorial.cpp -I ../ospray/include -I .. -I ../ospray/embree/common ./libospray.so -o ospTutorial

But when I try to execute it, i get the following error:

./ospTutorial: error while loading shared libraries: libospray.so.0: cannot open shared object file: No such file or directory

the libospray.so.0 exists in that directory, so I'm not sure what the issue is. My apologies in advance for this basic question!

thanks,
Tom