I'm CCing this to sage-devel. For Sage-devel people, the full thread can be found here:
http://www.mail-archive.com/jmol-us...@lists.sourceforge.net/index.html (subject: [Jmol-users] first peak at update to Jmol in SAGE (3-D function plotting)... The message I'm replying to specifically is: http://www.mail-archive.com/jmol-us...@lists.sourceforge.net/msg13382.html Robert Hanson wrote: > 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". > > Yes, that's right. > >>> 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. > If I recall correctly, there were problems when we had very large bounds (1e5?) or very small bounds (1e-8?). So the decision was made to rescale everything always to a 2x2x2 box centered at the origin (I believe). I assume that this is what we are addressing here. I wasn't in on the initial incorporation of jmol, so I don't know exactly what problems there were. But William Stein and Robert Bradshaw do; we can ask them on the mailing list. > > >>> 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 > > > Perfect. > >> * 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) > > I agree that we should look at interfaces. I was specifically thinking of matplotlib 3d commands here. > > >> * 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 > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
