[Bf-committers] Weekly developer meeting minutes, march 4 2012

Bastien Montagne montagne29 at wanadoo.fr
Mon Mar 5 14:01:35 CET 2012


No problem, Nathan, this is a proposition, and if it don’t make it to 
trunk, well, I won’t be much happy, but it’s the game! ;)

As for code, apart from all the RNA/DNA boiling plate, there are two 
areas impacted by that feature:
* Armature Pose bone evaluation itself, which is now gathered into a 
function that works (and will continue to work) as a blackbox for all 
parts of code needing it (pose evaluation, transform, snapping, 
constraints’ space conversions, etc.).
* Armature edit code: Here, it’s mainly checks for each operation that 
might modify the chains, to avoid getting invalid parenting… Many lines, 
but fairly simple (and quite repetitive).

But again, if most users don’t like it (or see it unuseful), well, so be it!

Bastien

Le 05/03/2012 09:26, Nathan Vegdahl a écrit :
>> and it
>> looks like there are some pretty major code changes in there
>> (admittedly, I only glanced through it).
> Looking through it a bit more carefully, "major" is not the right
> word.  But there is a fair bit of added code (300+ lines), and it will
> be code that later transform features will need to make sure they
> interact well with.
>
> I'm not saying that adding code is necessarily bad.  And it doesn't
> look to me like your code is bad (it seems well written, from what I
> remember of C).  It just seems really unnecessary in this case.
>
> Again, I do not mean to be disparaging of your work at all.
>
> --Nathan
>
>
> On Mon, Mar 5, 2012 at 12:08 AM, Nathan Vegdahl<cessen at cessen.com>  wrote:
>> Also, to be clear, I said to deprecate them, not remove them.  I agree
>> that, unfortunately, it would be very difficult to remove them and
>> their associated complexity without causing loading problems of older
>> files.  Although if they are deprecated for long enough, hopefully we
>> can then remove them in the future (although at that point one hopes
>> we could just develop a more modern transform system anyway, that
>> would cover these cases as part of a well thought out and elegant
>> design rather than as a mish-mash of corner-case features).
>>
>> And when I'm speaking of complexity, I'm largely speaking of internal
>> complexity.  Code maintenance.  Covering corner cases that weren't
>> originally envisioned.  Making it harder to add features that _can't_
>> be accomplished already by other means, such that everything works
>> together/isn't buggy.  Etc.
>>
>> I'm not going to kick or scream to keep this out.  As you say, I can
>> simply ignore it if I don't want to use it.  But I think there are
>> good reasons to leave it out.  Specifically, the benefit provided to
>> the user is extremely minor, it doesn't enable anything new, and it
>> looks like there are some pretty major code changes in there
>> (admittedly, I only glanced through it).
>>
>> --Nathan
>>
>>
>> On Sun, Mar 4, 2012 at 11:59 PM, Nathan Vegdahl<cessen at cessen.com>  wrote:
>>>> (and why not local location, while we
>>>> are at it?)
>>> Because the effects of local location cannot be achieved at all
>>> without that feature, much less as simply as one can achieve what
>>> hinge does.
>>>
>>> --Nathan
>>>
>>>
>>> On Sun, Mar 4, 2012 at 11:26 PM, Bastien Montagne<montagne29 at wanadoo.fr>  wrote:
>>>> I don’t think that feature adds that much complexity… On the user POV,
>>>> it changes nothing on a usual use case, just adding some options that
>>>> can become handy in some situations. In fact, it makes a quite specific
>>>> feature more generic, by just replacing two checkboxes by two « search
>>>> data » fields (or dropdown menus)… And it won’t come into your way as
>>>> long as you don’t need it!
>>>>
>>>> Removing hinge/no scale options (and why not local location, while we
>>>> are at it?) would make loading old files quite tricky (as we would have
>>>> to add constraints to mimic those options).
>>>>
>>>> PS: And I think I’ve already proven I do can work on the whole armature
>>>> subsystem, and not only on my « own little systems »! ;)
>>>>
>>>> Le 05/03/2012 07:23, Matt Ebb a écrit :
>>>>> On Mon, Mar 5, 2012 at 6:05 AM, Nathan Vegdahl<cessen at cessen.com>    wrote:
>>>>>> I agree.  But I would still rather see hinge deprecated than improved.
>>>>>>    I guess we just have different thresholds for "added back-end
>>>>>> complexity" vs "shorter workflow".  To me, this has a very minor
>>>>>> workflow benefit, but appears to make quite a lot of changes and add a
>>>>>> fair amount of complexity to the transform code base.
>>>>> +1
>>>>>
>>>>> As a general rule, blender is already too far on the 'overcomplicated
>>>>> hard-coded special cases' side - it needs more in the way of simple,
>>>>> rock solid, generic tools that work capably and reliably, that can be
>>>>> adapted to your own usage patterns. This seems harder to achieve in
>>>>> open source where volunteer devs like to work on their own little
>>>>> systems and portions of code, but it's better for users in the long
>>>>> run.
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



More information about the Bf-committers mailing list