lcbb / athena Goto Github PK

Dialog boxes for saving files and screenshots awkwardly say "Open" instead of "Save," because we're using QFileDialog.getExistingDirectory(). A custom directory with custom buttons would be better.

In addition, Mark notes that the default directory presented by the Save Results dialog is weird, (probably) especially when running from app translocation on a freshly downloaded Athena.app.

• Various issues with spelling and organization of default / sample geometries -- this is waiting on Mark and Hyungmin.

• Mark wants to see the left sidebar as a splitter instead of a fixed-width window. See if this can be done without major surgery.

• Need a switch to make 2D material transparent.

• Need a 'reset display options' menu item.

• A tool-run-success log would be helpful

  • Right now it's a flat dump of tool output, making it hierarchical would be better.

• Athena needs a desktop icon.

• s/athena_outputs/athena_output/

• Revisit how output folders are chosen to ensure nothing gets overwritten.

• Discuss how to best organize basic program workflow, see https://lcbb.slack.com/archives/G72A6Q90R/p1556848006142100

A useful paper on how to draw wireframes is "Two Methods for Antialiased Wireframe Drawing with Hidden Line Removal" : http://orbit.dtu.dk/files/3735323/wire-sccg.pdf

Athena is currently using a variant of their first, simpler method. (Historical note: I came to the method via the Qt3D wireframe example, which uses a similar but slightly dumber technique, and I modified it to suit our need for non-triangular faces. I found this paper after all that.)

Athena's needs would actually be better suited by their second, more general method, as this would clean up several rendering glitches that Athena has if you look at the output very closely or throw it a very difficult polygon. (More on that below.) However, the implementation time for the second method would run to several hours, and I'd need to think of a way to dovetail their method with our current fake 2-pass depth-sorting method so that transparent objects still look right-ish.

So I think implementing the second method would be worth doing to ensure very high-quality graphical output. But it's probably not worth doing before version 1.0.

As of v0.2.1 the GUI is feature-complete, but there are a few things that need to happen before we can move beyond beta status.

• Scaffold files -- for now we've decided that Athena can just ship with an m13 default

  • Scaffold import still needs UI, this should be quick to add.

• The repository README needs to be made ready for reading by newcomers.

• The LICENSE information needs to be updated to attribute code that has been brought in from other sources. (Specifically: Qt example code for QML and shader files, and the earcut code for triangulation.)

• The build files should be modified to include end-user README and LICENSE files in the distribution package.

• The built-in 2d and 3d example files should perhaps be slimmed down, spelling errors corrected, and any attribution given. (Do we have a right to distribute some / all / none of these?)

The following items are NICE TO HAVES for version 1.0, but we could live without them:

• The build files should apply version information automatically to the binary and the README, so that Athena as a self-contained artifact has accurate version information for users to report bugs.

• Athena should report the progress of sequence tools when they are running, ideally in a way that does not halt the program while they run.

• If the above can be done, then the text console can be hidden at launch time, leaving Athena as a truly one-window program. This had to be done to allow Athena to become Athena.app on OSX. Tools are dumping their progress into an in-process log window instead of a separate console window now, but they still halt the program while processing.

• Make color selection windows be non-modal (i.e. make them not halt the rest of the GUI).

Following the instructions in HACKING.txt, I get the python3 error:

athena % python3 src/main.py
No version.py available
Athena version is 0.4.7.dev2+g98c8769
Athena's output directory will be /var/folders/0n/lghg82jn4bb7pqjs3cbz4ljh0000gn/T/Athenan36jwwso
Traceback (most recent call last):
File "/Users/ben/LOCAL/athena/src/main.py", line 8, in
from athena.mainwindow import AthenaWindow
File "/Users/ben/LOCAL/athena/src/athena/mainwindow.py", line 18, in
from athena import bildparser, viewer, screenshot, geom, ATHENA_DIR, ATHENA_OUTPUT_DIR, ATHENA_SRC_DIR, logwindow, version
File "/Users/ben/LOCAL/athena/src/athena/viewer.py", line 15, in
from athena import ATHENA_SRC_DIR, plymesh, geom, decorations, screenshot
File "/Users/ben/LOCAL/athena/src/athena/decorations.py", line 14, in
class SphereDecorations(Qt3DCore.QEntity):
TypeError: 'Shiboken.ObjectType' object is not iterable

And downloading the latest .zip pre-release, moving the Athena app to /Applications and double clicking, it says:

"Athena is damaged and can't be opened"

I'm new at using ATHENA, and I wasn't able to reduce the bp in each helix. Looks like the minimum length is set to 42bp. I'm wondering if it's possible to reduce that number?

Hyungmin points out that, on Windows, Athena isn't displaying its icon at the window level. This should be possible with a Qt API call.

@hmjeon identified a bug with screenshots in v0.4.4, which seems to apply to both Windows and Mac: after taking a screenshot the camera is messed up.

I've tested this and narrowed it down to 0.4.4's Qt version upgrade (which was done while trying to solve #10). Something has changed in 5.13 with how the Qt3DWindow's framegraph is tracked, and I think Qt must be deleting some framegraph objects under the hood where previously it wasn't.

As a short-term fix I will back down to Qt 5.12.3 in our requirements.txt and v0.4.5. will ship with the library at that version. Longer-term, screenshots will need to be fixed. I think this could be done by changing AthenaFrameGraph.set[Off/On]ScreenRendering to always allocate new frame graph nodes instead of jiggering around the current ones. Checking what actual changes occur in the qt3d sources between 5.12.3 and 5.13.0 may also be insightful.

@hmjeon says: For the Athena, current version has maximum edge length as 126-bp, could you also increase it up to 210-bp? We used 210-bp DNA origami in the paper.

Question: is this new limit appropriate for all 4 of the tools?

Neither Qt3D's built-in ply file loader, nor the one currently implemented in Athena v0.1.1, will do the right thing for some complex polygonal faces. Qt3D's loader requires face polygons to be convex; our custom one can handle some concave polygons, but has other undesirable limitations. This means that, right now, there are some valid PLY files that will be displayed incorrectly by Athena.

Mark and Hyungmin and I discussed this in a Skype call on April 3rd. Fixing this will take a few days so I'm documenting progress here.

The general problem of triangulating an arbitrary (probably-)2D polygon within 3D space does not have a ready open-source solution that I can find. Various libraries are able to do it in two dimensions. Here's a promising one with no unreasonable dependencies and a permissive license: https://github.com/skogler/mapbox_earcut_python

To integrate this into Athena will take two steps:

1. Use this triangulation library only for polygons that arrive in Athena already in the XY plane. This is the common case for all inputs to PERDIX and METIS, and will cover all the problematic input files that we have today.

2. For 3D polygons, develop code to project vertices into 2D, triangulate as in (1), and then re-project the resulting triangles back to 3D. Since the earcut algorithm doesn't synthesize new vertices, the last step is very straightforward.

The additional code for supporting (2) will be small (numpy can calculate the projection easily enough), but testing (2) for robustness will take time; I will need to first synthesize some test cases.

This is Mark's "double-button press" bug. It takes two mouse clicks to activate Athena's qwidget controls if the mouse has already been clicked inside the 3D view. This is observed only on Macs with (force) touchpads running 10.13+. On my own mac, I do not see this behavior, but I'm not sure if that's because I'm on 10.12 or because I have an older, non-force touchpad.

I can reproduce this issue on another laptop that I have occasional access to. I've tried a bunch of things to fix it:

• Changing the graphics container to have Qt.NoFocus
• Explicitly ignoring mouse press and release events in the graphics view
• Various window flag options to QWidget.createContainerWindow.

Observing all events using QApplication.notify, I observe that the button widgets aren't getting a mouseRelease event on the first click. They do seem to be getting a mousePress event, which leaves them in a broken, half-activated state. A QWindow object is receiving the expected events, but its address as visible in Python seems to change from call to call, even on machines where the bug is not observed. (The changing address thing might be a PySide foible and not indicative of a bug, but I'm not sure.) In any case, I haven't been able to find out what QWindow object is getting these events or how to modify its behavior.

This smells like a bug internal to Qt, so a good thing to try would be upgrading Qt and see if it persists. If it persists, try harder to determine what is going on with the QWindow object that is swallowing these mouse release events.

Among its many exciting problems, Catalina has this problem: Athena builds from my Sierra machine do not run on it. Mark gets this error from either double-clicking or invoking the binary in the terminal:

The obvious culprit would be some essential code that is build for 32 bit instead of 64 bit platforms, but I don't detect any such code using file on the contents of Athena.app. There are some universal binaries, such as this one:

dist/Athena.app/Contents/MacOS/libgcc_s.1.dylib:                                                                           Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386]
dist/Athena.app/Contents/MacOS/libgcc_s.1.dylib (for architecture x86_64):      Mach-O 64-bit dynamically linked shared library x86_64
dist/Athena.app/Contents/MacOS/libgcc_s.1.dylib (for architecture i386):        Mach-O dynamically linked shared library i386

Need to determine if these might be the problem, or if there's some general other PyInstaller problem at work. Possibly the solution will have to be to get someone to build a separate binary for OSX 10.15+.

• Orthographic 3D display [2 days]

• Print-quality screenshots. (This depends on #2 and also requires some additional GUI work to set screenshot parameters.) [2 weeks]

• Output display / parsing of BILD files. [Basic utility in 1 week, further planning from there]

Calls to sequence tools and to pdbgen should be asynchronous to the GUI, in order to give the user a chance to see progress and cancel slow or stuck processes if necessary.

Would you mind putting the detailed installation guide for macOS, Windows and Ubuntu in the Readme file? I have some hard time getting the software installed.

Athena up to v0.3.5 shows bad z-fighting artifacts in its ray-traced output objects (cylinders, spheres, cones). v0.3.6 and later address this by choosing a better front plane for perspective projection.

What I really want to do, to address this more completely, is to change Athena's depth buffer to 32 bits instead of 24. Unfortunately this does not seem to be possible with today's PySide2 and Qt3D, because:

• Qt3DWindow.cpp unconditionally sets a 24 bit depth buffer, and
• It doesn't seem possible to set up a new OpenGL context in a child class, and
• It doesn't seem possible to control the actual buffer depth by first enabling shared OpenGL contexts (I tried), and
• Reimplementing Qt3DWindow in Python code is impossible because of a PySide2 bug. (Maybe it'd be possible under PyQt5?)

Once a 32-bit buffer can be enabled, it would be worthwhile to reverse the Z buffer per this article to gain a complete upper hand over these kind of rendering artifacts.