Any future plans to support geometry shaders?

[msobanion]

First off, thank you very much for your great software. I am finding Displaz to be very useful for testing out shaders for visualization of terrestrial lidar data. I was excited to see you work for Fugro, I worked for Fugro Consultants in California for about 5 years.

I was wondering if you have thought about supporting a newer version of GLSL so that geometry and tesselation shaders would available?

Thank you for your time and thanks again for your great work.

Best,
Matt O'Banion

[c42f]

Hi, glad that you find this tool useful!

Yes, I've thought about adding support for geometry shaders, and I think this would be useful in some cases. The main change would be work on the C++ side, I think, to ensure the geometry shaders are actually compiled and linked into the shader program.

I suppose geometry shaders should generally be available on the target hardware as they're a pretty old OpenGL feature by now.

[msobanion]

Thanks for the response!
I was thinking about using a geometry shader to visualize pre-computed normal vectors for each point as whiskers. This would be very useful for understanding how the computed normal vectors perform in different parts of the point cloud. The additional geometry may cause too much of a performance hit but it would be interesting to experiment with.

[c42f]

Another approach is to render a little vector on each point using the fragment shader. For an example, see shaders/point_vectors.glsl

[msobanion]

Great, thanks for bringing this to my attention!

[c42f]

The big downside of doing it in the fragment shader is that you've got to manually deal with the projected coordinate system and the pixel coordinates of the fragment patch which can be a bit tricky. It does stress a different part of the GPU pipeline so it may be more efficient, depending on the circumstances.

I found a shader kicking around on my disk which might be closer to what you want - I pushed it to master as an example - see https://github.com/c42f/displaz/blob/master/shaders/point_normals.glsl

[msobanion]

Hello,
Thank you for your help back in August! I ended up using your point normal shader code in a per-point uncertainty calculation and visualization shader I developed for TLS point cloud data. At this point in time, it is meant for only one scan position but I hope to incorporate registration error for multi-scan point clouds and maybe even airborne lidar in the future. I have written a paper that will be published in the ASCE Journal of Surveying Engineering and I plan to upload my shader code as an open-source software resource to be used with Displaz. Before the paper is finalized for publication and the shader code is uploaded I had a question:

While developing this shader, I ran into some interesting behavior when I displayed back-calculated values for horizontal angle (0 to 360 degrees for TLS) based on a scan origin of (0,0,0). When visualizing the change in horizontal angle of the points with a color ramp, the origin of rotation appeared offset from the actual scan origin. I was able to fix this by manually editing the ply point cloud file to include a fake point located at 0,0,0. Any idea why this might be happening in Displaz, like an auto computed point cloud centroid or something? It would be great if manual editing of the ply file was not necessary.

Thank you again for creating Displaz, it was very helpful for the development of my uncertainty shader. I have cited your creation of Displaz in the paper and added you to the acknowledgements.

Matt O'Banion