From: <jc...@fe...> - 2004-05-15 02:07:46
|
On Friday 14 May 2004 21:18, Alan W. Irwin wrote: | On 2004-05-14 19:37+0100 Jo=E3o Cardoso wrote: | > Good work. I remember using some debug code to see the triangles edges, | > 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 usi= ng | | touch plot3d.c | | make 'CFLAGS=3D-g -O2 -mieee-fp -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 allowed | by my latest cvs commit). =2E.. | Under these conditions the triangle edges are red, and the surface | contours are white so it is extremely easy to distinguish the two. I find | under these conditions that red overlays white somewhere on the upper rig= ht | 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 ea= ch | 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 ordinary | plline3 call that generates the contour for that same triangle. There is another possibility: latter drawn triangles partly overwrites=20 previous drawn triangle. As the contour uses the latter triangle, helas! | 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. =46or a line segment (one edge) with known endpoint coordinates (xm, ym, zm= ) and=20 (px, py, pz), the problem is to find the xx and yy coordinates of the line= =20 segment with a known z coordinate clevel[k]: xx[ct] =3D ((clevel[k] - pz[i])*(xm - px[i])) / (zm-pz[i]) + px[i]; yy[ct] =3D ((clevel[k] - pz[i])*(ym - py[i])) / (zm-pz[i]) + py[i]; I'm sure I followed a textbook. Numerically, problems could appear if the subtracted quantities, specially = zm=20 and pz, are very near each other, but that only happens when the triangle i= s=20 very long and thin | is=20 | propagating to an off-by-one in the identification of the edge pixel for | the two cases? In shade_triangle(), in the debug code, plline3() uses PLFLT, while plP_fil= l()=20 uses shorts, which is the result of plP_wcpcx(plP_w3wcx(PLFLT)). But plline3() internaly also uses the same sequence of =20 plP_wcpcx(plP_w3wcx(PLFLT)), so both suffer from the same roundoff errors. Good hunting :) Joao | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | 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 front-end to PLplot (yplot.sf.net), the | Loads of Linux Links project (loll.sf.net), and the Linux Brochure Proje= ct | (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This SF.Net email is sponsored by: SourceForge.net Broadband | Sign-up now for SourceForge Broadband and get the fastest | 6.0/768 connection for only $19.95/mo for the first 3 months! | http://ads.osdn.com/?ad_id%62&alloc_ida84&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |