Merge pull request #1791 from ghurstunither/Various_tsc_meeting_notes…

…_2023_2024

Various TSC meeting notes

tsc/meetings/2023-01-24.md

@@ -0,0 +1,125 @@
+Minutes from OpenVDB TSC meeting, January 24, 2023
+
+Attendees: *Jeff* L., *Andre* P, *Dan* B., *Ken* M., *Nick* A., *Greg* H.
+
+Additional Attendees: JT Nelson (Blender)
+
+Regrets: *Rich* J.
+
+Agenda:
+
+1) Confirm quorum
+2) Secretary
+3) Broken Houdini download link
+4) Open PR's
+5) Fracture CSG tools
+6) Active states
+7) Sharpening filter
+
+
+------------
+
+1) Confirm quorum
+
+Quorum is present.
+
+2) Secretary
+
+Secretary is Greg Hurst.
+
+3) Broken Houdini download link
+
+Houdini download link is broken at openvdb.org downloads page. Happened during git lfs switch. Need to upload regularly using git.
+
+File not updated often, so it's ok to not use git lfs and just use regular git commit.
+
+Maybe the URL needs to change in the html source when using git lfs?
+
+4) Open PR's
+
+Python bindings (1515)
+* Ken will try to look at the PR tomorrow
+* Recreate the PR to remedy the CLA issues and credit the original author
+* Or squash everything and go as if everything is just one commit
+
+Switch to using the static asserts (1522)
+* Why do we have a special wrapper for the static assert? 
+* NANOVDB_ASSERT instead of the static_assert
+* Soon nanovdb will require C++17 (waiting on pnanovdb)
+* Ideally we'd have #ifdef platform instead of #if 1, so keep skeleton code present through #if 0
+* Ken will approve and merge
+
+Prefer fixed-width integer types instead of size_t (1528)
+* Awaiting another approval -- Dan will approve
+
+Add missing separate_arguments cmake call (1534)
+* Needs another look -- not entirely clear why this was added
+* Splits list of arguments in case they're separated by non-standard delimiters
+* Perhaps re-ask OP what failed / why make this PR
+
+Support for IlmBase versions < 3.1 is deprecated and will be removed (1529)
+* vdbtool stuff
+* This PR looks to remove support for old version
+
+Remove the explicit default assignment operator (1530)
+* Remove explicit default assignment operator in nanovdb
+* Once something is given a default, you need to set default for other things too
+* More defaults need to be removed in the same file before approval
+
+Consolidated ValueAccessor implementations (1547)
+* Perhaps someone can build and see if everything still works, test against Houdini, etc.
+* Implementation related questions added to the PR by Dan
+* The override specifiers might be redundant
+* Need to add missing isCached in code base in similar piece of code.
+
+Fix Segfault in Projection Mode of VDB Advect Points SOP (1559)
+* Just awaiting approval from Jeff
+
+Fix all the int-in-bool-context warnings with GCC9 (1563)
+* Switch to use constexpr
+* Still need macros to guard type conversions? (Node type conversion warning, just relevant to float portion now)
+* LOD removed for bool grids
+
+5) Fracture CSG tools
+
+https://github.com/AcademySoftwareFoundation/openvdb/issues/1566
+
+Seemless free cuts -- how can you do this with OpenVDB? Can do it in Houdini though since it has robust mesh support.
+
+Really need this to make your split-frame free of artifacts and for water-tight union.
+
+Our current choice is to not support robust mesh computation. Currently OpenVDB just has polygon soup. Mainly used for translation purposes. Robust support could lead us down a rabbit hole.
+
+By templating our meshes, it's probably not clear that if you wrote your own accelerated structure, what methods you need.
+
+Houdini seems to use everything in OpenVDB here, and so we could return polygon soup and edge data list (MeshToVoxelEdgeData) and the user can do it. The SOP can be a reference.
+
+Point OP to this SOP / OpenVDB methods.
+
+6) Active / Inactive States
+
+What should the default behavior be and how to expose different functionalities.
+
+Default behavior proposed: Max of values and if either is active make result active.
+
+Currently the activeness of states is not being brought over.
+
+Not more efficient to make 2 passes when combining multiple grids. Loses cache coherency.
+2 passes node-wise will be more efficient than 2 passes tree-wise.
+
+Do we want the ability to handle active states differently? 
+Maybe we have a use to ignore when any grid has an inactive value. 
+
+max( (0.0, inactive), (-1.0, active) ) --> (0.0, active) or (0.0, inactive)?
+
+What does it mean for a fog volume node to be active? Tags (GRID_LEVEL_SET, etc in enum GridClass) give implicit meaning to active states / values
+Majority of tools don't seem to normalize fogs to lie between 0 and 1. Difficult to maintain this discipline.
+
+Make sure to make whatever choices extendable. Tricky part is coming up with different patterns. 
+Selection merge and reduction merge, etc.
+
+7) Sharpening filter
+
+Switch away from boost dependencies & add unit tests.
+
+Seems like updated PR could be around the corner.

tsc/meetings/2023-05-02.md

@@ -0,0 +1,89 @@
+Minutes from OpenVDB TSC meeting, May 02, 2023
+
+Attendees: *Jeff* L., *Andre* P, *Ken* M., *Greg* H., *Dan* B.
+
+Additional Attendees: 
+
+Regrets: *Rich* J., *Nick* A.
+
+Agenda:
+
+1) Confirm quorum
+2) Secretary
+3) SIGGRAPH 2023
+4) Website broken link
+5) Root node offset
+6) I/O revamp
+
+------------
+
+
+1) Confirm quorum
+
+Quorum is present.
+
+
+2) Secretary
+
+Secretary is Greg Hurst.
+
+
+3) SIGGRAPH 2023
+
+Course accepted with good feedback from reviewers.
+Must sign over copyrights for anything in the presentation. Need to do this now.
+Course material must be submitted by June 5. Option to revise slides by August 11.
+
+For ASWF: tentatively do Bird of a Feather and advertise SIGGRAPH course.
+
+
+4) Website broken link
+
+PR for broken Houdini link to be merged.
+https://github.com/AcademySoftwareFoundation/openvdb-website/pull/71
+
+Fixed link:
+https://www.openvdb.org/download/files/houdini_examples.hip-1.0.1.zip
+
+
+5) Root node offset
+
+Root node dense, all other nodes are dense. Root essentially hash table.
+
+Since root is sparse, root access is slower. Tend to avoid touching the root node. e.g. value accessors.
+
+Root is centered at origin (0, 0, 0), and so a small sphere centered at the origin makes 8 children.
+
+The offset mitigates this issue. 
+
+Root node now has mOrigin member, just like all other nodes (added in v10)
+
+Currently mOrigin is hard coded to origin still and even has checks to throw errors if not.
+
+First pass tried to hard code half offset (-2048, -2048, -2048) but saw no measurable speedup.
+
+Can we make mOrigin anything? If so looks like we will have massive overhead -- merging trees, etc will need to rebuild tree structure.
+
+If you guarantee that the root node is aligned with grandchild of other root
+e.g. If mOrigin is a multiple of 128, then only misaligned is child nodes of the root.
+And so during these operations, only root node needs to be rebuilt.
+It _can_ generalize to arbitrary fan factors but need different number from 128.
+2 level tree is a special case, but n (>= 3) follows above logic.
+
+What is the impact on the existing code? CSG, Combinations, etc.
+Merging 2 grids with incommensurate origins is tricky if const operators... duplicate data etc.
+
+How to maintain backward compatibility for I/O if we just hardcode (-2048, -2048, -2048)?
+And (it seems) that's the only backward compatibility to suss out.
+Export will need to recenter to (0, 0, 0)?
+I/O needs to be refactored anyway...
+Hardcoded global offset means we don't need to explicitly export it
+
+Ken will investigate and do deep dive
+
+
+6) I/O revamp
+
+Would be good to investigate into I/O revamp. 
+Come up with a list of modern requirements. 
+Refer to this list in future development efforts.

tsc/meetings/2023-09-05.md

@@ -0,0 +1,129 @@
+Minutes from OpenVDB TSC meeting, September 5, 2023
+
+Attendees: *Jeff* L., *Rich* J., *Ken* M., *Greg* H., *Dan* B., *Andre* P.
+
+Additional Attendees: 
+
+Regrets: *Nick* A.
+
+Agenda:
+
+1) Confirm quorum
+2) Secretary
+3) VTT
+4) VDB Maya
+5) V10.1
+6) PRs
+
+------------
+
+
+1) Confirm quorum
+
+Quorum is present.
+
+
+2) Secretary
+
+Secretary is Greg Hurst.
+
+
+3) VTT
+
+Autodesk has a product call Bifrost (sim framework)
+
+Internal multires grid
+
+NanoVTT github repo expires in September... but it's a fork of OpenVDB?
+
+Bifrost group seems gunghoe about open sourcing it
+
+Why open source it?
+Integration of nanovtt into OpenVDB will be intricate.
+Attend meetings, contribute to the CI is a good start, but will be much more complicating. What's the balance?
+
+Sampling across tiles is tricky and they have the method they want to use -- could be advantageous to open source as a standard
+
+Why should this be part of OpenVDB and not its own product? Best not to have competing formats
+But how can the two coexist in a meaningful way? Can't just have two independent things
+
+OpenVDB has threadpools, math functions, metadata, transforms, etc. And a standard API. VTT could integrate into these.
+
+VDB's are sparse (active / inactive, etc)
+VTT's is in some sense dense, but adaptive
+Complementary data structures
+
+This is an opportunity to rip out delayed loading for vdb
+We can have a family of grids that perform and specialize in different use cases
+When we write tools, what grids should & could these tools support?
+
+Could this be confusing to general users?
+Is VTT too similar sounding to VDB
+
+We will need support from them integrating properly
+We need commitment to delivering everything, not just nanovtt
+
+Another need is conversion between vdb and vtt, something that's missing at the moment
+
+Can we iterate of vtt grids in similar fashions (API-wise at least) to DynamicNodeManager?
+
+If they first just give us NanoVTT, then they write a converter, is that even a meaningful thing?
+OpenVDB grid does not contain adaptive information, but possible ways one might want to convert
+
+How does VTT compare to a stack of VDBs?
+
+Did VTT mention point support at all? Points to volume mentioned in their ppt
+
+Mathematica link to vtt? Probably, yes
+
+**********
+
+we agree we don't want just NanoVTT
+C++ structure for non-NanoVTT should have:
+  VTT needs a sampler
+  way to save and load from disk
+  NodeManager-esque interfaces
+  Converters
+  Random access
+
+**********
+
+Worth asking them about feasibility of above and what they have in the bifrost SDK
+
+Let's organize all of this in a Google doc to establish minimally required features.
+
+What version would this go into?
+This will change ABI? and so V12 integration?
+
+Probably would inherit GridBase without a Tree pointer.
+
+
+4) VDB Maya
+
+What happens to VDB Maya now?
+
+Probably broken at this point... 
+
+Should we just move it to its own repo and retire it from OpenVDB repo?
+
+It's a useful reference and useful starting point.
+
+Who own's the separate repo, etc...
+
+What about deleting from git repo but keep folder with a text file saying to go to a branch to find it?
+
+
+5) V10.1
+
+Ellipsoid stuff still being worked on
+
+Just push out what we have now
+
+
+6) PR
+
+PR 1651 suffering from TBB build errors: 
+  https://github.com/oneapi-src/oneTBB/issues/301
+  Bumping up to TBB 2021.2 will probably fix this
+PR 1655 needs a look
+PR 1666 on fast sweeping needs to be refactored