>> The result is that the two molecules are rendered with one directly on >> top >> of the other. >> >> Q: Is this a desirable thing? (I honestly don't know) > > This might be acceptable behavior - assuming that there was a way to > select a specific molecule (see below) and then move it around to get a > better view. > > I can also see one situation where this behavior would be expected - say > I do an alignment of two structures and save these structures to two > files. The alignment procedure will generate coordinates such that the > two molecules lie on top of each other (their center of gravity will lie > at the same point) - when these two are loaded into Jmol the user should > see that the molecules lying on top of each other and hence view the > alignment
OK >> Case 2 >> ------ >> Molecule A has atoms clustered around (1000,1000,1000) >> Molecule B has atoms clustered around (-1000,-1000,-1000) >> The average of all the points is somewhere near 0,0,0 >> We center at the average of all the points >> >> The result is that the molecules on-screen are very small ... two small >> clusters spread very far apart. >> > > Once again if this situation did occur then the user could move the > molecules closer to each other by hand after loading. Yes, but the scaling factor will be way off. The user can move the two so that they are superimposed, but they will be small spots taking up a very small portion of the screen real estate. >> Q: Do atom coordinates every get calculated so that they are located far >> away from (0,0,0)? I don't know. > > I have'nt seen HIN files with very large coordinates > > > One solution to the above problems could be to translate coordinates of > any loaded molecule to the origin. That is essentially Case 1 > But this might then create problems > with cases where say a file contains 2 molecules which are placed at > specific positions. Exactly > If Jmol considers all the molecules in a given file > as 1 system and translates the *whole* system to the origin then it > would work. If Jmol loads a file with multiple molecules as distinct > molecules then this idea would not be good. > > I tend to the option of letting the user load multiple molecules and > Jmol placing then wherever the coordinates indicate and let the use do > the maniuplation. But there is no such thing as 'wherever the coordinates indicate' If Jmol did that then I think that almost every file that was ever loaded would look lopsided. Put another way ... I have never seen a molecular model file where the default center of rotation was 0,0,0 > To make things easier for the user there could be menu options that > allow a molecule to be centered, or some aspect of the molecule set as > the origin etc. So an example workflow could be: > > 1) load a molecule. This will set the origin at some point > 2) load another molecule. Say the centroid of this molecule lies at > 10,10,10. > 3) The user can now > 3a) drag the second molecule closer to the first one > 3b) choose a menu option 'Center' that translates the molecule to > the origin of the first molecule > >> Q: Do people ever cut out pieces of a .pdb file just to look at section? >> Probably. > > I don't know > > >> > b) the center of the coordinate system that constitutes the current >> > viewport > > Well I made this comment based on some OpenGL code I had written a very > long time ago - so my terminology and/or understanding might be way off! > > My thinking was this: a XYZ file specifies some set of coordinates. To > dsiplay these coordinates, they need to be transformed to some world > coordinate system. Say the transformation is given by the unit matrix > (so the file coordinates are the world coordinates). The next step is > then to translate the world coordinates to screen coordinates - this > last set of screen coordinates would define the viewport. > >> Not sure what you mean by this. >> >> Q: Are you saying that selecting a molecule means selecting a viewport? > > No. My thinking is that that the viewport coordinate system (essentially > the screen coordinate system) is the same for all molecules that have > been loaded. So selection is not done by choosing viewports - rather > selections are done on the basis of atom/molecules and the center of > rotation would be defined as the center of the viewport (or as whatever > origin the used defined by using the 'Define Center' menu option) OK >> Q: If so, does this mean that the display 'shifts' when the user >> switches >> focus from one molecule to the next? > > See above. Sorry, I am getting lost. > However, as I mentioned, I have little experience with 3D graphics and > my understanding of the viewport may be totally wrong. So feel free to > ignore the above But I value your opinion. These are the issue that we need to think through if we are going to allow loading more than one molecule at a time. >> >> Separately, and more imporantly ... >> >> Q: Is there any other molecular vision package that does this? > > PyMOL > MOE I will try to find out how PyMOL handles this situation. > (though they're not just visualization packages) > > I read somewhere that the SWISS PDB viewer also does something like this > but as I have'nt used it I can't say much more > >> Q: Is there any other molecular vision packate that does it *well* ? > > I think the mechanisms by which the above packages work are quite nice. > > In the case of PyMOL, switch to mouse editing mode and then shift+right > click+drag rotates the molecule containing the atom that the mouse > pointer is nearest too Good. But I need you to figure out (or find out) what the center of rotation is. Do this for me. Take a small XYZ file and add 1000 to each of the coordinates. First, load it up by itself and see what happens. Then load it up with another XYZ file and see what happens. > In the case of MOE, select the molecule (by selecting an atom and then > extending the selection to the entire molecule) and then Alt+Shift+drag > middle button translates the selected molecule, Alt+drag middle button > rotates the selected molecule > > (Personally, I like the idea of extending selections - makes working > with large proteins very handy - does Jmol have this capability?) To be discussed in the future. Miguel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
