Minutes from OpenVDB TSC meeting, April 06, 2024

Attendees: *Jeff* L., *Andre* P, *Ken* M., *Greg* H., *Dan* B.,

Additional Attendees: Nishith Singhai

Regrets:

Agenda:

1) Confirm quorum
2) Secretary
3) Half Grid & Grid registration
4) PR 1780
5) retooling IO
6) Adaptive grids
7) xz

------------


1) Confirm quorum

Quorum is present.


2) Secretary

Secretary is Greg Hurst.


3) Half Grid

Andre will merge his work into master first
ghurst will then retool his branch too
Autodesk is working from Andre's branch too for half IO conversions

We should add Vec3HGrid

Other Vec2XXX grids, we might not want to register in the openvdb repo

We should be willing to add IO but not instantiation by default


4) PR 1780

Ivo presented 2 weeks ago

Question:
Is it worth to expose convert to half grid only first?
A lot of improvements could be made to IO in general, so it might make sense to start retooling here with a leaner implementation.

Answers:
But it's already 'done' and could influence how we want to retool the IO...
It is also much more efficient to do a JIT conversion during import.


5) retooling IO

Need to do some benchmarking to determine if it's worth retooling IO

Is there a way to merge vdb and nvdb into one file format?

What about adaptive, dense, etc.

No multipassing (multiple traversals of the tree to export), and so you work against that. i.e. you must write topology then data.

It's because the writers are on the tree because the methods need to be virtual. And so you can just write out certain internal nodes, etc.


6) Adaptive grids

We should decide if we're going to pitch to Autodesk the prototype that's put together.

Looking over PR 1760 again...


7) xz

SSH vulnerability since xz is compromised

Consequences for OpenVDB?

Treat external vdbs as suspect, and therefore we 'round-trip' import/export vdb or recreate the vdb ourselves? So binary vdbs being read for bug submissions / unit-tests.