[Bf-committers] Bf-committers Digest, Vol 85, Issue 1

[Bastien Montagne]

Ok, so I’ll commit (later today, I hope…) modifiers with clamped values 
(and min/max mapping for distance)… Once that will be done, I think we 
might consider VGroupModifiers as mergeable (unless Campbell sees other 
things to fix…).

But, IMHO, if we want to keep vgroups this way, we *really* need more 
general-purpose cdata layers, for vertices as well as edges and faces, 
with ways to “convert” them into vgroups/crease/whatever more specific 
cdatas might be needed. And tools that can use any values (like e.g. 
some modifiers, Wave, Displace, etc.) should then use those generic 
CData layers, instead of vgroups ones…

Cheers,
Bastien

PS : I’m really sorry for my big lack of reactivity, but I’m currently 
in “vacations” curing birds, and have nearly no time for anything else… 
Should be back in a week !

> Message: 11
> Date: Mon, 1 Aug 2011 10:00:29 +0200
> From: Lukas T?nne<lukas.toenne at googlemail.com>
> Subject: Re: [Bf-committers] Weights range in vgroups
> To: bf-blender developers<bf-committers at blender.org>
> Message-ID:
> 	<CANhmeOiA-MNNb41ax4OkZdXr7J7_kdnJGh1kRgFTqyA1YOd4tQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> I don't think I expressed any "opinion", the functionality is useful
>> but probably not the*place*  for this since vgroups are by definition
>> a 0.0-1.0 value. Blender has custom vertex data available in the C
>> API, but everything is so hardcoded that.. good luck using that in a
>> modifier or anywhere else. I keep looking forward to the nodetree and
>> for now I'll go with not enabling this where it doesn't belong.
> Good point!
> I think using vertex groups to store calculated results is a bit of an
> abuse: They are primarily user-defined inputs for modifiers and as
> such should be easily accessible (which includes 0-1 range as Campbell
> pointed out). Even more important might be that modifiers and other
> users of vgroups*expect*  them to be in 0-1 range, which would make
> them ignore out-of-range values in the best case or simply go crazy by
> extrapolating.
>
> Calculated values with unlimited range should instead be stored in
> custom vertex data, but as noted by Daniel these "custom" data layers
> are actually hardcoded - there is no way to add really new data layers
> for things like this, let alone access them anywhere. Nodes would
> unlock that beast, but until then i think it's best to keep them
> inside range limits.