VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Fri Oct 31 2008 - 16:59:44 CDT

On Fri, 31 Oct 2008, Benjamin Bouvier wrote:

BB> Rogan,
BB>
BB> Thanks for the link. Unfortunately, the tutorial confirms my initial idea of
BB> using variable traces and manually redrawing the whole scene each time the
BB> frame counter changes... In my case this is suboptimal, since it takes more
BB> than a minute to compute the custom graphics for a single frame (using C++

if you want to create an animation with vmd movie maker or equivalent,
this concern does not matter. in the other case, you could just draw
into multiple molecules and show only one of them using multimolanim.

cheers,
   axel.

BB> code). What I do now is to store the outputs of the C++ code (a Tcl script
BB> per frame) and 'eval' the right one in conjunction with 'trace', which is
BB> much better. Still, the scripts are long, and Tcl parsing does not come for
BB> free... Worse: while viewing a trajectory, I might look at a given frame
BB> several times, and each time the Tcl parsing has to be redone from
BB> scratch...
BB>
BB> Processing all frames once and for all and storing the resulting low-level
BB> primitives in some kind of display list (eg, as implemented by OpenGL) would
BB> be much more efficient. I was wondering whether there was any way to do
BB> that...

multimolanim is a close to that as you can get. everything else
would require additional low level programming.

BB>
BB> Cheers,
BB>
BB> On Fri, 31 Oct 2008 17:22:55 +0100, Rogan Carr <rogan_at_ks.uiuc.edu> wrote:
BB>
BB> >Hi Benjamin,
BB> >
BB> >You should check out the Images and Movies Tutorial. It has a section
BB> >on drawing per-frame graphics, as well as tcl example code.
BB> >
BB> >http://www.ks.uiuc.edu/Training/Tutorials/
BB> >
BB> >Cheers,
BB> >Rogan
BB> >
BB> >On Fri, 2008-10-31 at 16:46 +0100, Benjamin Bouvier wrote:
BB> > >Hi all,
BB> > >
BB> > >I'd like to make a movie out of a set of custom representations that are
BB> > >built using the 'graphics' low-level call.
BB> > >
BB> > >It seems, however, that 'graphics' calls affect all frames of a
BB> > >trajectory
BB> > >simultaneously rather than one at a time... Since the computation of the
BB> > >representations (ie, the generation of the Tcl code that draws them) is
BB> > >time-consuming, on-the-fly recalculation at each frame change is out of
BB> > >the question. My initial idea would be to store the Tcl code for each
BB> > >frame in a list or array, and have it execute at each frame change; not
BB> > >very elegant, and also not very fast, since parsing the (rather lengthy)
BB> > >Tcl code for each frame takes a couple of seconds...
BB> > >
BB> > >Any ideas?
BB> > >
BB> > >Cheers,
BB> > >--
BB> > >Benjamin
BB> >
BB>
BB>
BB>
BB> 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.