renderkit / ospray Goto Github PK
View Code? Open in Web Editor NEWAn Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
Home Page: http://ospray.org
License: Apache License 2.0
An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
Home Page: http://ospray.org
License: Apache License 2.0
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).
The problem is the usage of ftell() in apps/common/XML.cpp, which only support 32 bits.
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
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.
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.
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:
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
Does volume rendering require lights ?
Anything else I can check ? I assume its fine if the camera is inside the volume.
Thanks!
OSPRay run on anything older than SSE4.1, but does not currently report an error when executed on older machines, it just core dumps.
On develop branch I can't find a way to build the ospray if TBB is not present on the system.
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?
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
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 ()
Hi.
Great looking project!
I'm trying to get the windows binary to run.
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!!
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.
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.
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
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
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.
Some of the examples (Heptane, Forrest, probably more) do not work with 0.9 version. Please update them.
The current control is extremely unpredictable and difficult to use. Classic arcball would resolve this issue.
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
$ ospModelViewer fiu-groundwater.xml --renderer obj --sun-dir -1.5 -1 -1
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,
in ospray/include/ospray/ospray.h
struct box3f { vec2f lower, upper; };
should be
struct box3f { vec3f lower, upper; };
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
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 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?
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.
/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
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.
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.
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.
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]
with latest updates of devel release, the shared volume renderer no longer works. bricked volume still works fine though.
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!
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.
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);
}
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);
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.
Minor thing, but doc/dox/doxyconfig.in uses a hardcoded version number:
PROJECT_NUMBER = "Version 0.7.2, Mar 12, 2015"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.