Changing AverageFrames shifts z-position of mesh

[philipbelesky]

Changing the average frames value often (particularly if reducing the value) shifts the Z-axis. Reducing the average frame value shifts it more downwards than reducing increasing the average frame value shifts it upwards. The new position persists until the definition is reloaded. This occurs regardless of analysis type.

Haven't had a chance to dig into this extensively, but it seems like the block withrenderBuffer.Clear(); is not being triggered when it should be (presumably on an averageFrames input change). Does that mean an internal cache of averageFrames needs to be kept so that it can be explicitly compared to the parameter value in order to detect differences? This is how I assumed I would implement #30, but idk if there is a more elegant way to check for changed parameters between solves.

[mariuszhermansdorfer]

Glad you opened this one. I was about to ask you for assessment as well. It happens when you fiddle with sliders, but not when typing a value to a number slider directly.

There is a temporary workaround, when it happens, just increase the number of frames to average to a high number (30) and then reduce it to the desired amount by punching in the number.

This check is for some reason not doing its job properly. It seems to be related to the slider returning weird values while being dragged. https://github.com/mariuszhermansdorfer/SandWorm/blob/c400f8205a5c86e698fa34f8bf1112a73cef5097/SandWorm/SandWormComponent.cs#L169

[philipbelesky]

This is speculation, but could the problem be that the quick change in the variable causes a number of near-simultaneous SolveInstance() calls that create strange outputs because some of the class variables (renderBuffer, pointCloud) are being written to by each of those solves? Or maybe that each change of the parameter cancels an in-progress solve that hasn't finish processing the data? Or maybe there is some interaction with the functions that involve multithreading not being cleaned up.

I'm not really sure how Grasshopper handles scheduling that is triggered internally vs parameter changes, but if any of the above applies we could use BeforeSolveInstance to implement a simple lock that would prevent this?

[mariuszhermansdorfer]

I'm not sure I follow. Which part of code would you like to wrap in the BeforeSolveInstance lock?

[mariuszhermansdorfer]

Fixed with a reset button