Boundary Missing on OpenVDB

ParaView Support
1

Hi Paraview,
I was testing a tiny structure and found something weird.
This cube.vdb is a 3x3 cube with all values set as 1 while the center set as 0.

[[[1, 1, 1], [1, 1, 1], [1, 1, 1]]
[[1, 1, 1], [1, 0, 1], [1, 1, 1]]
[[1, 1, 1], [1, 1, 1], [1, 1, 1]]]

I expect to see a solid cube with single color in surface representation, but it looks like this.

image
image602×558 39 KB

And the data statistics also looks wrong.
image

It seems that OpenVDBReader shrinks the maximum boundary while loading vdb into partitioned dataset collection.
Is it an intended behavior? If so, is there a way to avoid it? Thank you!

2

Is it an intended behavior?

Yes, but it is a limiting behavior that should be improved

If so, is there a way to avoid it?

You can use RessampleToImage after the reader

3

Hi @mwestphal,
I found the issue in my other post (Unpredictable behavior of paraview-lite - ParaView Support - ParaView) is actually due to this boundary missing of VDB reader.
And it cannot be solved by the RessampleToImage, since I want to apply contouring on the source.

Is there a way to modify the VDB reader directly? Thank you!

4

please share your data

5

Sure, this is a simplified example containing two grids. test.vdb (990.9 KB)

Setting up two contours that contour by each grid, the view should be like:

image
image1269×551 72.8 KB

And after checking the Merge Image Volumes on VDB reader, the contour function gets Bounds from the whole structure. So the opening surfaces are closed.

image
image1277×554 79.2 KB

I would like to know if there’s a way to make contouring use the un-shrunken bounds without merging image volume. Thank you!

6

I’m not sure to follow, what do you mean by “un-shrunken bounds” ?

7

In this testcase, the test1 grid has Bounds (0, 139, 0, 287, 239, 257) and test2 grid has Bounds (0, 140, 0, 288, 289, 296). However, in the vdb file, the boundary of test1 is (0,140, 0, 288, 239, 258) and that of test2 is (0, 141, 0, 289, 289, 297). Which has been confirmed an intended behavior by your previous reply.

However, I found out merge image volume helps because the Bounds of merged grid became (0, 140, 0, 288, 239, 296) and the contour function can then count on the missing surface. And hence I realize Paraview do load the data, but it shrinks the Bounds for safety purpose.

So what I mean here is: can I tell the function to consider larger Bounds to count on the missing part.

8

Which function of the contour is impacted by the bounds ?

9

My suspect is that, while doing contouring, it considers the Bounds of the contourby element. And merge image volume make it consider the Bounds of the whole structure (also shrunken, but large enough) instead of the shrunken Bounds of the grid itself.

The Bounds of the Contour1 without merge image volume:

0 to 139 (delta: 139)
0 to 287 (delta: 287)
240.286 to 256.761 (delta: 16.4751)

The Bounds of the Contour1 with merge image volume:

0 to 140 (delta: 140)
0 to 288 (delta: 288)
240.286 to 256.761 (delta: 16.4751)
10

Ok, I see it now. To me it looks like the “correct” result is the one with the smaller bounds. ParaView is just adding data on the side that causes this “closing” effect in your contour, but, in truth, it should not be closed. Closing the surface itself is more in the realms of the Vespa project @Charles_Gueunet

11

Yes, I agree the opening surface is the “correct” behavior of paraview. However, I want to point out that the structure should be closed according to the .vdb file. It is open due to the intended shrink on the boundary. It would be helpful if you can provide any clue about the following questions.

  • How to “fake” bounds to cheat contour filter?
  • Is there another contouring way that can close opening surface itself?

Appreciate a lot for your time!

12

Ressample with an image with a slightly bigger bounds.