as_mutable_span() -> as_span() here since the function signature for apply_position_faces expects a Span
Since we dont have the CLAMP from smooth_position_node, I think it's probably worth duplicating the above assert for last
Since we iterate on this loop up to four times and the neighbors shouldn't change for this PBVH type, should we pull this overall calculation outside the iteration_strengths loop?
Idle thought that just came to me, I wonder if we would benefit from a naming scheme for Spans like new_positions to better communicate intent - something like new_positions_indexed? I don't think this is entirely necessary since we have the BLI_asserts, but it might help when looking at the function signature from a caller's POV?
I'd move this & fract to a constexpr inside the namespace, maybe change it to MAX_ITERATIONS as well.
@ThinkingPolygons - No ETA at the moment, currently pending code review, but there are competing priorities for time on the reviewers side. I'm keeping an eye on this in the meantime so that it…
This sounds like the same core issue as blender/blender#110616 and would likely be superseded by #118250
I have a feeling that the core issue here is rather deeply embedded in how we process events.
Option 1: Stopgap ""Solution""
A possible stop gap solution here could be to change the…
Hi, this is intended. Non-brush tools won't have the "brush cursor". It is quite misleading sometimes. Eg: resizing brush with
Fwhen box hide tool is selected. @PratikPB2123 - While I agree…
This no longer occurs in the current 4.2 builds, though I can reproduce it in 3.3.19, 3.6.12, and 4.1.1
