diff options
author | Sergey Sharybin <sergey@blender.org> | 2022-10-24 15:16:37 +0300 |
---|---|---|
committer | Sergey Sharybin <sergey@blender.org> | 2022-11-01 12:48:18 +0300 |
commit | f17fbf80653dc0e1561b30fe03f46e354deb12bf (patch) | |
tree | 46003d781a1b9ca0272112a9a9c2cdf45482d640 /source/blender/blenkernel/intern/softbody.c | |
parent | 8b2b5b0b8384c95d92da41297b1a950e729cd782 (diff) |
Refactor: Rename Object->obmat to Object->object_to_world
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
Diffstat (limited to 'source/blender/blenkernel/intern/softbody.c')
-rw-r--r-- | source/blender/blenkernel/intern/softbody.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/source/blender/blenkernel/intern/softbody.c b/source/blender/blenkernel/intern/softbody.c index b35031b9a88..be033f495c7 100644 --- a/source/blender/blenkernel/intern/softbody.c +++ b/source/blender/blenkernel/intern/softbody.c @@ -2644,7 +2644,7 @@ static void springs_from_mesh(Object *ob) bp = ob->soft->bpoint; for (a = 0; a < me->totvert; a++, bp++) { copy_v3_v3(bp->origS, verts[a].co); - mul_m4_v3(ob->obmat, bp->origS); + mul_m4_v3(ob->object_to_world, bp->origS); } } /* recalculate spring length for meshes here */ @@ -2809,9 +2809,9 @@ static float globallen(float *v1, float *v2, Object *ob) { float p1[3], p2[3]; copy_v3_v3(p1, v1); - mul_m4_v3(ob->obmat, p1); + mul_m4_v3(ob->object_to_world, p1); copy_v3_v3(p2, v2); - mul_m4_v3(ob->obmat, p2); + mul_m4_v3(ob->object_to_world, p2); return len_v3v3(p1, p2); } @@ -3073,7 +3073,7 @@ static void softbody_to_object(Object *ob, float (*vertexCos)[3], int numVerts, SB_estimate_transform(ob, sb->lcom, sb->lrot, sb->lscale); } /* Inverse matrix is not up to date. */ - invert_m4_m4(ob->imat, ob->obmat); + invert_m4_m4(ob->imat, ob->object_to_world); for (a = 0; a < numVerts; a++, bp++) { copy_v3_v3(vertexCos[a], bp->pos); @@ -3223,7 +3223,7 @@ static void softbody_update_positions(Object *ob, /* copy the position of the goals at desired end time */ copy_v3_v3(bp->origE, vertexCos[a]); /* vertexCos came from local world, go global */ - mul_m4_v3(ob->obmat, bp->origE); + mul_m4_v3(ob->object_to_world, bp->origE); /* just to be save give bp->origT a defined value * will be calculated in interpolate_exciter() */ copy_v3_v3(bp->origT, bp->origE); @@ -3279,7 +3279,7 @@ static void softbody_reset(Object *ob, SoftBody *sb, float (*vertexCos)[3], int for (a = 0, bp = sb->bpoint; a < numVerts; a++, bp++) { copy_v3_v3(bp->pos, vertexCos[a]); - mul_m4_v3(ob->obmat, bp->pos); /* Yep, soft-body is global coords. */ + mul_m4_v3(ob->object_to_world, bp->pos); /* Yep, soft-body is global coords. */ copy_v3_v3(bp->origS, bp->pos); copy_v3_v3(bp->origE, bp->pos); copy_v3_v3(bp->origT, bp->pos); |