Jump to content

Geometry Errors


Recommended Posts

Has anyone else encountered geometry and math errors in VW?

I was working on a revision of something within an extrude within a symbol and when I clipped a rectangle with an arc, the resulting shape had a slightly angled edge. For the life of me I couldn't figure out why.

I took the shapes I was using and pasted them into a clean file and now I'm getting math errors. The rectangle is 16' wide before clipping and 16' plus a little over a quarter inch extra. What's up with that?

The idea that VW is making math errors and taking geometry off square is very scary to me....

Kevin

ubbthreads.php?ubb=download&Number=16026&filename=Screen%20Shot%202016-07-29%20at%202.36.53%20PM.png

ubbthreads.php?ubb=download&Number=16027&filename=Screen%20Shot%202016-07-29%20at%202.37.11%20PM.png

Edited by Kevin McAllister
Link to comment

I've also noticed that it is a bit too easy to draw a line a bit off 0 or 90, even with the shift key down.

So, +1 me too.

I've also noticed another thing:

If you trim an oval with a line, it converts the oval to a poly line made of arcs similar to but not exactly the same as the line of the oval. It is a tiny error, but it is what it is.

d.

Link to comment

Perhaps a color field beneath the unit numbers,

using the corresponding HSV color of the color wheel degree = H hue

To make parts set to any angle more visible in OIP.

While 0, 90, 180, 270, could have less color brightness = V value

and

30, 60, 120, ..... degree could have little less sturation = S

So 0 and 360 degree would be Red but very dark while something

a little beside like 0,000001427 or 359,00007589 degree would be

bright and saturated signal Red.

Or about 90 is yellow, 180 green, 270 blue, .....

Link to comment

I have noticed math errors in Vw.

For a roof object I typed in the slope as 2:12, and the resulting degree slope showed as 9.50 degrees, when it should have been 9.46 degrees. (My document units are set at 0.00 precision).

Then I typed in 9.46 for the degrees on the roof slope and it rotated very slightly and now shows 9.46 degrees on the roof OIP.

Seemingly small math errors can multiply quickly. Especially if you are not even aware of them happening.

Link to comment

Hmm - thanks for checking.

In my case it may have been that the roof object was created in a file whose initial units were set at 0.0 degree precision, and then I changed it to 0.00 after I saw that 2:12 was not showing up as 9.46. I'll have to create a new test file to see if I can reproduce what I thought I saw.

Link to comment
If you trim an oval with a line, it converts the oval to a poly line made of arcs similar to but not exactly the same as the line of the oval. It is a tiny error, but it is what it is.

Donald,

   There is no exact way to represent a partial piece of an ellipse/oval after it has been trimmed. The path can be approximated by a set of Arcs (as you have seen), Bezier segments, or by a series of short straight Lines (a Polygon if they are connected). Each representation has errors. These can be minimized, but never completely removed.

   You're absolutely right, it is what it is.

Raymond

Link to comment

Raymond, respectfully disagree. Any set of points that can be defined mathematically can be represented equally well, in theory, by CAD. Apparently in this case NNA engineers have chosen not to write the code for a portion of any given ellipse. I have my doubts whether an obect of the VW type "oval" is a true ellipse, actually. From a pragmatic standpoint we are splitting hairs, no screen representation is exactly accurate, we are dealing with pixels and irrational numbers.

Link to comment

Hi Pete,

   I agree with you that oval segments CAN be represented accurately in a CAD environment, but in VW using the current set of available object types – Line, Arc, Bezier Segment, NURBS – they cannot be represented without some measurable error. There are no VW types available that give an exact equivalence to the Oval type.

   A series of points along an oval's curve (a Polygon) CAN be made to be as precise as needed (for all practical purposes) but it becomes "point heavy" quickly. Approximating an Oval with Arcs or Bezier segments has been proven by others to be inexact. There are some wonderful papers on the internet describing how to implement these approximations. I've read several and found them fascinating.

   On the recurring topic of Oval vs. Ellipse, as VW implements the Oval type it performs remarkably well as a perfect ellipse. It's CAD, it's digital, by that very nature it's not exact, but even LINES in CAD have holes in them if you try to specify too many digits. [ This reminds me of a discussion on this board with Petri, some 15 years ago. I do miss his presence still. :-) ]

   I know many people have their doubts about Oval/Ellipse equivalence in VW. That's okay. I know for what I need they are 100% interchangeable. There's plenty of room for opinions and split hairs here, and I don't need to convince anybody but myself, so we may agree to disagree.

Respectfully,

Raymond

Link to comment

Raymond, I initially had your thoughts, and I think we are 99% in agreement, except that there is an object type you don't mention germane to the question - the "Oval." Unlike an ellipse, the oval does not have a consensus mathematical definition, so I think it is telling that VW does not call their object an "Ellipse." What the VW "Oval" is I couldn't really say, and it may in mathematical definition be a bezier curve. So the fact that an Oval when trimmed becomes a series of polylines may not really represent a change of geometry. Donald, you originally raised this question, do you find that a line snapped to the oval becomes different in length when snapped to the trimmed curves?

Zoomer, funny! I assume you are tongue in cheek. Seriously, though, are we really moving to a design world in which forms which have been commonplace since the Renaissance are now to be shoved aside by the dictates of CAD engineers? That goes so much beyond the current discussion on precision it belongs in a different thread, but it's a big question, who is leading the development of CAD - designers or coders or marketers?

PS: I did the test. In my instance, I created a 3" line snapped to an oval. After trimming the oval, resulting in a polyline curve, and snapping the same line to that curve, it was shorter by 0.002248". This may have to do with the mathematical definition of a Bezier curve, which I don't have a completely firm grasp on despite having at least attempted to read Bezier's book. In my limited view, if you change the endpoint of a Bezier you may be unable to get the same shape regardless of how you tweak the Bezier parameters. Anyone know if this is true?

Sorry about the edits changing this post, that's the way the thought process works for me: on the other hand, if the "Oval" as defined by VW is in fact mathematically an ellipse, which has an equation defining every point, then there is no excuse for a clipped portion of that curve being mathematically different from the unclipped shape.

Link to comment

Zoom, perhaps math definitions are different in Europe, but in the US a cylinder is sometimes considered the special case of a cone with infinite height, and any slanting section through a cone (or cylinder) that is closed (reaches from one side to another) is an ellipse. An ellipse in (x,y) coordinates has a quadratic equation similar to but more complicated than a circle, which, again, is a special type of ellipse where the 2 focii coincide.

Link to comment

This conversation was held a decade or so ago on this forum, with the same outcome. Some people believed Ovals are ellipses and some did not. Without going into great detail, the term Oval in VW IS equivalent to the term Ellipse in math circles (or in math ovals, if you will). This can be tested with a script dropping any number of loci evenly around an elliptical path defined by a VW Oval's major and minor axes. For all digital purposes they are equivalent. They agree beautifully.

When a VW Oval is clipped, it is converted to a Polyline (a path object). VW Polylines can be composed of any combination of straight, arc, and bezier segments, however it is impossible to exactly represent an ellipse (i.e., a VW Oval), wholly or in part, using these path components. This last statement is based on other people's work. I've read some proofs on this topic and I agree with them. If anyone wants to learn further how to test my statements, please contact me offline.

Pete, I didn't use the Oval type above, because that would be the same as using a word in its own definition. As you suggest, it is entirely possible to have an oval's clipped path match a partial ellipse perfectly, but someone will have to submit an enhancement request for a different solution from the existing Polyline conversion, which can never be perfect. VW will need a new object type to achieve this. If a Circle clips to an Arc, perhaps an Oval will clip to an Orc. Forgive me, it's late and I see no obvious term for the requested shape. Let greater minds invent one.

HTH,

Raymond

Link to comment

Raymond, that's pretty interesting. Did anyone from NNA confirm that their "Oval" is generated from an ellipse equation? That would dispose of all the doubt, but like you say it's pragmatically of zero consequence. I like the idea of a separate object type for a segment of an ellipse. Its control points could be the 2 focii, plus the endpoints.

Link to comment

I just did a test and the Quarter Arc tool creates a quarter of a VW Oval when unconstrained. It is identical to the curve generated by the Oval tool with the same major and minor axes. I never really thought about how they related before....

I also converted a VW Oval to NURBS and brought it into Rhino. The Rhino "Ellipse" and the VW "Oval" are essentially identical when you run the Curve Deviation command (the maximum deviation is 2.47064e-12).

KM

Edited by Kevin McAllister
Link to comment

Confirmed that the "quarter arc" does indeed do what Kevin says. The curve is identified in the OIP as a "polyline" and has, in the example I generated, 2 bezier control points. Proof positive, I think, that the "Oval" is not a true ellipse.

Kevin, since Rhino is NURBS based software, I'm not surprised that its version of an ellipse is just a bezier approximation, which is what I think you have confirmed.

Link to comment
I just did a test and the Quarter Arc tool creates a quarter of a VW Oval when unconstrained. It is identical to the curve generated by the Oval tool with the same major and minor axes.

Kevin, look more closely. They are not equal, unless you clipped your Oval before comparing it to a Quarter Arc (QA) segment. When unconstrained, the QA tool draws a Polyline, not an Arc, and definitely not a quarter Oval or ellipse.

To test if an Oval in VW is an Ellipse, you should plot points by placing Loci at positions determined algebraically from an ellipse formula using the same major and minor axes of a drawn Oval. If done correctly the Loci will perfectly match the Oval's path, showing the Oval to be a real Ellipse in VW. Zoom in to 500,000% and the Loci are still sitting perfectly on the Oval's curve on the screen.

Compare that to a QA curve snapped to the same Oval (say, top-center on the oval to right-center on the oval.) The QA curve (now a polyline) is drawn farther out than the curve of the oval / ellipse. Like a trimmed Oval, the unconstrained QA curve can do no better than any other polyline.

I'm going back into my hole now. Have fun.

Raymond

Link to comment

Raymond, no!! not the hole!!

We can't rely on screen representation of curves at high magnification. They aren't drawn perfectly accurately, and that can be proved, case in point. The magnification test shows lack of coincidence, my test shows perfect coincidence despite the apparent discrepancy on screen.

I use a test that does not rely on the uncertainties of screen representation at high magnification. My test relies instead on the underlying math. I join a line to the curve at any randomly-selected point, adjust it so that the line's length is a whole number (like 2.0000000000 inches). Then after overlaying the quarter arc on the oval, take away the oval and join again. It's easy to see if there is a difference. In this case, it's still 2.0000000000 inches, indicating coincidence at that point within VW's minimum tolerance. Now since that quarter arc is a bezier polyline, doesn't that suggest that the oval is also based on a bezier polyline?

Tomorrow in my abundant spare time I will perform a test on a locus with coordinates calculated from the oval's major and minor axes, and report what I observe.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...