c42f / displaz Goto Github PK

The windows build starts correctly, but segfaults when any data is loaded.

• Use cmake external projects to manage the building of third party dependencies (laszip, pdal).
• Embed a copy of the small number of ilmbase parts which are used + kill of the weird header include situation on windows.
• Migrate from laslib to pdal

Having all files open in a single instance of displaz would be super handy for some use cases. Presumably this would happen through some kind of simple socket IPC mechanism on startup like the old QtSingleApplication class.

Possible code: https://github.com/itay-grudev/SingleApplication

Making the uniform variables const really helps to speed up the default vertex shader since it's a bit of a monster and the shader compiler can optimize out big chunks.

This would mean mapping the user tweakable parameters to const rather than uniform variables, and recompiling each time the user fiddles with the controls. If we also want stuff like the file index to be baked in as a constant, it would also mean having a unique compiled shader for each geometry.

The code has grown to a size where it's worth thinking about structuring things a bit more cleanly for clarity. Any larger branches should be merged first to avoid unnecessary pain.

Grab bag of tasks:

• Consider renaming some of the older classes, for example PointArray
• Rename files after the classes contained therein where it makes sense, including capitalization.
• Consider whether having some subdirectories makes sense. Potential categories include:
  • general GUI stuff
  • 3D rendering
  • file input
  • the dvox tool and associated hcloud utils
  • system utils (IPC, logging, etc)

Eric Li has requested collada mesh support which I guess would be useful... but supporting even a small part of the bloated collada standard is scary as hell! Let's use something like the assimp library (as an optional build time dependency).

It would be helpful for interpretation to have a point height colouring mode. Thanks.

Due to the new selection method, datasets with a single point can't be selected because they have a zero volume bounding box.

Probably best just to change the octree traversal to use a bound/sort strategy for traversal into nodes.

Revision 3e718f8 broke cursor snapping because QVector3D is represented internally by 32 bit floats, even though it uses qreal in the interface which is double precision (wtf qt?)

Solution should be to remove use of the qt vector and matrix classes entirely since we really need to ensure double precision for large offset handling. This will remove the nastyness related to translating between qt and imath types. (Alternatively consider Eigen as a better alternative to imath? That would be a big change though.)

The displaz language bindings call the displaz executable and let it handle IPC (this avoids the need for each binding to fiddle with single instance locking, sockets, speak the IPC protocol, etc.). The displaz process needs to have consistent behaviour across platforms so the bindings are reliable.

Ideally, when running from within a language binding:

• If no GUI is running, a new process is created for the GUI. This ensures that the initial GUI launch doesn't block the calling process. Might be nice for any command line arguments to be communicated via the socket for consistency & code simplicity.
• If the GUI is already running, block until the IPC with the GUI instance has completed. This ensures consistent ordering of commands coming into the socket.

The above is complicated by the fact that on windows, cmd.exe automatically puts GUI executables into the background - this may not be a problem when calling from scripting languages with powerful subprocess management (python, julia), but sometimes you're more or less left with nothing better than the system() call (eg, matlab, C++ without going to platform dependent code or linking against Qt). Useful links about how windows treats GUI programs, and how to make them behave a bit like console programs:

• http://stackoverflow.com/questions/13871617/winmain-and-main-in-c-extended
• http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx

The current code doesn't correctly bound the total number of points (or memory) used when loading files. There should be a way to do this automatically, though with users adding additional files (rather than adding all up front) it might be tricky.

displaz can't load ply files without \n at the end of the file

For small datasets, the near clipping plane is set to a value which is much too large - the points are clipped away just as you get close enough to have a good look.

Setting the OpenGL clipping planes are tricky: you want maximum precision from the depth buffer to avoid z fighting, but the geometry has unknown size. Might be best just to choose it dynamically per frame.

The Outerra blog has a wonderful post about depth buffer precision and analysis of why a perspective correct depth buffer is actually the wrong thing from the point of view of maximizing the available precision: http://outerra.blogspot.com.au/2012/11/maximizing-depth-buffer-range-and.html

It would be nice to have a simple CSV parsing function for point cloud input, since this would allow us to specify arbitrary column names using a really common and simple format.

The current "click to center" method of panning is fast but can be disorienting. Is there something better we can do?

Create UI elements to align the view with the axes.

There's really no excuse for not having this, it should make things 2x faster or more in many cases. Depends on issue #4.

Looks like I got the perspective axes in slightly the wrong direction in View3D::drawAxes(). It's something to do with Clip coordinates being scaled by the aspect ratio, since it works perfectly with a square viewport. Probably should be using the perspective matrix without the aspect ratio scaling or something.

Boring, but useful: it would be great to have the ability to view the list of currently loaded files and turn them on and off from the GUI. Implementing issue #17 will probably make this more pressing.

It's pretty slow right now for large point clouds (naive O(n)). Probably depends on having the octree stuff set up.

It would be useful to have color maps exposed as user-editable shader parameters in the same way as floats and ints are now. Presumably these would just be sampler1D uniforms in the shader. On the UI side, a combo box of standard colormaps might do, with an option to load custom ones from an image file.

The radial trimming is cool, but users often want to do it using a segment instead. Ideally should be able to specify the segment with two clicks and a drag from an orthographic view.

No idea how difficult this will be in the presence of point clouds which actually don't fit on the GPU - need some caching strategy in that case. Not even sure about the performance implications; needs experimentation.

As described on the pointdown mailing list (http://lists.osgeo.org/pipermail/pointdown/2015-February/000004.html), it would be awesome to have support for precomputed point cloud level of detail for visualization, ultimately in a form which is streamable via the web.

The attached ply file (generated by julia bindings) crashes displaz when run as

displaz -shader generic_points.glsl crash.ply

The issue seems to be related to passing a float32 type into a shader variable which should be an integer.

$ xxd crash.ply:

0000000: 706c 790a 666f 726d 6174 2062 696e 6172  ply.format binar
0000010: 795f 6c69 7474 6c65 5f65 6e64 6961 6e20  y_little_endian 
0000020: 312e 300a 636f 6d6d 656e 7420 4469 7370  1.0.comment Disp
0000030: 6c61 7a20 6e61 7469 7665 0a65 6c65 6d65  laz native.eleme
0000040: 6e74 2076 6572 7465 785f 706f 7369 7469  nt vertex_positi
0000050: 6f6e 2031 300a 7072 6f70 6572 7479 2066  on 10.property f
0000060: 6c6f 6174 3634 2078 0a70 726f 7065 7274  loat64 x.propert
0000070: 7920 666c 6f61 7436 3420 790a 7072 6f70  y float64 y.prop
0000080: 6572 7479 2066 6c6f 6174 3634 207a 0a65  erty float64 z.e
0000090: 6c65 6d65 6e74 2076 6572 7465 785f 636f  lement vertex_co
00000a0: 6c6f 7220 3130 0a70 726f 7065 7274 7920  lor 10.property 
00000b0: 666c 6f61 7433 3220 720a 7072 6f70 6572  float32 r.proper
00000c0: 7479 2066 6c6f 6174 3332 2067 0a70 726f  ty float32 g.pro
00000d0: 7065 7274 7920 666c 6f61 7433 3220 620a  perty float32 b.
00000e0: 656c 656d 656e 7420 7665 7274 6578 5f6d  element vertex_m
00000f0: 6172 6b65 7273 697a 6520 3130 0a70 726f  arkersize 10.pro
0000100: 7065 7274 7920 666c 6f61 7433 3220 300a  perty float32 0.
0000110: 656c 656d 656e 7420 7665 7274 6578 5f6d  element vertex_m
0000120: 6172 6b65 7273 6861 7065 2031 300a 7072  arkershape 10.pr
0000130: 6f70 6572 7479 2066 6c6f 6174 3332 2030  operty float32 0
0000140: 0a65 6e64 5f68 6561 6465 720a b176 1478  .end_header..v.x
0000150: 2dce f5bf 018c 8644 aee7 f4bf 0e48 1468  -......D.....H.h
0000160: 6907 e3bf e539 ca33 90eb d9bf e339 54ef  i....9.3.....9T.
0000170: 2d12 d2bf a429 04f9 2dd6 e5bf 6798 b23f  -....)..-...g..?
0000180: 8874 f2bf 7646 4d65 c232 f13f ffba 3de9  .t..vFMe.2.?..=.
0000190: c4de d53f af41 8d35 eb24 ebbf 212f 253f  ...?.A.5.$..!/%?
00001a0: 9080 bdbf 2ef0 5fcb 1240 de3f 3a75 e4ff  ......_..@.?:u..
00001b0: 2134 e83f f049 8f28 219d cb3f cf90 3c2a  !4.?.I.(!..?..<*
00001c0: 28aa 03c0 31c7 4294 ea29 edbf 2751 05e5  (...1.B..)..'Q..
00001d0: deea ed3f 869a 1566 02a1 eabf bd09 d251  ...?...f.......Q
00001e0: b2c2 f13f 0040 8d2a 337d 0540 ca4d fc13  ...?.@.*3}[email protected]..
00001f0: 8994 e6bf 22ec 6a5c 7208 ab3f a1ab e652  ....".j\r..?...R
0000200: c364 f2bf 3422 44f8 ba79 e23f 05f6 cdb5  .d..4"D..y.?....
0000210: 66e2 e0bf f33a 7e16 083d f63f 8a00 da0c  f....:~..=.?....
0000220: 3a6e ba3f 2c91 b9f0 ab7e f13f bf2a 5c76  :n.?,....~.?.*\v
0000230: c16a dc3f 4a04 f506 0d85 e93f 0000 803f  .j.?J......?...?
0000240: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000250: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000260: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000270: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000280: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000290: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
00002a0: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
00002b0: 0000 803f cdcc cc3d cdcc cc3d cdcc cc3d  ...?...=...=...=
00002c0: cdcc cc3d cdcc cc3d cdcc cc3d cdcc cc3d  ...=...=...=...=
00002d0: cdcc cc3d cdcc cc3d cdcc cc3d 0000 803f  ...=...=...=...?
00002e0: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
00002f0: 0000 803f 0000 803f 0000 803f 0000 803f  ...?...?...?...?
0000300: 0000 803f 0a                             ...?.

All the scripting interfaces share a big flaw: if a window isn't open already and multiple plot commands are run in quick succession, multiple windows get opened. This can even cause a window manager crash if enough windows are opened at once. Basically it's embarrassing and potentially disastrous for user system stability!

Fix should be to use proper locking around which displaz instances is going to become the server and actually launch the GUI. Unfortunately QSemaphore and QLocalServer are basically useless for this because they're not robust to process crashes on unix. Instead we need something like a file lock. Too bad QLocalFile is only available on qt >= 5.1 - will need to implement the platform dependent stuff.

Ok, this might be a toy, but it also might be quite useful. See the aqsis PBGI implementation as a reference (or may want the simpler approximation outlined in one of the GPU gems books?)

For example, in the test displaz_native_points.ply, the array elements don't seem to be getting sent to OpenGL quite right. In particular a[1] isn't found when sending the data.

It's a pain to have to type out the same thing all the time or copy and paste.

• Add file->"open shader" menu item to allow glsl files to be loaded from disk
• Add command line option to allow the shader to be read at startup
• Probably want some sort of "set as default" option too, but that depends on issue #1

Nick has asked for the ability to set the position and orientation of the camera via the socket interface. This would be cool and fits in nicely with the general idea of automating displaz from outside the interface.

Eric has asked that points can be classified by hand (and the results saved into an output file). This seems like a good idea - probably want to be able to lasso them with the mouse from various directions to add/remove points. It may be a good idea to take cues from the various mask tools in gimp.

This is required to improved robustness and rendering quality in the presence of unknown point densities.

Leaf nodes should probably contain a reasonably large number of points (1000? 10000?) to ensure the GPU has big chunks to chew on at a time.

At the moment, the user can only tweak the shader for point clouds. It would be great if the edge and face shaders were also available for editing. This will require some UI work to connect the shader editor up to multiple loaded shaders.

It would be useful to have the full 3D distance between points printed when a point is selected. (This is really easy, just don't want to forget it.)

Currently there's no axis labels or coordinate tick labels so it can be hard to orient yourself in the 3D view. I suppose this could be done by hooking into Qt's font rendering system and sending the resulting textures to OpenGL.

For the FPS players out there who undoubtedly won't stop requesting this if it's not supported... and for the potential Oculus Rift support which will require something similar.

Request from Andrew Barker:

Would it be possible to make displaz retain the last used shader parameters?

I would like to be able to set a default background colour, colour mode and point radius.

It's quite useful to be able to measure distances quickly. The basic idea would be to allow two or more points to be selected as a set of points of interest, and draw lines between these with some graphical representation of the distance (also worth putting it in the log window for copy&paste-ability). The (a?) 3D cursor is the obvious graphical element for creating user-defined vertices.

Whatever interface we use, the user should be free to move around with the usual controls between placing of the measurement vertices. 3D programs which don't allow camera motion when in "object creation mode" are irritating. wings3d is an example of a modeling program which correctly allows camera motion even in the middle of creating a geometric primitive.

potree has some useful ideas for this, so it's worth looking at as an example:
http://potree.org/demo/potree_2014.12.30/examples/viewer.html

See also the closely related #26 - these should share almost all the same UI elements; maybe they're even the same feature but with "measurement objects" being temporary by default.

A proof of concept hack shows that user defined points of interest can be very useful. We need

• Creation and deletion of points of interest
• Some system to save them to a file (or possibly the log)
• A way of loading them in again

Since these aren't exactly point clouds, we probably need a new geometry type for them; something that has flexible creation/deletion, and displays the points of interest in a visually distinctive way. Since the user is creating the points, it's probably fine to assume that there's not many of them.

Generalizing the concept, it also makes sense to support user-defined lines and planes since these can be useful for measuring things and creating models by hand for checking against automatically generated geometry. The tricky thing will be to keep this lightweight so that displaz doesn't try to grow into a full-blown 3D modeling program.

Displaz doesn't seem to work well with intel graphics drivers on windows (+ possibly other platforms): points in the foreground go missing, and the depth testing is messed up with foreground points sometimes appearing behind background points.

Create a 32 bit windows build (requested by @scottcarpenter).

Could review some uses of size_t and replace with uint64_t for supporting large files (or at least rejecting them since a 32 bit OS certainly won't be able to load anywhere near 2^32 points into memory).

The socket interface fails to connect when it's hit at rates approximately > 0.1 requests/second. This is really a pain when plotting many datasets using the language bindings.

Fix should be to figure out how to use the QLocalSocket interface properly using non-blocking mode via the event loop.

Let's not restrict ourselves to las files - general attributes shouldn't be too hard to support using pdal and will make things much more flexible. A simple first cut would be to support import from csv files, parsing the header line to figure out variable names which would get handed off to the shader system.

Since windows isn't the main development environment, it would be great to have a continuous build set up. appveyor looks really nice for this and I created an account, but it requires porting to qt5 ( #65 ) unless we want to build qt ourselves.

Particularly in the GLSL code, warnings are emitted by the nvidia compiler about using pre-opengl 3 features which are rather annoying. There's a few other places that deprecated APIs are used as well - should probably fire it up with a non-compatibility context and see what breaks.

Having the GUI seize up when loading a large point cloud is a bit embarrassin; loading in a separate thread would solve this issue.

Working from v0.2-171-g0a37088 on OSX 10.10.2, cmake version 3.1.1, I get the following when I run ninja ilmbase from my out-of-tree build:

[1/3] Performing build step for 'ilmbase'
FAILED: cd /Users/gadomski/Repos/displaz/build/thirdparty/external/ilmbase-prefix/src/ilmbase-build && /usr/local/Cellar/cmake/3.1.1/bin/cmake --build /Users/gadomski/Repos/displaz/build/thirdparty/external/ilmbase-prefix/src/ilmbase-build --config . && /usr/local/Cellar/cmake/3.1.1/bin/cmake -E touch /Users/gadomski/Repos/displaz/build/thirdparty/external/ilmbase-prefix/src/ilmbase-stamp/ilmbase-build
ninja: error: '/Users/gadomski/Repos/displaz/build/thirdparty/external/ilmbase-prefix/src/ilmbase/Half/toFloat.h', needed by 'Half/CMakeFiles/Half.dir/half.cpp.o', missing and no known rule to make it
ninja: build stopped: subcommand failed.

There does not seem to be a src/ilmbase/Half/toFloat.h in my ilmbase-prefix build directory. AFAICT toFloat.h hasn't been created by the toFloat custom command in ilmbase/Half/CMakeLists.txt, but I can't quite suss out why.

[was "Port to Qt5"]

Qt-4.* is basically out of support, and depending on it is a particular problem on OSX due to OpenGL integration issues. It would also be good to have on windows to ease the creation of a windows continuous build on appveyor.

• Less sucky indentation
• Basic emacs-like line editing shortcuts
• Syntax highlighting

This is too much work to do from scratch, but might be plausible if a text editor widget can be taken from another Qt project.

Having the cursor visible while zooming is a bit yuck. It's probably worth hiding it away as done for the custom draggable spinbox stuff.