March 2005 - Chimera-users - RBVI Mailing Lists

Registration and VRML output for molecules
by Thomas Goddard 09 Mar '05

09 Mar '05

Julio Ortiz asks about registration behind a fire wall, and VRML output for molecules (ribbons, sticks, spheres). Tom ------- Start of forwarded message ------- Date: Wed, 09 Mar 2005 09:09:04 +0100 From: Julio Otiz <ortiz(a)biochem.mpg.de> To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Subject: Registration-VRML-Chimera Hi Thomas: A couple of question: 1) Chimera registration: When I try to register from our institute, behind a firewall, I can not register, I received an error message as there were not internet connection. For my personal computer is not a problem. I can do it from home, but for other computers at the institute, it could be a problem. I would like to update all our versions from chimera, so..how to deal with the registration problem afterwards? 2) VRML export of pdb file representations: As far as I know Chimera can export surfaces of density maps to VRML format. It is possible to export some representation of a pdb files, like ribbons, sphere or sticks also to VRML?. There are some programs that do it, so maybe could be a nice feature to introduce in Chimera (if is not already possible). Greetings, Julio ------- End of forwarded message -------

3 2

Combining ribbons and ball-n-stick using neon
by Todd Weaver 09 Mar '05

09 Mar '05

Dear Chimera- Wondering if there is a way to combine ball-n-stick rendered with neon and displaying distances as dashed lines with ribbons for other parts of the protein. I have attached an image captured with save, all looks good except the distances are not displayed as black lines because it has not gone through neon. If I run neon the ribbons do not show up. I would like to have both in the final image. Warmest regards, TOdd -- Todd M. Weaver, Ph.D. UW-La Crosse 1725 State Street Chemistry Department 4020 Cowley Hall La Crosse, WI 54601 Ph. (608)785-8269 Fax (608)785-8281

3 2

suggestion
by Esther Garcia-Rodriguez 07 Mar '05

07 Mar '05

Hi, I am working with structure superposition and I have noticed that labelling relevant residues when two structures or more are superimposed is a bit of a nightmare. As the labels go to C-alpha in all cases it is very difficult to see anything. I would suggest to allow the user to change the default and be able to establish particular positions for labels, as well as the distance from the relevant atom. For example, label all selected residues in one chain at 0.1 angstroms from the CG atom and all of the second chain at 0.2 (in X or Y). Or maybe just been able to change the minimum distance between labels in all directions. Thanks, Esther Esther Garcia Rodriguez Henry Wellcome Building for Biocatalysis University of Exeter Stocker Road Exeter EX4 4QD United Kingdom

2 1

HELIX/SHEET/CONECT records for non-existent bonds/atoms are being inserted into file.pdb when pdbrun nouser cat > file.pdb is run
by Sabuj Pattanayek 07 Mar '05

07 Mar '05

Hi, If I load a pdb, display only selected atoms/bonds, then do pdbrun nouser cat > file.pdb, the outputted pdb file also has HELIX/SHEET/CONECT records for non-existent bonds/atoms (as if the pdb file in its entirety was written out). Is this a bug or a feature? Is there some way to completely turn off output of HELIX/SHEET/CONECT records? Thanks, Sabuj Pattanayek

2 1

"add-vertex" button volume viewer
by Andrew Jewett 02 Mar '05

02 Mar '05

Please forgive and ignore my earlier post. I should have read the manual first. These features are already implemented. I'm sorry. However there are some user-interface issues... In particular, the method for adding and deleting points to the transfer function that determines voxel opacity and color could be more intuitive. (CTRL-click) This can have a big impact. I suggest putting small add-vertex, cut-vertex buttons near the histogram graph (see attatchment #1). (I stole these icons from xv) The results of using multiple vertices to control colors and or brightness-levels are strikingly better than using just two points. It would be good to make it obvious from the user interface that this option is available. Also, each time the user adds another vertex, a new color should be chosen, not the default white, in order to clue the user that the color can be changed. Similarly, it would be good to explicitly have an "add surface" "delete surface" buttons in solid or mesh mode. (No icon necessary, just write the names out in the buttons themselves itself). So go ahead and leave CTRL-Click in, but add buttons to make it explicit, and make the default color change each time a new vertex (or isosurface) is added. I've played with volume-viewer for quite a while, without realizing these options were available. (RTFM, I know...) And these features are _cool_. For example, attatchment#2 is an image of the same phage-T4 shown in the chimera image gallery using multiple colors. I like it a little better than the static grey image that Steve McQuinn made for the image gallery. http://www.cgl.ucsf.edu/chimera/ImageGallery/entries/phageT4/phageT4c.jpg Again, I apologize for my earlier email. Anyway, cheers Andrew okay, back to work...

2 2

colormap -and- opacity functions for voxels
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. I've asked a lot of questions, and I keep getting these long thoughtful and technical replies. Thanks. It's nice to get these replies However don't feel obligated to reply at all, at least when I post a question. The other features I mentioned are more important to me at least. I don't want you to be kept busy replying to emails. The question is: why not have a simultaneous independent opacity-map and color-maps for voxel-rendering? (...and I suppose, why do they have to be linear functions? Is piecewise linear hard to implement?) It seems unnecessary that the voxel values should only determine the opacity of the voxel. It seems reasonable to allow the color to be determined by the volxel value in addition to the opacity (for example, a cold-to-warm-to-hot color scheme). It looks like some kind of colormap user interface has been implemented in chimera. (Nice T4-phage slab image, by the way..) Would this be hard? This way, one could distinguish the DNA inside the T4 phage from the within capsid shell. Currently, 3-D volumetric rendering is cool, but it needs ...something. Since the demand for voxel rendering is probably low, I would understand if you choose to delay to ignore these issues. Andrew ------- That's the end of my question, but I included ------- some pictures at the end, for comparison. ------- You can skip this part. ------- They are not in color, but they do look ...pretty. ------- I wonder what they are doing? http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F5 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F19 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F8B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F16A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F17 Probably the main reason it looks so nice I think is because their data is manifestly much less bumpy than electron microscopy data. Also I'm suspect that increadibly expensive 3-D hardware doesn't hurt either. However there is something else interesting going on in these pictures. It seems that what appear to be fully opaque objects have a range of brightnesses/colors. In chimera, fully opaque objects are solid white (or blue or whatever color is set by the user) and they have no features except their somewhat fuzzy silhouette. The source of these pictures is a paper published at: http://radiographics.rsnajnls.org/cgi/content/full/19/3/745 One thing they talked about in the article was that they use separate brightness and opacity functions as a function of voxel value. They also use more general piecewise-linear functions instead of linear ones ("percentage classification"). The combination of those two features might explain something. Anyway, I wonder what they are doing. No need to reply. I'd rather you work on other stuff right now. Cheers! Andrew

1 0

per-model-clipping needs "all models" option
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. Please forgive me for sending this message twice. In the first version, I forgot to include a subject line, so I'm sending it again. --------------- On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

3 4