Vertex Weight Modifier #26108

Closed
opened 2011-02-16 16:48:46 +01:00 by Bastien Montagne · 30 comments

%%%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.
%%%

%%%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. %%%
Author
Owner

Changed status to: 'Open'

Changed status to: 'Open'
Author
Owner

%%%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 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…%%%
Author
Owner

%%%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%%%

%%%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%%%

%%%I open a thread about your proposal on blenderartists. http://blenderartists.org/forum/showthread.php?t=209779%%%
Author
Owner

%%%*Built and tested against svn 35181.

*Big improvements, with four new important functionality (see also the 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%%%

%%%*Built and tested against svn 35181. *Big improvements, with four new important functionality (see also the [Manual page](User:Mont29/WeightVGroup/Man)): **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%%%
Author
Owner

%%%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 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.
%%%

%%%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 [Manual page](User:Mont29/WeightVGroup/Man)): **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. %%%
Author
Owner

%%%*Built and tested against svn 35433.

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

%%%*Built and tested against svn 35433. *Changed “0” func pointers into NULL ones (in ModifierTypeInfo struct). %%%
Author
Owner

%%%Updated patch against svn 35798%%%

%%%Updated patch against svn 35798%%%
Author
Owner

%%%updated patch to svn 35916…%%%

%%%updated patch to svn 35916…%%%
Author
Owner

%%%updated the patch to svn 36014…%%%

%%%updated the patch to svn 36014…%%%
Author
Owner

%%%Updated the patch to svn 36147…%%%

%%%Updated the patch to svn 36147…%%%
Author
Owner

%%%Updated the patch to svn 36281…%%%

%%%Updated the patch to svn 36281…%%%
Author
Owner

%%%Updated the patch to svn 36380…%%%

%%%Updated the patch to svn 36380…%%%
Member

%%%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%%%

%%%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%%%
Author
Owner

%%%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…%%%

%%%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…%%%
Author
Owner

%%%Updated the patch to svn36707…%%%

%%%Updated the patch to svn36707…%%%
Author
Owner

%%%Slightly modified the UI
Updated the patch to svn36818…%%%

%%%Slightly modified the UI Updated the patch to svn36818…%%%
Author
Owner

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

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

%%%Updated the patch to svn37436…%%%

%%%Updated the patch to svn37436…%%%
Author
Owner

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

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

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

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

%%%Updated the patch to svn37749…%%%

%%%Updated the patch to svn37749…%%%
Author
Owner

%%%Updated the patch to svn38009…%%%

%%%Updated the patch to svn38009…%%%

%%%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.%%%
%%%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.%%%
Author
Owner

%%%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…%%%

%%%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…%%%
Author
Owner

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

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

%%%Updated patch to svn38504%%%

%%%Updated patch to svn38504%%%

%%%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.
    %%%
%%%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. %%%
Author
Owner

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'

%%%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 ??%%%

%%%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 ??%%%
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#26108
No description provided.