3.4 KiB
Minutes from 105th OpenVDB TSC meeting, September 14th, 2021, (EDT)
Attendees: Ken M., Jeff L., Andre P, Nick A., Dan B.
Additional Attendees: JT Nelson (Blender), Richard Jones (DNeg), Sergio Rojas
Regrets:
Agenda:
-
Confirm Quorum
-
Secretary
-
Google Forum
-
Version 9
-
VDB Extrapolate
-
Next Meeting
-
Confirm Quorum
Quorum is present.
- Secretary
Secretary is Jeff Lait.
- Google Forum
No major issues.
- Version 9
a) OpenEXR. Must have
Support for 3.1 openexr. Do we use OpenEXR 3? Or remove OpenEXR support? Do we keep half standalone? Is it compatible for OpenEXR 3 half? 3's half is header only so maybe a light inclusion?
Half should be an actual type. Grids based on half would imply we should have a self-contained type.
Should we support OpenEXR 2 and 3 for the saving of the files?
Do we want to support the OpenEXR 3.1 half or just the render?
We should have #define for vdb render to remove EXR. It would be nice if it used exr 3, but if it is optional and off by default we don't care.
Do we have our built-in half support 2 and 3? Can we replace our half with EXR 3's half.
No support for removing the embedded half.
If we we do the #define in vdb_render and have it off by default we will comply with the VFX platform. We've agreed to do this as the essential step.
i) #define of vdb_render ii) Updating internal half with latest from EXR3 iii) Support for EXR3 external half
These are all independent. Also, our current use of half is internal - it is effectively a compression codec.
Our plan: Drop support in vdb_render by default. Work on Cary's pull request. Update our internal half at our leisure.
b) Nano VDB. Nice to have. PR 1139
Some updates are coming in. Plan is to nuke the old make. Being able to build nano from the root of openvdb. Currently stuck on the latter. Not a blocker, but is weird. The lack of CI is the blocker. Currently uses Circle and should migrate to Github Actions.
nanovdb/cmake has similar files to openvdb/cmake, this should be unified somehow. Doing this before the first release is important.
Documentation publishing also needs infrastructure work to match OpenVDB. Comment on the PR should be clear.
The intent is for AX and NanoVDB to build similarly. AX only differs in that it requires OpenVDB.
i) CI. Has to transfer from Circle -> github.
This is a blocker.
Required. Gtest based so should be easy to integrate.
Missing test for some configuration, like not TBB.
We are currently not testing GPU builds, need a nvidia build.
Some of the missing platforms we will drop if necessary.
ii) Share cmake files
Not a blocker.
iii) Build from root
Minor to do, but a blocker.
iv) Docker issues.
What are these? CI related.
This is a blocker. Likely to be removed.
v) Nest nanovdb
This is a blocker.
c) Template instantiation.
Out of time to discuss.
Still aimed for 9. Focus will be on tools, not the tree nodes, as we likely get biggest win this way.
d) Offset Root. Must/Nice?
IO code has to change. Plan is to not change format on disk. Delayed loading is not effected to our knowledge. Changes should be done in OpenVDB. Ken will make a branch PR for this.
e) Blind Data. Pending.
Awaiting Ken's approval for the 64 -> 32 bit fix.
- VDB Extrapolate. PR 1106
The slow down due to supporting one-sided is acceptable.
- Next meeting
Next meeting is September 28th, 2021. 12pm-1pm EST (GMT-5). This is in two weeks.