3.8 KiB
Minutes from 148th OpenVDB TSC meeting, September 27th, 2022
Attendees: Jeff L., Andre P, Nick A., Dan B., Rich J., Ken M.
Additional Attendees: Karl Marett, Bruce Cherniak (Intel), Michael Shenck, Tomas Krivan (SideFX), JT Nelson (Blender), Sebastian Gaida
Regrets: none
Agenda:
- Confirm quorum
- Secretary
- Forum
- NanoVDB Questions
- VDB from Polygons
- Scaling SDF in Houdini
- MAX FLT from extrapolate.
- Move meeting time one hour later
- vdb_tool changes
- Root Offset PR
- Accessor changes
- Next meeting
- Confirm quorum
Quorum is present.
- Secretary
Secretary is Jeff Lait
- Forum
No issues
- NanoVDB Questions
Michael has been trying to get NanoVDB to work with GLSL. Can read hard coded offsets but not anything with coordinate index.
This is PNanoVDB. This is supposed to work. Ken will put Michael in touch with the author. This might be a GLSL-only issue as GLSL was added after HLSL.
Sebastian confirms HLSL still works.
- VDB from Polygons
Hollow mesh can't convert to SDF because inside gets filled. We could provide an oracle that tells you the sign of the SDF. Currently done as flood fill from outside. When redistancing you can use the old SDF to tell the sign.
Three options:
a) If redistancing can just ask the old sdfs value.
b) Use an oracle like winding numbers, query once each
tile and flood fill in the tile. Or, for each voxel, track the sign
being fixed, and flood fill from there.
c) We could rasterize signed distance instead?
One mode is to build unsigned and flood from the outside. Another is to trust the surface and use normals. And the other is to use an oracle.
The current method has some smoothing built into it. This stops it being 1:1, so we will want a mode to disable that.
Can we trust the oracle, or is the flood fill per tile? What of non-determinism with inconsistent oracle?
Could we post-run a sign check?
We agreed if the provided oracle is inconsistent we can call that malformed, and thus be indeterminant. But if there is anyway to avoid that we should.
- Scaling SDF in Houdini
Should the values scale when you transform the vdb?
If it has the meta data this sounds good, but likely reveals inconsistancies in the internal tools.
An option should be added to the sop to transform.
What about negative scale? Should this invert the SDF? Negative scales should be ignored. Negative outside is not a valid VDB. This is opposite to how polygons work. A separate discussion is whether to allow negative SDFs to be defined by VDB, but this has a lot of far reaching implications.
- MAX FLT from extrapolate.
Isolated bits of that don't extrapolate are left with MAX that then is tracked as the new background. Should be ignored in sweep and then corrected with real background value.
Jeff will send Andre and example file.
- Move meeting time one hour later
Currently 10am PST, will become 11am. Likewise 1pm to 2pm for EST. (as usual, this tracks daylight savings in North America)
Unanimous vote. We have to now change the invite. Ken will try and get the time changed.
- vdb_tool changes
Andre has made many comments, awaiting Ken's comments.
- Root Offset PR
Original test was simplified. Everything is working now, but the offset modification method isn't as fast as it used to be. Had forgotten about inactive tiles. After a final benchmark it will be submitted.
Original PR is just to have the offset. Modifying the offset is a method on the tree. Should it be a dynamic node manager?
Ken will make the PR public after this call.
- Accessor changes
PR 1452 - improvement for accessors.
Ken also has an accessor improvement for caching tiles.
- Next meeting
Next meeting is on October 4th, 2022. 2pm-3pm EDT (GMT-4).
NOTE: This is one hour later.