Review patch based on Sergey's initial notes.

Removed flags for treating vertex and egde creases differently.

Use a CustomData layer for storing vertex creasing. No changes were made for the
edge creases storage, but if this is the way to go, I can work on a patch for
storing edge creases as CD layers as well.
One challenge I had was making sure vertex creases are properly written and read
from the .blend files. CD_CREASE is also an exceptional case when reading and
riting custom data layers though (I am not sure why because I don't know why the
other expectional layers are also exceptional, but that made it work).

Add vertex sharpness accessor in multires_reshape_smooth.c. I got initially
confused with how the feature is supposed to work. I think I got it in the end,
let me know if something looks obviously wrong. Main thing to note is that I had
to pass the index of the original coarse vertex around the various subdivision
callbacks in order to set the sharpness on the right grid vertex.

In D10145#292908, @Sergey Sharybin (sergey) wrote:

Mainly wondering whether there needs to be some sort of mapping of vertex crease similar to the edge one: the edge crease was feeling too sensitive at the lower ranges and not sensitive at the higher values range. Additionally, I believe an infinitely sharp vertex in OpenSubdiv will have sharpness of 10, while in Blender infinitely sharp is 1. So, either I'm missing something, or mapping similar to BKE_subdiv_edge_crease_to_sharpness_{f, char} is needed.

No, you are correct, this is somehow missing, although the Cycles code is remapping to 0-10.

What do you think of renaming the various *edge_crease* functions to remove edge, e.g. BKE_subdiv_edge_crease_to_sharpness_{f, char} -> BKE_subdiv_crease_to_sharpness_{f, char}? I guess I could have preemptively done it.

What do you think of renaming the various *edge_crease* functions to remove edge, e.g. BKE_subdiv_edge_crease_to_sharpness_{f, char} -> BKE_subdiv_crease_to_sharpness_{f, char}? I guess I could have preemptively done it.

This sounds good.
Just verify that the vertex crease control feels good.

Using the Loop Cut tool on a subdivided cube copies the vertex crease from adjacent vertices. Is this desired behaviour?

Apart from this, I've kept the review to the Alembic-specific code, as the rest seems to have been reviewed already by others.

In D10145#297229, @Sybren A. Stüvel (sybren) wrote:

Using the Loop Cut tool on a subdivided cube copies the vertex crease from adjacent vertices. Is this desired behaviour?

No, this is neither intended nor desired behaviour. The crease is apparently copied at two occasions:

• once in BM_vert_create via BM_elem_attrs_copy. We can get rid of this by passing CD_MASK_CREASE to BM_elem_attrs_copy_ex, however this will introduce a lot of noise as BM_elem_attrs_copy will need to be modified as well
• but even if we make use of CD_MASK_CREASE here, the crease is copied a second time through BM_data_interp_from_verts which is called later in BM_edge_split, and we cannot really control what is copied, apart from removing the custom data interpolation function for CD_CREASE which will also affect edge creases (where some interpolation/copy is interesting).

The only solution I found is to reset the vertex crease for the newly created vertex at the end of BM_edge_split, like so:

diff --git a/source/blender/bmesh/intern/bmesh_mods.c b/source/blender/bmesh/intern/bmesh_mods.c
index 76e32667804..3dbdf1a3889 100644
--- a/source/blender/bmesh/intern/bmesh_mods.c
+++ b/source/blender/bmesh/intern/bmesh_mods.c
@@ -700,6 +700,11 @@ BMVert *BM_edge_split(BMesh *bm, BMEdge *e, BMVert *v, BMEdge **r_e, float fac)
     BLI_array_free(oldfaces);
   }
 
+  const int cd_vertex_crease_offset = CustomData_get_offset(&bm->vdata, CD_CREASE);
+  if (cd_vertex_crease_offset != -1) {
+    BM_ELEM_CD_SET_FLOAT(v_new, cd_vertex_crease_offset, 0.0f);
+  }
+
   return v_new;
 }

@Campbell Barton (campbellbarton) what do you think?

While the concern about loopcut is reasonable it would be good to see what kinds of issues users end up running into (with any tool that creates geometry). At the moment it's not clear if each tool should have special handling for vertex-crease, or if this should be handled at a lower level in the API (at least by default).

While the current behavior with loop-cut is not ideal I don't see it as a blocker.

In D10145#253801, @Sergey Sharybin (sergey) wrote:

It should be a custom data layer, not a property which is always stored in vertex.

I also think that it should be represented in UI, like a special Crease section rather than Edges/Vertices separation - when you work with Crease it is preferable to see all available values at once instead of constantly switching between modes with each action to get the full picture of a setup of your selection.
Values can be greyed out according to the current submesh mode (or not).

I would like to suggest to let the same operator (shift+E on default keymap) to control both vertex and edge crease. An option list (or 2 buttons) to choose if we want to affect vertex crease, edge crease or both.
Of course this is out of scope of this patch.

Also I am not sure if interpolating vertex creasing during subdivision is expected behavior.
(screenshot also showing the bigger vertice points)

In D10145#363540, @Clément Foucault (fclem) wrote:

Also I am not sure if interpolating vertex creasing during subdivision is expected behavior.

That's not really expected (at least I wouldn't expect it). I think to fix this we can remove the CustomData interpolation function (LayerTypeInfo.interp) for CD_CREASE (it is currently reusing the one for bweights). Creases for edges are stored in the edge currently, but even when we move to a custom data layer there as well, interpolation should not be used, but rather copied from coarse edge to corresponding subdivided edge (which is the current behavior, and also what BMesh is doing). So I guess we can remove this.

@Kévin Dietrich (kevindietrich) +1 for not interpolating vertex creases for loop-cut / most subdivision tools. I'd rather this not be done in BM_edge_split though (the custom-data lookup could add unexpected overhead in modifiers for e.g.).

Removing the custom-data interpolation function seems OK, although we might end up wanting it at some point.
Off hand I can't think of any situations it's needed though, so +1 to remove the interpolation function as you suggest.
Code comments should explain why the function isn't present.