Loading mesh file into vsnray-viewer failed.

[Hao Wang]

Hi, Szellmann.

The visionary compiling succeed on NVCC 9.2, but a new problem occurred.

When I use the vsnray-viewer to load a mesh file (.obj file), it failed.

Loading model...
Creating BVH...
Ready
Segmentation fault (core dumped)

Could you please give some suggestions or cues about that, thus I can figure out the reason by myself.

Thanks again.

[szellmann-ukoeln]

Ah, this should not happen of course. Would be nice if you would help me find the bug! I assume you cannot share the obj mesh, right? Could you open the core file or restart the application with gdb and check where the application crashes (with thread apply all bt)? From the error message alone it is impossible to tell. Maybe you could paste some of the output (which will probably be huge) or attach it as a file?

…

On Sep 28, 2018, at 5:00 PM, Hao-HUST ***@***.***> wrote: Hi, Szellmann. The visionary compiling succeed on NVCC 9.2, but a new problem occurred. When I use the vsnray-viewer to load a mesh file (.obj file), it failed. Loading model... Creating BVH... Ready Segmentation fault (core dumped) Could you please give some suggestions or cues about that, thus I can figure out the reason by myself. Thanks again. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Hao Wang]

Hi, Szellmann.

Thanks for replying.

Unfortunately, I am unfamiliar with the GDB, but I still try to use it to debug.

The breaking occurred on the rend.event_loop (line 1503) as follow:

Thread 1 "vsnray-viewer" hit Breakpoint 1, main (argc=2, argv=0x7fffffffe378) at /root/Project/Massive_Point_Cloud_Rendering/visionaray/src/viewer/viewer.cpp:1501
1501        rend.add_manipulator( std::make_shared<zoom_manipulator>(rend.cam, mouse::Right) );
(gdb) n
1503        rend.event_loop();
(gdb) n

Thread 1 "vsnray-viewer" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)

The obj file is standard mesh file without texture and can be loaded into meshlab.

Any suggestion?

PS： I also try to use cmake to compile visionaray on windows, and the Visual Studio is more familiar for me, is that available in the near future?

Thanks again!

[Stefan Zellmann]

Could you generate a backtrace right where the application crashes? Commands for that would be

gdb --args vsnray-viewer /path/to/mesh.obj

In gdb you just type (without setting breakpoints)

> run

The application runs and will eventually crash. When it does so, you can generate a backtrace via

> thread apply all bt full

It would be best if you could compiled Visionaray in Debug mode for that (-DCMAKE_BUILD_TYPE=Debug on the cmake command line).

You definitely can compile Visionaray with the Visual Studio Compiler. (I haven't tested Visual Studio + CUDA in a while.) You need to have the dependencies for your specific Visual Studio version as well (Boost, FreeGLUT, GLEW). Then you can just generate a .sln File with Cmake that you can open with Visual Studio.

If you could share the mesh it would be easier, it's probably sth. about the mesh that my obj reader doesn't expect, but I understand if you can't of course.

[Stefan Zellmann]

A few things you could try which might be a bit more accessible than debugging the code and which would be helpful to know:

• You could check if this also happens in GPU mode. For that, you have to start the application in GPU mode from the command line: vsnray-viewer <filename> -device=gpu.

• You could also inspect the obj file. Most obj files I know usually have a structure where you first have long lists of v ..., vn ... and vt ..., followed by a long list of f .... I have seen certain obj files where there's alternating lines of vs and fs. I'm pretty sure actually that my reader will fail on these.

• One last thing you could try w/o having to dig too deep into the code is import the mesh with blender and reexport as obj. I'm pretty confident that vsnray-viewer can read the blender obj exports.

[Hao Wang]

Hi, Szellmann.

Sorry for delaying, I left for the holiday.

I gave up for compiling vsnray-viewer on my Ubunutu desktop. I think such an issue is not related to your software, because the viewer is able to run on -device=cpu but not on GPU. On my case, this is related to the nvidia GPU driver, the OpenGL cannot be running on my local case (but the deep learning framework, like tensorflow can be run on my GPU).

I spend a lot of time to compile your software because I want to see the performance and efficiency on massive point cloud rendering on your software, is there any other good open source software is available for the job of massive point cloud rendering?

I still hope to run your software on the window, the cmake file on windows will be available soon?

Thanks a lot.

[Stefan Zellmann]

Hi,

I'm not sure what's best for point cloud rendering, GPU rasterization or ray tracing. GPU gives you hardware acceleration, ray tracing gives you acceleration data structures. Software I know that can do point cloud rendering with OpenGL (not ray tracing) is https://github.com/hlrs-vis/covise and https://github.com/CalVR/calvr, but both are full-fledged visualization systems and are not so easy to compile and use. I'm sure there are other programs, but I'm no expert in this field.

To give you an idea, we use Visionaray to render a 97,000,000pts point cloud on a FullHD screen at 10 to 15 FPS on a GeForce GTX 1080 Ti. But I'm sure that OpenGL can also be fast, probably even faster.

As for your installation, I would recommend the following:
Check if HW accelerated rendering works. Therefore I would run glxinfo, it should output something useful like a list of visuals, driver info, OpenGL extensions etc. You can also run glxgears.

If this works, I would check the CUDA installation:
cd /usr/local/cuda/samples/1_Utilities/deviceQuery
sudo make
./deviceQuery
should print sth. useful. If not, you have an issue with your installation.

vsnray-viewer cannot directly render point clouds, you would have to do some coding.