Numerous updates

[lukehutch]

Viewport now needs an id

[m0glan]

Thank you for your contribution. pcl-java v0.5.0 relies upon PCL 1.8.1; a new version would have to be worked on for 1.9.1 support.

[lukehutch]

Right -- although this is the only API breakage I ran into (it builds fine with this one change). I didn't make a corresponding update to the README.md file to explain that PCL 1.9.1 was needed.

Separate question -- by chance do you have any support for the PCL pointcloud registration methods already written but not checked in? That's what I originally needed, but I didn't discover until I built the code that not much of PCL is covered yet.

[m0glan]

@lukehutch I don't. You are right when you say not much of PCL is covered. I started this project for my former employer with a limited predefined list of features. It's a shame I don't have time to work on this project anymore nowadays. I'll think of a solution or try to delegate the administration of this project to someone else.

[lukehutch]

Thanks, it is a shame -- I was excited to find the project, and assumed more was covered based on the README. I tried some other solutions too to generate a Java API, including Panama (which doesn't support C++ yet) and JNAerator (which didn't support some of the features of the PCL header files). I suppose I'll have to bite the bullet and get my hands dirty with C++!

[m0glan]

Good luck. I'm hoping to return to this project one day since I like the idea a lot. Code is much cleaner and readable in Java than C++ which is usually very attractive for academics.

[lukehutch]

Yes, and it is much, much easier to combine together code from different libraries in Java, by just pulling in a Maven dependency. I think you're right that this would help a lot of academics, but also hobbyists. It's unfortunate that a lot of the electronics and robotics hobby platforms require hobbyists to learn C/C++, since they require a lot of arcane knowledge to use properly.

[m0glan]

Perhaps a shame, but when it comes to costly operations such as pc calculations on millions of points, c++ had an undeniable advantage in performance.

[lukehutch]

BTW the Panama team have started to work on creating Java bindings for C++ libraries automatically, leveraging Clang to compile C++ headers into Java classes. (This works really well for C already.) If you're interested in contributing to that instead, it would solve the problem not just for PCL, but other libraries too. I might try to contribute to this too when I get some more time.

[m0glan]

Sounds great, thanks for that

[lukehutch]

Oops, I'm not sure why pushing to my master branch now sends all commits to this PR! I suppose I needed to create one branch per change? Sorry that these changes are not related to the original PR. I'm not sure how to split them out...

Most of the changes above were to make alloc() called automatically by the NativeObject constructor (following RAII), and to make NativeObject implement AutoCloseable (following Java conventions for resources that need freeing).

[lukehutch]

I haven't figured out yet why all my pushes are ending up in this PR, so I just changed the title of the PR :-D

There was a bit of back and forth during all the commits, so it might be best just to look at a diff of your tree against the final tree in the PR, to see what changes you want to merge, if any.

My goal was to enable point cloud registration through pcl-java, but actually I may not have time to test that now, as I am realizing that the overhead required to support the PCL features I need through JNI requires more overhead than I can really afford, so I'm looking at some other ways to get the pointcloud registration done. (In other words, I may not be able to commit more time to this, but I gave it the college try!)

[m0glan]

Hi, sorry for my slow replies, work. The git workflow you should follow is feature branching. Essentially:

1. Make sure your master is up-to-date with origin (git checkout master && git pull);
2. Create a branch for your feature or bug-fix:

git checkout -b feature/normal-estimation

or

git checkout -b bugfix/memory-issue-fix

3. Push branch to the origin of your fork:

git push --set-upstream origin <branch>

4. Make your feature related changes on the feature branch, add, commit and push them to the origin.

5. Create a pull request from your feature branch (origin of your fork) to the master of the original project.

That's it. This will make changes much easier for me to review over the next weekend since I can take a look at them individually.

[m0glan]

Also, I've skimmed through your additions, looks good ;)

[lukehutch]

Thanks, that's very helpful for future reference, and I appreciate the doc link!

Unfortunately I won't have the bandwidth to go back and split these changes apart for at least a couple of weeks, as I have to devote my time to another project. Sorry for the mess!

[oberdanpinheiro]

@vmoglan do I need to use the IterativeClosestPoint class do you have pcl_java.dll PCL 1.9.1?
Thanks