Re: [COOT] CCP4 7.1 Coot - stereo
Hi Pedro, For me (under Linux) the .coot file (placed the .coot-preferences directory) seems to be ignored. Hardware stereo for map display in Coot 0.9 only worked for me when I added (set-display-lists-for-maps 0) to the coot-preferences.scm (also in .coot-preferences directory) although there is the following warning in the file: ; These commands are the preferences of coot. You can evaluate them ; using "Calculate->Run Script...". ; DO NOT ADD COMMANDS TO THIS FILE - it is generated by Coot ; BUT feel free to edit the setting I wounder what would be the proper way to add settings to coot-preferences.scm? Christoph Am 6/17/20 um 3:20 PM schrieb Pedro Matias: As a follow-up to this message, set_display_lists_for_maps(0) in .coot.py does not work but (set-display-lists-for-maps 0) in .coot does work. Is there some nasty little insect at work here? Regards, Pedro Às 10:09 de 15/05/2020, Pedro Matias escreveu: Hi Paul, Sorry for insisting, but I can't get the set_display_lists_for_maps(0) to work on my $HOME/.coot.py preferences file. COOT starts in mono by default and this command is ignored. It only works after I enter stereo mode, input through the scripting window. Also, it does not seem to be saved in the 0-coot-state files so if I resume a previous COOT session I have the same problem. Am I doing something wrong? Is there a workaround for this issue? BTW, the stereo on COOT 0.9 looks great - I guest that the different approach makes a big improvement. Best, Pedro Às 16:23 de 12/05/2020, Paul Emsley escreveu: On 12/05/2020 14:42, Pedro Matias wrote: Hi, Hi. Is there a way to control stereo separation / depth in the new COOT? The picture is excessively deep in comparison with the previous version. What you are mostly seeing, I think, is that the transformation between the eyes is no longer a rotation and is now a shear. Which means that now we don't get part of the map showing up in the left eye but not the right (or vice versa). Anyway, yes there is and it's documented in Section 3.4.1 set_hardware_stereo_angle_factor(0.5) # for the Python fans BTW, the issue with set-display-lists-for-maps in stereo is still present in the COOT version distributed with CCP4 7.1. It might be a while before I am sitting at a stereo display so that I can address that. It's not top priority as there is a reasonable work-around. Paul. To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
[COOT] Coot 0.8.9.2 crashes upon CA Zone -> Mainchain conversion with >1 CA segment
Hi, Just noticed the new 'CA Zone -> Mainchain' feature (since version 0.8.9.2) crashes Coot when converting a CA baton molecule that contains more than one continous segment (e.g. contains two or more CA baton stretches in the same molecule). This occurs for instance if you create gaps in your baton, e.g. after skipping to a different region of the electron density. This problem did not exist in Coot versions <0.8.9.2 and is probably a side-effect of the new way 'CA Zone -> Mainchain' works. Same bug in WinCoot, too. I can provide data files if required. Thanks for a fix! :) Christoph To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
[COOT] Disable Option for CA Zone -> Mainchain builds in both directions?
Hi Paul, As written in the pre-release notes the following feature was currently added to Coot: o CHANGE: CA Zone -> Mainchain builds in both directions Would it be possible to make this fuction optional (to be enabled/disabled), so if disabled, CA Zone -> Mainchain generates only forward mainchain (if enabled, both directions are generated)? Reason: We use Coot a lot in teaching and try (hard) to get the students to recognize chain direction based on the electron densitiy map (resolution better than 2A, but phases from partial model) and also map skeleton. After they've made a decision on the direction, for educational purpose they start building the polypeptide chain from scratch (Ca baton building -> mainchain -> mutations) with the direction dictated by the residue numbering assigned to the Ca baton molecule. While I see that the changed 'Ca zone -> Mainchain' function with the two mainchain molecules of opposite direction is probably a benefit in 'real life' model building at a stage when chain direction is not yet clear, it is rather confusing for the students at this point, since they have to make their decision again, which mainchain peptide is the correct one and discard the wrong one. Not a big issue, but maybe a small fix or already included? ;-) Thanks, Christoph To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=COOT=1
Re: [COOT] COOT 0.89 crashes when Hardware-Stereo (Quad-buffered, NVIDIA 3Dvision2) is enabled
I double-checked all three points. They were all set correctly. WinCoot crashes anyway as described... What pointed me to suspect WInCoot to be the culprit is the fact that NVIDIA quad-buffered stereo works in PyMOL on the same machine using these settings (also uses OpenGL). Christoph
Re: [COOT] COOT 0.89 crashes when Hardware-Stereo (Quad-buffered, NVIDIA 3Dvision2) is enabled
Forgot to add: I followed the suggestions for NVIDIA stereo in WinCoot under Win10: http://bernhardcl.github.io/coot/wincoot-faq.html#mozTocId286925 Doesn't help in this case. Christoph > Hello, > > I'm currently preparing a set of new Windows10-workstations to be used with > COOT and other macromolecular software supporting quad-buffered OpenGL Stereo > with NVDIAs > 3DVision2 kit using USB IR emitters (without 3-pin mini DIN cable connected) > and a NVIDIA quadro K620 (low profile) graphics card. > > The currently installed NVIDIA driver version is 391.03 (64-bit Win10) > downloaded from Nvidia (after latest Win10 updates). > > Quad-buffered Stereo using NVidia 3D-Vision glasses is enabled and working > nicely e.g. for PyMOL 2.1.0 and the NVIDIA demos (e.g. stereoscopic picture > viewer). > > Unfortunately WinCoot crashes and terminates when enabling the 'Hardware > stereo' option in the menu 'Draw/Stereo...'. I tried WinCoot versions 0.86, > 0.87, 0.88 and the current 0.89. All > behave the same. > >Worth noting: >- Pymol (working stereo) and WinCoot (not...) both use the same profile for >the 3D settings in the NVIDIA control panel. >- When setting the 'Stereo - Enable' to 'Off' in the NVIDIA control panel >(Manage 3D settings) WinCoot does NOT crash when enabling the 'Hardware >stereo' in Coot, but, of course, it will > display not in stereo. So I assume the crash really occurs when turning the > 'quad-buffered' stereo on in WinCoot. > > Any advice? Any debuggung info I can provide? > > Thanks, > Christoph
[COOT] COOT 0.89 crashes when Hardware-Stereo (Quad-buffered, NVIDIA 3Dvision2) is enabled
Hello, I'm currently preparing a set of new Windows10-workstations to be used with COOT and other macromolecular software supporting quad-buffered OpenGL Stereo with NVDIAs 3DVision2 kit using USB IR emitters (without 3-pin mini DIN cable connected) and a NVIDIA quadro K620 (low profile) graphics card. The currently installed NVIDIA driver version is 391.03 (64-bit Win10) downloaded from Nvidia (after latest Win10 updates). Quad-buffered Stereo using NVidia 3D-Vision glasses is enabled and working nicely e.g. for PyMOL 2.1.0 and the NVIDIA demos (e.g. stereoscopic picture viewer). Unfortunately WinCoot crashes and terminates when enabling the 'Hardware stereo' option in the menu 'Draw/Stereo...'. I tried WinCoot versions 0.86, 0.87, 0.88 and the current 0.89. All behave the same. Worth noting: - Pymol (working stereo) and WinCoot (not...) both use the same profile for the 3D settings in the NVIDIA control panel. - When setting the 'Stereo - Enable' to 'Off' in the NVIDIA control panel (Manage 3D settings) WinCoot does NOT crash when enabling the 'Hardware stereo' in Coot, but, of course, it will display not in stereo. So I assume the crash really occurs when turning the 'quad-buffered' stereo on in WinCoot. Any advice? Any debuggung info I can provide? Thanks, Christoph
[COOT] C-alpha baton mode not working anymore in 0.8.7
Hi, Since version 0.87 starting C-alpha baton building (after map skeleton creation) crashes COOT. In version 0.86 it still worked. Occurs in Coot for Windows and Linux (Scientific Linux 6.7). We use the c-alpha baton mode a lot in teaching. A fix would be nice. Thanks, Christoph
[COOT] WinCoot: field 'Edit / Skeleton Parameters / Skeleton Radius' obscured
Hi, This seems to be a WinCoot issue: whenever the value for the 'Skeleton Box Radius' (Menu 'Edit/Skeleton Parameters) is to be changed, the field shows the current value followed by a set of strange non-numerical characters. The input seems to be unaffected, though. Christoph
[COOT] UNDO-Bug in C-alpha Baton Mode (Coot/WinCOOT)
Hi, I know the 'baton building' feature of COOT is rarely used, but - believe it or not - we use it in teaching quite a lot and there is a bug which every time results in desperate students (and supervisors...), so high time to report: Once 'Ca baton mode' is invoked and the first CAs are placed students often start to doubt their decisions and want to UNDO all CAs they have placed so far (including the very first one). This works nicely with the UNDO button in 'CA baton mode' as long as one doesn't UNDO (delete) the last atom (the first CA that was set). As soon as ALL CAs are removed (quite often in students initial building trials) it is not possible to start over baton building again: baton atoms will not be placed any more (choice of apropriate guide point works but the object 'baton atoms' is not created). Generally, baton building will not be possible in this particular COOT session any more (no 'baton atoms' object) - one has to restart COOT in order to resolve the issue. Fixing this would be great! Thanks, Christoph
