added a simple program to export files in .vdb format

[spyke7]

Hi @orbeckst
I have added OpenVDB.py inside gridData that simply export files in .vdb format. Also I have added test_vdb.py inside tests and it successfully passes.
fix #141

Required Libraries -
openvdb

• conda install -c conda-forge openvdb

There are many things that need to be updated like docs, etc, but I have just provided the file and test so that you can review it, and I can fix the problems. Please let me know if anything needs to be changed and updated.

[codecov]

Codecov Report

❌ Patch coverage is 30.35714% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.46%. Comparing base (dd8d17f) to head (09b88a3).

Files with missing lines	Patch %	Lines
gridData/OpenVDB.py	28.26%	33 Missing ⚠️
gridData/core.py	25.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #148      +/-   ##
==========================================
- Coverage   88.20%   84.46%   -3.75%     
==========================================
  Files           5        6       +1     
  Lines         814      869      +55     
  Branches      107      113       +6     
==========================================
+ Hits          718      734      +16     
- Misses         56       95      +39     
  Partials       40       40              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[spyke7]

@orbeckst , please review the OpenVDB.py file. After that, I will add some more test covering all the missing parts

[orbeckst]

Thank you for contribution. I’m currently on holidays and will come back to reviewing open source contributions in the new year. Am 12/27/25 um 03:16 schrieb Shreejan Dolai ***@***.***>:spyke7 left a comment (MDAnalysis/GridDataFormats#148) @orbeckst , please review the OpenVDB.py file. After that, I will add some more test covering all the missing parts —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[orbeckst]

Thank you for your contribution. Before going further, can you please try your own code and demonstrate that it works? For instance, take some of the bundled test files such as 1jzv.ccp4 or nAChR_M2_water.plt, write it to OpenVDB, load it in blender, and show an image of the rendered density?

Once we know that it's working in principle, we'll need proper tests (you can look at PR #147 for good example of minimal testing for writing functionality).

[orbeckst]

not needed, too much detail; see other entries for example. Just the user-relevant changes in functionality

[orbeckst]

not a fix but an Enhancement – put it into the existing 1.1.0 section and add you name there.

[orbeckst]

mention and link to the openvdb library/package

[orbeckst]

We may have to make openvdb optional and then this requires more robust handling of missing packages.

[orbeckst]

This looks really slow — iterating over a grid explicitly. For a start, you can find all cells above a threshold with numpy operations (np.abs(g) > threshold) and then ideally use it in a vectorized form to set the accessor.

[orbeckst]

These tests are not testing OpenVDB so remove until you have real tests.

[spyke7]

Hm yes
Let me first run the thing on blender and then provide you with more details
I will try my best as I am new in this, so it may take some time also :-)

[spyke7]

fixed the CHANGELOG and OpenVDB.py. I didn't get the time to work on the blender part due to exams. I will surely try do it!

[spyke7]

The first two are for naChR_M2_water.vdb and the last two are for 1jzv.vdb.
Also in the OpenVDB.py, the function should be transform.preTranslate which I will fix with the new tests.
Can you please confirm that these are the correct rendering?
I can provide the .vdb files as well here.

[orbeckst]

Good that you're able to load something into Blender. From a first glance I don;t recognize what I'd expect but this may be dependent on how you render in Blender. As I already said on Discord: Try to establish yourself what "correct" means. Load the original data in a program where you can reliably look at it. ChimeraX is probably the best for looking at densities; it can definitely read DX.

Btw, the M2 density should look similar to the blue "blobs" on the cover of https://sbcb.bioch.ox.ac.uk/users/oliver/download/Thesis/OB_thesis_2sided.pdf

[spyke7]

The first one is for 1jzv.vdb and second for nAChR_M2_water.vdb (not done the shading/coloring)
I think the .vdb files as generated by the OpenVDB.py are now correctly rendering in blender.

Can I proceed with the tests part?

[BradyAJohnston]

Mentioned in the Discord but also bringing up here: In your current examples (most obvious with the pore) is that the axis is flipped so that X is "up" compared to atomic coordinates which would have Z as up.

[spyke7]

Mentioned in the Discord but also bringing up here: In your current examples (most obvious with the pore) is that the axis is flipped so that X is "up" compared to atomic coordinates which would have Z as up.

Thank you for the update! will try to fix this

[spyke7]

I think this fixes the axis..

[BradyAJohnston]

Ideally we would see this alongside the atoms or density from MN as well - to double check alignment because you might also need to flip one of the X or Y axes.

[BradyAJohnston]

The scales might be different (larger or smaller by factors of 10) but you can just scale inside of Blender by that amount to align the scales, but we want to be double checking alignemnt and axes.

[spyke7]

Hi @BradyAJohnston

I have first of all added the MolecularNode add-on as given in the https://github.com/BradyAJohnston/MolecularNodes, and imported the 1jzv.pdb. After that import the .vdb file and there was difference in size of two. So I made the size the .pdb bigger. The centers of both of them are same and I didn't flipped any of the axes in the ss provided.

I wrote a small blender py script to compare bounding boxes of the pdb and vdb objects to verify centroids, extents and axis alignment-

import bpy
from mathutils import Vector

def bbox_world(obj):
    bbox = [obj.matrix_world @ Vector(c) for c in obj.bound_box]
    mn = Vector((min(p[i] for p in bbox) for i in range(3)))
    mx = Vector((max(p[i] for p in bbox) for i in range(3)))
    return mn, mx

def centroid_world(obj):
    mn, mx = bbox_world(obj)
    return (mn + mx) / 2.0

def size_world(obj):
    mn, mx = bbox_world(obj)
    return mx - mn

pdb = bpy.data.objects.get("1jzv.001")
vdb = bpy.data.objects.get("1jzv")

print("pdb centroid:", centroid_world(pdb))
print("pdb size:", size_world(pdb))
print("vdb centroid:", centroid_world(vdb))
print("vdb size:", size_world(vdb))

output -
pdb centroid: <Vector (7.6985, 23.7885, 76.0560)>
pdb size: <Vector (33.1410, 45.4170, 29.3960)>
vdb centroid: <Vector (8.7238, 23.4452, 76.7628)>
vdb size: <Vector (43.6190, 52.3429, 40.3425)>

The centroids are almost same I guess...
the data seems to be correctly aligned

[BradyAJohnston]

@spyke7 It's still not 100% clear from your screenshots - can you import with the pore instead as that is more clear? And when you are taking a screenshot it would be more helpful to have the imported density in the centre of the screen rather than mostly empty space.

[PardhavMaradani]

Looks like you are attempting a standalone export to .vdb files from GridDataFormats. (If your end use case is to use this only within Blender, I'd strongly recommend using MolecularNodes to import various grid formats as it already uses GridDataFormats internally and provides a lot of cool features like varying ISO values, different colors for positive and negative ISO values, slicing along all three major axes, showing contours, centering, inverting etc - both from GUI and API) From a quick scan of the code, you seem to want to support both pyopenvdb (the older one) and openvdb (the newer one) - note that there are some minor differences to take into account between them. You can take a look at the grid_to_vdb method from an earlier version in MN that shows the differences and handles the export to .vdb within MolecularNodes. Hope this helps. Thanks

[BradyAJohnston]

If this functionality can be added directly to GDF then we can also take advantage of that in MN going forwards.

[PardhavMaradani]

If this functionality can be added directly to GDF then we can also take advantage of that in MN going forwards.

Agreed. In addition to exporting to .vdb format, we also add some additional metadata (currently, info about inversion, centered) that we later use. So as long as the metadata for Grids is carried over during export, we should probably be good. Thanks

[BradyAJohnston]

In addition to exporting to .vdb format, we also add some additional metadata

This is a good point and something to consider as well. As far as I am aware Blender / MN (and other 3D animation packages) might be the only ones who use .vdb as a format rather than any scientific packages / pipelines.

If there is anything out there that does take .vdb then we might want to consider if any relevant metadata should be saved. We might want to standardise on relevant metadata entries (we could either re-use from MN or update inside of MN to more general ones) so that GDF interactions with .vdb attempt to approach some kind of standard. This might be a larger question outside of scope for a simple read / write, but certainly functionality to pass in custom metadata like we do in MN would be ideal.

[spyke7]

So these are the new ss. imported the .plt/.ccp4 and then imported the .vdb file.
In the second pic, the orange highlighted are the pores, and in the first one also it is visible.

If there is anything out there that does take .vdb then we might want to consider if any relevant metadata should be saved.

maybe sidefx houdini?

and should I add metadata argument to the exporter? or we can do this in a separate PR?

[spyke7]

@BradyAJohnston are the ss looking good? or any other thing should I plot ? and anything else...

[orbeckst]

For GridDataFormats we cannot use any MN code because MN is under GPL-3+ (@BradyAJohnston correct me if I am wrong) while GDF is LGPL-3+. We should not even be looking at the MN code.

However, if one of the original code authors (i.e. @PardhavMaradani ) wants to directly contribute their ideas to GDF then that's ok (I think, though I am not a lawyer).

[orbeckst]

@spyke7 – what have you done so far to convince yourself that, say the M2 density, was correctly processed by your code? It's a vital skill to come up with your own validation and not rely on others to tell you that you're right.

[spyke7]

@spyke7 – what have you done so far to convince yourself that, say the M2 density, was correctly processed by your code? It's a vital skill to come up with your own validation and not rely on others to tell you that you're right.

Till now one of the main problems were whether the .vdb as exported were in the correct alignment, and whether the main .plt/.ccp4 were overlapping correctly or not. After seeing the screenshots as provided by @PardhavMaradani I understood that there were problem with the axes and rotated it, and after that I imported the M2 density using the MN add on and imported the exported .vdb made by the OpenVDB.py to check whether they are same in orientation and overlapping or not .(the screenshots provided above) and I think they are overlapping

I have used the MN add-on by @BradyAJohnston to crosscheck this thing. And was asking for some final advice. Only thing is that I need to scale the imported M2 density .plt file to the size of the .vdb, eitherwise the origin are almost same.
but I’m still learning here and would appreciate confirmation or suggestions for more robust validation steps
(I’m still getting up to speed with molecular dynamics data conventions, so I appreciate any guidance here.)