From: Miguel <mt...@mt...> - 2003-10-06 07:09:23
|
>>Rather, the client > > Which client? Sorry ... in this case cdk ... :) Jmol now defines an API for accessing the molecular model ... as a layer to separate the rendering engine from the file IO and in-memory data structures. So, when I am playing in the Jmol sandbox, I have come to start thinking of cdk as the 'client'. > One approach is the have a separate library that will generate the > cartesian coordinates that need to be displayed. This then feeds the > complete data structure into Jmol. This is what would have to be done > for non-regular structures (e.g. MD simulations) Yes. >>should just go ahead and supply the atoms >>in the neighboring cells. >> >>I was looking for a simple/clean/efficient way to avoid building extra >> data structures for the adjoining cells ... but this no longer looks >> simple. > > I agree it is nice to have a small display list and iterate over it with > different operators. However you face the problem of what happens when > users select atoms in the expanded set - you have to reverse the > process. And when they want to measure distances between the sets Very good point. I now agree with you that the right thing to do is have Jmol focus on the rendering aspects of the problem. The 'client' library should calculate the positions of all the atoms in all the neighboring cells and pass this entire atom list to Jmol. Scripting commands can be used to restrict the display to subsets of the cells. Miguel |