Allow changing LUT properties of a shape actor

[aecins]

This PR is a follow up to #1581. It allows changing the properties of a LUT table used for visualizing a shape actor using the setShapeRenderingProperties function. The functionality added mimics that of setPointCloudRenderingProperties.
Here is a minimal example code.

[aecins]

@VictorLamoine , can you take a look?

[VictorLamoine]

Yes but not until 4 days!

[aecins]

Sounds good!

[VictorLamoine]

This works great and the code looks clean.
Your example code would really make a nice tutorial, do you mind adding one in an other pull request?

👍

[aecins]

Great, thanks for reviewing the code!
Yes, I think I can make a tutorial that explains how to use LUT's to colour pointclouds in a PCL visualizer. It could explain:

• how to use different data vector sources for the LUT i.e. pointcloud fields or external data vector
• how to change the LUT used for visualization

There are two issues I want to address first:

1. Using an external data vector for a LUT used for a pointcloud (Add ColorHandler to color points using custom data vector #1627).
2. Visualizing vtkPolyData objects that have Scalars set for CellData but not for PointData. This would allow visualizing weighted graphs defined over pointclouds using LUTs. I will create a pull request with more details after this one is merged.

[aecins]

@SergioRAgostinho Actually I believe that this PR is ready to merge. I will add a tutorial in a separate PR once all of the pending changes to the visualizer are complete.

[SergioRAgostinho]

This is targeted for 1.9.0, so we won't be merging this till the 1.8.1 probation period is over.

[aecins]

I see, in that case would it make sense to change the label to "ready to merge"?

[taketwo]

As far as I see, this parameter is not used at all?

[aecins]

Do you mean viewport? Yes, it is not used in any of the setShapeRenderingProperties or 'setPointCloudRenderingProperties' functions. I am not sure why it is there in the first place. Should we remove it?

[SergioRAgostinho]

Was it left there to allow (in the future) individual control over which viewport those properties are applied?

But to be honest that's not the only thing that bothers me with the signatures. The int property should be strong typed to the corresponding enum, like RenderingPropertiesfor instance. Just by reading the function signature description and help, it's impossible to know which properties are accepted.

[VictorLamoine]

Viewport is in pretty much all the functions but sometimes it's not implemented, which is is bad because it lures the user.

Changing the int property should be done in an other PR in my opinion because it must be done everywhere in PCLVisualizer code (including interactor_style.cpp)

[taketwo]

Ok, I understand that it seems to be a convention to have a viewport parameter even if we don't really need it, but I think the documentation should be clear about that it is not used.

Yep, centralized int -> enum conversion would be nice.

[aecins]

I can work on the int -> enum conversion. I have created an issue for that #1692. I will work on it after this PR is merged.

[SergioRAgostinho]

The tutorial you're gonna submit, will it be a single tutorial covering all the rendering properties related PRs you've created in the past weeks/months or is it one tutorial per each? In the latter case I would say to append it as a commit into this PR. In the former, this is indeed ready to ship.

[aecins]

I was thinking of a single tutorial showing all the capabilities of the visualizer and a nice code example showing how to use them (similar to the example code with this PR).