Minutes from 117th OpenVDB TSC meeting, January 18th, 2022, (EDT)

Attendees: *Ken* M., *Jeff* L., *Andre* P, *Nick* A., *Dan* B.,
*Rich* J.

Additional Attendees: Sebastian Gaida, Greg Hurst (United Therapeutics), Karl
Marett, Bruce Cherniak (Intel), JT Nelson (Blender), Sergio Rojas (Different
Dimension).

Regrets:

Agenda:

1) Confirm quorum
2) Secretary
3) Forum


--------------------

1) Confirm quorum

Quorum is present.

2) Secretary

Secretary is Jeff Lait.

3) Forum

a) Silence of TBB Warnings

Unclear why the entire header was deprecated in TBB, but this seems the correct fix.

4) VDB Doxygen

Where we should host it, and how to clean it up?  Currently with Dan.  The issue was with authentication - the OpenVDB repo can't post to the website.  Dan will continue to poke at this and report back any issues.

5) Platonic Solid

Forum asked how to generate cone.  Perhaps implement more platonic solids?  NanoVDB has a ton already.  These should be ported to OpenVDB.  Might also be a google-summer of code.  Maybe add as a first-issue?  More parameterizations for these generators, like rotations?   The box is currently explicit - ideally this would be implicit.

nanovdb/util.Primitives.h has the NanoVDB code.

Can AX be used?  Need to find footprint, which can be done if it is a true SDF.

We note that first issues are not very well advertised.  We could add more explicit links in documentation.  Or Pin on the top like we did with Python bindings.

6) Google Code

We have submitted Andre's list.

7) JIRA

We aren't using anymore.  Should we shut it down and move anything over that needs to?  Let's at least not create anymore content on it.  Move stuff over as needed.

Richard still has to export the more internal DNeg issues that are more general.  This would be a flood if they all were dumped onto the git hub or JIRA.  Ideally start with the bugs.

8) vdb_tool

The demo showed implicit pipelining.   This relies on isatty that is unstable, so now uses stdin.vdb and stdout.vdb.  Can now pipe geometry and possibly images, etc.

Sharing of code awaits further refactoring.

Should vdb_ax be unified with vdb_tool?  Or at least in terms of arguments?  Having an AX tool inside of vdb_tool would require more dependencies.  But vdb_tool already manages dependencies, so ax could be a plugin to vdb_tool?

Most of vdb_ax's other options are utilities: outputting help or AST.  Basic behaviour is grids + code string to outputs.

As a discussion, we note the glue between parameters can be what makes networks hard to convert to scripts like this.

Would be best if we can have a single tool to point people to with a single way of specifying parameters and inputs/outputs.  Analysis, compilation, can live as separate tools.  Questions of how to bind, etc, should be part of the vdb tool parameter set.

9) VFX Platform Survey

Linux is still predominant and people are staying on that.

10) Roadmap

Will be sent around so we can go over it next meeting.

11) Why are studios still behind in VDB?

Should we backport fixes to old versions?  This was triggered from a request to backport the half-separation.

In the past building was very complicated.  And if you had it working, CMake will have changed it.  A problem is the artists don't realize the benefit of upgrading so don't push it.

12) Next meeting

Next meeting is in one week, January 25th, 2022. 1pm-2pm EST (GMT-5). 

Plan is to start with the roadmap.

