Jump to content

Offset error or my imagination?


Recommended Posts

This is truly an unexpected bug! I was able to replicate the problem (the corners have to be set up as you show them so that the incorrectly placed segment is not directly opposite a segment from the parent polygon). If you check the DIAGONAL distance between the two corners with your red rectangles, you will probably find that it measures 12.000. This is obviously a programming or algorithm error, and it's a good thing for us users to know about - thanks! I hope NNA can correct this problem soon.

Link to comment

This has been a problem since VW 11.5. I reported it as a problem 12 months ago with a series of drawings like that one. It occurs whenever a polygon leg is less than the offset distance - the smaller the polygon leg gets the bigger the error gets. It wasn't fixed for version 12 - hopefully for version 12.5.

Other issues with offset:

- The additional vertice(s) that are created when you do offsets. (Makes doing multiple extrudes very tedious as you have to decompose and then recompose the polygon after you have fixed the defective side(s)).

- Sometimes having to click on the opposite side to where you want the offset to be to get it correct. I still haven't deduced what triggers this though I suspect it has something to do with rentrant portions.

Edited by mike m oz
Link to comment

As for the additional vertices, I've actually noticed an improvement over 11.5 -- *most* are healing itself away. I've had to do less "delete vertex" with the 2D reshape tool. I hope I'm talking about the same thing that you're talking about, Mike.

Multiple extrudes, however, have become worse for me. Even with clean vertex-for-vertex offsets, many polygons are simply NOT allowing for clean multiple extruding. They become twisted with seemingly each vertex going to the second next vertex over! ARRRGGHH!

Link to comment

I'm glad others find this 'extra vertices' issue a puzzle ? all I can say is that similar offsets also occur in Amapi Pro, Cinema, it even happens in Illustrator.

I've got used to it, I assume its just what happens when a line is copied and expanded in relation to the orignal curves rather than Scaling; using a locus, which is a very different sort of operation.

Link to comment

Islandmon, I have to disagree emphatically with you about this (note that above I have made the same observation you did). Okay, maybe it's a badly designed algorithm instead of a bug, but the results are not what we expect when an offset is done. Every segment or component of the offset object should be offset the same distance as measured by a line NORMAL to the original segment, even if you have to produce the offset segment to get that measurement.

Just consider this. If the offset is 12 and the segment is 10, in the example given, we get a result similar to what has been demonstrated. If you increase the length of the segment towards 12, the discrepancy decreases, until you are at 12. From that point on up, the measurement will be 12. Why would we ever want such a mishmash of results? (Rhetorical question; we don't want it like that.)

Can you make an argument for why the algorithm should stay as it is designed?

Link to comment
Can you make an argument for why the algorithm should stay as it is designed?

You can only have one control diagonal. In the example given there are 2.

One for 12@45? and one for the notch displacement angle @48.37. The disparity is the control dimension multiplied by the arctan of the displacement angle.

Correcting the displacement angle to 45? would also skew the control.

Trace the inside of the border polygon P1 with a double Line set @ 12 . Thereby creating a new inside polygon P3. See the small difference between the original P2 and the corrected polygon p3.

Now take the separation dimensions ... of course, they're all = 12.

Link to comment

Okay, that's a view of the algorithm that may or may not correspond to how the program is actually written, unless you have inside information. More to the point, this might be an explanation for the problem, but not a justification for the method.

It is possible to produce the geometry that the rest of us expect to see in an offset function. I could write the code, but it's not my job. I conceive of it this way: take each line segment, and move it in a normal direction by the offset distance. Then join all the line segments into a polygon. Yes, in some instances this does not result in a uniform offset angle for each of the vertices - but that parameter is not the goal of an offset command. There are also some shapes where the offsetting elements cross over each other, and we would want those cleaned up. I beleive the AutoCAD offset command works correctly, and if you have access to that, try it out.

Would you agree that the resulting geometry we are asking from from the offset command is the logical and desirable result? If so, would you join the others in this thread to ask NNA to come up with a solution?

Link to comment

I am just a landscape designer - logically I think the software should do what we expect.

Islandmon, I have read many off your posts and admire your knowledge and am grateful for your contributions. Thankfully we have this forum.

If the inner polygon was say a garden or a house and I wished to offset a path 1200 mm wide around it - shouldn't VW do just that.

Whist from your perspective you say 'No Bug" and given what you have stated I understand where you are coming from; from my end - dunno mate, might just have to go and sit in the corner and think about it for awhile.

I think an offset should be an offset and surely we must be able to trust that.

Link to comment

Islandmon, that last post appears to an accurate description of the problem (I don't know who Mike Moore is).

A question in my mind: how could the algorithm for offset be based on 1/cos45 (note, different from acos) when we can have polygons with internal angles different from 90? Also, we can now offset polylines with arcs and other curves and preserve the mathematical nature of those segments, as opposed to having the chordal approximations we used to have. To my thinking, this suggests that the method is more complex than a uniform vectoral displacement of vertices.

Could we all agree that the desired result of an offset command gives us a "garden path" sort of result as described by Darrell, i.e., an offset where the "width" is equal everywhere?

Finally, though v12 has vastly improved the offset command, we still have the following glitch, where offset a > dimension b:

Reentrant%20offset.jpg

Link to comment

I just checked the above scenario in all of our other programs and they offset correctly, as one would expect. This is just one of the many reasons we do not trust VW exports for our output to our CNC equipment.

I also noticed that no one from NNA has chimed in on what appears to be a recurring problem that still has not been fixed.

12 months and still a problem...........

Thanks.

tom

Link to comment

I suppose one way for NNA to cover up the "problem" is to rename it. Don't call it an Offset tool.

Better yet, just drop the tool altogether. That way, we're forced to scramble for another solution, like turning on the Edge Snaps constraint with offset and using the Polygon tool.

::roll eyes::

Link to comment

Why does it take so long for NNA to respond on such fundamental issues?

This is such a basic tool used regularly and it does not work accurately and NNA have still not got round to fixing it for years. I suggest that this has to be fixed in the next free update. If that is not possible then NNA are not ready to release the update.

If it took me years to sort out an error for a client I would be out of business.Or more to the point if a wall, for example, is constructed in the wrong place I would be sued and if it is an NNA error, and a known error, my insurers would want answers.

Link to comment
  • Vectorworks, Inc Employee

Well, MJW, the algorithm we use doesn't consider this an error, while I do. Based on my reading of this issue, it took about two weeks to fix part of this error, which I don't think is too bad. Please remember that posting an issue in this Tech Support board is NOT the same as submitting a bug to bugsubmit. The latter puts an issue on our "official" list of "stuff to deal with", while things that are discussed on this forum are, well, discussed on this forum and may or may not attract the attention of an engineer at NNA. It all depends on the moderator of the list. (I don't officially moderate this particular forum, but I've kind of "taken it on" as a matter of personal interest.) The upshot of all this is, if you consider something a bug, send it to bugsubmit@nemetschek.net !

Link to comment

MJW, it's unfair to say that NNA has taken "so long" to rectify "such fundamental issues". The problem described here is so trivial that almost noone knew about it, in spite of its being around for "so long". The person who started the thread wasn't even sure it's a bug, and there were highly intelligent arguments that it's not a bug.

This thread has been interesting reading, from a techno-geek point of view, but that's mainly because the discussion was an ongoing process of discovery. It's useful to know that this unexpected behavior exists, so that we can work around it. But if it's never fixed, I for one won't care, and most users probably won't ever know.

Also, the idea of blaming the CAD program for errors in an architect's drawing makes as much sense as blaming a draftsman or the manufacturer of the plotter paper. We're licensed and paid to oversee the process and to make sure the end result is correct.

Link to comment

Maybe we overreacted, but:

We do use bug submit but last time we did it was deleted without being read.

It may take two weeks to part fix the bug but thats pointless if users do not get the fix until the next free update in several months time and will it actually be included in the next free update? Anyway the bug has been around over 2 upgrades and not fixed.

We are still waiting for a fix to the 'container class' bug we reported and submitted several months ago.

I am not a software programmer but I am an architect and it may be unfair to blame the programme if a wall is built in the wrong place but I will have to take responsibility for it as it was built off my CAD dimensioned drawings - so I have to use CAD software I trust and is accurate.

NNA may not read the Tech Board, but it is great and the best for discussing and resolving problems, and if NNA want to develop VW to meet user needs then perhaps it should take more notice.

Link to comment

Robert, thanks very much for your interest and intelligent response. I think it would be more than we could expect to hear from a high-level engineer, if this were another CAD program we all know about.

Regarding whether this issue is important, I would rate it as highly significant, particularly if VW wants to position itself in the CAD/CAM world. All milling machines, including laser and waterjet cutters, have a tool or kerf diameter. So there is always an offset between the part outline and the tool path, which requires a reliable offset tool to deal with. It's fundamental.

Link to comment
...The problem described here is so trivial ...

jan15, I have to take issue with your comments.

First, as "the person who started the thread," I was in such total shock and disbelief about the INACCURACY (capitalized again for your benefit) of such a basic tool... that if you're reading my post as somebody who "wasn't even sure it's a bug," then you seriously have some comprehension problems. It is so ludicrous.

Second, if you're forming conclusions based on the seemingly "ongoing process of discovery" of some parts of this discussion, then you're completely missing the point. You obviously haven't used the offset tool much. You obviously don't use multiple extrude either. If you haven't used the software much, then you got no relevance nor validity in making your comments. Shame on you. You should just stay quiet if you don't use it and it doesn't affect you.

Third, blaming the CAD program for an error of this type and magnitude is EXACTLY what must be done because we're talking about what the CAD program should or should not do! Your analogy is so wrong. You are in fact suggesting that architects must somehow inspect every code of every function in every software program used to create his drawings and ultimately check every generated line and every digitally-created object for precision and accuracy. That is such utter nonsense.

A better analogy is a micro-surgeon who relies on a digital microscope. If the micrsocope is accurate *most* of the time, only occasionally showing last week's images when least expected, who then is to blame? How in the world would the surgeon know that the image is in fact of another patient from another day while he's focused on his surgical tasks at hand?

Link to comment
...you seriously have some comprehension problems. It is so ludicrous.

Ken,

Sorry that I misinterpreted your choice of title for the thread. I'll consult a cognition therapist to try to do something about my serious comprehension problems.

The discovery I was referring to was the discovery that the anomaly you described does indeed exist. Only one contributor, Mike Oz, said that he already knew about it. Islandmon may also have known, but didn't consider it a bug, at least initially. I couldn't tell whether the ongoing process of shared discovery changed his mind. All the other contributors appear to have been confirming and/or enlarging upon your discovery, which appears to have been new information to them. My point was that it's unfair to complain about failure to quickly fix a problem that hardly anyone knew about, and that if it was unknown for such a long time it can't be terribly important.

I have, in fact, used VectorWorks quite a bit. If I seem new, it's because I'm too shy to have contributed much to this tech board. And I have used the Offset tool a lot, and nearly always with polygons, but I've never gotten into trouble because an edge was not accurately offset the specified distance from the imaginary extension of the corresponding edge in the original. If I were designing for the milling machines Pete mentioned, I may well have suffered consequences from this anomaly, in which case I would have submitted a bug report, or else would have made a mental note to adjust the offset polygon whenever an edge in it is not directly opposite any part of the corresponding edge in the original, in case that ever happens again.

I agree with you that it would be preferable for software to have no bugs. But an architect can't pass on his responsibility to the software manufacturer, as I inferred (probably incorrectly, given my serious comprehension problems) from MJW's comment that "...I would be sued and if it is an NNA error, and a known error, my insurers would want answers."

VectorWorks has bugs. So does any software. Some of them get fixed, hopefully the most critical ones. If your own work is of micro-surgical precision, you can feel superior to NNA. What I've seen in my own and other architects' drawings, supplemented by candid reports from construction workers, suggests that few of us are in that position.

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