>>> I'm still of the opinion that the notcrossed function should not use >>> the 2 pixel fuzziness. At this point in the drawing we are dealing in >>> integer pixels and we need only an epsilon test I think. I think the >>> best fix is to change this. There are some sticking plaster solutions >>> that would hide the problem but not really fix it in my opinion. I >>> would really like to change the notcrossed function unless anyone has >>> some really strong objections? >> >> >> My opinion is this is an extraordinarily tricky topic where all the >> currently active fill code (i.e., the part of the code not currently >> removed by the C preprocessor) needs to be completely reviewed and >> potentially rewritten. Also, I think the fuzziness logic (with all >> bugs fixed in that code) should stay just in the interests of >> providing some tolerance for numerical rounding errors. For example, >> even the article <https://en.wikipedia.org/wiki/Point_in_polygon> >> talks of providing some numerical tolerance. Note also, such >> tolerance is certainly required for the integer case since minute >> rounding errors in the floating point calculations that decide, for >> example, whether a point is inside or outside a polygon can shift >> integer results around by +/- 1. >> >> I have a topic branch where I have already taken some substantial >> steps along the above ideas (including at least one bug fix in our >> current fuzzy logic in notcrossed). I temporarily halted work on that >> topic some time ago, but assuming you can provide a test example that >> triggers fill bugs regardless of compiler or optimization level, I >> plan to take up that topic again where the first order of business >> will be to compare (using imagemagick image differences) updated fill >> algorithm results versus 5.11.1 results for all our standard examples >> that use fill in some way. (That test should turn up any unusual fill >> artifacts in our examples that are generated by bugs in the original >> or revised fill algorithm, and once that test is implemented it should >> be done for any fill change from now on.) In addition, of course, I >> will look carefully at your example to make sure the revised fill >> algorithm produces the correct result for it. >> >> Assuming you are able to provide the requested example which triggers >> the fill bug regardless of rounding issues, and the above >> plan meets with your approval, I would plan to start working on this >> topic again just after the current release is out the door. >> >> Note also there are still a number of relatively small issues I would >> like to address for this release, but because of the break I mentioned >> above, I made little progress on those this summer so that release >> deadline is still indefinite and at least a month or two away. >> I agree that this is tricky, but feel this is something we can deal with without being too troublesome. Algorithms and code already exist to do this consistently - we're not the first to have to deal with it. In fact here is a 7 line C implementation that deals with the ray hitting a vertex correctly, but doesn't give any warning about if the point is close to or on a segment.
I still don't understand why we need two whole plplot units of fuzziness. I understand that we round and that can give us up to two pixels of error. But surely we just accept that and work with the rounded polygons as if they were exact - in fact they are exact because they use integers. for example we wish to plot two rectangles which end up with internal coordinates of the opposite corners of (200,400.2),(600,600.4) and (200,600.4),(600,800.1). We round these to give (200,400),(600,600) and (200,600),(600,800). Now there is absolutely no count that the point (350,600.2) is in the second rectangle. Of course if we were using the original coordinates this point would have been in the first rectangle. But we are not plotting the original coordinates, we are plotting the rounded coordinates and that is what matters - the coordinates we are plotting. I would clearly like to get this fixed properly, but in the meantime would anyone object if I apply a sticking plaster fix for this as it is something I have hit about half a dozen times over the last six months - I presume this is because I've been plotting some really high resolution data. So I do really need to avoid the issue for now. Phil ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
