Merge pull request #1758 from sideeffects/send_upstream_tscnotes_20240123

Meeting notes for Jan 23rd.

Author: jmlait

tsc/meetings/2024-01-23.md

@@ -0,0 +1,103 @@
+Minutes from OpenVDB TSC meeting, January 23rd, 2024
+
+Attendees: *Jeff* L., *Andre* P, *Dan* B., *Ken* M.,  *Nick* A.,
+*Rich* J., *Greg* H.
+
+Additional Attendees: 
+Kolton Yager (DWA)
+
+Regrets: None
+
+Agenda:
+
+1) Confirm quorum
+2) Secretary
+3) Autodesk VTT
+4) Read-Only Grids
+5) Half Grid Types
+6) Next meeting
+
+------------
+
+1) Confirm quorum
+
+Quorum is present.
+
+2) Secretary
+
+Secretary is Jeff Lait.
+
+3) Discussion of VTT Meeting.
+
+We threw ideas at them, but maybe weren't very concrete.
+
+We need to not move the goal posts on them.  Has anyone actually
+looked at how this fits in?  We seem to have increased our theoritical
+alignment, but we need to give a clear skeleton of where they should
+inject VTT.  
+
+Can it derive from TreeBase?  Or GridBaseBase?
+
+Can we provide a Dense version of TreeBase or GridBase?  And provide a
+directory to dump their tools into?  We can make a github branch they
+can work off for this.
+
+IO can save via the tree base.
+
+Name change proposal.  What would it look like?  Adaptive VDB vs
+Sparse VDB.  Much like Cartesian grids don't exist, we name the
+special one, we could have Adaptive VDB and VDB.  The C++ baseline
+doesn't have a VDB object so it could be Sparse there.  
+
+Tile is a harder word that is more deep in VTT.  Tile should be Node.  
+
+We could create a Dense VDB PR that is similar to what a Adapative VDB
+should look like.  Or we add an Adaptive tree with subdirectory.  It
+could be a dense grid, just called Adaptive.  
+
+nanovtt should be nanoavdb.  Current nanovdb probably can't be
+renamed.
+
+Dan will investigate making this PR.  
+
+4) TAC Update
+
+Presented Greg's work.  There is interest in Greg presenting for ASWF.
+
+5) Mathematica
+
+A strong desire for precompiled binaries.  How can they be hosted?
+Windows and Mac are more tractable targets.  No objection in principle
+to this, the lack of pre-compiled is probably more that packages like
+Houdiini naturally ship with them.
+
+6) vdb_view
+
+Kolton Yager presented their work in porting.
+
+vdb_view has been ported to Vulkan from GL.  Ported everything except
+clipping planes.  
+
+Other changes: dark theme, linear RGB, MSAA, better FPS, DPI scale of
+text.
+
+Same performance as GL at the end as rendering is too slow.
+
+6000 lines in addition to the existing 4000.  1000 are comments.  4000
+in separate C++ files.   200 lines of shader code.
+
+Should this be adopted?  No performance improvement.  OpenGL should
+keep working for a long time?  This may add more build issues.  Maybe the GL
+improvements could go in?
+
+There was interest in the idea of there being a Vulkan example,
+possibly as a separate tool so as to not complexify the base build.
+
+7) VDB Clip
+
+VDB clip by frustum was looking like a bug.  PR incoming for better
+documentation on this.  Some RFEs on this also incoming.
+
+8) Next meeting
+
+Next meeting is on January 30th, 2024. 2pm-3pm EST (GMT-5)