Nico wrote: > Concerning the output of secondary structure : the output of the 'Trace' > structure seems to work
Unfortunately, I am unable to get this to work properly. If I change showPolymers to true then I get warnings about the camera and fog. Then the rendering process proceeds very slowly. And the end result is speckled with blue pixels. I observe that your spline is colored blue, so I assume that is where they are coming from. > but there is still work to do on it : > - add method on Viewer to get the radius of the spline Yes. Note that the radius of the spline can vary along the length of the trace. trace structure > - add method on Viewer to get the color of the spline The color can also change along the length of the trace. try the commands: load samples/pdb/1CRN.pdb; trace structure; color trace amino This tells me that the spline should be output in segments, where each segment gets its own color and radius. Segments are associated with alpha carbons. Mid-points are the mid-points between alpha carbons. The segment associated with an alpha carbon runs from the mid-point before to the mid-point after each alpha carbon. This is the way that Jmol handles it internally. > - add method on Viewer to tell if traces (globally) or trace > (individually) should be displayed Within Jmol this is handled by checking the radius of the trace. If the radius is 0 then there is no trace for that segment. > - rethink the way to get the points of the polymer : with the > getPolymerLeadMidPoints() method I added to the Viewer, it currently > returns > the internal array of points without the viewer knowing it. Not good ! Correct. > I think the 'Trace' structure is a good example of what the PovraySaver > needs to output correctly the structure. We should do it clean before > moving to other structures. Yes. The other simple one is 'backbone'. It behaves almost exactly like 'trace', except the representation is cylinders that run directly from one alpha carbon to the next. > IMHO, before going on the povray output, we should really work on what the > viewer should provide access to and how it should be done. > I'm not sure I can help on this part, so I will wait for the moment. OK. I think that we need to try to come up with an API that allows us to pass in a string as a symbolic name for the shape we are interested in. By that mechanism we can avoid creating an entry point for each shape. Miguel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
