Re: [Plplot-devel] Surface contour problem for example 8

[<jc...@fe...>]

On Friday 14 May 2004 18:35, Alan W. Irwin wrote:
| On 2004-05-14 13:12+0100 Jo=E3o Cardoso wrote:
| > In plot3d.c code, after the comment
| >
| >  /* after shading, see if the triangle crosses one contour plane */
| >
| > one checks to see if the filled triangle intercepts any contour
| > level; for that, one gets the min and max z values of the triangle
| > vertices, and see if any contour level is between them.
| > If it is, one needs to know which triangle edge cross the countour
| > line, and get the x and y crossing coordinates.
| > After checking all three edges of the triangle, and storing the x/y
| > crossing points, if the number of crossing points is two, a line
| > segment is plotted between them.
| >
| > That is the logic, and I think it's correct. Of course there might
| > be problems in the implementation.
|
| Thanks for that explanation of the logic.
|
| My further experiments seem to indicate device problems are the
| source of the difficulties.
|
| The effect varies from device to device with png the worst, psc
| better, xwin near perfect, and tk perfect.  Concentrate on the eighth
| page of example 8 to see these effects, and further concentrate on
| the nearest part of the surface plot so that no hiding effects should
| be occurring.  For dev png, the surface contours are broken _a lot_
| as shown by both the ImageMagick display command and by kview.  For
| dev psc, the surface contours have triangular bits and pieces taken
| out of them as if rats nibbled it.  Use gv at 10x magnification
| -noantialias, then middle mouse to add say another 8x magnification
| to easily see the effect. (So we are using a mouse to catch a rat...
| :-)) If you use the xmag application on the xwin results a few of the
| surface contours are broken.  If you use zoom mode for dev tk, it
| appears no surface contours are broken.  For all devices, the bottom
| contours look fine.
|
| Since -dev tk seems fine, it appears the fundamental method used to
| generate the surface contours in plsurf... is fine, and we must look
| to device problems (or some core inconsistency that is device
| resolution dependent) to explain the bad surface contours.
|
| The only fundamental difference I can see between the way the good
| bottom contours and the bad surface contours are generated is the
| bottom contours are drawn by a series of calls to plline3 with no
| other fundamental device plotting command intervening, while surface
| contours are implemented by alternating calls to plP_fill (via
| shade_triangle) and plline3.  So I think for some devices, the
| transformation of x, y, z to projected pixels is not consistent
| between plline3 and plP_fill.  Or perhaps the core routines always
| have had such an inconsistency, and device resolution makes the
| effect larger on some devices than others. If the fill edges don't
| quite correspond in projected pixel space with the corresponding
| contour stopping and starting points at fill edges, then subsequent
| triangles will overlap previous surface contours and thus partially
| hide them.  Such an overlapping effect would be a function of the
| inherent resolution of the device, and it does appear that the
| problems generally decrease as the resolution of the device
| increases.
|
| To verify overlapping of fill areas is the source of the problem I
| temporarily disabled the call to plP_fill inside shade_triangle so
| the surface contours were generated by a series of plline3 calls with
| no other plotting calls to the device, and the problem with the
| surface contours disappears for the png device (and I presume for the
| others that show the problem as well).

Good work. I remember using some debug code to see the triangles edges,=20
without painting the triangles themself, but I don't remember doing=20
both things (contour lines and triangles without painting).

I always develop using the tk driver, because of the zoom, so I wouldn't=20
say that the tk driver is OK and the others are not -- it only happens=20
that eventual errors were corrected when viewed with the tk driver (at=20
high magnifications). But it means that that there are differences=20
between the drivers. We already knew that, but not with the severity=20
that you report.

Joao


|
| I think to debug this overlapping problem for each device, it will be
| important to look carefully at the contour ending points for each
| filled triangle to see why those don't correspond exactly (in
| projected pixel space for the device) with the edges of each fill
| area.
|
| 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 Project (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