Page MenuHome

Allow surface deform when target mesh increases number of vertices
ClosedPublic

Authored by Sergey Sharybin (sergey) on May 3 2022, 3:39 PM.
Tags
None
Tokens
"Like" token, awarded by hitrpr."Love" token, awarded by kivig."Love" token, awarded by dulrich."Love" token, awarded by simonthommes.

Details

Summary

A studio request actually.

The goal is to cover rather typical situation: when the mesh was
bound to target when the target was on subdivision level 0 but
uses a higher subdivision level for rendering. Example of such
setup is a facial hair bound to the face.

The idea of this change is to use first N vertices from the target
where N is the number of vertices on target during binding process.
While this sounds a bit arbitrary it covers typical modifier setup
used for rigging. Arguably, it is not more arbitrary than using a
number of polygons (which is how the modifier was checking for
changes on target before this change).

Quite straightforward change. A bit tricky part was to not break
the behavior since before this change we did not track number of
vertices sued when binding. The naming I'm also not super happy
with and just followed the existing one. Ideally the variables in
DNA will be prefixed with target_ but doing it for an existing
field would mean compatibility change, and only using prefix for
the new field will introduce weird semantic where the polygons
count will be even more easily confused with a count on the
deforming mesh.

Diff Detail

Repository
rB Blender
Branch
surface_deform (branched from master)
Build Status
Buildable 21938
Build 21938: arc lint + arc unit

Event Timeline

Sergey Sharybin (sergey) requested review of this revision.May 3 2022, 3:39 PM
Sergey Sharybin (sergey) created this revision.

This is great! Especially for pre/early production, where we have a bunch of early layout meshes that we want to rig quickly using Surface Deform. I only wish it didn't spam the console in this case! =)

Generally looks fine, makes sense to me to try to keep things working if possible, worst case scenario result will just be weirdly distorted... which is also a good way to warn the user that something is not going well ;)

As already suggested in person, think this is a good opportunity to rename badly named DNA variables though, in a separate commit.

This revision is now accepted and ready to land.May 3 2022, 5:52 PM