From: Alan W. Irwin <irwin@be...>  20040515 07:00:35

On 20040515 03:06+0100 Jo=E3o Cardoso wrote: > On Friday 14 May 2004 21:18, Alan W. Irwin wrote: >  On 20040514 19:37+0100 Jo=E3o Cardoso wrote: >  > Good work. I remember using some debug code to see the triangles edg= es, >  > without painting the triangles themself, but I don't remember doing >  > both things (contour lines and triangles without painting). >  >  I just tried this using SHADE_DEBUG to build and install the library u= sing >  >  touch plot3d.c >  >  make 'CFLAGS=3Dg O2 mieeefp DSHADE_DEBUG' install >  >  I then modified the installed x08c.c in the following way to make big >  visible triangles with white surface contour (this latter is only allo= wed >  by my latest cvs commit). > ... >  Under these conditions the triangle edges are red, and the surface >  contours are white so it is extremely easy to distinguish the two. I f= ind >  under these conditions that red overlays white somewhere on the upper r= ight >  hand corner of the plot (where there are no hidden surfaces) for _all_ >  devices including tk. If the end points of the contour associated with = each >  triangle were exactly the same as the edge of that triangle this would = be >  impossible since the contour line is always plotted later and therefore >  always overwrites its associated triangle (edge). So there has >  got to be a misalignment between the plline3 call under SHADE_DEBUG in >  shade_triangle which generates the edge of the triangle, and the ordin= ary >  plline3 call that generates the contour for that same triangle. > > There is another possibility: latter drawn triangles partly overwrites > previous drawn triangle. As the contour uses the latter triangle, helas! Exactly. It would be okay if the latter drawn triangle has a contour drawn right to its edge, then the two pieces of the contour would match up with each other and look continuous, but if the triangle edges aren't quite aligned with the end of the contours =3D=3D> problems (see ascii art below)= =2E > >  I wonder if roundoff error or some other inconsistency in defining the >  intersection between the edge of the triangle and the contour > > yes, this is also a possibility. I don't quite remember how I did that. > > For a line segment (one edge) with known endpoint coordinates (xm, ym, zm= ) and > (px, py, pz), the problem is to find the xx and yy coordinates of the lin= e > segment with a known z coordinate clevel[k]: > > =09=09 xx[ct] =3D ((clevel[k]  pz[i])*(xm  px[i])) / (zmpz[i]) + px[= i]; > =09=09 yy[ct] =3D ((clevel[k]  pz[i])*(ym  py[i])) / (zmpz[i]) + py[= i]; > > I'm sure I followed a textbook. > > Numerically, problems could appear if the subtracted quantities, speciall= y zm > and pz, are very near each other, but that only happens when the triangle= is > very long and thin. It's probably okay. I also tried, e.g., comb1 =3D (clevel[k]  pz[i])/(zmpz[i]); comb2 =3D (zm  clevel[k])/(zmpz[i]); xx[ct] =3D comb1*xm + comb2*px[i]; yy[ct] =3D comb1*ym + comb2*py[i]; which is algebraically equivalent, but which might be less subject to significance loss, but it made no difference. So I don't think it is a significance loss problem in that part of the code. > In shade_triangle(), in the debug code, plline3() uses PLFLT, while plP_f= ill() > uses shorts, which is the result of plP_wcpcx(plP_w3wcx(PLFLT)). > But plline3() internaly also uses the same sequence of > plP_wcpcx(plP_w3wcx(PLFLT)), so both suffer from the same roundoff errors= =2E > > Good hunting :) At high resolution the png results look like a series of pixels which are either filled or not to make a "staircase" to represent a line. Suppose we have the following pattern where o represents the pixels on the edge line and x represents the series of pixels for the two contour lines which join at either e or z. X OO X OO E ZO X OO X OO Now the normal case is the two contours join at Z, and all is well because the end of the two contours is on a boundary pixel so the triangle on the left is filled, then the left contour ending at Z is drawn, then the triangle on the right is filled (overwriting Z), but then the right contour is drawn ending at Z and thus restoring it to its proper colour. However, i= f due to some error the two adjacent contours join at E rather than on the pixel boundary at Z, then Z gets overwritten by the right hand triangle fil= l with the improper colour, and the subsequent contour draw ends at E rather than Z so the contour colour is not restored properly for Z. The above diagram convinces me that if the real intersection of the contour and boundary were close to half way between Z and E, then tiny floating point inconsistencies could conceivably flip the contour edge pixel off by one from Z to E, and we end up with badlooking broken contours. However, that should only be a small fraction (probably vanishingly small) with the floating point calculations done in double precision before being transformed to the pixel value of the boundary. Instead, looking at one area of the 8th page of example 8 (with filling restored), I am getting roughly 1/3rd of the intersections between contours and triangles are off b= y one, and I think that is way too many to be due to roundoff error. Furthermore, if I increase the number of png pixels by using the geometry 4000x3000 option (rather than default 800x600), the fraction of contour/fil= l edge intersections that have broken contours remains roughly the same. So I think it may actually be a bug (inconsistency in position interpretation between plline3 and plP_fill), but I have run out of time to track this down any further. Anybody else have time/inclination to take over now? Alan __________________________ Alan W. Irwin email: irwin@... phone: 2507272902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick frontend to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linuxpowered Science __________________________ 