Dangerous snap error!!!
This is a serious (frightening) one:I have just found that in some cases, it is not possible to get correct distance by the DIST command - I repeat the DIST command and keep getting seemingly random results! The points to be measured are both defined as intersection of a line and a polyline. ICAD snaps to different point (almost) every time. You can see an example of this in the file at http://www.pontex.cz/Download/ICAD/SnapError/SnapError.dwgThe only way to get correct result is to EXPLODE the polyline, then measure the distance. The error is MOST DANGEROUS as many set-out plans are used for actual measuring in CAD, the erroneous values are all quite similar, hence even more risk of not discovering the error! A good reason for sleepless night, indeed...I'm trying to push our users to ICAD but it's really tough when they come with such problems. PLEASE don't spend effort on 3D modelling, ACIS and similar 'top' features while the fundamental parts of the 2D 'engine' still lack reliability. Otherwise, we really can't afford the risk of using ICAD. I'm very sorry to say this, but that's how it is. Best regardsVaclav KvasnickaPontex Ltd. Consulting EngineersPragueCzech Republic
Comments
-
Sorry for wrong value in "Author" in my message - I have entered "Preview", then (knowing that if I "Post" from Preview, it will be from "Guest") I clicked "Edit", lost the contents of Name/e-mail/Subject, had to enter them again (and probably mistyped).BTW, the error in "Preview" (forcing name to Guest) is known for a long time (years?) - any chance of fix? Anyway, 'Guest' in closed forum is something unexpected...RegardsVaclav
0 -
Hello Vaclav,We analyzed what happens in your drawing. In intelliCAD you can use intersection snap to snap to virtual intersections with each of the segments of a polyline.This ability is an old design. It's not bad in itself but then you have to be able to distinguish between an actual intersection and a virtual intersection.The 'nearly straight' polylines in your sample drawing illustrate that this can be difficult.Consider the case below(you can copy the lines to the IntelliCAD commandline).Suppose you have a polyline of 3 segments, each segment making a slight angle with the previous segment(command "_pline" "0,0" "3,0" "6,0.2" "9,0.5" "")Then you have a simple line crossing the polyline close to a vertex.(command "_line" "2.9,-2" "2.9,2" "")For reference let's zoom extents(command "_zoom" "_e")And switch on intersection snap(setvar "osmode" 32)The above polyline has for each of the segments a candidate intersection points with the line. Normally most of the candidates will be ignored because they lay outside of the aperture of the cursor.The smaller the aperture, the less intersection snap points can fall inside it.In this case an aperture of 10 yields the maximum of 3 possible intersection points. (setvar "aperture" 10)If you start a line command and move the cursor a bit around you see that the snap marker takes 3 nearby positions.An aperture 5 yields 2 intersection points(setvar "aperture" 5)And if you zoom in you only get a single intersection point. There is no need to explode polylines.So that is the current behaviour. We'll have to analyze the possibilities to improve on this.For example we could restrict intersection snapping to a single segment, but there are also different ways to increase the feedback to the user.regards, Alexander Van HeuverzwynBricsCad
0 -
YES And my wish is that you highlight the selected objects ( flyover highlight) .This is a problem that occures a lot but in a different way.Lets say you draw a square 1000x1000 an put a hor dim on the bottom line inside the square. I use an offset from origin of app 2mm (drawing in 1/50) . Next time I pick the bottom right corner I get an endpoint snap that may snap to the dimline or the contour. As the lines are on top of each other it is very difficult to see if you go wrong if you dont zoom in heavily.Flyover highlighting would also save a lot of zooming in general.CHEERS Patrik
0 -
Sander, you didn't understand this problem correctly.Error appears during crossing line with arc segment of polyline. It is not possible to snap to this crossing point.Copy the lines below to the IntelliCAD commandline.Create a polyline of 3 segments, second segment is arc.(command "_pline" "0,0" "2,0" "A" "4,1" "L" "5,2" "")Then you have a simple line crossing the polyline over the arc segment.(command "_line" "2.9,-2" "2.9,2" "")Let's zoom extents(command "_zoom" "_e")Switch on intersection snap(setvar "osmode" 32)Now try create a line starting from intersection point of pline and line to some other point.What you see now ? Is the intersection point of arc segment of pline and line correct ?Not. From which point our new line start ? Nobody know it.regards Vladimir, Protea
0 -
I value you have quickly solved the problem described in the topic "Long names in Explorer" which cause total IntelliCAD collapse, but I am sure that snap inaccuracy is much more dangerous. User can draw or measure without any notion that all he has done is wrong.Please show again your positive approach this serious problem.
0 -
Vladimir, There are two issues here, not one misunderstood issue. The first issue was reported by Vaclav. You can verify in the testdrawing that it can be difficult to find the right snap point in a multitude of points. And as Patrik suggests, highlighting the relevant (sub)entities is a promising approach. Then there is the issue you report which is a regression that exists since version 4.Polylines that mix arcs and straight segments can have the following problem:- The intersection point is missing where an arc segment of the polyline intersects with a line.- Instead another candidate for intersection point is showing. This candidate point is showing even if it is outside of the aperture.This forces the user to resort to tricks in order to find the intersection, like exploding the polyline.We're investigating this issue now. regards, sanderBricsCad
0 -
I'm back after a week off, during which I kept quiet in this forum. Downloaded and installed 4.0.0041. Looks better than 4.0.0039 which (at least on my PC) didn't show the aperture box so snapping was quite a problem.I have further looked into the snap problem in the example drawing and I'm quite sure there's still something wrong with the ICAD behaviour which was not covered in the discussion so far.The issue and potential source of problem described by Sander is clear but is not the only problem, actually it was not the reason of the 'random' results - I normally use quite small aperture size (5) and even zooming closer to the points of interest did not solve the problem. I didn't test the problem described by Vladimir (intersecting arc segments of polyline). It looks quite important and I hope it will be solved soon - Sander's "which is a regression that exists since version 4" looks like it should not be a big problem.However, exploding the polyline in my problematic drawing shows the segments in question are all straight lines, no arcs. Zooming close to point 1 in the drawing, try several "ID" commands, you will get different results:- when approaching the intersection from left side of the polyline, X=0.494,Y=-4.826- when approaching the intersection from right side of the polyline, X=0.496,Y=-4.832After EXPLODing the polyline, the result is consistent, X=0.494,Y=-4.826. This, I believe, is another problem not explained yet.The approach described by Sander in his first reply is, I believe, very problematic and should be abandoned or at least (as an option) possible to switch off. I have observed this issue long time ago and I suspect there's a close relation between this aproach and the well known "snap freezing" problem found in older ICAD versions. The algorithm seemed to search for intersections with many (if not all) segments of the polyline (CPU intensive task, thus "freezing" on slower machines) and only then snapping to the nearest of these. Instead, the segment which intesects should be found first (much quicker task), then the (ONE) intersection found.The problems may clearly become more serious (and dangerous) when the polyline is nearly straight. This is, unfortunately, very common in bridge and road design, which happens to be our bussiness.Best regardsVaclav
0 -
Hello Vaclav,> Looks better than 4.0.0039 which (at least on my PC) didn't show the aperture box so snapping was quite a problem.There was an initialization problem with the cursorsize. This required the user to do an extra step. But indeed we fixed it. > is not the only problem, actually it was not the reason of the 'random' results - > I normally use quite small aperture size (5) and even zooming closer to the points of interest did not solve the problem.I disagree. But you may have to zoom a lot. It's hard to predict how much you have to zoom.Only intersection points that are inside the aperture are used and as you zoom in, more and more points fall away. To filter out competing intersection points you may have to zoom a factor 10. You may point out that this is far too much. I would agree.Imagine this approach: When the snap moves from one point to another point(even if it's less then a pixel away), we draw a temporary bullett next to the snap marker. When there are competing intersection points close together you see the bullet flashing while you move the cursor and you know you have to zoom in until the bullet disappears. It would work, but it's a weak improvement. You would make a lot less errors but a good improvement would spare you the zooming.> Sander's "which is a regression that exists since version 4" looks like it should not be a big problem.I was stating a fact. We already made a fix for Vladimir's problem in our development code.> However, exploding the polyline in my problematic drawing shows the segments in question are all straight lines, no arcs. That's right. So we agree Vladimir's problem is different from the one you reported.> Zooming close to point 1 in the drawing, try several "ID" commands, you will get different results:what are "ID" commands?> - when approaching the intersection from left side of the polyline, X=0.494,Y=-4.826> - when approaching the intersection from right side of the polyline, X=0.496,Y=-4.832> After EXPLODing the polyline, the result is consistent, X=0.494,Y=-4.826. > This, I believe, is another problem not explained yet.Do you mean, why do we show virtual intersections with polylines but not with lines? It is indeed inconsistent.Virtual intersections are more related to the more recent "autotracking" mechanism.> The approach described by Sander in his first reply is, I believe, very problematic > and should be abandoned or at least (as an option) possible to switch off. We're very cautious about disabling this behaviour. But allowing the user to switch off the virtual intersections is a good approach.> I have observed this issue long time ago and I suspect there's a close relation between this aproach and the well known "snap freezing" problem found in older ICAD versions. > The algorithm seemed to search for intersections with many (if not all) segments of the polyline (CPU intensive task, thus "freezing" on slower machines) > and only then snapping to the nearest of these. > Instead, the segment which intesects should be found first (much quicker task), then the (ONE) intersection found.The snap freezing(your machine hanging for about 1 minute) is not present in the current implementation. The freezing was due to something else.I also think we could improve intersection snap performance if we only allow the real intersections. > The problems may clearly become more serious (and dangerous) when the polyline is nearly straight. > This is, unfortunately, very common in bridge and road design, which happens to be our bussiness.Agreed.> Best regards> VaclavRegards, sanderBricsCad
0 -
Hi, my notes in text below:> > is not the only problem, actually it was not the reason of the 'random' results - > > I normally use quite small aperture size (5) and even zooming closer to the points of interest did not solve the problem.> I disagree. But you may have to zoom a lot. > It's hard to predict how much you have to zoom.> Only intersection points that are inside the aperture are used and as you zoom in, more and more points fall away. Well, this is really a problematic behaviour. I could imagine some ambiguity with the intersection poits if the aperture box contained more than one SEGMENT of the polyline and even this would be wrong. As the ambiguity appears for all intersection points of all segments this is even worse situation. From the user's point of view, a polyline is ONE object and should be treated as such whenever calculating intersections (or at least it should be an option).> To filter out competing intersection points you may have to zoom a factor 10. You may point out that this is far too much. I would agree.Yes, it is, but the worst is that it's not a 'clean' solution at all - one does not know if the zoom is enough - for nearly straight polylines which can be partially convex/concave.> > Imagine this approach: > When the snap moves from one point to another point(even if it's less then a pixel away), > we draw a temporary bullett next to the snap marker. > When there are competing intersection points close together you see the bullet flashing while you move the cursor and you know you have to zoom in until the bullet disappears. > It would work, but it's a weak improvement. You would make a lot less errors but a good improvement would spare you the zooming.Unfortunately, "a lot less errors" is still too much :-), not to mention the drop in productivity. > > Sander's "which is a regression that exists since version 4" looks like it should not be a big problem.> I was stating a fact. We already made a fix for Vladimir's problem in our development code.Glad to hear that, well done.> > Zooming close to point 1 in the drawing, try several "ID" commands, you will get different results:> what are "ID" commands?Sorry, ID is my alias for IDPOINT - equivalent to AutoCAD's ID command - returns point coordinates.> > - when approaching the intersection from left side of the polyline, X=0.494,Y=-4.826> > - when approaching the intersection from right side of the polyline, X=0.496,Y=-4.832> > After EXPLODing the polyline, the result is consistent, X=0.494,Y=-4.826. > > This, I believe, is another problem not explained yet.> Do you mean, why do we show virtual intersections with polylines but not with lines? > It is indeed inconsistent.Virtual intersections are more related to the more recent "autotracking" mechanism.I think the developers of ICAD face a dilemma based on ICAD not having explicit "Apparent intersection" snap mode - there's an effort to make "appint" available (it is really a must) but then one can get quite seriously confused about the results (mixing "intersection" with "apparent intersection"). Right now I tested my problematic drawing in AutoCAD2002 with the following results:1. Having "Intersection" snap on, it returns always the same coordinates (ID command), as expected, no matter if the mouse moves a pixel left/right etc. - it has ONE intersection only to offer.2. If I want the intersection of the line with a specific segment of the polyline, I select "Apparent intersection" snap mode, click the line first, then the segment in question and bingo.I'm affraid there's nothing better than this behaviour - no tricky highlighting of segment of the polyline and similar 'goodies' will make the job easier.> > The approach described by Sander in his first reply is, I believe, very problematic > > and should be abandoned or at least (as an option) possible to switch off. > We're very cautious about disabling this behaviour. Well, I don't really understand why. You should be much more cautious about preventing users getting completely erroneous results then having ... what, really :-)? (I don't see any advantage in having to move cursor slowly around and watching the snap symbol jump from one point to another).> But allowing the user to switch off the virtual intersections is a good approach.Yes, but this is effectively equivalent to turning off the default "apparent intersection" implementation of "intersection" snap mode, thus introducing REAL "Intersection" snap mode which I strongly recommend.> > > I have observed this issue long time ago and I suspect there's a close relation between this aproach and the well known "snap freezing" problem found in older ICAD versions. > > The algorithm seemed to search for intersections with many (if not all) segments of the polyline (CPU intensive task, thus "freezing" on slower machines) > > and only then snapping to the nearest of these. > > Instead, the segment which intesects should be found first (much quicker task), then the (ONE) intersection found.> The snap freezing(your machine hanging for about 1 minute) is not present in the current implementation. The freezing was due to something else.I believe it was something else, but forcing the program to calculate (apparent!) intersections with plethora of segments clearly slows down the program, am I right? Please note that I'm talking about nearly straight polylines with hundreds or even thousands of segments. There surely is a faster way to get the ONE damned intersection point :-)> I also think we could improve intersection snap performance if we only allow the real intersections. I'm sure it would help. But the speed is not the concern now, it's the functionality.> > The problems may clearly become more serious (and dangerous) when the polyline is nearly straight. > > This is, unfortunately, very common in bridge and road design, which happens to be our bussiness.> Agreed.Yes. But it's not only bridge engineers who could get in trouble through this problem. Therefore, I hope it won't be given a negligible priority.Best RegardsVaclav
0 -
This is what we did:- plain intersection snapping no longer considers extensions of segments of polylines. So Vaclav, the confusing multiple snap candidates are gone alltogether. - a new extended snap works in two steps: first click one (p)line , avoiding snap points. Then click the second (p)line. The intersection of the extended (p)lines becomes a snap point. - the TAB button allows for cycling with highlighting over competing snap points.Apart from that, there were some fixes like the perpendicular snap (to lines) that is no longer suppressed when endpoint snap is on.regards, sander
0 -
What a pleasant surprise! I'll give it a try as soon as it becomes available for download.ThanksVaclav
0 -
Hello Sander,I'm very glad you gave the "snap problem' discussed here the priority and did the improvements you describe. I have just one question: The changes you describe - will they be available in the nearest ICAD release or do the changes need to undergo some kind of formal approval process in ITC which could result in a delay of their deployment?Regards,Vaclav
0 -
The new 4.1.0006 version seems to have solved the problem. Well done and thanks.RegardsVaclav
0