This is new and unaccountable. Sweeping two rails with a number of profiles gives an unwanted shape
SweepIssue.3dm (202.2 KB)
Another one of those again and again…
First: there is no reason to use sweep on this one. You are having simple planar surfaces, extruded arcs and a few blends.
But: before you can start working on something with this, you will need to fix the input curves. There are several places where the curves should meet and they don’t. Rubbish in, rubbish out - it’s that simple. This image shows one of those instances:
I think I may need some new glasses. Is there a way to make highlited lines a bit thicker than the lines next too or overlapping them?
James, do you use Gumball as your primary input system for modeling? You might try using the mouse cursor instead with the appropriate OSnaps. With the Near and End OSnaps on it is simple to trivial to make sure a line/curve ends on another curve, or at the end of the curve if desired.
Use Intersect with your curves to find all the intersections. Use a separate layer, preferably with a bright color, for the intersections. Then carefully check each intersection to see if there are multiple points at an intersection where there should only be a single point.
Personally, I would try to join the curves that should be joinable. If they are not, you’ll be told. If the command doesn’t stop by itself when you have made - what should be - a closed loop, then the first and last curves are off and you need to check that intersection.
One of the things I’ve made a practice of is using the ‘intersection’ command to check my work. I think in the case pointed out by WIM the intersection created a point but the point was actually off a from the end of the line.
I’ve been working with grid snap on at all times and that’s made for more reliable line work. It’s embarrassing really to be making such mistakes. I’ve tried changing the highlight color to make things more visually apparent but I’m obviously still missing things.
I’ve moved away from the gumball for anything but the grosser functions. I do at times experience a over load of snapping points displaying and have to be careful of which to respond too. I’ve not yet taken the time to make quick key methods to turn on the particular snapping points when needed, but rather keep a number of them on. I only turn on center when needed and turn off grid when not.
As too the duplicates issue, those may have been brought forward from earlier versions of the model I’m learning with. I’m up to the 10th copy now. I’ve a key combo to check for dups I’ve been using for the last month I think and I’m not having the issue of late.
I’ve been notified at times that the curves I’ve selected to make a surface from require some boolean function and have accepted that. I then delete the original curves and use create curves from face to replace them. My thinking is then the curves will be corrected as well as planar
[quote=“wim, post:5, topic:30048”]
Personally, I would try to join the curves that should be joinable. If they are not, you’ll be told. If the command doesn’t stop by itself when you have made - what should be - a closed loop, then the first and last curves are off and you need to check that intersection
[/quote]Good advice when trying to make a closed loop. But it doesn’t tell you when a T-junction isn’t quite a T-junction.
Run intersection on your set of curves again. Select all the curves at once, not just a pair of curves. Then check for how many points were generated in the neighborhood of each intersection. If the curves properly intersect there should only be one point at each intersection. The location where wim identified a problem there are two points. Elsewhere, for instance at the bottom of that end curve there are three points.
I use Rhino for Windows and it is simple to turn OSnaps on and off by checking the appropriate boxes. I assume something similar is possible in Rhino for Mac.
Be very careful having Grid snap on all the time. That can cause errors if there is a grid point close but not exactly at the proper location because the cursor may snap to the grid location instead of the appropriate OSnap. Been there, done that.
[quote=“JKayten, post:7, topic:30048”]
I’ve been notified at times that the curves I’ve selected to make a surface from require some boolean function and have accepted that. I then delete the original curves and use create curves from face to replace them. My thinking is then the curves corrected as well as planar[/quote]
Properly modeled curves generally don’t require any Boolean functions to correct.
More:
I do use the gumball to make a copy of a curve that I want to move along a rail. I also use the copy command. In either case though I’ll end up with an error shown below. After checking the curves intersect, making a copy an moving it orthagonally along a rail it no longer is intersecting with both rails but is off by a tiny bit.
How are you moving it “orthogonally”?
If, and the big if, the rails are parallel, which can be checked using the Angle command, and the initial curve intersects both rails; then using Copy, selecting the curve to copy, selecting the end of the curve as the point to copy from (End OSnap), and selecting another point on the parallel rail using the Near OSnap as the location to copy to, will result in the copied curve intersecting both rails.
However Angle shows that the straight parts of your rails are not parallel. Instead they are out of parallel by 0.005 degrees. Not a lot but enough to cause problems. How did you do that?
Added: Several of your straight curves are almost but not quite parallel to the x, y or z axis. This can cause problems if you assume they are parallel.
Oh lord if I only knew!
I assume the gumball will move items orthoganonally. Most every if not all the horizonal curves are projected to a standard cplane to insure they are flat and then brought back up to the desired level using the gumball and grid snap.
The angle command will now enter my to do habits.
With input curve issues and trying to achieve dimensional accuracy it is probably best to keep the Near OSnap off. I very seldom use the near snap when modeling because it can make things appear accurate when in fact they are not. I only use the near snap for extracting information from the model and can ballpark where I need it from.
You should try to create horizontal, planar curves as horizontal and planar to begin with. The “Planar” option/command should be used when curves are to be in a plane parallel to the construction plane that you are working in.
If a curve needs to be moved or copied with precision then use Move or Copy while carefully selecting the starting point and the corresponding final point. SetPt can be also be used if a curve needs to be moved into a plane parallel in either the local or world coordinate systems with a given constant x, y, or z coordinates.
I use the Near Osnap when I need the end of curve to lie on another curve but the exact location along the curve is not critical. Trying to do so without using an Osnap will frequently result in being close, but not quite on the curve.
The Near Osnap is “weak” compared to most (perhaps all) of the other Osnaps. If End, Point, Mid, etc are also on then the cursor will jump to the end of a curve, a point, the middle of a curve, etc when the cursor is brought close to one of those and the Near Osnap is over-ridden.
I have the Osnap option turned on in Cursor ToolTips so that the Osnap which the cursor is snapping to is shown, and I pay attention to which of the active Osnaps, if any, is being used to locate the cursor.
I agree with you completely here, it is the only way to properly terminate a line on an arbitrary point on the existing line. It does not appear that James is trying to do that which is why I suggested keeping that snap off.
While training my drafting department many of them were using it and producing inaccurate parts, both in terms of planarity and dimensional accuracy. We more or less placed a “ban” on using the Near OSnap and Patch to promote better modeling techniques and it made a world of difference; I am hoping James can achieve the same results, which is why I suggested it in the first place.
I deactivated the ‘near’ snap some time ago as I noticed it was making things a mess.
These are the osnaps I keep on:
I recall some input from Pascal awhile back about setting up key strokes shortcuts to turn on osnaps as needed. I’ll have to go back a study that.
Intersection, I toggle off and on as needed.
It can snap to the wrong thing depending on the view you are working in and what geometry is present in the view
I thought is was only relevent to actual intersection rather than a visual orientation.
This is the usual setup I’m working with at this point, turning on and off the gumball as needed.
most times yes, it can also be triggered by an “apparent” intersection. The two lines in the file actually do not intersect at all, only visually. See the attached image Note the difference between the top view and perspective view. (I just realized the intersect tooltip is not in the screenshot, for some reason print screen did not capture that 
)