The Rewrite: BB2 Redux

[zeffii]

Over the next couple of days (unless something unforeseen happens) I have time to make a start with building the add-on from scratch. Getting it to match the working features of BB2 will take a while. It's difficult to put a time frame on it until the process gets rolling.

The decision to start from scratch is not done in haste. I think some of the responders on this repository have expressed similar feelings about how to proceed. There's lots that can be taken from the current code-base, but a lot that I really want to sanitize and arrange into separate files. The core of this was written when Blender 2.5 was still young and the API not very well defined, and prone to convoluted solutions.

If I can reach feature parity and structure the code better then I will consider it a success, speeding up the import (and avoiding recursive updates) is not my first priority, making it easier for others to contribute is far more important.

Ticks indicates functionality seems to be restored for that panel, certainly report any issues with those sectons. The unticked sections have had no major checks done other than suppressing import errors. The section labelled next is either being worked on or that's where the most recent code changes have taken place.

• [x] gui_panel_ep.py
• [x] gui_panel_mlp.py
• [ ] gui_panel_nma_viz.py
• [ ] gui_panel_output_animation.py
• [x] gui_panel_pdb_import.py
• [ ] gui_panel_pdb_output.py <---next
• [ ] gui_panel_physics_sim.py
• [x] gui_panel_view.py

[zeffii]

oh.. " relative to covalent " in

some atoms scale by 1.5 while others multiply the radius by 4 or more, relative to covalent.

is interesting, and i'm not sure I understand :)

[zeffii]

might be worth noting that the scale_vdw table isn't used anywhere in BioBlender master, and therefor that explains why there is no feature to use the vdw on the import stage either. It's not obvious to me how those values would be used or if they are correct. -- other than how I interpreted their use, which seemed logical.

[zeffii]

I do see big differences in the table you posted and the current bioblender tables..

[zeffii]

we can have any number of tables if you want, and make a selector with a descriptor of all the scales (maybe some scales emphasize certain properties over others)

[MonZop]

It seems that we have 3 measures for radii: Covalent, Van der Waals and collision. While the Cov and VdW are physical, the collision radius was a 'trick' introduced by us in order to allow the game engine some room for calculating the motions. I would keep the 3 values, but I suggest that for each atom the VdW value are the ones in the table above. Some atoms do not have a 'real' VdW measure, because it is not a relevant property in physics, but if it is necessary to place a number, I suggest that we use the covalent radius. I am doing some other urgent work right now, will get back as soon as possible

[MonZop]

I think that we could change the values in Tables.py and make it a single table for ewach atoms, including: [Covalent, VdW, Collision radii, and [color]] what do you think?

[zeffii]

On the surface there's nothing wrong with that suggestion, it certainly makes sense to store all three in an atom_properties_table. But i'd like to solve the problem first, and changing them into one table is a bit more of a code shuffle than is necessary for this stage of the Redux.

[zeffii]

'''
Define atom scales
0 vdw = visual Van der Waals scale
1 cov = visual covalent scale
2 collision = collision radius scale
3 color = representation 
'''
atom_properties = {
    # :   vdw, cov, collision, color
    'C':  [1.35, 1.10, 0.6, [0.10, 0.10, 0.10]], 
    'CA': [1.59, 0.99, 0.6, [0.40, 1.00, 0.14]], 
    'N':  [1.23, 1.07, 0.6, [0.24, 0.41, 0.70]], 
    'O':  [1.20, 1.04, 0.6, [0.46, 0.10, 0.10]], 
    'S':  [1.43, 1.46, 0.6, [1.00, 0.75, 0.17]],
    'P':  [1.43, 1.51, 0.6, [1.00, 0.37, 0.05]], 
    'FE': [1.59, 0.64, 0.6, [1.00, 0.50, 0.00]], 
    'MG': [1.37, 0.65, 0.6, [0.64, 1.00, 0.05]], 
    'ZN': [1.10, 0.74, 0.6, [0.32, 0.42, 1.00]], 
    'CU': [1.10, 0.72, 0.6, [1.00, 0.67, 0.00]],
    'NA': [1.80, 0.95, 0.6, [0.80, 0.48, 1.00]], 
    'K':  [2.18, 1.33, 0.6, [0.72, 0.29, 1.00]], 
    'CL': [1.37, 1.81, 0.6, [0.10, 1.00, 0.60]], 
    'MN': [1.59, 0.46, 0.6, [0.67, 0.60, 1.00]], 
    'H':  [0.95, 0.53, 0.3, [0.90, 0.90, 0.90]], 
    'F':  [1.16, 1.36, 0.6, [0.27, 0.80, 0.21]]
}

[zeffii]

the above table is not updated from data in your table (yet!), merely the three old tables merged.

[MonZop]

atom_properties = {
    # :   vdw, cov, collision, color
    'C':  [1.70, 0.70, 0.6, [0.10, 0.10, 0.10]], 
    'CA': [2.30, 1.80, 0.6, [0.40, 1.00, 0.14]], 
    'N':  [1.55, 0.65, 0.6, [0.24, 0.41, 0.70]], 
    'O':  [1.52, 0.60, 0.6, [0.46, 0.10, 0.10]], 
    'S':  [1.80, 1.00, 0.6, [1.00, 0.75, 0.17]],
    'P':  [1.80, 1.00, 0.6, [1.00, 0.37, 0.05]], 
    'FE': [1.30, 1.30, 0.6, [1.00, 0.50, 0.00]], 
    'MG': [1.73, 1.30, 0.6, [0.64, 1.00, 0.05]], 
    'ZN': [1.40, 1.30, 0.6, [0.32, 0.42, 1.00]], 
    'CU': [1.40, 1.40, 0.6, [1.00, 0.67, 0.00]],
    'NA': [2.27, 1.60, 0.6, [0.80, 0.48, 1.00]], 
    'K':  [2.75, 2.00, 0.6, [0.72, 0.29, 1.00]], 
    'CL': [1.75, 1.00, 0.6, [0.10, 1.00, 0.60]], 
    'MN': [1.40, 1.40, 0.6, [0.67, 0.60, 1.00]], 
    'H':  [1.20, 0.30, 0.3, [0.90, 0.90, 0.90]], 
    'F':  [1.47, 0.60, 0.6, [0.27, 0.80, 0.21]]
}

This table includes the more realistic sizes for VdW and Cov. I will work more on colors

[zeffii]

Cool. now the table exists, could implement it a.s.a.p. and make a new branch for the modified table, it doesn't have a massive impact on the code. maybe I'll delete / "stash"(archive) stages s1..s5, or delete them altogether.

[zeffii]

i've pushed, but not yet tested. I like the leading lines, normally we don't format 'dicts' in any special way, but because this is a table with a legenda, I think this convention is OK.

atom_properties = {
    #      vdw
    #       |    cov
    #       |     |  collision
    #       |     |     |          color
    #       |     |     |           |
    'C':  [1.70, 0.70, 0.6, [0.10, 0.10, 0.10]],
    'CA': [2.30, 1.80, 0.6, [0.40, 1.00, 0.14]],
    'N':  [1.55, 0.65, 0.6, [0.24, 0.41, 0.70]],
    'O':  [1.52, 0.60, 0.6, [0.46, 0.10, 0.10]],
    'S':  [1.80, 1.00, 0.6, [1.00, 0.75, 0.17]],
    'P':  [1.80, 1.00, 0.6, [1.00, 0.37, 0.05]],
    'FE': [1.30, 1.30, 0.6, [1.00, 0.50, 0.00]],
    'MG': [1.73, 1.30, 0.6, [0.64, 1.00, 0.05]],
    'ZN': [1.40, 1.30, 0.6, [0.32, 0.42, 1.00]],
    'CU': [1.40, 1.40, 0.6, [1.00, 0.67, 0.00]],
    'NA': [2.27, 1.60, 0.6, [0.80, 0.48, 1.00]],
    'K':  [2.75, 2.00, 0.6, [0.72, 0.29, 1.00]],
    'CL': [1.75, 1.00, 0.6, [0.10, 1.00, 0.60]],
    'MN': [1.40, 1.40, 0.6, [0.67, 0.60, 1.00]],
    'H':  [1.20, 0.30, 0.3, [0.90, 0.90, 0.90]],
    'F':  [1.47, 0.60, 0.6, [0.27, 0.80, 0.21]]
}

[zeffii]

now vdw looks like :

but covalent is unusual :) but i don't know if good/bad

[zeffii]

I guess, as a layman, the lower image makes more sense if I imagine tubes connecting the atoms to represent bonds..

[MonZop]

Oh oh, something wrong. Let me double check the values

[MonZop]

But the VdW look right

[MonZop]

The covalent bond is (by definition) the contriobution of each atom to the total distance between two atoms: in theoryall atoms should touch their neighbours to which they are bonded.

I have two possible explanations: a) there is a mistake and the covalent and collsion radii got mixed up b) atom size is not set to precise size, but is scaled by a factor (less likely)

[zeffii]

weird :) i don't see anything immediately wrong with how I restructured the code, but it does seems weird that the game radius is larger than the covalent radius 0_o

[zeffii]

OK, i don't know :)

[zeffii]

The code should behave the same as before, but the big difference are the new values of the Covalent. I could for a test replace the cov scales values with the original ones, to see if I made a mistake in the scale assignments (it's not much effort to find out)

[zeffii]

btw, 'covalent scale' , what measurement is that relative to ? the radius of a H atom?

[MonZop]

I notice that in the Transform panel, (besides the fact that all parameters are keyframed, including Scale, which should not be), there is the Dimension value, and a Scale value.. I guess that the sphere are created with a radius, (possibily the Cov), and then scaled by the same value. Example: Oxygen has a Scale = [0.6, 0.6, 0.6]. If I change the scaling to = [1.0, 1.0, 1.0] the resulting size is .. [1.3, 1.3, 1.3], which is not the right size anyways!! wiered! :confused:

[zeffii]

hmm, it may be that the cov values in the old table take this into account? It may just require a simple inversion..

[zeffii]

hehe, I raised this concern even before tackling the code: https://github.com/MonZop/BioBlender/issues/32#issuecomment-116628432

[MonZop]

Good point! What if we: create the atom/sphere all with size 1 (radius), and then change to the proper radius, according to what we want . It seems to me that even the VdW (which at first sight seems OK) has problems

[zeffii]

this is what gets imported as the 'template atom' at the moment:

[MonZop]

I would say that it is the typical Carbon atom, radius 0.7

[zeffii]

right, everything is scaled relative to the carbon atom then

[zeffii]

maybe figure this out today, I have some quiet time to myself.

[MonZop]

Oooops!! Checking the new Bledner, I was playing with MLP, and noticed that it does map perfectly on the surface, but the render has lost the texture and material features. I cannot say if these features worked before, as the master cannot render the MLP. Any hint?

[zeffii]

it does map perfectly on the surface, but the render has lost the texture and material features.

Which branch? I don't recall modifying a lot of code for the MLP panel, it is entirely possible that I didn't catch one or two things. I have the feeling that render / baking still relies on the values in one of the imported temporary files..and may just need to be told to read the new vertex colour data for baking noise.

Also i'm still not sure what exactly to do about the vdw / covalent scale flip, but the code to do it is in place

[zeffii]

I responded , but can't look at the code right now

[zeffii]

OK, I can return to this now, this bugs the hell out of me.

I'll write a small test script that generates an Atom of each type and provide a switch to flip between covalent vs vdw radius. This way the table and switching radii can be understood separately from the BioBlender addon. It doesn't make the slightest bit of difference if we are looking at Molecules or just a string of unique atoms in x,y space to get the right scaling.

I'd really like to move on from this bit of the code.

[zeffii]

or an artificial soup of molecules that show each type of atom, for quick debugging

[MonZop]

I have prepared a pdb file, called BunchOfAtoms, but 1. I do not remember how to add it to the Test Molecules folder and 2. I am a little ashamed at circulating a totally meaningless/impossible atomic file. I can send it through the mail for your use

[zeffii]

yes, please send via email. it's a debug pdb then..so not entirely meaningless :)