Robert Bradshaw wrote: > On Dec 30, 2007, at 10:38 AM, Bob Hanson wrote: > >> Robert Bradshaw wrote: >> > > Yep, I think this is the way to go. You mentioned curves, arrows, and > ellipses. What are the commands for curves/arrows? (If the > documentation is clear, just point me there...) And I couldn't figure > out a way to get a non-axis aligned ellipsoid (or one with three > separate radii). > curves, arrows, lines, points (spheres), planes -- all simple DRAW objects. Curves and arrows may be any number of segments, which are connected using a Hermite. Lines are two points. Planes are three (triangle) or four (quadrilateral) points.
> >>> >> this sounds very much like a simple set of Jmol script + associated >> files. > > > Yep. > >> In fact, just recently I expanded the zip file reading to ANY file of >> any sort read by Jmol. For example, right now in Jmol 11.3.65 you can >> give the command: >> >> script "spt.zip|ta.spt" >> >> which runs the script "ta.spt" found in the zip file "spt.zip". > > > Cool. How does ta.spt refer to other files in that zip file? Right now there's no way to specify "in my zip file" -- but I should add that -- so you would just specify the file name again, as for the script file. pmesh "spt.zip|meshes|mesh1.pmesh" something like that. > Just going to binary is going to do that (on both ends). The ascii > pmesh format is very simple and efficient to implement, with the > exception of the decimal conversions and having to close up the polygon. > > I would just as soon only allow one mesh per file--I'm thinking of > the TIFF file format that allows multiple images in a single file and > this greatly complicates the interface (not worried about the format, > the interface)--when reading a TIFF one always has to worry about > there being multiple images (though 99% of the time you want one) and > if there is more than one you have to worry about which one you want, > or how to show/pass two distinct images on to the user. > yes - well, zip files are fine, too, and a good binary header would allow jumping, but one problem is that web browsers must stream -- no random access! > E.g. If I did "load binary_pmesh.blah" and there were two meshes, how > would the script distinguish them. And if it couldn't, why not call > it all the same pmesh (as it doesn't have to be connected)? Or is it > an issue of being able to reset the vertex counters (e.g. specify > some vertices, then some faces, then some more vertices, then some > more faces, etc.) > keeping them separate allows full control over color of each, translucency, mesh vs. fill, etc. Quite possibly one-per-file and within a zip file would be the best. You get the compression, plus binary, plus readability. So then the files them selves could be extraordinarily simple: PM[0x00][0x01] nVertices nPolyhedra a few other items float[] vertices..... int[] polyhedra.... That would be about it. > If you think this kind of thing would be useful, than we could still > do it though. > >> 2) we use as much already-present Jmol functionality as possible, not >> duplicating that >> 3) it provides what you really need, not an approximation > > > I think Jmol + binary pmesh + zip archives will do an excellent job. > Let's go for that. I have exactly 24 hours to implement something like this just so you can try it out, then I'm off to Jamaica for a month without a whole lot of time for anything. > - Robert > -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
