- User Since
- Jan 28 2019, 8:02 PM (156 w, 3 d)
So fixing that would mean having to change cmake files to do add_definitions(-DWITH_TBB) or somesuch.
I've created a prototype patch here: D13939: Fix T95185: Invalid normals after undo in sculpt mode
Thanks for the report. Something does look a little weird here, but without all the context from your project, I'm finding your file hard to debug.
Could you please spend a few minutes going through your file, removing anything that you can, as long as it doesn't change the problem?
The fewer nodes, objects, etc. the better. It makes such a huge difference in how possible it is to find the problem. Thanks.
The basic idea seems reasonable. However, I don't think the node class should be stored in bNode, since it's runtime information.
I've been doing a fair amount of refactoring recently trying to _remove_ runtime information from bNode, I'd rather not reverse that.
I can confirm this. I needed to do some fast vertex painting to reproduce it. It manifests as a crash, or a freeze. I also saw a memory leak once.
Oops, I didn't see you had claimed this @Philipp Oeser (lichtwerk) . Feel free to commit a fix directly if you have one, this looks like a simple issue.
I would consider this "sort of a bug". There is really no great way to choose the normal direction for the extrude node when extruding from loose edges.
I like the idea here. I think ideally code would be shared between this node and the attribute statistics node (which would be a special case of this node). Then any optimization we do to one would also apply to the other. I don't have a strong opinion about whether that should be a separate step or not though.
I toggled the monitor off and on for a while on debug and release builds didn't get a crash. However, I have found that the normals look completely wrong compared to 2.93, so clearly there's something going wrong here. Maybe the two issues are related.
Hmm, I can't reproduce this, on either a debug build or a release build. What I did:
- Extract the blend file
- Open the file
- Click the monitor icon in the modifier header (no crash)
- Enter edit mode (no crash)
- Add a camera and render the scene (no crash)
I did some performance tests, choosing the function that looks the simplest to me, BKE_crazyspace_set_quats_mesh.
On a 1.5 million vertex mesh, the function took 0.38696 seconds before, on average. After, it took 0.38044 seconds.
That's an improvement of 1.7%. So a negligible change, but more likely to be an improvement.
My guess is that less memory needs to be loaded to check the flags, since they are all contiguous. Which means that loading unnecessary mesh vertices can be skipped.
That seems like a fairly typical situation to me. This doesn't even contain the improvements from when the flag can eventually be removed from MVert.
I'm closing this, since the merge by distance node was committed to master. The basic approach was the same as used in this patch, just differences in the details.
Closing this revision, since rB95981c987648 was committed. Thanks for the contribution.
Wed, Jan 26
The code looks good, I'd like to discuss this one more time though, since last time I think we weren't completely sure we wanted to add it.
Design-wise, I could see this as part of a "Point Primitives" menu with another 2D/3D grid node.
This report does not contain all the requested information, which is required for us to investigate the issue.