Merge pull request #1303 from danrbailey/tsc_2501

Add meeting notes 25th Jan

Author: danrbailey

tsc/meetings/2022-01-25.md

@@ -0,0 +1,97 @@
+Minutes from 118th OpenVDB TSC meeting, January 25th, 2022, (EDT)
+
+Attendees: *Ken* M., *Jeff* L., *Andre* P, *Nick* A., *Dan* B.,
+*Rich* J.
+
+Additional Attendees: Sebastian Gaida, Greg Hurst (United Therapeutics), Bruce Cherniak (Intel),
+JT Nelson (Blender), Sergio Rojas (Different Dimension).
+
+Regrets:
+
+Agenda:
+
+1) Confirm quorum
+2) Secretary
+3) Forum
+4) Level Set Propagation
+5) Half VDBs
+6) Roadmap
+7) Next meeting
+
+
+--------------------
+
+1) Confirm quorum
+
+Quorum is present.
+
+2) Secretary
+
+Secretary is Dan Bailey.
+
+3) Forum
+
+Discussion on Google groups about deep merging point trees. Author of the post
+shared some interesting context about their application and provided some
+feedback and details about the type of datasets that were tried. Dan to
+investigate performance regarding his merging implementation. Nick thinks we
+should consider accepting his deep merge implementation.
+
+Issue 1287 - we should investigate if the proposed solution is worth
+implementing.
+
+PR 1282 - Ken to try this suggested change out and reply with his feedback. Greg
+mentioned that he ran into the same issue recently and will help review.
+
+Discussion 1286 - Question about distributing a compiled Python module. Someone
+should reply to this, but we don't have time or knowledge to look into doing
+this right now.
+
+4) Level Set Propagation
+
+Ken has a new tool to do level set propagation, will share shortly.
+
+5) Half VDBs
+
+Greg has been looking at adding half grids as a native runtime type. Various
+changes required, some more hacky as proof of concept, but it is working. Some
+discussion around what precision to do computation at, whether to promote to
+double for example and then lower to half for in-memory storage. Computing
+natively at half is slower. API and tools are not very consistent about this,
+but this is more forgiving with float and double than with half, so this issue
+will need to be resolved.
+
+Possibility of using a compression type. Jeff highlighted that something similar
+is done with Houdini volumes, where constant tiles can be stored with a
+compressed type different from the volume type.
+
+6) Roadmap
+
+Live discussion and updates to the roadmap, see this document:
+
+https://docs.google.com/document/d/1F1hmGnS1kIMobnfgpTJ6SYSrEPhC2B0WQAlt-idAo5w/edit?usp=sharing
+
+
+Of particular note during this discussion:
+
+6a) MultiResGrid - no major progress on this front recently, but worth
+discussing with Autodesk and making a final call on whether this is something
+we can pursue or not. 6b) PointRasterize - Nick's implementation for point
+rasterizing has languished on a PR for a while. Contention is around how to
+include multiple similar but different tools. Rasterization is a complex and
+multi-faceted problem. No reason not to add more than one similar tool, but
+general agreement that the current practice of having tools self-documented in
+header files would make this harder to navigate and more confusing. Nick
+highlighted that we should really improve our documentation and rely more on
+well-written Doxygen or Sphinx to help our users. Ken suggested that we could
+introduce new translation units which would make the header files simpler and
+easier to navigate, though this has implications for explicit template
+instantiation. Other suggestions include having a single entry header
+(PointRasterize.h) which pulled in all other implementations. Nick pointed at
+other libraries that use a detail namespace for better abstracting
+implementation detail away from the user. Dan to review Nick's PR with a view
+to merge this in shortly.
+
+7) Next meeting
+
+Next meeting is in one week, February 1st, 2022. 1pm-2pm EST (GMT-5).