Hi,
Am 07.10.2012 um 20:07 schrieb Robert Hanson:
> nice. A few comments:
>
> you can just use
>
> monomers[i].getProteinStructure() == monomers[iNext].getProteinStructure()
>
> instead of all these:
>
> ( (isHelix(i) && isHelix(iNext)) || (isSheet(i) && isSheet(iNext)) ||
> (isTurn(i) && isTurn(iNext)) )
>
> and it's a bit more accurate, since your definition of "isTurn" as (not Helix
> and not Sheet) is not quite correct.
good, that's simpler
> Why the removal of the eccentricity/variable radius business?
Previously the wingHermites were only calculated for "eccentric" elements
(cartoons of helices, sheets) and not for turns or traces. The wingHermite
vectors provide the direction in which the helix or sheets is stretched. This
is not needed for turns or traces but you still need some vector perpendicular
to the controlHermite vector. The "random reference" Z was used to calculate
such a vector but with that the start/end vertices of the trace/turn meshes did
not overlap. So I use the wingHermite vectors also for turns or traces.
Regarding the variable radius; I reordered the code a bit.
Best
Alexander
> Bob
>
> On Sat, Oct 6, 2012 at 4:49 PM, Alexander Rose <alexander.r...@weirdbyte.de>
> wrote:
> Hi,
>
> better images...
>
> https://www.dropbox.com/s/o5vdr88ebwqqf6o/1CRN_seams.jpg
> https://www.dropbox.com/s/vcqxh6w0fh9ik7s/1CRN_noSeams.jpg
>
> Am 06.10.2012 um 23:44 schrieb Alexander Rose:
>
>> Hi,
>>
>> I created an initial patch that aims to fix the seams between cartoon mesh
>> elements of consecutive residues. Attached are two images to illustrate the
>> seams. The seams occur because the (lighting) vertex normals are calculated
>> for each cartoon mesh elements individually without considering the adjacent
>> elements. The patch includes a helper function that smoothes the vertex
>> normals for the overlapping vertices two consecutive cartoon meshes. I also
>> needed to slightly change the way by which the mesh of turn/loop elements is
>> created so that the start/end vertices of two turn/loop elements always
>> overlap.
>>
>> The patch is against revision 17624.
>>
>> There are problems. I adjust the normals between two consecutive elements
>> when constructing the second element's mesh, so the first element's mesh has
>> been already created (needed to adjust the normals) and also once
>> rendered/drawn. Therefor to see the adjusted normals the meshes need to be
>> rendered/drawn again. Just interacting with Jmol, e.g. zooming, naturally
>> triggers a redraw. However its not nice initially. An idea. I could trigger
>> a redraw in Jmol after cartoon mesh constructions. How? Or do you have other
>> suggestions?
>>
>> Also I need to carefully check if the code works also when individual
>> residues are (randomly) displayed/hidden one after the other.
>>
>> Please let me know what you think!
>>
>> Best
>> Alexander
>>
>>
>> <patch_seams_r17624.txt>
>>
>> <1CRN_seams.jpeg><1CRN_noSeams.jpeg>------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
>> Jmol-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Chemistry Department
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
