Proposed package structure and code style changes

[zeffii]

Structure

This issue is to describe an alternative structure of the addon. The intention is to separate concepts which do not need to be coupled merely because they rely on a global variable to carry state. It's a lot of work to pull these things apart and i'm not asking anyone else to do it, in fact I will do this in another experimental Branch called "BB2_273_modular". After the addon is compatible with 2.73, and all test molecules import correctly

I'm thinking something like

bio_modules/ui/..              # all panels
bio_modules/operators/..       # all operators
bio_modules/utils/..           # all decoupled functions
bio_modules/constants/..       # all huge tables / dicts 
bio_test_molecules/..
bin/..
tmp/..
data/..
__init__.py
BioBlender2.py                 # should shrink significantly or disappear
License.txt
mouse26.txt
README.md

Code Style

Once the structure is modular and working, It may be wise to start thinking of how the code is written:

• I would like to move to spaces instead of tabs for indentation (but will hold off for now)
• use more aliasing, all these chained . lookups make the code look more imposing than it is.
• propose max line length of 100
• propose limits to how deeply if statements are nested ( beyond three becomes a pain )
• ideally we start using pep8 / pylint style checker, it is python after all.

• we use os.path.join() instead of joining os.sep manually.

  fullpath =  `path + os.sep + dir1 + os.sep + dir2 + os.sep + filename`
  # would become
  fullpath = os.path.join(path, dir1, dir2, filename)
  

• Use the modern string formatting features of python
• Add more elaborate Exception handling messages, the line number / line would be more helpful
• example of tricky code to maintain: this: https://gist.github.com/anonymous/34abaf7c88ed2ad84b2f Eventually I will like to speed test it against something like this: https://gist.github.com/zeffii/c4955c4b4955b6de4518 If the alternative is of similar speed it is a bit more pythonic, and would get my vote..

I will add more to this thread as it comes to me.

[zeffii]

ultra minimal pdb import routine (mere experiment, took 5 minutes to code) https://gist.github.com/zeffii/9f71c319ff8f245df43e

[zeffii]

import time below 0.2 second using dupl-verts, each vertex of the objects atoms_C, atoms_N, atoms_O, atoms_P, atoms_S gives the location of an atom of that type. Each atom (from my limited understanding) is represented by a radius (first element of scale_cov dictionary). and a common color (color not yet done)

script https://gist.github.com/zeffii/a56ca2e1771ec16b3281

[zeffii]

(Cycles Viewerport render, with light grey background color and Ambient Occlusion on, no additional lighting)

this one takes radii and comon color into account. fast import. could probably reduce memory footprint by adding subsurf to the child atom.

here script: https://gist.github.com/zeffii/21fdce98b73285621f83

next script will include checks for existing materials, and a section to wipe existing meshes so the script can be run repeatedly.

[zeffii]

this script also sets the render mode to cycles, but the user must change the viewport to materials https://gist.github.com/zeffii/b5cf927b00d31a87b4fe

None of these scripts take the SCALE1, SCALE2, SCALE3 lines into account, because of this the radii may seem awfully big

[MonZop]

Nice work, thanks. But I have to remark that the import of atoms is just a preliminary step: the entire point of BioBlender is to show molecules NOT as the collection of atoms, but as the continuous volume, which is defined by those atoms, i.e., the molecular surface. The 'coloring' of this surface is, once agin, determined by the underlying atoms, but integrated using a library of vlaues and a formula that attributes to the surface (vertex by vertex) the value resulting from the calculation.

[MonZop]

The second major point of BioBlender, is the molecular motion. Just like legs and arms in 'normal' carachters, atoms in a molecule can move, but are not entirely free: for this reason we used bones in the place of each chemical bond, and provided that:

• bones cannot change length
• planar angles of the joints cannot change
• only rotation along the joint axis is permitted. To this, it is necessary to add the collision control (something that could not be done using instances of spheres). All this is achieved using the Blender Game Engine. Also this can be changed, of course, but at the moment it seems more reasonable to fix the present BioBlender, because we have already demonstrated that it produces scientifically sound results.

[zeffii]

@MonZop The more i know about pdb the better I can judge the data structures it has been parsed into by BB2. It isn't my intention to write a full pdb importer. (Importers exist already but represent only static shapes), not the convolving animated entities BioBlender is aimed at showing. This is a first step to figuring out a way to animate the data as vertices of an object, instead of directly using objects.

[zeffii]

@MonZop but before any of the experiments here are taken further, I agree that the current state of BB2 should at least import the test molecules without failures. It would really help to have brief communication with whoever wrote the lines I highlighted in https://github.com/MonZop/BioBlender/issues/8

[MonZop]

The lines are part of the code that builds the joints, while creating the atoms. The first time it was written by Mike Pan (it worked), and it was then re-used , slightly modified for BioBledner 1 and 2 by Francesco Milanese (both of them know about this repository, but I will mail them again). Hope they can help!

[zeffii]

@MonZop do you have the various old source-codes as separate zips leading up to this point? Maybe with a bit of code-archeology I can see where that modelList variable got lost..

[zeffii]

i'm closing this for now to reduce the noise.

[mikepan]

Hi, I was notified of this repo and thought I should chime in:

The lines you are seeing in #8 represent rigid body joints. They are used to animated the molecule inside the game engine. They are safe to remove if you have another way of simulating them physically, The BGE isn't very deterministic with simulating them anyways.

[zeffii]

Hi @mikepan, thanks for the heads up. I haven't looked closely at the rigging or game engine code yet. Perhaps may I fire the occasional question in your direction? I don't mind doing the coding of course :) but the BGE and Rigging aren't my areas of expertise.

Providing the physics simulation via other means is not a primary concern. Of course I have some curiosity towards trying the simulation using numpy and modules

[mikepan]

Sure, by all means. I think you are on the right track with doing as much of the simulation as possible in code, and using dupliverts in Blender for drawing. API calls in Blender is really slow, especially when object updates are involved. That was the main reason why importing something tiny takes 30 seconds, It was all in the scene update.

[MonZop]

In this respect, with a colleague who is a mathematician, we are devising a procedure to calculate protein motion trhough a Monte Carlo procedure using quaternions (all coded in Pthon/numpy/biopython). As soon as we see it working, we can try to introduce it in BioBlender. It is meant to provide both random motion and directed transition between fixed conformations.

[zeffii]

I wonder then if it's worth my time trying to get the BGE stuff working. Offloading to a dedicated process to produce a motion-cache and bond-cache seems a natural progression, and would allow the use of dedicated hardware (CUDA..GPU) and dedicated routines.

[mikepan]

BGE doesn't support geometry instancing the way Blender does. So you might run into problems. Personally I would just focus on native Blender. On 30 Jan 2015 11:43, "Dealga McArdle" notifications@github.com wrote:

I wonder then if it's worth my time trying to get the BGE stuff working. Offloading to a dedicated process to produce a motion-cache and bond-cache seems a natural progression, and would allow the use of dedicated hardware (CUDA..GPU) and dedicated routines.

— Reply to this email directly or view it on GitHub https://github.com/MonZop/BioBlender/issues/7#issuecomment-72258457.

[zeffii]

So we agree, using the BGE is not the way forward, but caching positions and bonds via other means (method alluded to by @MonZop ) would be most desirable.