3.4 KiB
Minutes from 119th OpenVDB TSC meeting, February 2nd, 2022, (EDT)
Attendees: Ken M., Jeff L., Andre P., Nick A., Dan B., Rich J.
Additional Attendees: JT Nelson (Blender), Bruce Cherniak (Intel), Sebastian Gaida, Greg Hurst(United Therapeutics), Karl Marett, Sergio Rojas
Agenda:
- Confirm Quorum
- Secretary
- Forum
- Github Issues/PRs
- Rasterize PR 1008 & tool separation in library
- Doxygen hosting
- CI
- Next meeting
- Confirm Quorum
Quorum is present.
- Secretary
Secretary is Richard Jones.
- Forum
Question regarding point merging ongoing. User has tested versions from Dan and Nick and found some issues regarding performance with the former. Investigation ongoing. Question regarding generating triangle meshes from nanoVDB. Ken to look into this.
- Github Issues/PRs
PR No. 1297 & No. 1279 should be fine to go in.
PR No. 1300 about relative includes needs looking at.
Ken looking at PR No. 1282 about addLeaf and addTile for non-standard tree dimensions, also hit by Greg (e.g. meshToVolume not working for trees depth 5).
- Rasterize PR 1008 & tool separation in library
Some discussion of the specifics of the Rasterization PR No. 1008 and wider discussion of having multiple similar tools in the library if they are better for different scenarios. Consensus is if we wish to have most optimal methods for different scenarios this is probably inevitable but consideration should be made to the user API. Jeff states that there are many tools that are similar to one another in Houdini but this allows users to use best tool for the job, so a similar approach in VDB would be fine. If possible top level user API would be able to choose best method under the hood. Most likely first step is to document different use cases and why each implementation might be used, should consider a place for this kind of freestanding developer documentation.
Dan suggests to accept the PR (after renaming RasterizeSDF to Surfacer) and work out combination with his own rasterization tools before next version release. Nick has SOP to demonstrate functionality but wasn't planning to include until we have made decisions on final SOP possibly including other rasterization methods. Committee suggest having a 'Labs' prefix or some other dev options (possibly with a CMake flag) to allow developers to opt-in to building these SOPs whilst they are WIP.
General suggestion to improve cookbooks with more functionality to document different frameworks such as these. NanoVDB has code examples which are tested - means they must be kept up to date which is good.
Further suggestions to reorganise library to make these kind of frameworks easier to use. Suggestions for catch all headers with the API functions for a specific functionality, say rasterization, and separate implementation files. Could take this further and separate tools and core library, or add further namespaces etc. Separation has been previously looked at but new CMake build system may make this easier. Could do these kind of major changes for a v10 release. Nick will try to make some progress towards this with rasterize PR.
- Doxygen hosting
Dan to look at it soon, need to figure out where we are hosting it.
- CI
JT has posted on Slack about OTIO and their use of CI that may be of interest to the committee.
- Next meeting
Next meeting is in one week, February 8th, 2022. 1pm-2pm EST (GMT-5).