-
Notifications
You must be signed in to change notification settings - Fork 32
Improve clipping code performance #1654
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
Draft
gunney1
wants to merge
290
commits into
develop
Choose a base branch
from
feature/gunney/shaping-refactor-and-perf
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Trying to achieve fast but not-too-trivial configs.
This is for performance testing.
This is for comparing with clipping code.
The checks didn't yield and change. I added notes about its use but left it disabled.
The bounding-box search didn't improve performance. Maybe this will.
Use CoordinateTransformer to support arbitrary Cone positions and rotations. Adding code for SorClipper::labelInOut.
New implementations should be faster and not omit intersections between cell vertices.
The previous one is a bit slow. New one screens using the tet's bounding box, and computes signed distance based on that. Labling cells uses the characteristic-length-based threshold to ensure we don't lose intersections that occur between cell vertices.
This version doesn't miss intersections between vertices.
…ture/gunney/sor-clipper
to pass some sanity checks.
It doesn't hurt anything and it's not worth the hassle to remove.
…ture/gunney/tetmesh-clipper
…ture/gunney/shaping-refactor-and-perf
… feature/gunney/shaping-refactor-and-perf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
This PR is a feature. It does the following:
MeshClippertest with the new geometries.The following new classes implement the
MeshClipperStrategyinterface:PlaneClipperfor a plane geometryTetClipperfor a tetrahedronHexClipperfor a hexahedronSphereClipperfor a sphereFSorClipperfor a surface of revolution where the discrete curve r(z) is a function. Although the curve may have vertical segments, it may not double back in z. It can support stepped geometries but not hollow geometries. Cones and cylinders are supported by this implementation.SorClipperfor surface of revolution where the r(z) curve can double back on itself, for example to make a bowl.TetMeshClipperfor a general geometry described by a tetrahedral mesh.New code are in
namespace experimental, because this is still a work in progress.Dependencies
The mesh clipping refactor includes multiple PRs. Please review these before this one.
Image of geometries supported (excluding the plane clipper)
Performance comparison
This is a comparison of clipping times for the
IntersectionShaperand theMeshClipper, showing the wall time it took to clip a sample of geometries. It uses thequest_shape_in_memoryexample for theIntersectionShaperand thequest_mesh_clippertest for theMeshClipper. The tests are run on the CPU on rzwhippet and on the GPU on rzadams. The mesh is 30^3 for the CPU and 100^3 for the GPU. Most of the geometries occupy about 1/16 of the mesh. Note that performance is highly configuration dependent, so this data does not tell the whole story. Furthermore, the amortization of shared costs in the new code was not used.rzwhippet + seq, 303 mesh
rzadams + hip, 1003 mesh