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

[Stephen Norris]

Hello Tom,
The point about ribbon meshes definitely is good, and means that the
approach I was thinking is definitely the correct one to pursue. I guess we
may have a different approach on this, but typically we start developing
our models with a general sense of what the final scale will be. After
we've determined coloring, styles, etc we then adjust component scales to
prepare for printing. For models with a ribbon or ball and stick kind of
structure, as opposed to surface models, we usually end up looking for a
tradeoff between having a crowded model, components too thin, or having a
model that's too big. Typically we end up wanting to print as small as
possible but also having a model that is not too crowded so we can see the
internal features more easily. The idea is that since we know components
should be a set thickness, usually around 3-4mm, we can enable this feature
to allow us to compare different scales by simply zooming the model. I
would likely set it up so that you can then save the scale and disable the
feature temporarily so that you can zoom in and work with the model as
needed. This feature could also be useful for new students as we can tell
them to aim for a specific physical thickness in order for their models to
be strong enough for printing. In addition it can be useful to determine if
a large protein will be feasible as a ribbon model. For example the Zika
virus cryo-em structure that was recently published (pdb id 5ire) is
absolutely too big to print the entire shell as ribbon, so we used the
Multiscale surfaces. If we can set a minimum thickness we can quickly get a
good determination if a ribbon model is feasible or we should do a surface
model.
Stephen

On Wed, Jul 20, 2016 at 2:15 PM, Tom Goddard <goddard at sonic.net> wrote:

> Hi Stephen,
>
>   I think the automatic scaling of strut and ribbon thickness is not a
> good feature, independent of speed or implementation difficulty.  Here’s
> why.  When I make a model to print I do use the physical size on the screen
> as a guide — I zoom the model so it appears on screen the size I want to
> print.  That let’s me judge whether my model has too much detail or whether
> some parts are too thin to print.  But since I print small sizes (e.g. 10
> cm) I don’t keep working in Chimera at that zoomed down size, I zoom so
> that the model is big on my screen (30 cm), make some changes, then maybe
> zoom back to physical size to see if I like the result.  Making it big
> helps select atoms, bonds, residues with the mouse, and is just easier on
> my eyes.  So I really don’t want the ribbons and struts rescaled to
> maintain a fixed physical size.  I don’t see a case where I would want them
> automatically resized.  If I decide I want to print my model a little
> bigger, I probably want scale the struts and ribbons by the same scale for
> best appearance, in other words, I would not want to adjust ribbons/struts
> to keep the same physical sizes as the smaller model.
>
>   If you think there are good reasons to pursue automatic scaling here are
> Chimera rendering details for guessing performance.  Bonds are displayed by
> scaling a single cylinder instance to render different sizes so that should
> be fast.  Ribbons are a mesh of triangles and will have to compute a new
> mesh if the thickness is changed — this probably won’t happen at 60 frames
> per second and will of course depend on how many ribbon residues you are
> showing.  Only testing will make clear the speed.
>
> Tom
>
>
> On Jul 20, 2016, at 10:37 AM, Stephen Norris wrote:
>
> 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 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 at 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 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/20160720/e3368fe7/attachment.html>