This commit is part refactor changing else if / return...

I'm not so keen on this as it means we can't easily add cleanup/finalization functions at the end of existing code, without adding goto's or switching back to else-if blocks (causes noisy changes).

In this case I think it makes more sense to split these into functions, then the logic to run them reads much better:

Something like this:

if (cu->bevel_mode == CU_BEV_MODE_OBJECT) {
  curve_bevel_make_with_object(ob, disp);
}
else if (!(use_extrude || use_bevel)) {
  /* pass */
}
else if (!use_bevel) {
  curve_bevel_make_with_round(ob, disp);
}
else if ((cu->bevel_mode != CU_BEV_MODE_CUSTOM) && build_full && !use_extrude) {
  curve_bevel_make_with_curve_profile(ob, disp);
}
else {
  /* The general case for nonzero extrusion or an incomplete loop. */
  curve_bevel_make_extrusion(ob, disp);
}

Since this function is growing and getting more involved, I think it's reasonable to split this into curve_bevel.c too, as curve.c is quite large and it seems this is reasonable to isolate.

It'd be better to split out from this change though.

I don't think this is thread safe, as this runs from the main object update function which runs from threads, and objects can share object data.

It looks like it could be removed.

Term build here is quite generic.

Maybe use_fill_(front/back/full) ?

Use const for values that don't change.

These will be small enough to use stack memory (alloca).

Regarding terminology, I'm not sure about using "Custom", this made some sense for mesh bevel since it's the only way to customize.

For curve-objects curve objects are just as custom as curve profiles. Suggest renaming CU_BEV_MODE_CUSTOM to CU_BEV_MODE_CURVE_PROFILE, as it's then clear what's being used.
If this is too cramped for the UI, we could use the term "Profile" instead of the full "Curve Profile".

Besides custom seeming a too generic, I don't have a strong opinions on this so check with others on the UI team.

I initially did the refactor because working a few levels of indentation deep is just annoying.

But you're right, it shouldn't be part of this patch. So I split it off, along with a bit more cleanup: D8425

Right, that makes sense. The issue I had is that the segments table (the curveprofile evauation) is cleared when the file is saved, so the segment table is empty. Maybe just changing that is the thing to do, but it's runtime data. Maybe in the depsgraph there's a way to run something once per object data?

I agree! I didn't think of anything at the time, but I think exposing "Profile" for the UI is a good solution.

It could work to put this in CurveCache, so each object gets it's own run-time curve profile data.

I messed around with a file with a bunch of objects using the same curve data. Everything worked fine until I did undo, then I had a double free from a separate thread. So definitely a memory issue.

So about solutions:

1. Save segments table in file: Each point is 40 bytes. The number of segments is usually low, but in the worst case this could add 4000 bytes per bevel modifier with maxed resolution (and 1280 bytes per curve data with max resolution).
2. Running initialize on file read: I'm not sure if there is precedent for this?
3. Storing a runtime copy in CurveCache: I can look into this more. Looking at it briefly it appeared that the areas that deal with CurveCache are still threaded?

I think it looks like that because the general case is used for the curve profile bevel even when there is no extrusion (Which would have previously been just curve_bevel_make_full_circle).

Since the logic before was dependent on setting the angle correctly rather than choosing the right indices to pull the location from, I'm not sure it makes sense to split off changes from this patch.

Yeah, I agree this is a bit of an issue. Thing is, this is a problem in master too. These properties apply even when the bevel depth is 0, because they control the mapping for only extrusions too. I created D8910 to address this.