1.9 KiB
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:
- Confirm quorum
- Secretary
- Half Grid & Grid registration
- PR 1780
- retooling IO
- Adaptive grids
- xz
- Confirm quorum
Quorum is present.
- Secretary
Secretary is Greg Hurst.
- 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
- 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.
- 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.
- Adaptive grids
We should decide if we're going to pitch to Autodesk the prototype that's put together.
Looking over PR 1760 again...
- 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.