11–19 of 19 posts
Earlier quoted context omitted.
> This is sort of neat but not really useful and not novel. Who said it had to be? It is a blog post, not a SIGGRAPH paper!
Maybe it was not polite of him to dismiss the blog post (and maybe that wasn't his intention), but I do appreciate that he provided references to prior art, and also took the time to put them in context.
This honestly seems like a standard approach to smoothing for computer vision (not to say, this isn't different in a technical sense).
This is sort of neat but not really useful and not novel. The reason it isn't novel is that people have been smoothly filling holes via various polynomials and other smooth curves for the last twenty years. I wrote my first attempt in 1997 as an undergraduate. In real life you have contradictory information given you to from a 3D scanner. there are multiple surfaces that seem to intersect and do not technically make…
My first thought was, this will be great for fixing the annoying gaps created by bad STL exports.
A weakness of this method is that it globally changes the entire mesh! That's bad. You might lose important detail elsewhere. I wonder if those refinement and unrefinement steps are really necessary or not?
This is sort of neat but not really useful and not novel. The reason it isn't novel is that people have been smoothly filling holes via various polynomials and other smooth curves for the last twenty years. I wrote my first attempt in 1997 as an undergraduate. In real life you have contradictory information given you to from a 3D scanner. there are multiple surfaces that seem to intersect and do not technically make…
I agree with you mostly. I just think that this is an interesting usage of variational calculus, which is not that well understood by other programmers, so I wanted to write this article about this, in order to introduce other programmers to the topic. And also because I thought the literature about this out there wasn't really that readable, and I always think there is value in writing expository texts like this.
My first thought was, this will be great for fixing the annoying gaps created by bad STL exports.
For visualization or maybe 3D printing, yea. But for finite element analysis, you don't want smooth filling at weird corners/etc. A flat surface is more efficient since it can have fewer mesh elements. A weakness of this method is that it globally changes the entire mesh! That's bad. You might lose important detail elsewhere. I wonder if those refinement and unrefinement steps are really necessary or not?
I did almost the same thing in a very different way as part of my PhD research: https://imgur.com/a/k6AQi I did it by representing the surface implicitly with radial basis function approximations, which can't produce surfaces with holes (well, edges - a torus is fine).
This is sort of neat but not really useful and not novel. The reason it isn't novel is that people have been smoothly filling holes via various polynomials and other smooth curves for the last twenty years. I wrote my first attempt in 1997 as an undergraduate. In real life you have contradictory information given you to from a 3D scanner. there are multiple surfaces that seem to intersect and do not technically make…
The case you outlined can be subdivided into (non-dense / non-watertight) surface reconstruction followed by hole-filling on the extracted surface.
Also, the given algorithm could still be used for filling holes in the data of a single-frame of a 3D sensor, where you "only" deal with noise, but not with overlapping data "layers".