Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WindowedSinc smoothing option during grooming scales meshes #1354

Closed
patkins opened this issue Jun 25, 2021 · 8 comments
Closed

WindowedSinc smoothing option during grooming scales meshes #1354

patkins opened this issue Jun 25, 2021 · 8 comments

Comments

@patkins
Copy link

patkins commented Jun 25, 2021

In Studio (v6.1.0 RC12), application of WindowedSinc type smoothing (iterations 1, pass band 0.05) to meshes adjusts the scale of the shapes, such that the groomed surfaces are tiny in comparison to the original surfaces. Use of Laplacian smoothing does not seem to result in a similar issue.

Groomed surfaces
image
Original surfaces
image

@patkins
Copy link
Author

patkins commented Jun 25, 2021

#1273

@patkins
Copy link
Author

patkins commented Jun 25, 2021

Interestingly, the observed scaling seems to be an effect of the number of iterations used, where the use of 10 iterations results in no scaling offset. I then tried a few others (2, 5, and 20 iterations) and there also did not seem to be an offset in scaling.

@akenmorris
Copy link
Contributor

akenmorris commented Jun 25, 2021

https://vtk.org/doc/nightly/html/classvtkWindowedSincPolyDataFilter.html

"Note: Care must be taken to avoid smoothing with too few iterations. A Chebyshev approximation with too few terms is an poor approximation. The first few smoothing iterations represent a severe scaling and translation of the data. Subsequent iterations cause the smoothed polyhedron to converge to the true location and scale of the object. We have attempted to protect against this by automatically adjusting the filter, effectively widening the pass band. This adjustment is only possible if the number of iterations is greater than 1."

Well, you learn something new every day. After reading this, I think we should bottom out at 2 iterations, right? @sheryjoe , @patkins .

@patkins
Copy link
Author

patkins commented Jun 25, 2021

Well at least I'm not crazy. 2 iterations seemed reasonable, so I think that would be appropriate. Thanks for looking into that, @akenmorris!

@sheryjoe
Copy link
Contributor

@akenmorris yes right.

@akenmorris
Copy link
Contributor

I was going to use the same input validator strategy as the Optimize panel, but it's going to be much more complicated for grooming. In the presence of multiple domains, there are unseen parameters on other pages that have to be validated. This is then separate from what the user sees and I'm not sure how to indicate to the user that a parameter on a different domain that's currently not visible isn't valid. For the optimize page, all parameters are seen at all times, so we simply highlight that box in red and then disable the "run" button. But how to indicate this for grooming when not all controls are visible? This will take some thought.

For now, should we just force the iterations up to 2 if something below 2 is given?

@sheryjoe
Copy link
Contributor

For now, should we just force the iterations up to 2 if something below 2 is given?

Yes. Maybe also indicate this min number of iterations in the tooltip.

@akenmorris
Copy link
Contributor

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants