Supporting Blender 2.7+

[zeffii]

There's quite a number of changes between the Blender Python api since 2.68 and 2.7+. It is possible to have code coexist that works for older version of Blender but it will start to get messy. Right now the main thing stopping this addon from working on the current 2.73 is the calling non existing operators.

# old
bpy.ops.wm.link_append(filepath = Path, filename = objName, directory = Directory, link = False)

# new equivalent
bpy.ops.wm.append(filepath = Path, filename = objName, directory = Directory)

One could check easily and run the correct code like so:

def append_file_to_current_blend(Path, objName, Directory):
    print('appending file')
    wm = bpy.ops.wm
    # if hasattr(wm, 'link_append'):
    if 'link_append' in dir(wm):
        wm.link_append(filepath=Path, filename=objName, directory=Directory, link=False)
    else:
        wm.append(filepath=Path, filename=objName, directory=Directory)

[zeffii]

Of course this also does not solve the surface issue.

[mfvescovi]

Given that Blender 2.7x is almost python3-based, it would a good idea to port everything to 3.x

[zeffii]

@mfvescovi my understanding is that the Blender addon (which will be running in a 3.4 python process) is calling an external python2+ process and that python2+ process writes files to the disk, which the python3+ processing can read. Porting those py2+ modules to py3+ would be neat, but perhaps not essential?

[mfvescovi]

@zeffii, exactly. Probably neat and a wishlist, for now ;)

[zeffii]

I am much more concerned about the maintainability of a 4k Python source file :) I've made several aborted attempts to restructure the files into a directory system. At present the usage of global variables is posing some superficial issue, which can probably be resolved by introducing scene properties, or addon preferences/properties. I will need more familiarity with the addon, it's gigantic, with almost no repetitive code :)

I'm also a little bit surprised at how much processing is needed to import the pdb files, easily 30 seconds here. While object duplication doesn't take up more space because they reuse meshes, the object creation time becomes higher with every new object.

[MonZop]

About the time to import pdb files, it is indeed a major problem. My understanding is that Blender reset the hierarchical tree at every step, i.e. for each atom, and possibily for every bone if the 'make bones' option is checked.

[mfvescovi]

IIRC, Monica reported her concerns already back in November 2014 with this post. Hope we can find a way to re-factor the process so that it becomes more performant on that.

[zeffii]

Yes, I read that post and was disappointed that It didn't receive traction even after the Blender Conference. I enjoyed watching the talk!

Bluntly, if I may, I think the addon is doing too much in one file, and due to global variables suffers from significant indirection. It's not impossible to follow, but it could be easier by clearer separation of UI panels / Operators / helper functions and interim storage.

But this fact does not affect the speed of execution. I am reading that part of the code now

[zeffii]

In the BConf talk the idea is proposed to make the molecule as one object, where each vertex represents an atom and each edge a bond. I'll experiment with that, and using dupli-verts to place duplicates of the atoms at the vertices. This would allow for much faster internal blender routines to handle the objects.

for example, here the parent (a sphere) donates the locations of its vertices to place child objects (also spheres). This is a ridiculously fast operation.

[MonZop]

Yes, that was the idea, and I am still ocnvinced that it could work better than the complex object made of thousands of sphere that we use now. However, to go this direction, means to introduce a major modification to BioBlender, especially in the way that the movements are calculated. With the bones we could set the rotation limits, and keep fixed the planar angles between bones. Is it possible to put such constraints also to the vertices in the mesh?

[zeffii]

I was thinking that it might be possible to perform the movement calculations in the same way, except on empties alone. as a type of proxy object. Then transfer the new locations to the molecule mesh. It's worth trying.

[MonZop]

You mean build the skeleton with all the bones, and attribute a collision radius to the empties (atoms). I am not sure it would be faster, but if you think so, let's try

[zeffii]

I don't know the source well enough to suggest any big changes, for now i'm only comfortable gradually reading it and experimenting

[zeffii]

The 273-compatible branch will focus first on allowing Blender 2.73 users to use the addon. Nothing that happens in this branch will affect the master source until a pull request ( me asking you to pull my code in ) is accepted. Although as a collaborator I can also accept pull-requests I won't initially do this, to allow you and others to test the code to see if it is satisfactory.

The powerful feature of GIT and revision control is that many experiments can be performed on the same code without ever losing the original state of the code in the master branch. This is non-destructive editing. Just please don't delete any branches I make.

[MonZop]

nono, you can rest assured I won't delete nothing at all!

[zeffii]

OK. let's ROK. I will still try to get a version of PyMOLwin, there are unofficial precompiled versions freely available which should work as the surface calculations should not even require any of the GUI of pymolwin. just pymol + commands + pymol output to disk.

[MonZop]

ROK?

[zeffii]

inside joke from the movie aliens ( https://www.youtube.com/watch?v=49OZ0M_0fhg ) we are bug hunting, and aliens are big bugs :)