Open Jojain opened 2 years ago
@Jojain Good thoughts.
I think to be responsive the synthetizer mechanism should have a fallback solution if the computation of a more complex (robust) selection is taking too long or the algo isn't converging towards a solution.
Agreed.
A slightly better one is to first thin down by global axis so
I may be misunderstanding that you mean here, but the vector based selectors I have created do filter faces by their normals matching the axis first, and then step through them, comparing the selected face to all if its siblings.
faces(">(1,1,1)")
There are times when the computed normal has float rounding errors in them, so 1 might be 0.999997 or something like that. I've been thinking that we may need an "almost" comparator, similar to what the CadQuery test suite uses for things like vector comparison.
I think that in this repo some approaches can be implemented in parallel and we can see what works out the best. You should have commit access, so feel free to start adding code as you see fit. If you change selector synthesis code that's already in place, I've been using the tests to drive my development, where the algorithm has to find the selector solution I expect (but we probably also need to allow unexpected equivalents). We should probably also add some execution time logging so that we have information on which algorithms perform the best.
I'm writing here an idea I just got for further processing, in short :
faces(">>X[index]")
which is still not great but is an improvmentfaces(">(1,1,1)")
. In the case of planar faces to fallback to a selector doingfaces(">>(normalDir)[index]")
seems a bit more robust than previous ideas and should be less likely to break upon design changes.Eventually it would be great to not have to use poor fallback selectors but it should however ensure that a graphical selection is always matched by a valid selector even if this selector is not robust