Repository navigation
Conversation
… parameter range, extending or shortening it; it works in homogeneous coordinates, so rational curves stay exact. Fix SSurface::ClosestPointTo() for planes whose u and v directions aren't perpendicular, and the clip of a plane-plane intersection line to the planes' (u, v) range in the same case: both now use the dual basis of the two directions.
New edge modifier, SShell::ModifyEdges(), in src/srf/chamfer.cpp, with sphere patches for corners in src/srf/sphere_patch.cpp. Fillets and chamfers are built from the rolling ball's cross-section between faces at any angle, on straight, arc, quadratic and cubic edges (quadratics and cubics are split in 2 and offset piece by piece), along tangent chains, at three-edge corners (flat triangle or sphere patch), with miters at reflex corners, and ending on flat or curved end faces. Traced pieces use SSurface::MarchIntersection(). Edges that can't be done are left out and the rest are filleted. The design and its limits are described at the top of chamfer.cpp. Not active yet: SShell::GetEdgeModifier() picks no edges, and the call to ModifyEdges() in Group::GenerateShellAndMesh() is commented out, until edges can be picked in the user interface.
There was a problem hiding this comment.
@phkahler how would it help you if this was on master?
As for merging it:
- "+" It's fairly unobtrusive
- "-" It's totally not ready
- No inside fillets/chamfers
-
- This beautiful monster (body smaller than the fillets)
- No inside fillets/chamfers
By the way the beautiful monster may be a decent way to fail (it's pretty obvious) instead of trying to detect it (it will be complicated) and somehow explain the problem to the user.
Bottom line - this a good start but is too unfinished - in my opinion it should live on a branch for now.
That said, if you have a very good reason why it should go into master please let me know.
| Vector dp = p.Minus(orig); | ||
| *u = dp.Dot(bu) / tx.MagSquared(); | ||
| *v = dp.Dot(bv) / ty.MagSquared(); | ||
| *u = dp.Dot(tx) / tx.MagSquared(); |
There was a problem hiding this comment.
Hey you picked up the fix from #1812 :-)
0c63d8c#diff-9a3c0518824c807f35571bba5775d312f07c78f39e153ef725d3163f47e07bcaR537
| s->ClosestPointTo(p, &up, &vp); | ||
| ud = (dl.Dot(tu)) / tu.MagSquared(); | ||
| vd = (dl.Dot(tv)) / tv.MagSquared(); | ||
| ud = (dl.Dot(tx)) / tx.MagSquared(); |
There was a problem hiding this comment.
Aha - one more spot -the same bug.
|
@ruevs I think I'm just being a bit paranoid about keeping it on my machine, and also having it become hard to merge later. But as this squash shows, very little of master is touched, and by putting that in a separate commit it should remain easy to merge. I'll probably create a branch for it. As for your models. When a fillet in a chain fails, it tends to propagate to the entire chain. So your complex intersections are causing the entire groups not to fillet. In practice one should usually wait and apply them all once the main geometry is done. You could make something with a flat top and bottom and extrude union or difference through that. Interior fillets definitely do work, but where concave and convex meet at a vertex it will fail - not sure how many of them will fail. Anyway, a branch it shall be. I need to get the UI working so we can more easily make specific test cases. |
This adds functions to modify shell edges with either a fillet or chamfer but no UI to do so.
The PR is broken into two commits - one that has changes to existing files which could be independent. And one that brings in the new functions in a couple new files.
@ruevs I normally wouldn't want to merge a WIP feature like this, but I think the fillet functionality is at a good stopping point. It lies almost entirely in new files, and you can even build with it without it being called. I'd like to spend some time working on some internals we will need to pass edge selections down to the NURBS code, and it will be easier with this part on master. I understand if you say NO loudly since it's incomplete.
Another reason for this: People have already done this with OCCT, so maybe they would like to try with a built-in capability.
All you need to do to test it is uncomment line 418 in groupmesh.cpp which reads:
Then go into chamfer.cpp line 296 and change the return value from this function:
Have it return a radius in mm. It will then try to apply that radius to every edge on your shell. This will probably be bad to do with multiple groups, since priors will already have them. The correct way to connect the UI is through that function - it will need to determine which edges a user has selected for rounding and what size. BTW make the return negative to get fillets.
You can try checking coordinates of a curve and only modifying say the top of a text extrusion. But this is in no way a useful modeling tool without a proper UI.
My next steps will be in establishing correct tagging of shell edges with the handle of the entity that created them, or was generated on top of them. That will give us mapping from selectable entities to shell edges. Still not UI, but a step closer.