-
Notifications
You must be signed in to change notification settings - Fork 279
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support vertex centred data #2615
Support vertex centred data #2615
Conversation
4d6c62e
to
0d0a7f3
Compare
@yt-fido test this please |
/format |
0d0a7f3
to
ca02f97
Compare
This one's ready to go! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a refactoring suggestion.
Unfortunately it's not really clear to me how this goes down to the user. Is this new code already hit by existing tests ? If so, which ones ?
This add support for computing e.g. isocontours for RAMSES datasets. This could in principle be extended to any oct-based dataset, but that'd require extra work. |
626610a
to
04acdf8
Compare
Adds support for vertex centred data. This has the effect of making isocontours possible on octree datasets using the same API as for the rest of yt.
This should be merged after #2425 has been merged. I marked it as draft to prevent people from reviewing it, since many files have been modified in the aforementioned PRs.
This allows for example to export a dataset to sketchfab.
Note that in its current form, the isosurface algorithm does work. However, it is very slow as it performs the marching cube algorithm on each individual oct. It also returns a non-connected set of points (that represent the isosurface), since the output of the marching cube algorithms aren't stitched together. Note that a quick hack would be to merge vertices of the isosurface if they are very close one from another. A better solution however would be to feed sets of connected octs that live at the same level to the marching cube algorithms, but this is well beyond the scope of the current PR.