Synthetizing faces

[Jojain]

I'm writing here an idea I just got for further processing, in short :

• 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.
• The most general fallback would be to list all the shapes and find the index where is the one selected, however that's obviously a very bad selection (even if it always work).
• A slightly better one is to first thin down by global axis so, to select a face we would go faces(">>X[index]") which is still not great but is an improvment
• About planar faces particularly we could compute the normal of the selected face to make a Direction Selector to target that particular face. Let's imagine the chamfered vertex of a box, the synthetizer could compute the face normal and end up with a selector looking like : faces(">(1,1,1)"). In the case of planar faces to fallback to a selector doing faces(">>(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

[jmwright]

@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.