- Chimera-dev - RBVI Mailing Lists

read file by python script and color pdb file with script
by Sanjeev Sariya 25 Apr '14

25 Apr '14

I am having 2 coordinates in check file. I want to take/read them and paint my pdb file loaded in chimera. I have chimera in my ~/bin/ System specs: ubuntu 64 bit, 13.10, 4gb ram Below is the command I have used for script-chimera communication $ chimera64-1.8.1 --script "y.py check" -- Q6UXT6.pdb I am storing values in listu and want to use them for coloring my file loaded. rc("color blue :"+listu[0]+"-"+listu[1]) This works well, if hard coded rc ("color red :55-86") I do not get any error. The particular protein length is not colored. attached 3 files. Kindly suggest, how do I proceed. -- Regards Sariya

2 2

Re: [chimera-dev] Help with "looping through PDB IDs" script
by Eric Pettersen 22 Apr '14

22 Apr '14

Hi Navya, This later mail of yours provides some additional details that help. So for one thing you might also want to look at the Programmer's Examples (Examples), particularly the first one ("Chimera's Object Model"). At any rate, the obvious problem with the script you have so far is that you haven't defined the 'residues' variable. Let's say you are trying to work with residues 50.A, 55.A, and 70.A. Here's a little code snippet that will get those residues into the 'residues' variable once you've opened your structure: rc("sel :50.a:55.a:70.a") from chimera.selection import currentResidues residues = currentResidues() Now, I don't know where you're storing your lists of residues. Are they in the same file as the IDs? A separate file? I don't know if you need more help with that or not. So once you have the residues, then printing the atomic surface areas and bfactors is: for r in residues: for a in r.atoms: print>>outf, a, a.areaSAS, a.bfactor Getting the CASTp information is another whole can of worms however, since Chimera stores that info in the CASTp dialog rather than with the atoms and residues. Nonetheless, once you've got the rest of your script working you could try to do that part. In would involve copying the processCastpID function from CASTp/__init__.py (in your Chimera installation's 'share' folder) and deleting the last two lines and instead return the cavity list. Each CastpCavity instance has 'mouthInfo' and 'pocketInfo' attributes which are dictionaries that have an 'atoms' key. The value for the 'atoms' key is a chimera.selection.ItemizedSelection instance. You can use the contains() method of those ItemizedSelections to see if a particular atom is in the ItemizedSelection. The pocketInfo dictionary also has 'SA volume' and 'MS volume' keys you can use to get the desired volume info. --Eric Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu On Apr 16, 2014, at 12:44 PM, Navya Shilpa Josyula <njosyu2(a)uic.edu> wrote: > Hi, > > I need a help in chimera scripting. I have text file with list of PDB IDs and corresponding residue list. I am trying to write a chimera command which will scan this file, open each PDB ID and select the corresponding residues listed in the file. After selecting, it should write out the values of atomic areaSAS, atomic Bfactor and which atom belong to CASTp identified pockets (with pocket volume). I know I am asking a lot here but I am new to chimera scripting and I searched the users mailing list and found the "looping" script, > > http://www.cgl.ucsf.edu/pipermail/chimera-users/2012-February/007281.html > > but it is not working for me. Attached is the script I have till now. > > Please help me on this. > > Thank you in advance, > Navya > <test.py> import os from chimera import runCommand as rc # use 'rc' as shorthand for runCommand from chimera import replyobj # for emitting status messages # change to folder with data files os.chdir("C:/Users/Navya Shilpa/Desktop/thesis/All_Proteins/nonred") # open file of PDB IDs f = open("C:/Users/Navya Shilpa/Desktop/thesis/All_Proteins/nonred/nr-list.txt", 'r') # loop through the IDs, opening, processing, and closing each in turn for line in f: pdbID = line.strip() replyobj.status("Processing " + pdbID) # show what PDB we're working on rc("open " + pdbID) rc("surf") # surface receptor outf = open(pdbID, "w") for r in residues: print>>outf, r, r.areaSAS outf.close() rc("close all") # uncommenting the line below will cause Chimera to exit when the script is done #rc("stop now") # note that indentation is significant in Python; the fact that # the above command is exdented means that it is executed after # the loop completes, whereas the indented commands that # preceded it are executed as part of the loop.

3 7

Fwd: [Chimera-users] Working with several proteins
by Elaine Meng 16 Apr '14

16 Apr '14

Begin forwarded message: > From: Elaine Meng <meng(a)cgl.ucsf.edu> > Subject: Re: [Chimera-users] Working with several proteins > Date: April 16, 2014 3:16:07 PM PDT > To: Navya Shilpa Josyula <njosyu2(a)uic.edu> > Cc: chimera-users(a)cgl.ucsf.edu > Reply-To: "chimera-users(a)cgl.ucsf.edu BB" <chimera-users(a)cgl.ucsf.edu>, "chimera-dev(a)cgl.ucsf.edu" <chimera-dev(a)cgl.ucsf.edu> > > Dear Navya, > This would require Python programming because not all of these tasks can be done with Chimera commands. See the Chimera programmer's guide: > <http://www.rbvi.ucsf.edu/chimera/current/docs/ProgrammersGuide/index.html> > > You did not say if your structures are from the PDB database or whether you generated them somehow (for example, from a simulation). If they are in the PDB database, it is possible they are also in the CASTp database, in which case you could open each with a Chimera command something like: > > open castp:2gbp > > CASTp finds a lot of pockets for one structure, and each pocket would have a separate volume value and list of residues. > <http://www.rbvi.ucsf.edu/chimera/current/docs/UsersGuide/castp.html#pocketl…> > > If the structures are not in the CASTp database, you would have to upload them individually for a calculation at the CASTp web server, and this cannot be done from inside Chimera. After you got the CASTp results by email, you could open them in Chimera. Even if the structure is already in CASTp, it might just be better to get the CASTp results files directly from their website and not use Chimera. If showing CASTp results in Chimera, you would then have to use python to write out the desired information to a file anyway. > > CASTp search at their website: > <http://sts-fw.bioengr.uic.edu/castp/index.php> > CASTp upload for new structure calculation: > <http://sts-fw.bioengr.uic.edu/castp/calculation.php> > > For bfactor, again you can just get the values directly from the text of the PDB files, no need to go through Chimera. Just like for CASTp, it may be simpler to write your own scripts to get the values from these files. > > Back to Chimera: To calculate areaSAS you have to show the surface (for example, command: surface). Attribute values can be written out to a file using the File menu of the Render by Attribute tool (in menu under Tools… Depiction), > <http://www.rbvi.ucsf.edu/chimera/current/docs/ContributedSoftware/render/re…> > ...but again to process many structures instead of using the GUI, you would have to use python scripting because there isn't a command. There is a similar script attached to this previous post (get the writeAttr.py attachment using the URL near the bottom, unfortunately it will be named attachment.bin but it is really a text file containing the script): > <http://plato.cgl.ucsf.edu/pipermail/chimera-users/2009-February/003531.html> > > Best, > Elaine > ---------- > Elaine C. Meng, Ph.D. > UCSF Computer Graphics Lab (Chimera team) and Babbitt Lab > Department of Pharmaceutical Chemistry > University of California, San Francisco > > On Apr 15, 2014, at 7:29 PM, Navya Shilpa Josyula <njosyu2(a)uic.edu> wrote: > >> Hi, >> >> I am working on a set of 400 proteins and for all these proteins I have specific list of amino acid residues. I wanted to know if there is any available script or a command to get the following >> • atomic areaSAS >> • atomic B-factor values >> • CASTp identified pocket residues and >> • CASTp identified pocket volumes >> for all the residues of these 400 proteins to be written in a single file. Kindly help me at your earliest. >> >> Thank you in advance for your help. >> Regards, >> Navya > > > _______________________________________________ > Chimera-users mailing list > Chimera-users(a)cgl.ucsf.edu > http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users >

1 0

Working with several proteins
by Navya Shilpa Josyula 16 Apr '14

16 Apr '14

Hi, I am working on a set of 400 proteins and for all these proteins I have specific list of amino acid residues. I wanted to know if there is any available script or a command to get the following 1. atomic areaSAS 2. atomic B-factor values 3. CASTp identified pocket residues and 4. CASTp identified pocket volumes for all the residues of these 400 proteins to be written in a single file. Kindly help me at your earliest. Thank you in advance for your help. Regards, Navya

1 0

Re: [chimera-dev] Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 10 Apr '14

10 Apr '14

Hi Matt, The sensible approach is to make a small example of the per-vertex collada coloring not working in Blender and submit it as a bug to the Blender developers and see if anything happens. If they just ignore it then it isn’t worth trying to find all the other bugs in their collada importer. If they do fix it, and you have another bug, then it will be worth sending a simple case of the next bug. By simple example, for example use a huge step size for a volume map, so all you see is one tetrahedron. A small example will allow the developer to easily open the text file and see how it is encoding the colors without having to deal with 500 pages of mesh coordinates. Also provide an image of the correct appearance as shown by Mac Preview. It is best to use Preview rather than Chimera since that shows that other software can read the colors. You can say the file comes from UCSF Chimera but just give them the file since they aren’t likely to get Chimera — that would be too much work for them. A good bug report might take an hour to create and submit. If you want test cases of all the Chimera export features, then you should make them. It sounds like a lot of work. Import bugs sometimes involve combinations of features so you will not be able to catch all the problems this way. I think instead the approach of submitting bugs as you find them to the responsible developers is the way to go. Tom On Apr 9, 2014, at 4:38 PM, Dougherty, Matthew T wrote: > It would be good to develop some test cases using the collada & X3D formats; something that generates all graphical methods used by chimera. Clearly CGL can't become bogged down chasing down and correcting other software packages. > > Sticking with my workflow strategy (using chimera as a modeller and using a pro-animation package to do more sophisticated production), it looks like I have two options: > > 1) fix the blender collada/x3d problem, the onus on me. Having some small test cases I can take to the blender community might bring resolution. If someone at CGL can generate them I will make the effort to track down the blender developers and resolve the problem. > > 2) switch to another animation package that could process the chimera test cases. Downside is learning new complex software. > Having a CGL webpage listing animation software that can read these test cases would be helpful in making purchases. > > This is not say I am giving up on chimera animation. For most of conference and supplemental animations I plan to stick with chimera because I plan through my sw extensions, to get the lab researchers to vet out coloring and camera positions; then there are the animations involving volume rendering, which I would expect cannot be moved to another package. > > But for the complex animations that involve raytracing, tricky camera trajectories, compositing models, lighting variance, stereo3D, etc.; that chimera can't perform and is uneconomical to duplicate those features within chimera. > > > > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Wednesday, April 09, 2014 4:24 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: Export Chimera models to Blender, Maya, Cinema4d > > Hi Matt, > > Yes Chimera exports RGBA vertex colors of surfaces in X3D. Chimera does not use polygon colors, only vertex colors. I don’t know if Chimera exports vertex colors for Collada. Conrad Huang wrote that code and he would know the answer. > > “Passing the OpenGL scenegraph” is not a feasible solution. All of the graphics programs represent the data differently. If you just gave the OpenGL calls to render the scene — none of the programs could do anything with that low level information. The common ground between programs is through standard scene description file formats like Collada, X3D, FBX, …. > > Tom > > > On Apr 9, 2014, at 2:14 PM, Dougherty, Matthew T wrote: > >> Hi Tom, >> >> I agree with your assessment. I have looked at the blender import code, basically a bunch of if statements chopping text; that is, it does not use std conversion libraries, so they inherently pick favorites of the format, and other things are broken. >> >> Regarding collada, this seems to have best importation into blender. The normals are preserved. The problem I am running into using it are the colors. >> When I do a volume surface color and export collada, Importing into polytrans & blender the polygon colors are missing. Does chimera output colors at the polygons and vertex level? RGB, RGBA? >> >> I spoke with the president of x3d, he runs the viz at Virginia tech. He said partnering with X3d might be an option. Doing a grant together and they code is a possibility. >> >> FBX would be another route using their format library. That would provide reasonable compatibility to autodesk sw, and possibly blender et al. I have researched it. Blender does the same thing for fbx and x3d, chop text no std libraries. Fbx offers a lot, but you get a lot of boiler plate bloat. >> >> What I am digging into is the best animation strategy. Chimera is the best for getting into the data and visualizing it. But as you noted in prior emails it will never be a pro animation package with ray tracing and animation UI tools to manage timelines. Generic animation packages are generic with a few targeted plugins. Passing the OpenGL scenegraph in a socket would be nice. >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Wednesday, April 09, 2014 3:37 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Export Chimera models to Blender, Maya, Cinema4d >> >> Hi Matt, >> >> It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. >> >> Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. >> >> I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. >> >> Tom >> >> >> On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: >> >>> UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. >>> >>> Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. >>> >>> Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. >>> >>> The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. >>> >>> Any ideas how to export natively or pipeline the packages? >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> ________________________________________ >>> From: Tom Goddard [goddard(a)sonic.net] >>> Sent: Tuesday, April 08, 2014 4:03 PM >>> To: Dougherty, Matthew T >>> Cc: chimera-dev(a)cgl.ucsf.edu >>> Subject: Re: [chimera-dev] dome camera/S3D >>> >>> Hi Matt, >>> >>> That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! >>> >>> http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html >>> >>> Tom >>> >>> >>> On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: >>> >>>> Hi Tom, >>>> >>>> came across this >>>> >>>> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >>>> >>>> Matthew Dougherty >>>> National Center for Macromolecular Imaging >>>> Baylor College of Medicine >>>> ________________________________________ >>>> From: Tom Goddard [goddard(a)sonic.net] >>>> Sent: Monday, April 07, 2014 8:18 PM >>>> To: Dougherty, Matthew T >>>> Cc: chimera-dev(a)cgl.ucsf.edu >>>> Subject: Re: [chimera-dev] dome camera/S3D >>>> >>>> Hi Matt, >>>> >>>> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >>>> >>>> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >>>> >>>> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >>>> >>>> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >>>> >>>> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >>>> >>>> Tom >>>> >>>> >>>> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >>>> >>>>> Hi Greg, >>>>> >>>>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>>>> >>>>> Reading the documentation: >>>>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>>>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>>>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>>>> >>>>> >>>>> >>>>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>>>> >>>>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>>>> >>>>> +5° would be the left eye, and -5° the right? >>>>> Proper usage would be +n and -n; that is symmetrical around 0? >>>>> as opposed to +5° and 0°, or +4 and -2? >>>>> >>>>> Is the focal plane actually the dome screen? >>>>> Setting the focal plane in the side view, does it actually do anything? >>>>> >>>>> >>>>> >>>>> Matthew Dougherty >>>>> National Center for Macromolecular Imaging >>>>> Baylor College of Medicine >>>>> >>>>> _______________________________________________ >>>>> Chimera-dev mailing list >>>>> Chimera-dev(a)cgl.ucsf.edu >>>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>>>> >>>> >>>> >>> >>> >> >> > >

2 1

Re: [chimera-dev] Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 09 Apr '14

09 Apr '14

Hi Matt, Yes Chimera exports RGBA vertex colors of surfaces in X3D. Chimera does not use polygon colors, only vertex colors. I don’t know if Chimera exports vertex colors for Collada. Conrad Huang wrote that code and he would know the answer. “Passing the OpenGL scenegraph” is not a feasible solution. All of the graphics programs represent the data differently. If you just gave the OpenGL calls to render the scene — none of the programs could do anything with that low level information. The common ground between programs is through standard scene description file formats like Collada, X3D, FBX, …. Tom On Apr 9, 2014, at 2:14 PM, Dougherty, Matthew T wrote: > Hi Tom, > > I agree with your assessment. I have looked at the blender import code, basically a bunch of if statements chopping text; that is, it does not use std conversion libraries, so they inherently pick favorites of the format, and other things are broken. > > Regarding collada, this seems to have best importation into blender. The normals are preserved. The problem I am running into using it are the colors. > When I do a volume surface color and export collada, Importing into polytrans & blender the polygon colors are missing. Does chimera output colors at the polygons and vertex level? RGB, RGBA? > > I spoke with the president of x3d, he runs the viz at Virginia tech. He said partnering with X3d might be an option. Doing a grant together and they code is a possibility. > > FBX would be another route using their format library. That would provide reasonable compatibility to autodesk sw, and possibly blender et al. I have researched it. Blender does the same thing for fbx and x3d, chop text no std libraries. Fbx offers a lot, but you get a lot of boiler plate bloat. > > What I am digging into is the best animation strategy. Chimera is the best for getting into the data and visualizing it. But as you noted in prior emails it will never be a pro animation package with ray tracing and animation UI tools to manage timelines. Generic animation packages are generic with a few targeted plugins. Passing the OpenGL scenegraph in a socket would be nice. > > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Wednesday, April 09, 2014 3:37 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Export Chimera models to Blender, Maya, Cinema4d > > Hi Matt, > > It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. > > Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. > > I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. > > Tom > > > On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: > >> UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. >> >> Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. >> >> Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. >> >> The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. >> >> Any ideas how to export natively or pipeline the packages? >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Tuesday, April 08, 2014 4:03 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Re: [chimera-dev] dome camera/S3D >> >> Hi Matt, >> >> That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! >> >> http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html >> >> Tom >> >> >> On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: >> >>> Hi Tom, >>> >>> came across this >>> >>> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> ________________________________________ >>> From: Tom Goddard [goddard(a)sonic.net] >>> Sent: Monday, April 07, 2014 8:18 PM >>> To: Dougherty, Matthew T >>> Cc: chimera-dev(a)cgl.ucsf.edu >>> Subject: Re: [chimera-dev] dome camera/S3D >>> >>> Hi Matt, >>> >>> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >>> >>> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >>> >>> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >>> >>> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >>> >>> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >>> >>> Tom >>> >>> >>> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >>> >>>> Hi Greg, >>>> >>>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>>> >>>> Reading the documentation: >>>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>>> >>>> >>>> >>>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>>> >>>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>>> >>>> +5° would be the left eye, and -5° the right? >>>> Proper usage would be +n and -n; that is symmetrical around 0? >>>> as opposed to +5° and 0°, or +4 and -2? >>>> >>>> Is the focal plane actually the dome screen? >>>> Setting the focal plane in the side view, does it actually do anything? >>>> >>>> >>>> >>>> Matthew Dougherty >>>> National Center for Macromolecular Imaging >>>> Baylor College of Medicine >>>> >>>> _______________________________________________ >>>> Chimera-dev mailing list >>>> Chimera-dev(a)cgl.ucsf.edu >>>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>>> >>> >>> >> >> > >

2 1

Export Chimera models to Blender, Maya, Cinema4d
by Tom Goddard 09 Apr '14

09 Apr '14

Hi Matt, It has been a problem getting molecular models exported from Chimera to be read in by Blender and Maya. For example Greg in our lab recently looked at why Blender does not correctly show the end-caps on ribbons exported from Chimera as X3D. This is a bug in the Blender X3D importer. We’ve worked to make sure Chimera exports valid 3d scene files. But we don’t fix bugs in Blender or Maya. As you know, there seems to be know consensus in the 3d model field about what file format to use to exchange data. Conrad in our lab added Collada format export (in daily builds) but his experience was that only some software would properly render it. I also have been reading Collada format in our next generation Chimera work which has not been released. Graham Johnson who made ePMV is here at UCSF. I’d have to ask how he handles data exchange between the PMV molecular viewer and the animation packages (Cinema4d, Blender, Maya). My impression was that it used plugins written for each animation package which presents a user interface and can call PMV to compute molecular surfaces and do other molecular analysis. The plugin could just transfer the data in some internal format rather than using some standard file format. That solution can work if you have enough money to implement it. I think it will take interest from Blender, Maya, Cinema4d, … developers to make progress, and money to pay them to work on more reliable file exchange to allow molecular vis programs like Chimera to operate with professional animation programs. Tom On Apr 8, 2014, at 2:54 PM, Dougherty, Matthew T wrote: > UNM had a NSF grant to extend OpenGL to do rendering to a sphere, simplifying s3d. > > Blender now has a full dome camera as part of the cycles camera rig. So this 3 fisheye approach should apply in terms of workflow. > > Getting back to your comment regarding the inherent animation limitations of chimera, and the various scene graph export file glitches; more thought might be given yo bridge that gap. Both packages use python and OpenGL. > > The ePMV approach of extending maya, blender, etc seems like a strategy of avoiding a lot of graphic file problems. > > Any ideas how to export natively or pipeline the packages? > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Tuesday, April 08, 2014 4:03 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] dome camera/S3D > > Hi Matt, > > That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! > > http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html > > Tom > > > On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: > >> Hi Tom, >> >> came across this >> >> http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> ________________________________________ >> From: Tom Goddard [goddard(a)sonic.net] >> Sent: Monday, April 07, 2014 8:18 PM >> To: Dougherty, Matthew T >> Cc: chimera-dev(a)cgl.ucsf.edu >> Subject: Re: [chimera-dev] dome camera/S3D >> >> Hi Matt, >> >> Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. >> >> The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. >> >> It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. >> >> The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. >> >> I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. >> >> Tom >> >> >> On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: >> >>> Hi Greg, >>> >>> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >>> >>> Reading the documentation: >>> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >>> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >>> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >>> >>> >>> >>> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >>> >>> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >>> >>> +5° would be the left eye, and -5° the right? >>> Proper usage would be +n and -n; that is symmetrical around 0? >>> as opposed to +5° and 0°, or +4 and -2? >>> >>> Is the focal plane actually the dome screen? >>> Setting the focal plane in the side view, does it actually do anything? >>> >>> >>> >>> Matthew Dougherty >>> National Center for Macromolecular Imaging >>> Baylor College of Medicine >>> >>> _______________________________________________ >>> Chimera-dev mailing list >>> Chimera-dev(a)cgl.ucsf.edu >>> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >>> >> >> > >

1 0

Re: [chimera-dev] [Chimera-users] mutating residues
by Elaine Meng 08 Apr '14

08 Apr '14

Dear Hussain MR, The chimera-users(a)cgl.ucsf.edu address (not the others) is recommended for asking questions about using Chimera. To change an amino acid in a protein structure, you can use the Rotamers tool (in menu under Tools… Structure Editing) or the "swapaa" command. Please see the manual: <http://www.rbvi.ucsf.edu/chimera/docs/ContributedSoftware/rotamers/framerot…> <http://www.rbvi.ucsf.edu/chimera/docs/UsersGuide/midas/swapaa.html> There are "swapaa" examples in the link above, and examples of using Rotamers in the "Structure Analysis and Comparison Tutorial": <http://www.rbvi.ucsf.edu/chimera/docs/UsersGuide/tutorials/squalene.html> You can find tutorials and search the documentation using the Help menu in Chimera. I hope this helps, Elaine ---------- Elaine C. Meng, Ph.D. UCSF Computer Graphics Lab (Chimera team) and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco On Apr 8, 2014, at 5:07 AM, MUHAMMAD RAMZAN MANWAR <geniouschemist26(a)gmail.com> wrote: > Dear Dr. Ferrin, > Hope this email finds you the best of your health. First of all, I did appreciate the effort that You and Your team did in the form of UCSF Chimera. Being the part of academic/government university, I have used Chimera tool for protein modeling and cited in my two articles: one published in JCB-Wiley and other in Hundawi in 2014. Current email I am sending to request for guidance about how can I substitute an amino acid (wild type to mutant residue) within protein 3D model by using Chimera. I will be thankful for your guidance, if possible. > With regards > Hussain MR > PACER-HD, KAU, KSA

1 0

Re: [chimera-dev] dome camera/S3D
by Tom Goddard 08 Apr '14

08 Apr '14

Hi Matt, That looks interesting. Looks like the same technique I tried a few years ago at the Imiloa stereo dome in Hawaii where I used 24000 virtual cameras so that each vertical strip had the stereo cameras facing that strip. This paper describes camera hardware for videoing the real world so it uses just 3 fish-eye cameras and there are artifacts because of that. The author says the artifacts are much reduced with 5 cameras. It would be a good technique to try even for virtual rendering where you can get away with thousands of cameras, because it would be a lot faster to render. You’d especially want that for interactive rendering in stereo dome. My stereo dome rendering took 15 minutes per frame with the 24000 camera approach! http://www.cgl.ucsf.edu/Outreach/technotes/dome3d/dome3d.html Tom On Apr 8, 2014, at 12:53 PM, Dougherty, Matthew T <matthewd(a)bcm.edu> wrote: > Hi Tom, > > came across this > > http://vision3d.iro.umontreal.ca/en/blog/2013/07/29/the-omnipolar-camera-a-… > > Matthew Dougherty > National Center for Macromolecular Imaging > Baylor College of Medicine > ________________________________________ > From: Tom Goddard [goddard(a)sonic.net] > Sent: Monday, April 07, 2014 8:18 PM > To: Dougherty, Matthew T > Cc: chimera-dev(a)cgl.ucsf.edu > Subject: Re: [chimera-dev] dome camera/S3D > > Hi Matt, > > Yes the parallax angle used for Chimera dome stereo with the stereo command is half the “convergence angle” if by convergence angle you mean the angle between the lines of sight from your two eyes to an object on the dome surface level with your eyes and midway between them. So if I was setting it for a viewer in the center of a 4 meter radius dome, with eye separation of 0.06 meters I would use an angle atan(0.03 / 4) = 0.43 degrees. > > The positive angle is for the right eye negative for the left eye, because the y-axis points up and a positive rotation in the standard mathematical conventions (right-hand rule) would rotate your straight ahead view line to instead point slightly leftward. The view line is supposed to intercept an object at dome distance midway between eyes. A simple test in Chimera dome mode using “stereo dome parallax 10” verifies that this gives a view from the right as should be seen by the right eye. > > It makes sense to use symmetrical values +d degrees for the right eye and -d degrees for the left eye. If instead you shifted the two parallax values so their sum is not zero, that would give an effect as if your head was facing a different direction in the dome other than straight ahead. > > The Chimera focal plane setting seen in the Top View mode of the Side View dialog (menu Tools / Viewing Controls / Side View) does correspond to the dome screen position in the straight ahead position. I say in the “straight ahead position” because the focal plane is a flat plane, and of course the dome is a spherical surface. The focal plane position is important. Setting the parallax value does two things. It moves the camera right or left along the x-axis, and it rotates the camera view direction. The shift along the x-axis is by an amount so that the view line will hit the mid-point on the dome screen, ie (x camera shift) = (focal distance) * tan(parallax). The Chimera “eye separation” parameter is not used for dome parallax mode. The reason for that is because the dome parallax mode isn’t a stereo mode — it renders only one image using one camera. You have to record your whole movie with a right eye setting, and then re-record it with a left eye setting, then combine the two movies with some external software. Since it is a mono mode being used twice, it doesn’t use the “eye separation” parameter in the Camera panel (menu Tools / Viewing Controls / Camera). Instead the eye separation is implied by the parallax value and focal plane distance. > > I realize this is all somewhat quirky. If we provided a real interactive dome stereo mode that for instance produced side-by-side left and right eye dome images, then we could do away with parallax and use the eye separation and focal distance parameters that are used for other Chimera stereo modes. Since the fish-eye projection generally needs to be warped before display on the dome, this interactive stereo mode would probably also need to accept a warping texture described in a file in order to be useful. > > Tom > > > On Apr 7, 2014, at 2:10 PM, Dougherty, Matthew T wrote: > >> Hi Greg, >> >> I was experimenting with the dome parallax and needed some help understanding your sw and terminology. >> >> Reading the documentation: >> Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. >> The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. >> For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. >> >> >> >> When you talk about p-angle it reminds me of the angle of convergence. Is that correct? >> >> In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. >> >> +5° would be the left eye, and -5° the right? >> Proper usage would be +n and -n; that is symmetrical around 0? >> as opposed to +5° and 0°, or +4 and -2? >> >> Is the focal plane actually the dome screen? >> Setting the focal plane in the side view, does it actually do anything? >> >> >> >> Matthew Dougherty >> National Center for Macromolecular Imaging >> Baylor College of Medicine >> >> _______________________________________________ >> Chimera-dev mailing list >> Chimera-dev(a)cgl.ucsf.edu >> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev >> > >

1 0

dome camera/S3D
by Dougherty, Matthew T 08 Apr '14

08 Apr '14

Hi Greg, I was experimenting with the dome parallax and needed some help understanding your sw and terminology. Reading the documentation: Left- and right-eye stereo views for dome display can be generated by specifying parallax angles of opposite signs. The views are rotated by p-angle degrees about the Y (vertical) axis through the center of the focal plane. For example, views recorded with dome parallax ±5° can be combined to give a stereo effect when viewed in the forward (−Z) direction. When you talk about p-angle it reminds me of the angle of convergence. Is that correct? In hollywood terminology they calibrate the word "parallax" to percentages. Zero parallax is on the screen, positive is behind the screen, and negative in front of the screen. +5° would be the left eye, and -5° the right? Proper usage would be +n and -n; that is symmetrical around 0? as opposed to +5° and 0°, or +4 and -2? Is the focal plane actually the dome screen? Setting the focal plane in the side view, does it actually do anything? Matthew Dougherty National Center for Macromolecular Imaging Baylor College of Medicine

2 1