Skip to content

VDBObject : Don't bake in automatic metadata when querying metadata #1423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 19, 2025

Conversation

danieldresser-ie
Copy link
Contributor

This addresses proposal 2) from John's comment here:
GafferHQ/gaffer#5923 (comment)

I think a PR is probably the most direct way to discuss it, though I'm not entirely convinced that just merging this is necessarily correct.

I think the argument is completely sound that the previous behaviour was wrong - we were calling this function assuming it was const, and this was resulting in things getting written in the cache in a completely non-threadsafe way. This definitely seems more correct.

But just doing this results in a worse experience for users. Seeing the voxel counts and bounding box sizes in the Gaffer Scene Inspector seems quite useful.

Perhaps the Gaffer inspector should compute the bounding box and voxel counts explicitly, in addition to showing the metadata? That is pretty independent from this, but maybe we should have a plan for it before we merge this.

@danieldresser-ie
Copy link
Contributor Author

Added a fix commit so that worldBound returns correct results in the scenario that the metadata isn't set.

This kind of confirms though that finding the right approach for all this stuff may not be trivial. evalActiveVoxelBoundingBox seems potentially expensive to possibly end up calling repeatedly on the same VDB every time you need the bbox ... and it only works if the grids are fully loaded?

I do start to wonder whether there could be merit in the opposite approach ( make sure that everything that accesses the metadata goes through a wrapper that is thread safe and adds in the standard stats if they aren't present ).

johnhaddon added a commit to johnhaddon/gaffer that referenced this pull request Aug 14, 2025
This fixes `SphereLevelSetTest.testBounds` which I broke when I merged e6cbd98. That exposed a bug in `VDBObject::bound()` whereby it relied on metadata to provide the bound, when in fact the metadata is entirely optional. The VDBObject bug hasn't been a problem for any of our other VDB nodes because they compute Gaffer bounds efficiently rather than making them depend on the voxel grid. While we do have a fix for the VDBObject bug (see ImageEngine/cortex#1423), it seems worthwhile to have a more efficient implementation for SphereLevelSet anyway.
@johnhaddon
Copy link
Member

Recap on some changes since this PR was opened :

For those reasons, I propose to update this PR to go even further, and remove VDBObject::metadata() entirely. If VDBObject is the thinnest wrapper we can make it, then we have less opportunities to create the kind of bug this PR is addressing.

Any thoughts @danieldresser-ie?

johnhaddon added a commit to johnhaddon/gaffer that referenced this pull request Aug 14, 2025
This fixes `SphereLevelSetTest.testBounds` which I broke when I merged e6cbd98. That exposed a bug in `VDBObject::bound()` whereby it relied on metadata to provide the bound, when in fact the metadata is entirely optional. The VDBObject bug hasn't been a problem for any of our other VDB nodes because they compute Gaffer bounds efficiently rather than making them depend on the voxel grid. While we do have a fix for the VDBObject bug (see ImageEngine/cortex#1423), it seems worthwhile to have a more efficient implementation for SphereLevelSet anyway.
@danieldresser-ie
Copy link
Contributor Author

If Gaffer isn't using VDBObject::metadata(), then it seems like a pretty obvious win from our point of view to remove it.

I suppose the only question is whether anyone other than Gaffer is using this, but that does't seem particularly likely.

@johnhaddon
Copy link
Member

@ivanimanishi, any objections to removing the VDBObject::metadata() method?

@ivanimanishi
Copy link
Member

We do have an IERendering node (VolumeMetadataToAttributes) that uses that method (IECore::ConstCompoundObjectPtr metadata = const_cast<IECoreVDB::VDBObject *>( vdbObject )->metadata( gridName );), and that is in active use.

I could find it in a single box though (which is itself used extensively in production), so if there are alternative approaches to address the production needs, it might not be too hard to update things.

So, on initial inspection, we do need to keep the metadata() method.

If there is an easy alternative in c++ to access the same data skipping cortex (maybe by accessing VDB's api directly?) to replace that line I linked above, we could update VolumeMetadataToAttributes to use it.

Or, if you want to understand how it's being used in production to see if there is a better approach they can use, reach out to Martin Bohn, as he's the author of said Box that uses VolumeMetadataToAttributes.

An final extra piece of info that might be useful to you, as far as I can tell, the properties from the metadata currently being queried are: file_voxel_count, maximum, file_bbox_max and file_bbox_min.

@johnhaddon
Copy link
Member

If there is an easy alternative in c++ to access the same data skipping cortex (maybe by accessing VDB's api directly?) to replace that line I linked above, we could update VolumeMetadataToAttributes to use it.

We're using the VDB API directly in Gaffer, and it's pretty straightforward :

https://github.com/GafferHQ/gaffer/blob/main/src/GafferVDBUIModule/GafferVDBUIModule.cpp#L88-L150

If you think you can switch over too then let us know, but if you have enough on your plate already then we can keep that method around for a bit longer...

@ivanimanishi
Copy link
Member

Let's keep it around for a bit longer, since we already have to deal with a quite a few other breaking changes.

@danieldresser-ie
Copy link
Contributor Author

Updated this PR to keep the worldBound fix, but not change metadata() other than adding a deprecation warning. I'm fairly hopeful that the place where ImageEngine is relying on metadata() can be removed completely in the long term, but it makes sense for now to not change something that isn't broken.

@johnhaddon johnhaddon merged commit 68ec51e into ImageEngine:RB-10.5 Aug 19, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants