Page MenuHome

Vertex Weight Modifier
Closed, ArchivedPublicPATCH

Description

As an exercise (and preparing a wider project), I have coded a new modifier, which affects the weights of a given vertex group.

Currently, it only uses the distance between another object and the vertices (or the whole mesh object) to modify these weights.

Go to wiki.blender.org/index.php/User:Mont29/WeightVGroup/Main to learn more, and see a small video illustrating it (coming soon…).

This is my first C development for Blender, so I hope it is correct (at least it works on my machine ;) ). I heavily copied/edited other modifiers’ code, using them as sort of templates…

I use a laptop (i7 720QM and HD5730 mobility 1GB) under Debian Squeeze, and CMake build system.

The patch file included is built against the 34776 svn revision.

I also attached a test/demo blend file.

Event Timeline

A new patch, built against svn 34904.
Also, now using BLI_strncopy instead of standard strcopy

And as soon as I’ll have access to graphicall.org, I’ll try to put a Blender build with this modifier on it…

A new patch, built against svn 34970.
Added an icon for it (this is why the patch is now compressed!)…

And now, you can test it with this build on graphicall.org (built on a debian testing amd64):
http://graphicall.org/builds/builds/showbuild.php?action=show&id=1731

I open a thread about your proposal on blenderartists.

http://blenderartists.org/forum/showthread.php?t=209779

*Built and tested against svn 35181.

*Big improvements, with four new important functionality (see also the [[User:Mont29/WeightVGroup/Man|Manual page]]):
**You can now use the reference object’s geometry to compute (minimal) distance to the vertices of the affected object.
**Also, the modifier can now add/remove vertices from the vertex group, based on their final computed weight. This makes this modifier also useful for modifiers that do not use vgroup weights, like e.g. the {{Literal|Mask}} one.
**There’s now a mapping power factor, which allows non-linear mappings between the dist and the weight factor.
**Finally, a new mode, {{Literal|Static}}, allows you to affect the vgroup with a constant weight factor, or another VGroup weights. This allows you, among other things, to do some basic actions on vgroup, like clamp, bust-out null-weighted vertices from the vgroup, etc.

*Added two new mix mode options, difference and average.
*Added an optional «revert» step on weightf, before mixing it with old weight.

*A small optimization in the mapping process, now caching the mapping factors to avoid re-computing them for each vertex!
*Another small optimization, now getting the full vertex array instead of getting each vertex one after the other…
*Other minor updates – note however that this might make files created with previous versions of this modifier somewhat incompatible (they’ll load, but some modifier’s property values might be lost…).
*Fixed the steps values for UI sliders, UI changes.

I also added an optimized build, in addition to the debug one:
http://www.graphicall.org/builds/builds/showbuild.php?action=show&id=1736

Another update.
Note this should be the last new-features release – I think we now have quite a large and rather complete choice of functionality…
Of course, if some bugs appear, I’ll (try to) make fixes ;).

*Built and tested against svn 35286.

*Another big improvements “release”, with two new important functionality (see also the [[User:Mont29/WeightVGroup/Man|Manual page]]):
**Textures can now be used as weight factor sources as well (via a forth mode, {{Literal|Texture}}). Huh! Took me an hour to figure out that using texture ID implied to implement a foreachIDLink func!
**I Added an optional custom curve mapping to affect the weight factor before mixing it with old weight. Note this implied to edit writefile.c/readfile.c, to store/load that curve!

*Use Ref Object Geometry now also available in OBJ2OBJDIST mode (even though I’m not sure it will be most useful ;) ).

*Moved the MOD_WEIGHTVGROUP_ZEROFLOOR def from DNA_modifier_types.h to MOD_weightvgroup.c (had nothing to do in dna stuff…).
*Upgraded UI accordingly.

*Built and tested against svn 35433.

*Changed “0” func pointers into NULL ones (in ModifierTypeInfo struct).

Updated patch against svn 35798

Updated the patch to svn 36380…

IMO this is too specific for a modifier, this kind of functionality should be solved in the nodetree. Of course this modifier is useful but there could be a million variables of the same idea and this can't contemplate them all

Yes Daniel, I agree having a node-based modifier system would be great – we might even have it soon ;)

But meanwhile, I think this modifier helps anyway – its nearly the only solution to animate (other than manually) vgroups right now, afaik !

And there’s already quite a few ways (i.e. variables) to affect vgroups through this mod…

Slightly modified the UI
Updated the patch to svn36818…

Slightly modified the UI again (work from zeauro).
Updated the patch to svn37200…

Also uploaded the latest version of my .blend test file…

Also uploaded the latest version of my .blend test file…

Weight Modifier review

So, from looking at the initial patch, this functionality is undoubtedly very useful.

However there are a few reservations I have about the modifier.

First a general comment that there are many possible modifier you could have that modify weights, you may for example want to weight vertices based on the change in shape from the base mesh or based on convex areas, or generated based on some aspect of the geometry, I feel like weight modifiers are better suited to being used in a node setup and this is worth raising with other developers when deciding weather to accept this patch.

So ignoring the possibilities of nodal modifiers Ill go on with the functional review.

The main issue I have with this modifier is it includes too much functionality in a single modifier, just because the modifier edits vertex groups is not a good enough reason to include everything in 1 modifier, IMHO this is best from both a code + usability standpoint.


For example, using the distance from another objects geometry to influence the weights is very different from using a texture, or another vertex group to modulate a vertex group.

So I'd suggest to break this into 3 modifiers,
(I don't like the names especially, but functionality described)
- Weight Edit: Scale/invert the weight group, adjust weight by curves.
- Weight Mix: Mix 2 weight groups with different mix modes.
- Weight Proximity: The part of the modifier which adjusts weight based on close geometry or object distance can be made into its own modifier.

Each of the modifiers can optionally use a secondary vertex group and texture to mask/adjust their influence.

Implementation details.
1) Currently the modifier always copies the mesh, It could modify the existing weights in place in cases when the base mesh is not modified.
2) Currently objdst_use_refobj_mesh uses its own cached data structure, but I think it would be better to use the existing BVH mesh acceleration structure which derivedmesh supports, getting the nearest point to a face or edge is supported.

Ok, so here are the changes I made:

* There are now three WeightVG modifiers, Edit (which does mapping, adding/removing of vertices to/from vgroups, and clamping), Mix (which mixes two vgroups, or a vgroup and a float value), and Proximity (which uses distance to another object or its geometry as weights).
* All those three modifiers have an influence factor, and optionally a masking vgroup or texture.
* Also, now using BVH in Proximity, and only copying MDEFORMVERT cdl, when doing a copy of dm (didn’t found yet how to detect whether a dm has the org cdl or not, though…).

So basically, you can do the same things as with previous monoblock version, plus a few others, but sometimes at the cost of a bit more work, and the use of an intermediary vgroup might be necessary in a few situations.

Note also that this implies that output vgroups might (will) have weights out of standard [0.0, 1.0] range – it’s up to the user to decide whether (s)he wants to ultimately clamp them, or not!

I also attached an updated test blend file, as ones saved with previous versions will loose all WeightVGroup setups…

I’ll update the doc this week, and perhaps try to make a new demo video too…

Grr… Dummy mistake, had to update patch and builds!

Hi Bastien reviewed you're updated patch. svn38504
attached slightly updated version, only made it build on linux and made weight_vg_mask in properties_data_modifier.py a staticmathod.
removed old modifier too which was not built but still included in the patch.

Review
---
There are still some changes I think should be made, but would like to make these changes in an SVN branch (or perhaps GIT?),
Since I think its better to make them before people start using them in trunk.

From a quick review
- Going into weight paint mode with these modifiers enabled results in a strange bug where the entire mesh shows as an orange color, perhaps this is because they are not clamped?
- Readfile initializes curve mapping, I'm not sure why this would be needed, shouldn't the modifier do this on creation? - Commenting this code the file saves/loads ok still.
- get_ob2ob_distance doesn;t need to call mat4_to_loc_rot_size at all, this is enough.
return len_v3v3(ob->obmat[3], rob->obmat[3]);

RNA (Being Picky Here, think these are easiest done in a branch, I could help with them too)
- O2O, O2V - Should be more clear with names here Object Distance, Vertex Distance for eg.
- Button min/max's for all modifiers mean dragging values easy go over 100 +, when in some of these Im quite sure a range of 0-1 is typical.
- Proximity Modifier haw 3x 'To Targer' Buttons, should show vert/edge/face.
- Some other rna name cleanups would be good but think this is better done in a branch, at least not be uploading updated patches each time.

Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Oct 21 2011, 2:57 PM

Bastien, you're a genius!

Campbell and Top Brass: thank you for including this in the official BF2.6x releases!

Have you guys any idea of how useful the Weight Proximity can be,
for fitting CLOTHES ??