VMD 1.3 Bugs

• The OpenGL version of VMD does not work correctly with the following text commands:
  • color change ambient
  • color change diffuse
  • color change specular
  The problem appears to be a deficiency in the OpenGL rendering code, and will be addressed in a future version of VMD.
• VMD versions 1.3 and earlier contain a bug in coloring by index. For very large systems, or systems containing many molecules, VMD may have problems with the "color by index" rendering option, resulting in many error messages being generated in the VMD command console. This bug has already been fixed in VMD 1.4.
• DEC/Compaq Alpha support: At long last, the VMD source compiles on Alpha systems. VMD still has a small number of runtime problems due to fact it is not 100% 64-bit-clean yet. We will not be shipping pre-compiled versions of VMD for the Alpha machines until we fix these problems.
• The OpenGL versions of VMD use the standard GLX routines to ask for a visual that supports stereoscopic display. VMD then proceeds to use the standard GLX mechanisms for performing buffer swaps on the stereo visual. Some SGI systems will return a visual that supports a special form of stereo requiring special handling (i.e. the normal GLX calls have no effect). VMD does not presently contain the code necessary to support these systems.
• Versions of VMD built with the most recent xforms libraries do not respond to changes in the light enable/disable box in the display form. This problem occurs with versions of VMD compiled with xforms 0.88 and possibly others. Versions of VMD built with the older 0.81 version of xforms do not have this problem, but there were other problems which necessitated the upgrade to xforms 0.88.
• There are a small number of rendering bugs in VMD related to the connections between tubes and beta sheets, and between tubes in the "cartoon" representation. These will be fixed in a future version of VMD. (there are tiny gaps between the end of tubes, sheets, or cartoons in some circumstances)
• Mesa does not support stereoscopic display due to the lack of a full underlying GLX implementation. GLX is the X server extension that handles hardware double buffering, stereoscopic display, and vertical retrace synchronization. Future versions of Mesa may include a complete implementation of GLX, which would allow true double buffering and stereoscopic display.
• The antialias commands don't work -- neither the text commands nor the buttons in the display form control the antialias settings in any deterministic fashion. This bug is still under investigation.
• Reading some DCD files with fixed atoms doesn't work -- this appears to be a problem with our DCD reader, which was written in C to read a Fortran-written binary data file. It could be a problem with the reverse-engineering of the format, or perhaps a difference in formats between different machines.
  Workaround: either:
  • don't use fixed atoms in the DCD file
  -or-
  • write the DCD file into a set of PDB files with a simple numeric extension (eg, "s.pdb.1", "s.pdb.2", ...) then read them in by hand or with a script, such as:

    proc read_converted_dcdfile {basename num {molid top}} {
        set mol [molinfo $molid get id]
        for {set i 1} {$i <= $num} {incr i} {
            animate read pdb "$basename.$i" $mol.$i
        }
    }
    

• Changing some of the atom information (secondary structure classification, beta and occupancy values, etc.) doesn't update the graphics display automatically. Workaround: press the "Apply Changes" button on the graphics form.
• Reading records of type 7 (triangle normals) from a Raster3D input script (such as the one produced from 'ungrasp') doesn't work because VMD mistakenly expects a non-existent RGB color triplet at the end of the line.
  Workaround: Use the following awk script to convert the records.

  cat inputfile.r3d | awk 'flg == 0 {print} flg==1 {print $0, "0 0 0";
     flg=0} /^7/ && NF ==1 {flg=1}' > outputfile.r3d
  

  This has a slight chance of modifying the header information, so double check that before you use it.
• The colors aren't the same between VMD and Raster3D. Raster3D uses the square root of the RGB value of an object. VMD doesn't compute that factor, so the output Raster3D files will have an RGB which needs to be squared, and the RGB values of a Raster3D input file will need to be, er.., square-root'ed.