Skip to content

Conversation

@hughcars
Copy link
Contributor

Note: This is based on top of #112 as a required predicate.

Changes as part of #112 significantly reduced the number of entities being rendered to the SolidModel before postrendering. One consequence of this is to reduce the time required for all postrendering operations, as they generally scale superlinearly with number of entities. Additionally, because mesh entities were by nature colocated with many detailed piece of a component, this resulted in a significant amount of nodes, segments and surfaces that were non-reconcilable without a fragment operation. By removing these entities, the "auto union" operation commonly used with negative or positive layers has been made significantly more powerful, as the union with entity removal reduces the number of total surfaces enormously.

This has two consequences: 1) it reduces the number of entities that need to fragment, improving the run time significantly, and 2) it removes constraints on the mesher associated with adhering to these "construction" entities which aren't actually relevant to the physical geometry, thereby improving mesh speed and quality.

This can be most cleanly seen in the QPU17 example, where comparing main against the results from this branch, when run on an M1 mac using a single thread for meshing.

Before:

Rendering to SolidModel: 1965.336371 seconds (110.03 M allocations: 7.415 GiB, 0.06% gc time, 0.98% compilation time: <1% of which was recompilation)
Generating 1D Mesh: 270.173185 seconds
Generating 2D Mesh: 761.339575 seconds
Generating 3D Mesh: 478.235420 seconds

and after:

Rendering to SolidModel: 538.681900 seconds (103.71 M allocations: 6.577 GiB, 0.14% gc time, 3.48% compilation time: <1% of which was recompilation)
Generating 1D Mesh: 11.668969 seconds (155.80 k allocations: 7.668 MiB, 0.45% compilation time)
Generating 2D Mesh: 9.354619 seconds
Generating 3D Mesh: 231.924238 seconds

Giving a 3.64x speed up in render, 23.15x in 1D meshing, 81.39x in 2D meshing and 2.06x in 3D meshing, for an overall speedup of 4.38x. The most dramatic improvements are in the 1D and 2D meshing, which it's hypothesized comes from a) the huge reduction in total entities, and b) the simplification of those entities that remain.

@hughcars hughcars requested a review from gpeairs November 25, 2025 17:12
@hughcars hughcars force-pushed the hughcars/mesh-size-without-physical-groups branch from 6377159 to 4f02a37 Compare November 26, 2025 17:14
@hughcars hughcars force-pushed the hughcars/remove-restrict-operation branch from 6e33136 to 0eba4df Compare November 26, 2025 17:19
@hughcars hughcars force-pushed the hughcars/mesh-size-without-physical-groups branch from 4f02a37 to fc7e961 Compare November 28, 2025 19:00
@hughcars hughcars force-pushed the hughcars/remove-restrict-operation branch from 82088bb to 62f0825 Compare November 28, 2025 19:04
@codecov
Copy link

codecov bot commented Nov 28, 2025

Codecov Report

❌ Patch coverage is 93.54839% with 2 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/solidmodels/render.jl 83.33% 2 Missing ⚠️

📢 Thoughts on this report? Let us know!

@hughcars hughcars marked this pull request as ready for review November 28, 2025 19:36
@hughcars hughcars force-pushed the hughcars/mesh-size-without-physical-groups branch from 1c6589e to dff13bb Compare December 1, 2025 15:52
@hughcars hughcars force-pushed the hughcars/remove-restrict-operation branch from fdf4034 to e5fdb03 Compare December 1, 2025 16:22
Copy link
Member

@gpeairs gpeairs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two PRs are pretty exciting. Just one comment, and I'll take another look if there are any new changes once you're done testing, but otherwise LGTM

Comment on lines 999 to 1003
s::Float64 = mesh_scale()
trees::Dict{
Tuple{Float64, Float64},
KDTree{SVector{3, Float64}, Euclidean, Float64, SVector{3, Float64}}
} = mesh_control_trees()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to use these in the loop below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, must've been a rebase error. I was trying to force away a yellow type safety warning from some unions, but I don't think it helped. I'll check it again and get rid of the debris.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants