point_cloud_viewer icon indicating copy to clipboard operation
point_cloud_viewer copied to clipboard

NodeNotFound error in build_octree

Open lukehutch opened this issue 5 years ago • 2 comments

I get the following when running build_octree:

target/release/build_octree --num_threads 16 ~/Input.ply --output_directory ~/Octree
Determining bounding box: 1909129216 / 1909129216 [======================================================] 100.00 % 75083.64/s Creating octree structure.
Splitting r which has 1909129216 points (19091.29x MAX_POINTS_PER_NODE).
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(NodeNotFound, State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })', src/libcore/result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(NodeNotFound, State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })', src/libcore/result.rs:1165:5
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(NodeNotFound, State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })', src/libcore/result.rs:1165:5
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error(NodeNotFound, State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })', src/libcore/result.rs:1165:5
thread 'main' panicked at 'WaitGroup explicitly poisoned!', /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped-pool-1.0.0/src/lib.rs:457:13

The .ply file has this header:

ply
format binary_little_endian 1.0
element vertex 1909129216
property float x
property float y
property float z
property float key
end_header

I can't provide the raw data, unfortunately -- the file is huge, and the data is proprietary.

I will work on getting the backtrace with RUST_BACKTRACE=1, but it will take several hours to run this again (#395).

Possibly related fixed bug: #209 -- how can node finding be made robust, since this has been an issue in the past (presumably for different reasons)?

lukehutch avatar Jan 17 '20 12:01 lukehutch

build_octree unfortunately currently is hard coded to assume r, g, b as well as intensity information in addition in the ply file. It's been on the wish list for a while to make it dynamic... you are welcome to dig into the code and open a PR.

feuerste avatar Jan 17 '20 12:01 feuerste

Could this at least be documented somewhere? And it would be helpful if the program bombed right at the beginning, with a more helpful error message, rather than many hours into processing with NodeNotFound if the required fields are not present...

key is the intensity value in this case (there is no color information). Maybe that should be specified in a commandline switch? If color is not present, it should probably default to something like white/gray, just as it looks like the current code can handle intensity not being present.

I have zero knowledge or experience with Rust, and very limited time to work on this unfortunately :-/

lukehutch avatar Jan 17 '20 13:01 lukehutch