PointDeviation Tool Issues

I noticed an unexpected slowdown when using the PointDeviation tool in 8.13.

Open the attached Rhino file, launch the PointDeviation tool and feed it the point cloud and surface in the attached file. Disable “Automatically apply changes”, set ignore to 10, bad point to 8, and good point to 2, and apply. Now increase ignore from 10 to 60. It will then freeze for a bit as soon as the number is entered as it immediately applies the change, WITHOUT the apply button being clicked. This does not happen when you change the other two colour scale values, it remains responsive and the colours don’t change until you actually click apply.

On this cloud it’s not too bad since I reduced the size to something that can be uploaded here but on a larger cloud (or a slower system) it could be unexpectedly frozen for a while. I also tried this in 6.35 and it seems to work as expected there; punching in a larger number in the ignore field doesn’t do anything until I click “Apply”.

On the subject of performance, I want to ask if there’s any possibility of improving performance of the PointDeviation tool in 8. When it was overhauled in 6, it became noticeably and dramatically slower. I’ve done a bit of benchmarking and I’m finding that in Rhino 6, it takes anywhere from 5 to 30 times longer than it did in Rhino 5 to colour or re-colour the same cloud, depending on the specific cloud used and how much the new colour scale setting changes the number of points that need to be coloured. 8 is maybe a tiny bit faster than 6, but still many times slower than 5. My team works with laser scanners that measure up to 2 million points per second, so it adds up fast. If the performance gap between 8 and 5 can at least be reduced, it might save us having to go back and forth between 5 and 8 constantly.

PointDeviationTestSample rh6.3dm (18.5 MB)

Hi Raymond,

I see what you mean with regard to the display updating without the “Automatically apply changes” being checked. That shouldn’t happen. I’ll see if I can get that fixed.

As far as performance in general is concerned, I know that between V5 and V6 the command was ported from native C++ to dotnet. I think that was for the sake of getting it to run on Mac but I honestly can’t remember now if that was the only reason. I’m not smart enough to figure out why there is a performance problem on my own so I’m checking in with one of the geniuses. I’ll update here when I know more.

Tim

Here’s a link where you can monitor progress on this.
https://mcneel.myjetbrains.com/youtrack/issue/RH-85003

Thanks Tim,

Appreciate you taking the time to have a look at this.

RH-85003 is fixed in Rhino 8 Service Release 15