Add TSC meeting notes from 2021-06-15.

Signed-off-by: Andre Pradhana <[email protected]>

Author: apradhana

tsc/meetings/2021-06-15.md

@@ -0,0 +1,193 @@
+Minutes from 95th OpenVDB TSC meeting, June 15th, 2021, (EDT)
+
+Attendees: *Ken* M., *Jeff* L., *Dan* B., *Andre* P.
+
+Regrets: *Nick* A.
+
+Additional Attendees: JT Nelson (Blender), Richard Jones (DNeg),
+Johannes Meng (Intel), Sergio Rojas, Bruce Cherniak (Intel),
+Chris Flesher
+
+Regrets: None
+
+Agenda:
+
+1) Confirm Quorum
+2) Secretary
+3) Forum 
+4) Open Source Day 
+5) 8.1.0 Release
+6) NanoVDB
+7) Multiple Tickets
+8) TSC Membership
+9) Python Binding
+10) Fast Sweeping
+11) Next meeting
+
+
+1) Confirm Quorum
+
+Quorum is present.
+
+2) Secretary
+
+Secretary is Andre Pradhana.
+
+3) Forum 
+
+Dan mentions that at a future meeting, we should discuss what we should do
+with the forum and the github discussion page. The latter is readily available
+in the OpenVDB Website github repository.
+
+There is a question about doing csgDifference where the second argument is
+an implicit function. Dan provides an answer to the question where he suggests
+to use tools::visitNodeDepthFirst() or to use the dynamic node manager. Dan
+also points out one example of an implicit function, which is an EnrightField,
+primarily used for debugging.
+
+This question is related to the support for implicit function, especially
+in the case of doing CSG-type operation with an implicit function. 
+The challenge is how to introduce a scripting language that allows you
+to represent an analytic function/ closed form expression that can be
+combined with an explicit grid. Ken asks whether AX provides the proper
+solution for the purpose of for implicit function support in OpenVDB or
+if there is a light-weight solution that can be added to the core library. 
+
+Jeff thinks that OpenVDB should stick with being an explicit grid library.
+Dan thinks that it can be valuable to have something that samples from
+a closed form expression. Jeff thinks that the proper way to address this
+is through an AX kernel. Ken argues that OpenVDB has support for meshes
+because you can generate an explicit SDF grid from that. Jeff says that
+AX is the ultimate generator for such things. Ken agrees that AX is
+probably the natural place to put this. He also mentions that
+Rhythm and Hues used to have a scripting language that supports this idea.
+Dan mentions that ILM has Zeno technology field that is also very useful.
+Ken thinks that if there is a light-weight way to add such thing to the
+core library, it will be very useful.
+
+Dan mentions that we cannot put a grid type in AX that is not listed in
+the core-library.
+
+In conclusion, we should table the discussion and revisit it at a later time.
+
+4) Open Source Day
+
+Open Source day hosted by ASWF will take place between Wednesday, August 4th
+to Thursday, August 5th 2021. Ken confirmed that OpenVDB will participate.
+The program is 1 hour, including Q+A. But by June 23rd, Ken needs to submit a
+form outlining the intent/program and the speakers.
+
+OpenVDB presentation at SIGGRAPH will be available at the beginning of August
+or the end of July. The course video will only be available for SIGGRAPH
+attendees and OpenVDB has signed over the rights for it over to ACM SIGGRAPH,
+so we may not be able to put the video in the OpenVDB website. However, there
+is a chance that it will be available to be accessed through the ACM Digital
+Library.
+
+Ken thinks that we can discuss it next Tuesday. He proposes if we take the
+discussion on the email thread. We should talk about the things that is not
+included in the course, which may include the road map and also fo ask
+OpenVDB users/clients for what they would like to see from the project.
+We should also mention about our intent to accept contribution for
+OpenVDB Python binding that is based on PyBind11. See Python Binding
+(Section 9) discussion below.
+
+JT mentions that he finds that OpenVDB is very useful in his line of work
+and expresses intention to keep helping with video production related
+to OpenVDB.
+
+5) 8.1.0 Release
+
+Ken says that he followed the guideline for releasing a new version of OpenVDB.
+However, he encounters a conflict during the release. We need to add a sentence
+on how to resolve conflicts if they arise during the release process.
+
+Dan says that the state of the release is good. We need announcement of the
+release.  Merging the release branch into master is required to keep everything
+in-sync.
+
+6) NanoVDB
+
+Ken says that there is a user who branches off an old version of NanoVDB. Ken
+will fix the issue and will merge in some new changes. Jeff says that it has
+been branched off an old version, so it hasn't been kept up-to-date with head
+
+Ken says that there is fixed-bit-rate compression and variable-bit-rate
+compression. He is able to make variable-bit-rate compression to be branchless
+to make it faster.
+
+7) Multiple Tickets
+
+Rich asks for a way to keep track of tickets, ideas, and development process
+as Nick A. moves from DNEG. Rich and Nick will continue to work on OpenVDB
+AX and they would like to be able to have a process to collaborate.
+
+Ken mentions the need to triage the tickets/tasks/issues as they come in.
+Dan mentions that the OpenVDB JIRA will no longer be used. He proposes to use
+the Github Issue section. Currently, the Github Issue section includes
+discussion, questions, bug reports, etc. Dan thinks that we should switch on
+Github Discussion tab and Github Issue will contain tasks that we want to
+do. Dan thinks that the Forum should no longer be used and should be moved
+to Github Discussion. By triage, Ken means to properly tag them properly
+and to create corresponding Github issues for the ones we will work on.
+
+Ken asks Rich about the nature of the tickets that he wants to migrate
+over. Rich says they vary from old issues, simple API improvements, and
+bugs. Jeff thinks that Github Issue is the right place to put them.
+
+Ken asks if there is a way for us to tag a discussion with labels such as
+core, houdini, maya, AX, etc. Dan says it is doable. 
+
+Dan also thinks that Github Issue is the right place to put them in.
+Dan will send an email summarizing what we talk about during the meeting to
+loop Nick. We will discuss this topic again the next time we meet.
+
+8) TSC Membership
+
+Nick leaves DNEG on Tuesday. We should discuss Rich's promotion to be part
+of TSC. Jeff mentions that the TSC position goes with the person and not
+with the company. Ken says that there is an unwritten consensus that
+one company gets one vote.
+
+9) Python Binding
+
+Somebody made a response to our discussion about Python binding for OpenVDB.
+Ken talked to Matthew Cong.
+
+Imath is the glue that binds everything together, so the Python binding for
+OpenVDB at ILM is relying heavily on IMath. IMath is currently the glue that
+keeps everything together, e.g. between UT_Vector and OpenVDB::math vector.
+Jeff mentions that if only C++ has a standard Vec3 class. 
+
+Dan mentions that we made the decision that PyBind11 will be accepted to the
+library if somebody were to do the work. We should mention this on the
+Open Source day.
+
+10) Fast Sweeping
+
+Andre has a PR-1106, which adds support for extending a field in one direction,
+i.e. when the corresponding SDF/Fog value is above or below a given iso-value,
+as well as dilation.
+
+Andre says that he will look at the FastSweeping unit test in debug mode that
+is currently running very slow. Andre will also add support for extending
+SDF into a mask if the mask grid does not have the same transform as the
+SDF grid. Ken thinks that doing trilinear interpolation inside the FastSweeping
+algorithm can slow down the code, so perhaps the right way to go about it
+is to re-sample the mask grid at the SOP level. Jeff thinks that there are cases,
+e.g. when we upres a really light-weight mask field against an SDF grid that is
+really dense. Andre will investigate this. 
+
+10) Baking Minor Version to The ABI
+
+Jeff brought up the fact that we bake the ABI minor version into the namespace.
+He asks if the minor version should be part of the namespace because the intent
+is that you should be able to mix-and-match anything that matches the major
+version. Patch number is not part of the namespace.
+
+Dan wonders if Peter Cucka has a reason for why he does it this way. We should
+think of repercussions of stripping it.
+
+11) Next meeting
+
+Next meeting is June 22nd, 2021. 12pm-1pm EST (GMT-5).