[chimera-dev] Help with chimera extension for 3D printing

Tue Jul 19 16:34:02 PDT 2016

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/ <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 <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 at cgl.ucsf.edu
> http://www.rbvi.ucsf.edu/mailman/listinfo/chimera-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://plato.cgl.ucsf.edu/pipermail/chimera-dev/attachments/20160719/365c964a/attachment.html>