- Notifications
You must be signed in to change notification settings - Fork718
Initial Adaptive Grid prototype#1760
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
81f9b7e toe32a221CompareSigned-off-by: Dan Bailey <danbailey@ilm.com>
Signed-off-by: Dan Bailey <danbailey@ilm.com>
Signed-off-by: Dan Bailey <danbailey@ilm.com>
Signed-off-by: Dan Bailey <danbailey@ilm.com>
Signed-off-by: Dan Bailey <danbailey@ilm.com>
This PR should pass all the CI checks when#1775 and#1776 are merged in. @kmuseth - to follow up on one of your questions from the meeting yesterday. The ValueAccessor registry stores the https://github.com/AcademySoftwareFoundation/openvdb/blob/master/openvdb/openvdb/tree/Tree.h#L1016 Moving the accessor alias and ValueAccessor construction from the Grid to the Tree does not affect the registry in any way. Finally, this registry is stored on the tree and not the grid, so for an adaptive tree there is no registry needed as implemented. |
…ptive treesSigned-off-by: Dan Bailey <danbailey@ilm.com>
…daptive gridSigned-off-by: Dan Bailey <danbailey@ilm.com>
zap150 commentedApr 30, 2024
@danrbailey is there any ETA or roadmap for this feature? Also, can you disclose what structure will be used for the adaptive volume (tree, sparse grid, already existing implementation outside of OpenVDB, papers...)? |
Uh oh!
There was an error while loading.Please reload this page.
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/adaptivesub-directory and I'm calling thisAdaptiveTree. It derives fromTreeBaseas we discussed and this is nested within aGridas well and aliased toAdaptiveGrid.I've introduced a new
AllGridTypesalias that addsAdaptiveGridTypestoSparseGridTypes. 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
TreeTraitsclass 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 thePointAdvectclass 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
implsub-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?