Load local PDB File using the python API.

[kainszs]

Load local PDB File using the python API.

[BradyAJohnston]

Please feel free to to make some suggestions - it's early days for the class so I'm happy to make more drastic changes for the sake of usability in the future.

The Molecule class does reference the Blender object here:

MolecularNodes/molecularnodes/io/parse/molecule.py

Line 55 in 12fb08d

self.object: Optional[bpy.types.Object] = None

When the create_model() method is called an object is created and stored there for future reference.

Molecule doesn't subclass bpy.types.Object as the idea is to create a class that is better suited for molecular visualisation. The basic Object class is very busy already (if you look at the docs linked). I had thought that it would be better to create a cleaner interface that just showed what was important. I'm not super familiar with OOP though, so if you can see improvements for this setup then please do suggest them.

I can certainly imagine this being part of GSoC, but we'll need to make sure it stays associated with MDAnalysis data. Currently the Molecule class is separate to the AtomGroupInBlender class which is currently how the MDA data is imported and viewed in Blender:

MolecularNodes/molecularnodes/io/parse/mda.py

Line 37 in 12fb08d

class AtomGroupInBlender:

There would be potential for unifying these a bit better, which would certainly fit well with the GSoC.

[kainszs]

I have been working on the bug all day today and realized that you are already tackling it in the PR #448 and in the Issues #454 and #3.

Regarding the molecule class I would like to offer my help.

I'm noticing some methods associated with the Molecule superclass that utilize self.data (see below), which is not an instantiated class variable in either the Molecule class nor the PDB, CIF, MMTF subclasses.

Some of these are leftovers of GitHub Copilot generated boilerplate that I didn't get around to cleaning up if I am being honest. I haven't really implemented anything that uses them - so it was on the todo list to clean up.

You raise an important point that about how these methods should work (or if they are relevant) which also touches on discussions in other threads.

Currently the Molecule object (and others) have the self.data and self.object. When using named_attribute() or store_named_attribute() we are getting and setting on the Blender object - should we be updating the underlying data biotite.AtomArray or MDAnalysis.Universe? Tracking and having two sources of 'truth' I am not a big fan of.

My thoughts are that once we have everything inside of Blender we should pretty much just be interacting with the object, and we should just make sure we have pulled all relevant information from the file itself, with the option to 're-parse' the file for additional information if required for specific use cases.

Within this PR I would remove all code, which contains self.data, so that the code works properly with the merged PR #448. After that we could open a follow-up PR?

[BradyAJohnston]

Hi @kainszs ! The first error you are getting is related to initilisation. Currently when the add-on is used inside of Blender, Blender calls a molecularnodes.register() function. I haven't figured out a nice way to have that called when importing inside of a script other than just manually calling it. Something to hopefully be improved upon.

For now, you can fix it with

import molecularnodes as mn
mn.register()
mn.io.local.load("tests/data/1cd3.pdb")

[BradyAJohnston]

And yes if you wanted to open a PR to clean up the Molecule class a bit that would be a great start!

[BradyAJohnston]

The API is a bit of a mess as you might see in some of the issues. A focus for me will be on improving it, which can hopefully work well with improving the interfacing with MDAnalysis as well for GSOC.

[kainszs]

I have looked at the auto_load.py file, can you explain to me what exactly the init, register and unregister methods are for? And it is also not clear to me from the code why the molecule object has an additional attribute after mn.register().

[kainszs]

Regarding the molecule class. What should it be able to do? How would you like to work with it?

[BradyAJohnston]

I have added some more documentation that hopefully explains some of the aspects of the add-on in #463

In short, all operators, UI components and other aspects that are to be used inside of Blender for the add-on have to be registered when loading the add-on, so that Blender knows about them and can display them properly. When the add-on is disabled, they have to be unregistered so you don't still have UI components hanging around when an add-on isn't enabled.

You have to register() and unregister() for each of those components individually. The Blender VSCode Development plugin provides a submodule auto_load which scans through the add-on/package and detects all required operators and UI components, so they can be successfully registered and unregistered. That way we don't have to manually include each method.

[BradyAJohnston]

Regarding the Molecule class. Currently when structures are imported, a 3D model is created inside of Blender. The idea is that the Molecule will contain information about the file that this model came from, and provide an interface that the user can change the associated style and edit the underlying information of the structure through this class. The currently existing python API isn't setup well for interacting with molecular structures, or changing the Geometry Nodes tress that are associated with the models. The class will hopefully provide a neater interface for loading, editing and styling the model, in a way that is nice to script with inside of a Jupyter Notebook or similar script.

[kainszs]

Good morning, thank you for the detailed reply. Would you be open to me making a few suggestions for the molecule class? I think by writing magic methods (eg. setattr) a lot can be simplified. But it would also be a major change.

I haven't looked at the blender object in the source code either, but why doesn't molecule inherit from it, for example, or set it as an internal data structure?

Can you also imagine this as part of the GSoC?

[kainszs]

I will think about it.

In short, all operators, UI components and other aspects that are to be used inside of Blender for the add-on have to be registered when loading the add-on, so that Blender knows about them and can display them properly. When the add-on is disabled, they have to be unregistered so you don't still have UI components hanging around when an add-on isn't enabled.