[Chimera-users] features/question: stereo3d and volume rendering

Tom Goddard goddard at sonic.net
Wed Nov 27 13:41:59 PST 2013

Hi Matt,

1)  Chimera saves most of the camera stereo settings in session files: eye separation, angular field of view, and focal plane position.  But it doesn't save screen width, instead when you start Chimera it tries to figure out the width of the actual screen (which depends on what computer you open the session on).  I say it "tries" to figure out the screen width.  On a Mac it appears to correctly get the width of the screen in pixels, but then it converts that to inches assuming 72 pixels per inch instead of using parameters for your actual screen.  So for my screen which is about 24 inches wide, Chimera starts saying it is 35 inches wide.  Distance to screen is related to screen width and field of view angle: tan(a/2) = (w/2)/d.  Another factor is that if you resize the Chimera window the distance to screen changes.  That may seem odd, but we decided it is better to keep the angular field of view fixed during the resize.  So if you resize the window twice as wide, then in also doubles the distance to screen to keep the field of view fixed.  Given this set of quirky behaviors I suggest the way to get reproducible results is don't change the screen width setting in the Camera dialog.  That setting is not saved.  Adjust only the field of view, the eye separation, and the focal plane position.  The trouble comes in when the screen width isn't the size of your actual screen.  The eye separation (expressed in inches or millimeters) is calibrated to the screen width (also expressed in inches or millimeters) in order to find the separation of the left and right eye cameras in molecular scene units (typically Angstroms).  So if your real screen width is 10 times larger than what Chimera says, then you should make the eye separation 0.2 inches instead of 2 inches, so the ratio of eye separation to screen width that Chimera is using matches the physical reality.

  This is pretty screwed up.  I run into this problem too using our stereo projector and saved sessions.  A basic difficulty is that Chimera gets the wrong screen size -- not too surprising since I have both a monitor and a projector hooked up, and it can't possibly know the the projected image size unless I tell it.

  Maybe the solution is to save the screen width in sessions and use that when you load the session ignoring what the computer thinks the actual screen size is.  That isn't good if I save a session and later view it on stereo screens of different sizes, then saving the screen width in the session will give bad results, while the current Chimera behavior of trusting what the operating system says is the screen width would be better (if that value is actually right).  So I guess the current Chimera behavior is actually best if the operating system tells Chimera the actual screen width.  But in practice, especially with a projector, it tells Chimera the wrong screen width.  So maybe the rule should be that if you type in a new screen width in the Camera dialog, overriding what the operating system said the screen width was, then it should be saved in sessions.  And once you override it and it goes into a session, that session will always override the screen width when you load it.  I think that will fix your problem and mine without the above tinkering with the eye-separation value.  So I've changed it -- in tonight's Chimera daily build.

2) When you open the same density map multiple times in Chimera it only caches one copy of the data in memory.  The out-of-memory problem is probably because you are using solid style (volumetric) rendering for all of them, and each copy separately allocates the 3-d color array (OpenGL textures).  Those will consume 4 bytes per displayed grid-point.  Even if you undisplay a map it keeps the 3-d color array for solid style rendering unless you switch the display style to surface or mesh.  I guess you show just one copy at a time since Chimera does not properly display two transparent models.  So one solution is to change the display style to surface for undisplayed models to free up the large 3-d color array used for solid style rendering.  Another solution is use the "minimize texture memory" option in solid rendering options -- that will just use a 2-d color array over and over for every slice of a map and render slowly but use less memory.


On Nov 27, 2013, at 9:54 AM, "Dougherty, Matthew T" wrote:

> 1) I have been doing S3D animations.  One of things I am realizing is that I need to frequently adjust the interaxial and screen distances.  Sometimes my IA might be 1mm or it might be 23 inches depending on the shot.  Currently chimera does not maintain this camera metadata, so every session I need to reset the values which makes my animations slightly different.  Since rendering can take several hours, one typo can trash the effort.  Any suggestions on a workaround?  There is also a linkage between IA, horizontal field of view, and screen distance, sometimes I think I get caught in a hysteresis loop trying to converge to the desired shot.  As a note, I pretty much stopped using the zoom and have gone to dolly, keeping the scale to one.
> 2) when doing volume rendering of electron tomograms I am finding it useful to load the same mrc map file in multiple times, such that each model has a different transfer function relating to different densities or structures.  I can currently load seven, but four must be changed from floating point to byte in order to prevent memory lockout thrashing, error messages, etc. Is there a way to load a single map file in and have multiple models and transfer functions for the solid viewing?
> Matthew Dougherty
> National Center for Macromolecular Imaging
> Baylor College of Medicine
> _______________________________________________
> Chimera-users mailing list
> Chimera-users at cgl.ucsf.edu
> http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-users

More information about the Chimera-users mailing list