Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Draft
danrbailey wants to merge7 commits intomaster
base:master
Choose a base branch
Loading
fromfeature/adaptive
Draft

Conversation

@danrbailey
Copy link
Contributor

@danrbaileydanrbailey commentedJan 30, 2024
edited
Loading

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 anadaptive:: 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 newAllGridTypes 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 newTreeTraits 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.

BoxSampler::sample(const TreeT& inTree, const Vec3R& inCoord,                    typename TreeT::ValueType& result){    ....    if constexpr (isSparseTree<TreeT>()) {        // sparse implementation    } else if constexpr (isAdaptiveTree<TreeT>()) {        // adaptive implementation    }    OPENVDB_THROW(NotImplementedError, "");}

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 animpl 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?

NiallHornFX reacted with thumbs up emoji
@danrbaileydanrbaileyforce-pushed thefeature/adaptive branch 2 times, most recently from81f9b7e toe32a221CompareMarch 9, 2024 01:25
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>
Signed-off-by: Dan Bailey <danbailey@ilm.com>
@danrbailey
Copy link
ContributorAuthor

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 theValueAccessorBase which means any variant of the ValueAccessor will be registered provided that it derives from this base class:

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
Copy link

@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...)?

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@kmusethkmusethAwaiting requested review from kmusethkmuseth will be requested when the pull request is marked ready for reviewkmuseth is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@danrbailey@zap150

[8]ページ先頭

©2009-2025 Movatter.jp