Files
UnrealEngine/Engine/Source/ThirdParty/OpenVDB/openvdb-12.0.0/tsc/meetings/2023-09-05.md
2025-05-18 13:04:45 +08:00

3.3 KiB

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.

  1. Secretary

Secretary is Greg Hurst.

  1. 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.

  1. 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?

  1. V10.1

Ellipsoid stuff still being worked on

Just push out what we have now

  1. 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