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 92.96875% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.89%. Comparing base (947226b) to head (ddd8c0e).

Files with missing lines	Patch %	Lines
gridData/OpenVDB.py	91.08%	7 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #148      +/-   ##
==========================================
+ Coverage   89.69%   89.89%   +0.20%     
==========================================
  Files           5        6       +1     
  Lines         844      950     +106     
  Branches      108      125      +17     
==========================================
+ Hits          757      854      +97     
- Misses         52       59       +7     
- Partials       35       37       +2     

☔ 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 a fix but an Enhancement – put it into the existing 1.1.0 section and add you name there.

[spyke7]

In the CHANGELOG, this PR and issue are in the 1.1.0 release, so should I add my name in the 1.1.0 release or remove those lines and put them in the new section?

[orbeckst]

Yes, now move it to the new section above since we released 1.1.0.

[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.

[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.

[orbeckst]

The PR is in a good shape. However, my understanding is that we want this to work with a convert_to(). Thus, we actually need #161 first and then come back here.

I know this is getting long @spyke7 . As I said before, if you didn't do interesting work, we wouldn't have this conversation about major changes to the package.

Are you able to take on #161 ?

[spyke7]

The PR is in a good shape. However, my understanding is that we want this to work with a convert_to(). Thus, we actually need #161 first and then come back here.

I know this is getting long @spyke7 . As I said before, if you didn't do interesting work, we wouldn't have this conversation about major changes to the package.

Are you able to take on #161 ?

Sorry, for not updating on #160 or #161 , as I was also busy for the past week (class internals and assignments 🥲).
I have improved some of the bugs inside OpenVDB.py in write() and _populate(), and also working on convert_to() for now. But not worked on Creating a Grid from a native object: overloading Grid.__init__(). I will be updating it by today, but need some help on what docstring to add for it! ( I have added minimum info )

[spyke7]

Need some guidance to write docstrings for convert_to() and pls check other docs and code for _load_from_native, and _is_native_object.
Implemented - _extract_from_vdb_grid solely for extracting origin, delta and grid

is there a way to get the grid without loosing tolerance? like I'm getting the original grid from _extract_from_vdb_grid , and that is why I cannot reuse the self.vdb_grid for tolerance not None.
I couldn't find/understand how to do that....
@orbeckst @BradyAJohnston

[orbeckst]

@spyke7 please create a NEW PR for the convert_to functionality — basically anything that is NOT related to VDB should be its own PR that then addresses the separate issue #161 .

Sorry if I wasn't clear, but it's really too difficult and time consuming to review multiple things together.

[spyke7]

Removed the last few commits, so as to remove the new edits/updates for core.py
And added a new PR, containing all the things of this PR with the removed commits. As, without this , I cannot implement those convert_to() from grid to native and native to grid in core.py.

[spyke7]

@orbeckst I'm adding the new updates in this PR only, that way there would not be need of #163 (and the tests will pass!)

[orbeckst]

Ok, then close PR #163 please!

[orbeckst]

This looks pretty good. I have a few comments that need addressing but for most of them you can probably just "accept suggestion".

There's some code that's not yet covered by tests. Please look at the coverage reports. For instance https://app.codecov.io/gh/MDAnalysis/GridDataFormats/pull/148?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=checks&utm_campaign=pr+comments&utm_term=MDAnalysis shows that OpenVDBFiled.from_grid() and .native are not tested but these are important for the API so we need explicit tests.

Also run black on the whole file. Hopefully it re-orders the imports so that standard lib imports come before external packages.

The core code looks all good so should be an easy merge.

[orbeckst]

Make sure that there's only a single Enhancements section by adding your new line below.

[orbeckst]

The latest change improved the coverage but it will still be important to test the new attributes and functions explicitly.

[spyke7]

Hi @orbeckst, sorry for late reply.
I have tested it by running some codes on 1jzv and nAChR_M2_water
And everything looks fine. But I was thinking about passing the native wrapper (i.e openvdbgrid) into Grid class

This piece of test code works fine -

from gridData import Grid
g = Grid(str(filename))
g.export(str(outputfile), tolerance=1e-2)

But if I try to take out the wrapper and pass it to the same Grid it is showing error (obviously)

g = Grid(str(filename))
grid1 = g.convert_to("vdb")    #  -> native wrapper
grid2 = Grid(grid=grid1)          # -> Error

as edges, origin and delta are None.

Quick workaround is using the openvdb itself

# Above code without grid2
import openvdb
openvdb.write(str(output_file), grids = [grid1])

So I was thinking if inside from_grid, we can extract origin, delta, and edges from provided openvdb.FloatGrid
I have tried to get out the things but was looking how to reuse it. What are your thoughts on it?

[orbeckst]

grid1 = g.convert_to("vdb")    #  -> native wrapper
grid2 = Grid(grid=grid1)          # -> Error

grid1 is the native OpenVDB FloatGrid.

Then the second line is really what #162 is about — that could wait until we address that issue.

[orbeckst]

At this stage I'd be happy to merge this PR if you address my comments and include explicit tests for the from_grid() and .native functionality.

The changes that I made test these implicitly so coverage is now sufficient but we should have explicit tests for key API functionality.

@PardhavMaradani I know that you're busy. Let us know if you would like to have some extra time for reviewing or if you're ok with proceeding as necessary.

[spyke7]

The changes that I made test these implicitly so coverage is now sufficient but we should have explicit tests for key API functionality.

Yeah, I was looking into other comments, and will create the tests as required.
Once it is implemented, we can focus on solving #162