Sculpt Trim tools are very slow #84229
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
18 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#84229
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: macOS Mojave 10.14.6
Graphics card:
Blender Version
Broken: Version 2.91.0 (2.91.0 2020-11-25) & Version 2.92.0 (2.92.0 2020-12-27)
Worked: n/a
Short description of error
Using Box Trim is very slow. If you use the tool and then switch to another program like a web browser before the task is done, Blender becomes unresponsive and you have to force quit it.
Exact steps for others to reproduce the error
See video of the slowness.
boxtrim.mov
Added subscriber: @kuzey
#95189 was marked as duplicate of this issue
#83078 was marked as duplicate of this issue
#97295 was marked as duplicate of this issue
Added subscriber: @rjg
Changed status from 'Needs Triage' to: 'Archived'
It is a memory intensive operation. Depending on the complexity of your mesh, your operating system may have to use the page file, because you are using more memory than RAM is available, which is quite slow. You can check this by opening the task manager and monitoring the memory usage.
While we always try to improve performance, potential areas that could be optimized aren't triaged as bugs.
Added subscribers: @PabloDobarro, @howardt, @Sergey, @lichtwerk
Changed status from 'Archived' to: 'Needs Developer To Reproduce'
We already had #83078 (Box Trim Causes Crash) reported for this (but that one never got an answer from @PabloDobarro -- and was also closed for the wrong reason).
The thing here is that it uses new exact booleans under the hood [which can be very slow].
So unless you are saying that this is performing worse than regular booleans, I would assume this has little chance to be classified as bug.
That being said, it does feel weird having to wait 100 seconds for a tool like this in sculpting [where a higher poly count is to be expected]
CC @howardt
CC @Sergey
Performance should be a little bit worse than regular booleans (it need to perform the boolean operation, a mesh ->bmesh -> mesh conversion and a PBVH rebuild. Parts of this can be optimized, like avoiding the mesh -> bmesh conversion if the boolean code supports that in the future. After that, the speed of the tool will completely depend on the speed of the boolean code.
I don't think this is a bug, more like an optimization TODO.
OKi, thanx checking @PabloDobarro , will set to TODO then
Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'
I am working right now on code that avoids trip in and out of BMesh for Exact Booleans. That may help some. After I do that, I still have a number of places in the code where I can use multithreading. and intend to do that.
Exact Boolean uses a lot of memory. I haven't paid any attention to memory optimization. I may do that too. It is quite possible that as Robert Guetzkow speculated above, the example shown here is a case where it is using more memory than the user has available, and so it is paging.
The other place where Exact Boolean is unreasonably slow right now is when the input is not "PWN" (piecewise-constant-winding number) -- which approximately means: when both operands are not closed volumes, and the only non-manifold edges are "touching" kind (think: two cubes touching along a shared edge). I imagine the cutting shape that Pablo is using is always PWN, but I can't tell from the video whether the other shape is too. I need to do something different when the inputs are not PWN, as the current method is clearly too slow. So I will work on that too.
Added subscriber: @muhuk
Added subscriber: @AdamJanz
Yes, I noticed this is unusually slow. In this video by Zach Reinhardt, the lasso trim tool appears to work quite fast compared to on my system. Same in both Blender 2.92 official and 2.93 alpha. I'm using i7-5930K 6 core @ 3.5 GHz (3.7 boost), a GTX 970 with 4 GB, and 32 GB RAM, and Zach is using a i7-7700 4 core @ 4.2 GHz , a GTX 1070 ti with 8 GB, and 64 GB RAM. However, the operation in both cases is ultra-simple: using the lasso tool to cut the default rounded cube, which has a mere 24,578 vertices. Is this operation heavily dependent on CUDA cores (1664 vs 2432), because judging by the monitors on my system, the simple operation barely touches my GPU RAM, GPU load, or system RAM? Link to Zach's video: https://youtu.be/tQfFlzHJJ88?t=289 (The same operation hangs for 7 seconds on my system). Thanks for looking into this.
Added subscriber: @Zsolt-Kantor
It quickly ate up 5 GB of system RAM on a mesh of 24k faces. First I thought maybe symmetry caused the cutter shape to be too complex but that's not the case. The two cuts are applied separately. 2.93 LTS and the newest 3.0 master alpha.
Added subscriber: @lictex_1
Added subscribers: @Stephen_Sensei, @PratikPB2123
Added subscribers: @mike.cairns86, @iss, @Foaly
Added subscriber: @Bun
Curious to know what's changed on this front as this is a feature I'm deeply interested in as a sculptor and the inability to rapidly combine, separate or trim meshes makes a lot of the tried and true workflows many are used to coming from other tools essentially impossible.
Around 30% of the power in a sculpting workflow is locked behind curved trims and curved separations of meshes or the recombination of elements.
I did do the thing I referred to in Dec 2020 (avoiding the round trip in and out of BMesh) but realize that doesn't help much of the case of large numbers of faces. I need a new approach. Either one that avoids doing exact arithmetic most of the time, like in the paper "Interactive and Robust Mesh Booleans by Cherchi et al., or something that isolates the calculations to only those parts of the mesh near the intersection, like in the paper "EMBER: exact mesh booleans via efficient & robust local arrangements" by Trettner, Nehring-Wirxel, Kobbelt. I think I'll try one or the other of these approaches, or maybe a combination. But since I'm working on Bevel V2 right now, it will be a number of months before I can get to that.
Thank-you and I appreciate the response. This is pretty much the one complaint I hear from a lot of ZBrush mains (sick of the general pain of the tool) who want to jump ship to Blender fulltime so to know its on your mind fills me with enormous hope. Best of luck with the work on Bevel V2 and best wishes. We all want to jump ship to Blender for our entire workflows not just most of the workflow.
Box Trim tool is very slowto Sculpt Trim tools are very slowAdded subscribers: @Limarest, @JulienKaspar, @Garek
Added subscriber: @s12a
Added subscriber: @feefity
Any word on even incremental changes (eg, trip-avoidance in and out of exact bools before multi-threading support)?
I'm wondering if dropping the mesh precision as the polycount increases would make sense, given it seems like a precision tradeoff is ideal given that as the polycount goes up, the relative polygon size to the model goes down in a way which is typically proportional and if this principle can be taken advantage of.
As the polycount goes up, the perceptible gains of precision become marginal and then eventually imperceivable.
That very small difference could then be compensated with a cheaper operation, such as projecting the new polygons along the normal of the cutting surface, assuming it is even needed at all whatsoever.
I'm here to make someone remember again. Need quick(er) Trim! I really am ready it to be less precise but faster!
Another friendly reminder: Quicker trim. Lower precision, higher speed, just like MaximTkachenko said a month ago.
This still is a workflow breaking problem at the moment.
Some users have had success using "mask slice to new object", though the problem is that this is first extremely tedious, and second a new object isn't actually needed. This also better aligns with what the trim tool's expected behavior is during a sculpting workflow
the fact this isn't on a roadmap or this isn't even a quick fix slid into the sculpting workflow to make do until something better comes along for the short term with suggestions like this to make this faster is kinda sad cuz users (see above link) are finding ways to sort-of make do but they are incredibly awkward to actually do since the tools are designed for other totally different tasks.
Looking at the old trim tool, I can sort of see something interesting
The way the existing trim tool bottoms out/flattens along a normal to produce a flat pizza-geometry with overlapping polygons at its base. This really is not fit for purpose and isn't what trimming "is" in a sculpting workflow, at all, even if it is "adequate" in some very limited edge-casees where the trimmed geometry has a smaller profile than the host geometry.
This isn't supposed to happen, at all which makes me wonder if the spec itself was at fault and didn't adequately describe the function of the tool in precise enough terms during its design? In which case, whoever's designing the spec needs someone who uses tools like this so the edgecases get caught early.
Its weird considering most of the sculpting tools in Blender so far have been exceptionally good too.
The generally agreed upon function of a trim tool is:
In doing so, you sorta get the capacity to very rapidly produce very complex shapes with very little action. The sacrifice is the percieved precision being high, while the actual precision is kinda low and the precision level itself adapts, getting less precise as polycounts get higher to help keep stuff speedy.
In one of these subtractive workflows, masking and trimming like this is a great way to search for shapes inside a volume with rapid operations in sequence.
I hope two years from now Blender has one. A lot of folks really wanna get off the ZBrush train, especially given the new pricing plans.
@Bun Thanks a lot for the thoughtful feedback! We'll add this to the notes for when this feature gets some development time again 👍
Is there any progress in this problem? I'm using blender 3.2 right now, and the 1kk poly mesh trim operation just ate 26gb of RAM and 99% of CPU in seconds and froze blender.
AMD Ryzen 5 3600, 32gb ddr4, nvidia geforce RTX 3070TI.
The good news is that I have actively started implementing the Ember boolean algorithm that I mentioned about 9 months ago in this conversation. It promises to be maybe 100x faster than the current Exact Boolean. However, doing a new boolean is a major undertaking, so don't expect this for probably 6 months (sorry), unless I find a lot of spare time (I'm a volunteer Blender developer, with another full-time job that takes up my days). I may have found a partner to help, and that partner has much more free time, so if I am successful there, this may go faster.
@howardt That sounds great, Howard! I'm glad it's on the radar. You all are doing a fantastic job and I realize there are other priorities with day-to-day work. Hopefully the Blender Foundation will take you on full time someday. Have a great week ahead! :-)
It seems a problem with the trim implementation and no with the boolean algorithm, you can try to use the boolean modifier in a 500k mesh, in my computer it takes less than 10 seconds to compute the operation and to apply the modier and it is more or less same time with the carver addon but it takes several minutes to trim the same mesh with the sculpt tool.
You probably tried the modifier with the "fast" mode, not the "exact" mode that I believe the sculpt tool uses.
Am a still actively working on the very fast Ember exact algorithm implementation, but unfortunately it is taking longer that I had hoped. Probably another couple of months at least before I might be able to release even an experimental version of it.
Yes sorry, i was using the exact mode, with fast it takes a couple of seconds, I suppose carver uses the exact mode because it takes almost the same time too, to me the problem with the modifier starts with more dense meshes, >10M could take more than a minute to compute in exact mode, more than 30 minutes with the trim tool.
While work is continuing on Howard's side for the EMBER exact algorithm, I'm starting to look at some short-term fixes to make the tool more usable. I have a PR to add the option of choosing to use the Fast solver for trim operations linked above. I'm also planning on taking a look at the overall performance of the Trim tools outside of the boolean solvers to see if there's further areas to improve.