I’m sweeping arcs along two simple rails but I cannot get an apparently smooth surface as can be seen in the images. What might be causing this?
zebr.3dm.zip (936.3 KB)
Here is a method to create this set of surfaces with a few more (simple) steps than using the Sweep2 along the fillet.
Makes for more useful geometry and surfaces as you build complexity into the model. Good idea to contiually double check the construction curves as you go, to maintain connection.
Thanks for the help Brian. It’s not clear to me what’s being done here however. In the first image, have you two seperate sweeps from either end, or a single sweep and then removed the corner?
When you speak of the clean radii, are you referring to the edges of the sweeps.
In my case, I’d extruded the lower joined curves to create the flat surfaces and then used the extruded edge to serve as a sweep rail.
Its not apparent in the image but did you move the wires on the back to match the arcs?
Also, there’s another thing that always shows up - that is when trying to use the edge of a surface for sweeping and sometimes making a surface blend, the selected edge will only be partially highlighted. There’s no edge curve, only the surface object.
I tried moving some wires and made sure the curves used to sweep are clean, but I still get the anomoly. Some kind of tension in the surface.
zebr.3dm 2.zip (77.6 KB)
Sweep2 in from each end, which allows Rhino to find nice curves to use at the corner surface.
I was referring to the 8 rad. arcs from your geometry.
That works, but I’d prefer to break thing down a bit in this instance
Yes, I moved them to the start of the sweeps
In a simple shape like this I think it’s a good idea to have the construction wires meet up at natural connections, i.e. the intersect of a straight line and the adjoining fillet
Having a further look at this, I see the construction geometry is not as square as it is probably intended. These discrepancies will result in surfaces which will need correcting along the way as the model grows.
zebr Squared.3dm (2.1 MB)
I don’t understand why the application would allow such tiny descrepencies when using the modeling aides.
The image above is disconcerting - 89.9976 degrees? 89.9797 degrees? A line that’s .001 long - the lenth of the tolerance limit? Such utter bullshit. A complex model would require a degree of error checking that’s absurd. How can such a thing be happening?
This is the kind of thing that drive me up a wall.
So I’m not alone.
I think the application should be such that one would have to absolutely insist on variance of such miniscule proprtions. Most designers are confident in the utility of orthographic construction. When an arc is drawn they expect the arc to be reliably created - and not be off by such a silly amount. So too with any other aspect of design. When I set a stop on my drill press or a fence on my table saw, I expect the resulting cuts to be consistently identical. I’m expecting even more precision from a program that exist in a virtual digital world not subject to the physical limitions of the actual world like temperature affecting the measurement tools, or moisture affecting the materials. These CAD creations are essentially works of fiction - and fiction is the one place were perfection is most likely to be accomplished.
This might come as a shock but this application is actually written by humans.
It is up to you to produce an example where you consistently are able to reproduce a mistake where none should be made in order for the programmers to be able to catch what you are doing wrong.
Well, I hate to destroy your faith in the perfection of the CAD world, but in fact those “variances” are indeed quite normal in the world of digital computing and even more so in the world of NURBS math. First, read about how floating point math in digital computers is itself an approximation.
Next, free-form NURBS curves and the surfaces derived from them are also approximations with a given tolerance. In general this is the absolute tolerance you set with each file. Here is a Rhino Wiki page on that subject.
Now, whenever possible, Rhino calculates far beyond the file tolerance to as far as floating point math allows - Rhino’s “absolute zero” is 1e-12. Some operations allow this type of accuracy, others do not. In general squares should be absolutely square, so if you are finding they aren’t, there is something else happening, and it generally isn’t caused by an inaccuracy in Rhino’s basic geometry engine, but rather how it is being used.
Rhino will also not refuse to create bad geometry. The premise is that you as the user are the boss and that Rhino will try to do what you ask it to do, even if it’s not good or accurate. Rhino assumes you know what you are doing and does not make judgement calls for you. This can be either good or bad, the important thing to know is that’s just how Rhino behaves. When you draw something slightly off square, Rhino will not automatically correct it for you - it assumes you did it deliberately.
–Mitch
If I could consistantly reproduce a mistake then I’d be able to avoid it. The issue is the reliabilty (consistency) of the application. What I’m dong wrong it seems is not inspecting every last curve to make certain it’s actually snapped to what it indicated it was snapping to. Again, the errors are extremely small, but apparently large enough to throw things off.
[/quote]
Perhaps it should.
Suppose the boss insists on good geometery?
As per:[quote=“Helvetosaur, post:10, topic:30831”]
floating point math in digital computers is itself an approximation. "Some decimal numbers can’t be represented exactly in binary, resulting in small roundoff errors.
[/quote]
Then In any case, if such variances are normal then why would they cause problems?
I’m sorry if I’m offending the programming sorts. I don’t mean things that way. I cannot begin to imagine the effort it takes to write such an application.
Perhaps Rhino could run in ‘dummies mode’ for those that aren’t up to the level of the long-term useres.
Here’s an example of the problem. In this bit, there’s a solid that’s wire cut and then shelled. The shelling operation results in a non-solid with some messing edges. Those messy edges are created by the shelling.
It’s then necessary to fix the edges, but the command has generated a number of excessive points that make creating clean replacement surfaces a chore.
For some reason even though the file consists only of some copied elements, it’s showing to be over 10mg! What?
It was ‘saved small’ to make things better but there’s no helping it. I compresssed it and it’s still over 6mg.
Shelling.3dm.zip (6.1 MB)
Uploading…
Uploading…
What mistakes have I commited in this case?
If a straight line is drawn on world top plane, I definitely want to see a string of zeros after the decimal point, in the Z value, even if the .001 discrepancy is within tolerance. The .001 will possibly affect something later if the line is used to copy, fillet etc. etc.
A simple way to check for perfect connection while modelling is to set up a button with Fillet, rad zero and check the geometry along the way. Even if the intersect is within tolerance, if it doesn’t fillet, it may indicate something is not right.
Using this check, the illustration below shows the comparison between the geometry in question and the corrected in red.
Using the ‘What’ command I see you use the Gumball to duplicate some parts. I don’t use Gumball for duplicating or moving - is it possible for that to create discrepancies?
I think I recall a few that considered the gumball a sketchy tool. I’ve been using the duplicate command more often, but the gumball is very handy. [quote=“BrianM, post:12, topic:30831”]
A simple way to check for perfect connection while modelling is to set up a button with Fillet, rad zero and check the geometry along the way.
[/quote]
Is that a macro? Something you use regularly?
If you look at the results of the shelling you’ll see the complexified upper corners. I extracted the surface, but to create a new clean replacement I have to deal with the edges that have excess breaks in them. In other words if I use the duplcate edge tool I end up with a messy curve to work with. If I try to replace it with an arc, I have several end points that want to accept a snap.
Most every arc used is created with the curve fillet tool and I simply expect the resulting arc to be correct. When I duplicate the arc I suppose it’s complete and when snapped to a new point will be orthogonally sound.
I’m getting the impression that I’m being judged too demanding.
No, but it would be good if you could show a case of an action failing to move or copy objects accurately - I understand you are frustrated, but so far, the examples are shown well after the fact if I am not mistaken - in other words, who knows what the moving or drawing action actually was, and what happened since. The fact that this is not a constant complaint by users in general suggests that possibly there is some pilot error somewhere along the line - perhaps, if so, it is pilot error that Rhino can do better at avoiding via better workflow or what have you, but the first step, whether or not Rhino or the user is more responsible, is to identify a concrete problem and reproduce it.
FWIW, I not all that infrequently find my own carelessness leads to things being askew, but the advantage I have is that I am pretty familiar with how Rhino operates and I can generally backtrack to see where my goof-up was.
-Pascal
1 Like
You can use Connect for this as well. Then Fillet does not have its radius reset.
-Pascal
[quote=“JKayten, post:11, topic:30831”]
What I’m dong wrong it seems is not inspecting every last curve to make certain it’s actually snapped to what it indicated it was snapping to.
[/quote]I’m one of the folks who suggested that you should carefully inspect each curve. But the reason was not because inspecting each curve every time is necessary to insure quality. It is not.
Rather the reason I suggested you inspect each curve was so that you find when the inaccuracies occur, and then try to deduce what specific actions might be causing the problems.
As BrianM said any straight line drawn parallel to a coordinate axis should be as “exact” as the floating point math can calculate, which generally means within 0.000000000001 (10e-12) or better. Copying and moving such lines should keep that level of precision. If your lines are not that precise then you need to determine what exact actions where used in creating the lines.
I don’t doubt that at all. Perhaps I’m haveing unrealistic expectations.
An analogy - when doing a scroll cut through some material in the real world, I can use a jig saw and get reletivly square edges. If I need better accuracy I can use a band saw. The point is each tool functions as a means towards greater precision to a degree not possible by a human. (Although I was once very, very good with just my hands)
Perhaps such tools exist in Rhino and it’s a matter of time and practice before I find and learn how to use them. It’s just at this stage the tools I’m relying on for accuracy are not making up for my mortal shortcomings.
Another analogy; when doing a scroll cut through some material in the real world, whether with a jig saw or a band saw, the edges may not be exactly square if when re-positioning the wood on the saw a bit of saw dust is trapped between the wood and saw table, That inaccuracy would be the result of the particular technique used, lifting the piece of wood slightly and re-positioning it without ensuring the table is clean, not a fault of the the saw.
My guess, and only a guess, is the small inaccuracies in your work result from some small, subtle detail of your technique.