1) Have you accumulated any test shapes yet?
In my case, it's mostly about 3-axis machining, so the test cases are quite standard mechanical parts. Here is the archive: http://quaoar.su/files/dfm-cases.zip
Some of the cases are taken from the DFMPro
application. I have never used it myself (it is commercial) but took time to install it just to grab some files and the user manual that explains which accessibility checks they have. Here is this manual (precompiled HTML): http://quaoar.su/files/dfmpro.chm
I found it to be quite useful, especially for non-engineers (like me).
2) Why won't an occt incremental mesh with the appropriate deflection parameters work?
Whatever parameters I passed there, it left planar faces subdivided with a very coarse mesh. That's a typical test part I use and the typical result from BRepMesh:
I tried different settings of the OCC mesher, including some hacks, such as converting all analytical shapes to splines and even inserting vertices with TopAbs_INTERNAL orientation inside the planar faces' domains. Nothing helped. The only effect of having internal vertices I've seen was the emergence of degenerated triangles and sometimes crashes of the mesher.
In contrast, here is the mesh generated by NetGen on this part:
It's fine enough, so I can have accessibility check on its triangles. For example, here's the accessibility test for the direction X+:
3) Have you thought about the occt Hidden Line Removal algos.
The last subcontracting job I did for OCC was a deep analysis of HLR algos. They work reasonably well for small models (single parts), even though the discrete version of the algo seems to be worse than the precise method. That was surprising as the discrete version is conceptually simpler, but as of now, it is quite unusable (and they will unlikely improve these things in open source). The precise version, on the other hand, seems to be an overkill for such a type of analysis. Also, given that both algos are thousands of lines of legacy code, this whole thing looks quite non-maintainable. It's just scary to ground your paid project on a codebase that you have no idea about.
The visibility check I'm implementing is, on the other hand, quite simple. The key here is the fast ray-mesh intersection where we can benefit from the BVH structures of OpenCascade.