From: Miguel <mi...@jm...> - 2007-12-28 19:27:09
|
>> I suspect that you will encounter other issues with lighting on very f= lat >> triangles and "cracking" in triangulated surfaces. As I understand it, these are typical problems with graphics engines ... and there was never >> much demand for these kinds of things within Jmol. > > Java3D seems to handle this kind of thing fine, so I'm sure it can be done with Jmol too (just that no one's needed/noticed it before). Agreed. > I was thinking about implementing a "binary" pmesh (same exact > format), unless someone's already done that. Also, it'd be nice to read in a whole bundle of files at once (I'm thinking a .zip file with a script and all associated resources). I think that would be fine. Jmol has support built in for gzip files. Any molecular data file format can be gzipped and Jmol will automagically unzip it. gzip was nicer for this application because I was reading a single file. 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. >>>> I put together a little page for you guys to experiment with. It's a= t >>>> http://chemapps.stolaf.edu/jmol/docs/examples-11/math.htm >>>> Try a few things there; see what you think. The example uses 100,000 quadrilaterals, and it's pretty fast in terms of rendering. >>> >>> Awesome! >> >> Bob ... that is beautiful! > > I've been having trouble connecting to chemapps.stolaf.edu... is it jus= t me or is anyone else having issues with this? Uhhh ... I think it is you :) Miguel |
From: Robert H. <ha...@st...> - 2007-12-30 04:55:35
|
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 2) includes a header that clearly distiguishes the file format within the first 4 bytes -- the "magic number" idea. 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. 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. 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. On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel" <mi...@jm...> 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. Bob |
From: Bob H. <ha...@st...> - 2007-12-30 18:06:10
|
possibly, but let's talk first about what you are really interested in doing, then talk format. Arrays aren't necessarily the solution. Pmesh is not what you want for simple planes and objects -- that is for complex mathematical descriptions of surfaces. Using specific colorings and shadings sounds like Jmol scripting to me. So I think you are talking about a mix of objects, some of which are memory/filespace intensive, such as mathematical surfaces, and some of which are simple objects. Give us a few scenarios to work on. What would these sage-results entail? Q: Do you ever map surface data with other data so as to color it with, say, a scalar field? Bob Fernando Perez wrote: >Howdy, > >On Dec 29, 2007 10:59 PM, Robert Bradshaw <rob...@ma...> wrote: > > >Just as an FYI: as of the last few days, numpy has developed a binary >format for arbitrary arrays. The current plan is to have the base >file format (default extension .npy, but there's a magic string header >for extension-less identification) contain single arrays, and to use >zip files for multi-array files with a dict-like interface. > >It's in a branch right now, here's the format spec: > >http://projects.scipy.org/scipy/numpy/browser/branches/lib_for_io/format.py > > > Bob -- 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 |
From: Bob H. <ha...@st...> - 2007-12-30 18:38:58
|
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). Take some time to think about all the sorts of objects you will want. We already have spheres and ellipses, planes, lines, curves, arrows, and labels. These are not pmesh objects, and there is absolutely no reason to encode them as such. It's quite possible that the current inline scripting of pmesh will suit your purpose quite well for surface data and Jmol scripting would allow you to deliver other objects such as these just fine. > >> 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. If possible, I would prefer all floats -- it is going to be converted to floats anyway, as Jmol does not deal in doubles at all. > >> 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. > this sounds very much like a simple set of Jmol script + associated files. 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". >> 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" <mi...@jm...> >> 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? > That reminds me, it isn't yet. It is demonstrated at http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm#topic61 The manifest capability only applies to loading models, not pmesh objects. Let's keep thinking about this. We need to make sure that 1) the mechanism is efficient 2) we use as much already-present Jmol functionality as possible, not duplicating that 3) it provides what you really need, not an approximation --Bob -- 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 |
From: Bob H. <ha...@st...> - 2007-12-31 19:09:48
|
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 |
From: Bob H. <ha...@st...> - 2008-01-01 04:23:55
|
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" <mi...@jm...> >> 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 |
From: Bob H. <ha...@st...> - 2008-01-01 20:28:27
|
The zip file business is complete. What you do is, in 11.5.2, set defaultdirectory "whateverfile.zip" then when you issue load myfile.xyz or script "test.spt" those files are drawn from the zip file, just as though it were a real directory. To go back to normal operation, issue set defaultDirectory "" Also, I modified the pmesh binary specs just a bit. I decided we really needed four full bytes of magic number, so it's the fifth byte that indicates big/little-endian. We could compress this a bit more by using bytes instead of ints for each polygon # of vertices, but maybe that's not necessary? For now, consider this binary format HIGHLY experimental and subject to change. Bob # new feature: pmesh BINARY "filename" # BINARY keyword is optional, but recommended for efficiency # # * 4 bytes: P M \1 \0 # * 1 byte: \0 for bigEndian # * 3 bytes: reserved # * 4 bytes: (int) vertexCount # * 4 bytes: (int) polygonCount # * 64 bytes: reserved # * ------------------------------ # * float[vertexCount*3]vertices {x,y,z} # * [polygonCount] polygons # * --each polygon-- # * 4 bytes: (int)nVertices (1,2,3, or 4) # * [4 bytes * nVertices] int[nVertices] # * # * note that there is NO redundant extra vertex in this format # # see little-endian example at http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin # and http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt Nico will release 11.5.2 probably later today. Bob Robert Bradshaw wrote: > Thanks. Looks good to me. Where can I get some jars to play around > with this? > > Any more work on the zip file stuff? > > - Robert > > > On Dec 31, 2007, at 8:23 PM, Bob Hanson wrote: > >> 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" <mi...@jm...> >>>> 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 >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ >> To post to this group, send email to sag...@go... >> To unsubscribe from this group, send email to sage-devel- >> uns...@go... >> 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/ >> -~----------~----~----~----~------~----~------~--~--- > -- 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 |