Hello Tom, Yes, for 1) and 2) the idea is that the user would just select the units that they would like the exported file to be in. The extension can then determine the correct scale factor for the output based on the current viewer scale factor. For 3) the 'elegant' solution that I would dream of would be to have something like how stick scale in the Molecule Model settings and radius in the Bond settings both affect the scale of bonds in ball and stick mode. One scaling factor would be set by the user to the desired mm/cm/inches, and the second factor would be controlled by the extension and apply globally to the entire model. However it completely depends on how chimera actually handles the models as to whether this would actually be efficient. For example if each bond has it's own mesh that needs to be updated that would still be expensive. I just don't know how this works so I can't completely judge what kind of approach is best. I just got Eric's email as I'm typing this. The alternative approach I was thinking of in case doing the brute-force method is slow was something where I wait a moment for the zoom to stop changing but I guess there's already a trigger for this! Thanks! Stephen On Wed, Jul 20, 2016 at 1:03 PM, Tom Goddard <goddard@sonic.net> wrote:
Hi Stephen,
It sounds like you have 3 problems.
1) How does the user figure out a scale factor for printing. 2) How to make a vrml file that includes the right scale factor, so the file is all you need to print. 3) How to make thicknesses of struts and ribbons automatically adjust as you zoom the Chimera view.
For 1 and 2 you can just have the user zoom the model so its size on the screen is the desired size, then they press the export button on your extension, it writes the x3d, then your code modifies the resulting file by putting in the needed top level scaling transform, then runs the x3d2vrml conversion. I guess the user will still need to know what the units are for that VRML file, centimeters or millimeters or inches…. Unless the printer software can recognize a units field in the vrml file I don’t see anything you can do about that.
For 3, your extension could be notified on every zoom and adjust the strut and ribbon sizes. You are right this will probably be to slow to be usable for a modest size protein because I believe it will recompute the ribbon at each zoom step. The strut size changes would probably be fast enough. Maybe the ribbon resize would be for a small protein. You’d have to try it to know.
All our development effort has been on our next generation ChimeraX software the past year, we just do maintenance on Chimera. So adding the scale factor support for x3d output isn’t likely to happen, although we will do it for ChimeraX. Putting in support to automatically scale strut and ribbon thicknesses so they remain fixed in screen pixel size during zooming is not likely to happen — it is too much complexity added to the code benefitting too few users. We have few programmers maintaining an large range of Chimera functionality and can't take that on.
Tom
On Jul 20, 2016, at 9:37 AM, Stephen Norris wrote:
Hello Tom,
First of all, my comment about the units in chimera being arbitrary was in respect to how they are useless without knowing the corresponding scale that the model will be printed at. This is a problem for us because as I mentioned we don't really have a good method currently of determining the scale we want to print at in chimera and then transferring that scale to the printer software. Additionally it is difficult to compare sizes for printing as we need to have both a saved build file from the printing software and an original chimera session. This is because both the scale of printing and original settings used in chimera affect the actual size when printed. What we can do however is pick up a pair of calipers and actually measure the width of segments of models we've printed.
Also, I should be clear and try to explain what the extension currently does as it may clear things up. The extension uses the monitor's physical dimensions/DPI, which it tries to automatically get using the Tk winfo commands as you mentioned. I've found that the DPI isn't actually reported on some systems such as ubuntu (The X11 developers are at fault for that but don't get me started) so there is an option to manually determine these parameters. The extension can then use the horizontal dpi to determine the physical width of the viewer window and use set the view size to be the actual physical size (in inches). This then means the viewer's scalefactor is then the printing scale factor to get a model the same size as what is displayed on the screen (in inches, but can be converted easily). In addition there is a grid and ruler system so if you wanted a model 10cm across you can turn on the grid and simply zoom the model so that it fits into 10cm.
So, for exporting the model it would be good to have the scaling built into the export. Your point about surfaces is good, for that side point I was only thinking about simple ball and stick kind of stuff but that idea doesn't really pan out when it comes to making it work for everything else. The main working idea I have though is to modify the x3d export so that all the models are placed under a single transform node that holds the printing scaling. This can be done by simply nesting it just inside the group tag. From what I can tell this works fine even with the x3d2vrml conversion program with a test x3d file I modified by hand.
For setting style parameters the idea is that the extension can use the current scalefactor to determine the size in angstroms to set each parameter. So if we wanted struts of diameter 3mm and the model was currently at 50% scale, the extension can convert 3mm to inches and then divide by the scale to get struts of 3mm. What would be great would be to be able to set them to be 3mm but have them update to stay 3mm when the scale factor changes. This could be done by setting every parameter every time the scale factor changes but I'm guessing this would be too expensive to work in real time smoothly.
Stephen
On Tue, Jul 19, 2016 at 7:34 PM, Tom Goddard <goddard@sonic.net> wrote:
Hi Stephen,
Your printed molecular models are neat and your Chimera extensions is interesting too. Here are some ideas on what is possible in Chimera regarding size scale.
First the Chimera units are not arbitrary, they are Angstroms because all molecular structures are in Angstroms. Chimera uses certain atom sphere sizes and ribbon thicknesses, and those are all assuming the units are Angstroms. If you have a protein that is say 50 Angstroms across and you want to print it as a plastic model 10 cm across you would end up using a scale factor of 0.2 in the printer software to convert from the Angstroms in the Chimera exported STL or X3D or VRML or OBJ file to centimeters, and you would tell your printer software to use centimeters. When I am designing a molecule model to print I first decide how big I am going to print it, e.g. 10 centimeters. I know the smallest feature my printer can make that won’t break to easily is say 0.2 centimeters which is 50x smaller than my model size. So I need to make all features at least 1/50 of the full size, or 1 Angstrom for a 50 Angstrom model. When making models to print I usually decide the smallest features can only be 1/50 the full size, then I choose strut radius and ribbon thickness by eye so they appear at least 1/50 the full molecule size.
This could all be simpler if all the sizes in Chimera like strut radius or ribbon size was in centimeters and you already scaled your molecule up to be 10 centimeters across. I don’t advise trying to do that. You could after you open a PDB molecule file use some Python code to scale all the coordinates, atom radii, bond radii, ribbon thicknesses. But you will create problems because many Chimera tools assume Angstroms. For instance if you make a molecular surface it is going to use a probe radius of 1.4 Angstroms for computing the surface and this may be very bad for the scaled model. If you ask for hydrogen bonds it will use expected hydrogen bond lengths in Angstroms, and simply won’t work.
So instead I think you should live with the fact that Chimera units are Angstroms, and the exported X3D, STL, … is in units of Angstroms, and instead try to help provide scale factors and suggested minimal feature sizes. I don’t know of any way to scale the coordinates in the X3D or STL produced by Chimera other than changing all the molecule dimensions. So I guess I’d suggest your extension should help them determine the model size to print, maybe by reporting the current size as shown on screen. For that you should really use the actual screen DPI, not 72 — the Tk "winfo pixels” command should give you that. Then you might report a scale factor from Angstroms to the displayed physical size on screen in centimeters (for entering to the printer software). And maybe you could also report the displayed physical ribbon thickness and strut diameter (in centimeters).
Tom
On Jul 19, 2016, at 8:48 AM, Stephen Norris wrote:
Hello Chimera developers! I'm a recent graduate of URI where I worked as part of a 3D printing group working on molecular visualization. You can see some examples of our work at http://web.uri.edu/pharmacy/3d/3d-gallery/ . When we started the program we used both Jmol and Chimera on individual models but ever since Tom added the struts commands we've been 100% using Chimera and loving it! However as I'm ending my personal involvement in projects there, I still want to do one last thing which is to solve a major headache for the 3D printing process. When developing model in Chimera we cannot really determine what scale the model and it's components like strut diameter will be when printing. These scales can only really be determined once we import the model into the 3D printing software and set an overall scaling for the model. This is a problem as we can easily make a model which looks nice but when we determine the overall scale the struts may turn out to be too thin, and then we have to go back and re-export the model until we get them acceptable. In addition is no way to relate the scale of a model shown in the viewing window to an actual scale we could input to the computer software. The solution would be to have functionality in Chimera to work with the model and scale things in terms of real-life units. A program like solidworks would easily let one do this but for Chimera units are somewhat arbitrary. One trick with the 3D printing software is that the print bed is shown with a grid of units so we can expand the ortho view until the screen is showing the objects to be printed at their actual real life sizes. I've already developed an extension to do this in Chimera and a side effect is that the scale to input to the printer to get a model at the scale displayed on the screen is easily obtained. I've made a github repo for the extension at https://github.com/gerbi7/UCSF-Chimera-RealScale-Extension . So now I'm running into two problems which could use some expert advice or ideas: 1. It would be good to be able to export models with the scaling pre-applied so that one just has to select the correct unit when importing to the 3D printing software. As far as I can tell most of the export functionality is in C++ and doesn't include support for applying a global scale to an export. Since it's in C++ I don't know if this would be viable as an extension to modify it. So far my idea would be to modify the outputted file? 2. It would be incredibly useful if one could set style parameters such as ribbon width, strut widths, etc in terms of real-life units, and have them stay constant while the user can modify the overall scale of the model by zooming in and out. It would be good if there was some elegant way of doing this instead of brute-force setting every parameter whenever the zoom changes. As a side note if it was possible to just insert a scaling factor whenever an atom coordinate is needed for graphics purposes that would probably work to solve both problems but I doubt that exists currently. I look forward to hearing back from you. Stephen Norris _______________________________________________ Chimera-dev mailing list Chimera-dev@cgl.ucsf.edu http://plato.cgl.ucsf.edu/mailman/listinfo/chimera-dev