On Dec 31, 2007, at 11:09 AM, Bob Hanson wrote: > > 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.
Excellent. >>> 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. OK. It'd be nice if the zip file were self-contained (e.g. one could rename and move them around freely). I'd like to be able to just load a zip file, and it would read MANIFEST (or some other standard file) to find what scripts/files inside the zip archive to load. How does jmol deal with relative paths? >> 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. My thoughts exactly. Not sure what "a few other items" would be, but for extensibility one could do PM[0x00][0x01] long chunk_length byte[chunk_length] data ... long 0 # chunk length 0 specifies beginning of data nVertices nPolyhedra float[] vertices..... int[] polyhedra.... >> 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. Thanks! I'll be excited to try it out, and have a great vacation in Jamaica. - Robert --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
