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

Bastien Montagne montagne29 at wanadoo.fr
Wed Aug 17 15:16:39 CEST 2011

Hy Campbell, and sorry again for this late reply…

Now that I’m back to « work » ;) , I’ve committed the changes you suggested (I agree that as we do not allow out-of-range weights, all mapping&  clamping can now be done with the curve control…). I only commented out the code for now, though – and let the DNA structure untouched, to allow « old » files to load correctly !

On Tue, 9 Aug 2011 14:35:56 +1000, Campbell Barton<ideasman42 at gmail.com>  wrote:

> Hi Bastien, once you have the range clamping in I'd like to go over a
> final review, take time to understand the use case for some of the
> settings, this wasn't clear to me without range clamping but I got the
> impression some were redundant or gave very similar functionality but
> I could be wrong.
> Having a curve, a multiplier and clamp settings may not be needed -
> the curve on its own should be enough?
> On Mon, Aug 8, 2011 at 11:06 PM, Bastien Montagne<montagne29 at wanadoo.fr>  wrote:
>> 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.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> -- - Campbell

More information about the Bf-committers mailing list