Alright, thank you!

In T98427#1380119, @Marc (MarcM0) wrote:

Hey, I was wondering how long it would usually take for these commits to make it into the release?

Hi, fix has been committed to master so you can expect this in 3.3 release
But you can even check this today in fresh 3.3-alpha build: https://builder.blender.org/download/daily/

Hey, I was wondering how long it would usually take for these commits to make it into the release?

Was able to recreate this and can confirm it is resolved in master by the same fix as https://developer.blender.org/T98427

This is my understanding of the data flow:

Can still repro crash in recent buildbot build. So reopening the ticket :)

Was able to recreate this bug and it is fixed in master by the fix for https://developer.blender.org/T98427

If you dont understand how my fast surface grid algo used here is working

Thanks for the report. I'm assuming this was what was fixed on rB522dcc54af35.

This issue should be resolved in master by https://developer.blender.org/D15269

@Philipp Oeser (lichtwerk) I believe this issue is now resolved in master by https://developer.blender.org/D15269 and can be closed

It would be useful if (like the extrude node) there were also outputs for the new faces created by the bevel, and the inverted selection (all faces excluding the new ones). This is one of the distinct advantages of nodes over modifiers, and I've yearned for it for a long time.

Personally I would have only CD_PROP_UV and no CD_PROP_FLOAT2. It's not clear to me there are good use cases where using either CD_PROP_UV or CD_PROP_FLOAT3 would not work well. I don't think users care much about the differences, they would mainly get in the way.

@Campbell Barton (campbellbarton) perfect! Your changes seem like a much safer way to solve this problem, and are still fixing the issues for my test cases. I left some small comments on it and will close this revision, thanks for taking a look into this!

Thanks @Scurest (scurest), I will mark this as in need of information from developers for the time being.

I hit an assert BLI_assert_msg(0, "Custom data layer not found in geometry"); in debug mode in the provided file.

See https://developer.blender.org/T43332#294071. You can first create them all, then fetch them by name.

There are many exporters/importers that need to know what the UV maps are, so it seems like something that must be resolved before UV map to float2 attribute conversion lands.

Nope, I just didn't get to commit it yet, I will today.

It's an uninitialized value, so the crash may be somewhat random.

AFAIK soon particle system will be replaced by new system. So not sure if this issue will be tackled by developers or not
Tagging modules for more information since multiple people has been able getting this issue.
(I've made some edits in original reports after reading all comments)

Added this report and commit in corrective release list. Feel free to remove if you've any concerns

I'm not able to repro this (in both 3.2, 3.3). Crash occurs in 3.2 too? Can someone confirm?

Hi, it's been two weeks, is this patch stuck?

Looking into this, it's quite error prone that manta-flow is manipulating the __main__ namespace which may be owned by the caller.

I believe this issue will be fixed by https://developer.blender.org/T98427 which is currently waiting for review

@Philipp Oeser (lichtwerk) I am pretty sure this is the same underlying issue as https://developer.blender.org/T98427, and should be fixed by that patch. I was able to recreate the crash on close, but not when opening the preferences menu, and can confirm that it is resolved by the fix for that task that is currently waiting for review.