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)