Jonathan and Jason, This is a great starting point for a list.
> 1) An arbitrary number of isosurfaces, with attributes color, > > transparency, visibility, mesh color, mesh visibility, lighting state > > (fullylit default). The range for the numbers in these isosurfaces > > should be limited only by the number range available for floating point. > Jmol 11.9 has a COLOR MESH option to isosurface/pmesh so that you can color the mesh a different color than the surface itself. In addition, like I said, you can add contour lines along planes; I think this is more what the Sage community is interested in than a set of lines around the triangles that we have called "mesh". > > 2) Strings to title the X, Y and Z axes > This should be very easy to implement. > > 3) Based on the range of the isosurfaces (pmeshes) provided Jmol would > > determine the bounding box and the scale adjustment for display. > Of course the way to do this now is with invisible atoms, but I agree, that should be simple enough to add as an option. > > 4) This structure would have scriptable functions for turning on and > > off each of the edges of the bounding box, the axis titles and > > automatically computed numerical ranges on the axes (a real bonus > > would be if the tick numbers could be associated with any of four > > equivalent axes). I think the SAGE solution of a minimum of 3 numbers > > per axis is pretty good. Really big displays (> 600 px square) could > > benefit from 5 numbers per axis. > > > A nice little project. In the past I have written graphing systems (for example, http://stolaf.edu/people/hansonr/divgraph/examples.htm), so I am well aware of the issues there with respect to ticks and numbering. It's not a simple issue. > > Things related to axes/bounding boxes that come to mind (possibly > covered in what you said above) are: > > * a way specify tick locations for each axis (in addition to the option > of jmol doing things automatically) > If you propose a method, I can implement that. > * a way to specify formats for tick values (e.g., "%.3f", or whatever is > easiest for you guys to parse and use) > Right, we already use that. It looks like this: $ print format("%0.3f",0.52) 0.520 $ print format("%0.-2f",0.52) 5.20E-1 $ print format("testing %10.3f here",0.52) testing 0.520 here $ print format("testing %-10.3f here",0.52) testing 0.520 here > * a way to specify just a list of tick labels (so we could do a tick > labeled "pi", for example) > How about if we just copy gnuPlot's method for doing this? Does gnuPlot do what you need it to do? Or Maple or Mathematica? No sense in reinventing the wheel. Since we are in 3D we need to think about how these objects would move around as the model is rotated. That's a good trick. (important, too, I think) > * a way to turn on and off axes that meet at the origin and the bounding > boxes, independently. (this is already possible, I'm pretty sure) > yes, easy. * Axes that meet at the origin having tickmarks too. > > sure > > > So ideally SAGE can just generate an unscaled list of isosurfaces, > > planes, etc.. Then Jmol would worry about making the plot pretty. > > > > that is definitely the idea. > > That would be great and would clean up the code right now that does > scaling, etc., before things ever get to jmol. It would also allow us > to more easily use things like picking in jmol, which I think is messed > up right now since we scale everything before it gets to jmol. > > I'd like to suggest also that Jmol be able to scale a plot any which way. Sage should not have to do the transform from user numbers to Jmol coordinates. You should be able to just use the coordinate system of the user and let Jmol do the rest. Or you could specify some sort of affine transform you want Jmol to apply. Jmol already does this with atoms -- it's just the specification of a unit cell. An interesting challenge. Bob -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
