Conversation
|
@rcarmo have you tested this with complex models with curves that are not exact? In other words, things like the intersection of a torus and a cylinder? Also, you're actually reconstructing connectivity information that is present in the SShell data structure. It's not easy to get at it in the step exporter, but isn't complete in curves like I mentioned above. A "correct" step export would simply write out all the curves and trims in one batch with no redundancy and record the step ID for each one. Then later when exporting surfaces, only the step ID would be needed (and I think a reverse flag) for each trim. That brakes down for inexact curves that only have PWL representation, as these get written as a bunch of approximate beziers. This is something I've wanted to try for a long time, but just don't have time. So have you tried this with the afore mentioned complex curves? Does it work? Or most importantly is it no worse than what we have now? Thank you for attempting this. I'll try to get around to testing. @ruevs what do you think? |
|
@phkahler I agree - as you said - what belongs to what is available/deducible from the model. |
|
The "correct" STEP export is neither this nor #1589 but some "nonlinear combination" of both may be :-) |
|
Yeah, well, this was a way for me to get familiar with the code, so the SShell thing wasn't immediately obvious. Plus I've been held back by #1579 and had to do a "blind" build on Linux to work around it, etc. The key blocker, though, is that I think I need a reference test file. I don't see one for #1589, but am happy to pull that in and see if I can merge them - I just think this needs some sort of formal test case to validate it. |
|
Here is the "test file" that #1589 used. |
|
Much obliged. I'll try to have another go this weekend. |
|
Your solution exports unnecessary edges, vertexes (just like current master) and even one extra surface. |
|
|
||
| // Helper function to normalize coordinate values for STEP export | ||
| // This avoids tiny floating point errors like 14.9999999993 that lead to open edges | ||
| static double normalizeCoordinate(double val) { |
There was a problem hiding this comment.
The rounding that this function does can be achieved much easier and the function becomes redundant.
All you need to do is round the values in the fprintf statements to five decimal places (search for "%." in the file). This should solve the problem since LENGTH_EPS = 1e-6 (defined here) is used everywhere as a threshold for numerical solutions. Therefore all numbers (like your 14.9999999993 example) should be either ".00000" or ".99999" up to the fith decimal place and will round to the "intended" value.
For example instead of :
fprintf(f, "#%d=CARTESIAN_POINT('',(%.10f,%.10f,%.10f));\n"`
use:
fprintf(f, "#%d=CARTESIAN_POINT('',(%.5f,%.5f,%.5f));\n"`
|
@rcarmo I've merged one of the other PRs that does a similar reuse of the curves. This is one issue I never would have expected to have multiple PRs at the same time. I hope that suits your needs as well. |
After a little fiddling with the STEP exporter, I managed to take the cube from #206 and export it correctly (select all, export).
This PR adds better float precision, a bit of clamping when outputting coordinates, and a couple of iterations at navigating the surface tree for export to try to ensure correct ordering.