Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sharing an initial Adaptive Grid prototype. In this case, it's not even a dense grid, it just contains a single background value and I've done the minimal work to make this compile with most of the required methods set to throw a not implemented error currently. No IO implemented. Some brief notes:
I'm using an
adaptive::
namespace, this sits within anopenvdb/adaptive
sub-directory and I'm calling thisAdaptiveTree
. It derives fromTreeBase
as we discussed and this is nested within aGrid
as well and aliased toAdaptiveGrid
.I've introduced a new
AllGridTypes
alias that addsAdaptiveGridTypes
toSparseGridTypes
. Adaptive Grids are registered, but existing methods that callgrid.apply<GridTypes>()
will not apply to new Adaptive Grids and will have to be intentionally extended if that is the desired behavior.I introduced a new
TreeTraits
class to determine whether grids are adaptive or sparse and added a specialization to the relevant template classes. The main goal here was to not need to add new virtual methods or static member variables to the Tree class (or any other derived classes there might be in the wild). I've added logic to the interpolation routines to handle sparse vs adaptive trees, which can then be used in thePointAdvect
class without further changes.This should be sufficient to get some conversation going as to how this kind of thing could work. It might make sense to consider using an
impl
sub-directory as we have done elsewhere, but where should the implementation for sparse trees and adaptive trees live? Should we just include both implementations in the body of this function as I've done here? Should we add a new sparse sub-directory and put the original implementation of this method there and then put the adaptive one in the adaptive sub-directory? How would this work for some of the much larger, more complicated methods? What about if we added more logic for handling dense trees? How is this going to work with explicit template instantiation?