Was this 0.25f value just determined experimentally?
As is this comment doesn't seem particularly helpful; I think if any part warrants a comment it'd be stating that we cap the min size based on the point where we cant visually display any more info.
Small nit, otherwise looks good - I think the lookup naming is fine, I don't really have any better suggestions than that, fetch seems about as appropriate, really anything that implies that it isnt a simple attribute accessor.
This float3* usage seems a bit odd - I think using a separate index here is probably better than the pointer math on line 2468
Haven't yet gone through and done any sort of testing for this patch, just an initial pass over from the code side of things
I find these flags to be a bit confusing, and this is likely outside of the scope of this PR, but why does Rebuild not imply Update as well?
Since display_level is now a static 0, I think this can be simplified to
nit: I think use_ instead of do_ reads better here as a boolean flag.
More for my own knowledge than anything about this PR, but is there something that describes the sharp_face attribute and why / how it's used?
I know you mentioned performance on a large mesh in the main PR text, but it might be interesting to see multires performance specifically with this change.
Why do we need the const_cast here? Shouldn't *pbvh as the first parameter just work?
Would it be better to only calculate visible_nodes when update_only_visible is true (i.e. do this as an if statement instead of a ternary? Not sure about the relative costs here and if we actually update the entire mesh that often.
@ideasman42 AFAIK, 4.2 shouldn't have a crash here since it was caused by a change I made in 4.3, if you mean the change to always rebuild the PBVH at the beginning of the cursor, it's possible,…