Jmol 11.5.1 has pmesh binary "filename"
It's just experimental -- totally up to you what you want there, Robert -- but for now it looks like this: http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin described here: http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt seems to work with that one file. I'm hoping you can work with this and see how it goes. I'm done for some time now. Bob Robert Bradshaw wrote: > On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote: > >> I'm a bit lost on this thread, but I wanted to respond to the >> binary/multiple file issue. >> >> First, it's a fine idea to create a binary Pmesh file format. If we do >> that, though, let's not rush into it and just "create a binary >> equivalent >> of a Pmesh file." If this is really useful, then let's create a >> format that >> >> >> 1) allows for multiple pmesh objects > > > Sure, though if the zip file thing is working I think it is fine to > have one object per file too (as we also want to specify color, etc. > and will probably have spheres, labels, etc. too, so we'll be dealing > with multiple files anyway and it probably isn't worth trying to > figure out a way to encode this as scripts work so nice). > >> 2) includes a header that clearly distiguishes the file format >> within the >> first 4 bytes -- the "magic number" idea. > > > Yes, this is a good idea. One or two non-ascii bytes maybe (so other > readers can detect that it's binary data). Perhaps a flag that > specifies floats vs. doubles. Java already stores things in a endian- > consistant way, so we don't need to deal with that. > >> 3) allows for a simpler polygon definition -- for example, there >> should not >> be the need to redundantly specify the first vertex twice, as is >> part of >> the pmesh file format. > > > Certainly. Other than that the format is very simple to implement, > and I can't think of any changes that need to be made. > >> >> I recently added ZIP (JAR) file reading capability to Jmol -- no >> need for >> gzip here -- we can now read a zip file directory directly if we >> wanted to >> -- but that seems to me to be an unnecessary complication in this >> case. All >> we really need is a new binary pmesh format. > > > I often have more than just pmeshes that I want to include, and > presentation stuff (color, wireframe or not, etc.) is nicely kept > separate from the data in an easy-to-read ascii file. > >> Note that Jmol must be able to distinguish the file type from the >> initial >> few bytes of data, not the file extension. That's the role of the >> header. >> >> I'd be very happy to write this reader; but before we do so, let's >> brainstorm a bit on what would be optimal. > > > This would be great. > >> >> >> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel" <[EMAIL PROTECTED]> >> wrote: >> >>> >>> zip (jar) would be better for sets of files ... although Jmol >>> currently >>> doesn't have any mechanism to deal with a directory of files. That >>> is, it >>> wouldn't know which of the files you wanted to *open* and what you >>> would >>> want to do with the other files. >>> >> >> Jmol 11.3.65 can and does read ZIP files and their directories, and for >> model files, if the ZIP file contains a "manifest" then specific >> files can >> be read or skipped, then the directory contents may be investigated >> prior >> to model loading. This capability is iterative, so zip files >> contained in >> zip files contained in zip files.... can be read. > > > This sounds perfect--where is this documented? > > - 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
