[chimera-dev] pointers

[Dougherty, Matthew T]

2) The Tk window toolkit sets the Mac top-of-screen menu to the menus on whichever Chimera dialog that has the focus.  Chimera does not do this and I doubt you can change the Tk behavior.  It is something of an atrocity to have different sets of menus for different Chimera dialogs.  But it is hard to organize all Chimera functionality under one set of menus.

>is there a way I can put the focus on a particular menu?
eg, setting the windowsize.




3) Including density map files with sessions is a feature several people have requested and I too think it would be useful.  The question is how to implement it.  One approach is that you choose a new directory name and Chimera creates it, puts the session file (*.py) and copies of all map files in that directory.  But what if I need to give you 5 different sessions that use the same set of 10 maps.  Should I copy all the maps 5 separate times?  Maybe I'd want to put the extra session files in the same directory that already has the copied maps.  Then I wouldn't need to make more copies.  But how do I know those copied maps are the right maps?  Just because they have the same file name doesn't mean they are the same maps.  It's a can of worms.  Not sure what to do and that's why it hasn't been done.

>how do I get a list of the mrc files that a session uses?  As a first step I need to create a manifest of all the models' sources relating to a session.  I agree it is a can of worms, something the users are going to have to deal with rather than the developers.  As a developer it is hard to guess operational workflows, when the users are not that organized. 




4) The Chimera focal plane position is a distance in front of the camera in the scene where the left and right eye image of a point at that distance will appear at the same position on the display.  So an object at that distance in front of the camera appears in stereo viewing to be exactly at the same depth as the physical display.  I don't know what your terms "convergence plane", "screen plane", "zero parallax" (parallax is an angle).

> This means the focal plane is the same as convergence plane, the convergence plane is the same as the screen plane for S3D, for holography that could change.  Zero parallax is the parallax value of the screen plane.  Parallax is the difference between two image pairs, angle and interaxial distance are variables to the parallax.  Generally parallax is measured as a function of screen percentage, a second method is in pixels.  I am using terms out of Lipton's books and the recent S3D books that Dreamworks are promoting.  I would recommend changing the label "eye separation" to "inter-axial distance". With the experiments I am doing, not uncommon to have IA of 5mm or 1000mm to make the S3D to pop out.  Kind of like defining values that are suitable when looking at a building; flying over I might want 30 ft, or following a dust particle coming into the ventilation staff might be 0.1mm.  Part of the mind block for years has been locking into 63mm and think maybe change it +/- 2mm.  I am doing crazy stuff like 150mm IA and screen distance is 300mm for a 2000m screen size; but it looks good and the researchers are really getting into their data; part of it relates to the size of the object I am looking at and what I am trying to highlight.  volume rendering and S3D have a lot of potential, it helps increase the s/n perception.  As for the S3D, we should organize a meeting of the minds, the industry is starting to form definite approaches, being in alignment with their evolving terms and practices should help us take advantage of their heavy lifting. 





5) Transfering model positions and camera views between sessions is a nightmare.  I have this problem to.  I guess you mean you want the named positions saved with savepos in session1 to be carried over to session2.  In my use I usually make session1, save some positions, then delete some models, add others, and save as session2.  In that case the positions from session1 also got copied to session2.  That takes care of most situations.  But now I might create a new position in session1 and want to copy it to session2.  There's no easy way to do it.  The "matrixget" and "matrixset" will write all the model positions of session1 and read them into session2 but you have new models in session2 and they won't get the right positions, and the camera parameters are not copied with those commands.  Here's an idea for some new command that might help.  Have a command that reports the camera position and view direction, and up direction relative to the coordinates of a specified model, and the same command would also be able to set the camera position using those 3 vectors.  This would allow copying camera view points between scenes.  Another case is a move model 1 relative to model 2 in session1 and want to do the same relative motion in session2.  A new command could report the position of model 2 relative to model 1 as say a translation and rotation axis and rotation angle, and the command could allow setting the relative position using those parameters.

>will get back to you on this. 

6) There is no facility to animate light positions.  They are not saved by savepos, although they could be added to savepos/reset.  The light positions are relative to the camera, and the Chimera camera always points along the -z axis in the Chimera scene coordinate system (rotations always work by rotating the models, not moving the camera).

> I plan to write the code, I just need to understand the limitations.  Can I add another light?  I see how they are done.  If I add my own, will it break anything?  I do not need them to show up on the lighting dialog.  I would think it would be similar to adding shapes and vertexes. 

>could be added to savepos/reset.    How difficult to code, say in hours? How difficult for me to code?  May want to try something independent and not deal with distribution/future code breakage issues.