Nurbs geometry differencing problems #497
Comments
|
I had a solution myself, by setting the second diameter to 20.001, then the solver appears normal, maybe this method could be used as a workaround for this problem, as it seems to be difficult to solve. |
|
I created something similar. There were NURBS boolean issues. The attached model works with equal sized cylinders. The trick was to create the plane for the second one at an angle (see the construction lines for that workplane). A circle is actually composed of 4 arcs of 90 degrees. When doing this difference using axially aligned circles, the corner points are at the intersection of 4 surface patches. By rotating one of them the complexity of the surface intersections is reduced a bit. That's my guess as to why it works anyway. Oh wait. The success also required the changes in my nurbs branch, so that attached file doesn't work with master. There are some missing edges without that fix, so this may be of interest to @ruevs who had been doing recent work on booleans. The only thing in the nurbs branch (PR #473) that seems like it might apply is the one change to keep U,V coordinates in range 0 to 1. I didn't expect that to matter but it does. (Edited to remove crash references) |
neuks
changed the title
|
sorry for the 'crash' word, there's no application crash, just the geometric solver's blow up, I have changed the title, so that we would not be mistaken. |
System information
SolveSpace version: 3.0~5d78f99
Operating system: Windows7 64bits
Expected behavior
When differencing a cylinder with the same diameter with the direction right perpendicular and through the axis line, there should be a hole which right seperated the left and right side of the cylinder.
PS: This is an important feature, similar conditions including drilling some perpendicular screw holes which intersects.
Actual behavior
When differencing a cylinder with the same diameter with the direction right perpendicular and through the axis line, the nurbs geometry solver crashes.
(sorry I forget to upload the issue image)
I know there's a solution by activating the 'Force nurbs surface to triangle mesh', but it's not what I expected, as the latter modifications would always be resolved to triangle meshes.
Additional information
This situation happens with all versions of SolveSpace, as checked on version 2.3~latest.
Great thanks for your work on SolveSpace, and it is very helpful with my research work.
For bugs, please attach a savefile that shows the problematic behavior.
You can attach
.slvsfiles by archiving them into a.zipfirst.The text was updated successfully, but these errors were encountered: