Jump to content

Geometry Errors


Recommended Posts

We can't rely on screen representation of curves at high magnification.

But Pete, you should be able to rely on Lines and Loci being drawn well on VW's cartesian grid at any zoom.

About your test, I don't know what you mean by "join a line to the curve", if the curve is an Oval. I am unable to do that, since the oval is a closed object. Do you mean SNAP a line to an Oval or TRIM a Line with an Oval? Trim works, but Snap-to-Object for Ovals does not.

I guessed at what you described (using TRIM) and got the opposite results. If you would like, I'd be happy to talk to you on the phone to compare notes and we should both spend my less of our "abundant spare time" on this topic. I'll send you my number offline.

All the best,

Raymond

Link to comment

Raymond, after talking with you and testing, I have discovered the source of my error, which causes us even more distress if we are concerned about accuracy and the integrity of the CAD calculation engine. I now agree that the VW "Oval" must be a true ellipse, and is probably generated from the algebraic ellipse equation ((x/a)^2 + (y/b)^2 = 1).

First, here was the source of my error, and without talking to Ray I would never have guessed. In my attempt to cause the calculation engine to reveal its secrets, I used two methods interchangeably: the join tool, whereby the program calculated the intersection between a line and a curve, and a snapping method, whereby I extended a line beyond the curve, and dragged it back to the "object/object" snap cursor. It turns out that those two methods give different results!! I believe in the case of an "Oval" that the "object/object" snap point does not actually lie on the oval curve (the difference in my test situation on a 2" wide oval was about 0.0003" - which could amount to feet on a large site oval).

I also verified Ray's method by calculating the coordinates of two random points on the ellipse (using the formula above) and placing loci there, and discovered that they exactly coincide. I tested the coincidence by creating a 1.0000000000" line horizontally from the locus, then joined that line to the oval, resulting in exactly the same length to 10 decimal places, the limits of VW accuracy.

Link to comment

Matt,

   I like the first half of your statement, but the second half disagrees with my observations, unless my measurements and conclusions are flawed.

   If a set of Loci are placed by script (meaning very accurately) around an elliptical path over an Oval of the same geometry, the Loci sit perfectly on the outline of the Oval across a very wide range of zoom levels (100% to 20,000,000%). If as you say, the oval is not displayed "absolutely perfectly", then that would imply the Loci are not displayed "absolutely perfectly" either, and share the same display distortions ovals do. Is this also true?

   Can you, or your "secret source", elaborate a little more, please? (Hmm – "secret source" – sounds like burger chain jargon. Where is this thread headed?)

   One moment while I get back on topic... If there is a distortion with the onscreen display, but you can draw Lines between the Loci on the Oval and get proper feedback through the OIP, and/or the Fixed and Floating Data Bars, AND Reshaper, as to their length, angle, dX and dY, and XY positions of their endpoints, AND those values agree with predicted measurements, is there really a distortion we need to worry about?

   The next thing I fear you'll tell me is the color of ovals on my monitor may be inaccurate. ;-)

TIA,

Raymond

PS - I think the VW Oval should be renamed a Rodney Dangerfield loop, 'cause "it don't get no respect!"

Link to comment
  • Vectorworks, Inc Employee

Hi Raymond,

I'd rather not get my "sources" caught up in this when they have deadlines to tend with. :-)

It may very well be that the slight imperfections are so negligible that the last half of my statement should be left out. I'll just say that the VW oval is, in fact, based on a true mathematical ellipse and I'll leave the rest alone. ;-)

As for the COLOR accuracy of your oval, all bets are off when you're talking color. :-P

Link to comment

Matt, amazing that you were able to get the basic info on this! Thanks, it's great to have some clarity.

I think Ray filed a bug on the other aspect of this, which is that snapping calculations on the Oval curve appear to be incorrect. Nothing to do with screen representation, just a verifiable error of geometry (see my post above).

Link to comment

I can add a couple experiences, using all current software.

1. Using the shift key to constrain an unconstrained line does not always constrain it to the exact angle (say 0 or 90). I find I'm checking lines in the OI pallet for angle.

2. I recently had the experience creating an oval using the height then length option (with a rectangle to set the length and width) and the result was that the bounding box of the oval, say the left side, did not align exactly with the edge of the oval. So if I drew a vertical line to the left of the object, and then used Align Objects to align the left edge of the oval with the line, it resulted in a misalignment.

3. I can't offer facts, but I have suspicion that dwg translation of some ovals converts the oval to a polyline that does not exactly match the geometry of the oval.

I can work around all this.

Donald

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...