[Bf-blender-cvs] [c686951233c] master: Cleanup: improve comment about shape keys, correct spelling

[Campbell Barton]

Commit: c686951233c68896d512ac0cac9813bb36a89692
Author: Campbell Barton
Date:   Tue Oct 27 13:49:45 2020 +1100
Branches: master
https://developer.blender.org/rBc686951233c68896d512ac0cac9813bb36a89692

Cleanup: improve comment about shape keys, correct spelling

===================================================================

M	source/blender/blenkernel/intern/lib_override.c
M	source/blender/editors/object/object_modifier.c

===================================================================

diff --git a/source/blender/blenkernel/intern/lib_override.c b/source/blender/blenkernel/intern/lib_override.c
index 79e33f768b6..57dc83f1db7 100644
--- a/source/blender/blenkernel/intern/lib_override.c
+++ b/source/blender/blenkernel/intern/lib_override.c
@@ -1427,9 +1427,9 @@ void BKE_lib_override_library_main_operations_create(Main *bmain, const bool for
   }
 
   /* Usual pose bones issue, need to be done outside of the threaded process or we may run into
-   * concurency issues here.
+   * concurrency issues here.
    * Note that calling #BKE_pose_ensure again in thread in
-   * #BKE_lib_override_library_operations_create is not a problem then.. */
+   * #BKE_lib_override_library_operations_create is not a problem then. */
   LISTBASE_FOREACH (Object *, ob, &bmain->objects) {
     if (ob->type == OB_ARMATURE) {
       BLI_assert(ob->data != NULL);
diff --git a/source/blender/editors/object/object_modifier.c b/source/blender/editors/object/object_modifier.c
index 146e399a04d..17dc8f46796 100644
--- a/source/blender/editors/object/object_modifier.c
+++ b/source/blender/editors/object/object_modifier.c
@@ -680,16 +680,15 @@ static int modifier_apply_shape(Main *bmain,
     return 0;
   }
 
-  /*
-   * It should be ridiculously easy to extract the original verts that we want
-   * and form the shape data.  We can probably use the CD KEYINDEX layer (or
-   * whatever I ended up calling it, too tired to check now), though this would
-   * by necessity have to make some potentially ugly assumptions about the order
-   * of the mesh data :-/  you can probably assume in 99% of cases that the first
-   * element of a given index is the original, and any subsequent duplicates are
-   * copies/interpolates, but that's an assumption that would need to be tested
-   * and then predominantly stated in comments in a half dozen headers.
-   */
+  /* We could investigate using the #CD_ORIGINDEX layer
+   * to support other kinds of modifiers besides deforming modifiers.
+   * as this is done in many other places, see: #BKE_mesh_foreach_mapped_vert_coords_get.
+   *
+   * This isn't high priority in practice since most modifiers users
+   * want to apply as a shape are deforming modifiers.
+   *
+   * If a compelling use-case comes up where we want to support other kinds of modifiers
+   * we can look into supporting them. */
 
   if (ob->type == OB_MESH) {
     Mesh *mesh_applied;
@@ -722,7 +721,7 @@ static int modifier_apply_shape(Main *bmain,
     BKE_id_free(NULL, mesh_applied);
   }
   else {
-    /* TODO: implement for hair, pointclouds and volumes. */
+    /* TODO: implement for hair, point-clouds and volumes. */
     BKE_report(reports, RPT_ERROR, "Cannot apply modifier for this object type");
     return 0;
   }
@@ -819,7 +818,7 @@ static int modifier_apply_obdata(
     DEG_id_tag_update(&ob->id, ID_RECALC_GEOMETRY);
   }
   else {
-    /* TODO: implement for hair, pointclouds and volumes. */
+    /* TODO: implement for hair, point-clouds and volumes. */
     BKE_report(reports, RPT_ERROR, "Cannot apply modifier for this object type");
     return 0;
   }