Hi Alan, this would actually be a nice addition to the plplot library, to also make it more modern. Look for example at
http://www.scilab.org/publications/JARAUSCH/PinconD.pdf on page 84 (document is in German). The colors of the 3d plot on the right are interpolated and this looks actually quite nice. We could add an additional parameter for the driver function which draws filled polygons. In addition to the array of points, we could also have an array of colors (for the corresponding points) as parameter. This would be minimal changes to the drivers and the driver itself would have to decide what it does with the colors if anything. Werner Alan W. Irwin wrote: > What started me thinking about how to support gradients within PLplot is the > large PLplot logo at the top of our webpage which is smoothly darkened on > the left. I don't know how Werner created that effect, but it is unlikely > to be within PLplot because we currently don't support gradients. Instead, > what we do (e.g., example 16) is approximate gradients by a series of > (normally rather wide) steps. Thus, in my attempt to mimic that logo within > PLplot, I plan to approximate the darkening effect, but I may have to use a > lot of narrow steps to get a good-looking smooth effect. This seems a > misuse of SVG which natively supports gradients so I may just hand-edit the > SVG code for the rectangle involved to apply a smooth gradient to it. > > I have done a quick google survey, > and it appears most/all of our modern devices (e.g., svg), and at least one > of our older devices (e.g., ps) have native gradient capability. This > represents an opportunity for PLplot to also support RGB (and RGBA) > gradients for those drivers with that capability. That would obviously > help for such > specialized applications as generating our logo, but I think it would also > be a big improvement for all our plot styles that represent surfaces. To > take a concrete example, look at > http://plplot.sourceforge.net/examples-data/demo08/x08.01.png where there is > room for improvement in how the bottom of the banana-shaped valley is > represented even for the relatively fine grid used for that example. > Typically, we represent those surfaces as a series of filled triangles. The > three points of the triangle allow you to approximate the local gradient and > apply it to the RGB and alpha of the colour of the triangle. That implies > much smoother looking surface results and/or larger triangles/smaller plot > files to represent the same surface for those devices that have native > gradient support. > > Note, the question of PLplot support for gradients has internal core library > implications (e.g., triangle representation for surfaces), API implications > (what is the most convenient way to let PLplot users specify gradients?), > and implications for each driver with potential native gradient capability > (how to translate from PLplot's representation of gradients to the driver's > representation). Furthermore, we will probably want to do a core library > fallback if the device driver doesn't have native gradient capability. Note, > so far I have only been talking about linear gradients, and my preliminary > feeling is we should stick just to those, but I should at least mention that > there are other kinds of gradient styles as well, see, e.g., the radial > gradient that is supported in the SVG specification > (http://www.w3.org/TR/SVG/pservers.html). > > So there is a lot to consider here. Nevertheless, gradient capability is > obviously important for graphics, and I therefore think it is time we > started discussing how we should support gradients with PLplot. > > So please give your thoughts on this topic especially if you can think of > better ways to implement it than my preliminary thoughts on that matter > above. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); 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 the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
