Fixes from IBOIS's dry run

[9and3]

description

This PR introduces small fixes while testing the subtractive chapter and pipeline from IBOIS's side.

fixes

• no more error for the DF_build_assembly, DF_cloud_voxel_downsample, DF_cloud_size_downsample, DF_cloud_normal_estimator and many others as dropped on the canvas
• the assembly preview is been fixed and it is now working for single beams
• added the mean value to all the error compute, visualizer and csv exporter

[eleniv3d]

Small comment here and perhaps not directly related to the PR.. for the case of beam or joint we are using the joint.to_mesh() and beam.to_mesh() that get the input of the MaximumEdgeLength which the user directly changes from the inputs of the Component. This is not the case now for the case where we evaluate the face of each joint where Rhino.Geometry.MeshingParameters.QualityRenderMesh is always used.

[eleniv3d]

I believe Normal Segmentator and Colorize Cloud are still red when dropped on the canvas, otherwise no complaints.

[9and3]

I believe Normal Segmentator and Colorize Cloud are still red when dropped on the canvas, otherwise no complaints.

Would you be able to add a commit to fix this with the if.. catch at the beginning plis? Thanks 👐

btw @eleni I am almost finished with the refactored that you might want to test, I still have it for a couple of hours..I'll pop a message here!

[eleniv3d]

I believe Normal Segmentator and Colorize Cloud are still red when dropped on the canvas, otherwise no complaints.

Would you be able to add a commit to fix this with the if.. catch at the beginning plis? Thanks 👐

btw @eleni I am almost finished with the refactored that you might want to test, I still have it for a couple of hours..I'll pop a message here!

Okie. Done ✔️

In case the checks fail me, let the record show that I tried..

[9and3]

Ok I pushed the refactor components and corresponding Python API for the components: computer-error, visualization and csv exporter.

I'll try to resume what we changed: basically the problem came from the fact that for joins if one was veeery far or there was a missing cloud (due to missing points in the scan) we were not able to establish this. Now we are.
The mechanism is quite simple, we mark the rh_cloud with a string indicating the sanity of it (0=good, 1=too_far, 2=missing_points). In this way the results are not contaminated by clouds that we consider really off.

In the followin image the 0-2 joint is detected as way too far (the scan is on the bottom of the image.

Important:

• this was tested with subtractive pipeline and it works
• the swap in the compute error component is not working for now (I am on it)
• this should be tested with the assembly

[9and3]

In case the checks fail me, let the record show that I tried..

the hereby CI jury has emitted a "not guilty" output

[9and3]

@eleniv3d mesh swap is also fine!