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

[Nathan Vegdahl]

> To make it flexible and predictable/simple would probably
> take re-engineering a bit- for instance, pulling transform out as
> independent 'thing' that is stackable (or in the future nodable) along
> with constraints,

Yeah, this is what I'm hoping for in the future (I think we've
discussed this before?).

In any case, I think I've changed my mind.  Particularly since it
sounds like this patch also organizes things more cleanly code-side,
which will probably actually make things less likely to break in the
long-run.  And I can always just keep ignoring the option if I don't
want to use it. ;-)

A cleaner system is a larger project anyway, as Bassam notes, so I
probably shouldn't worry about short-term special-case features within
our current more limited system.

--Nathan


On Mon, Mar 5, 2012 at 7:55 AM, Bassam Kurdali  wrote:
> The original hinge option was added by Ton as a simplifier for users;
> the idea was to avoid using multiple bones and constraints when a
> simple option could take care of it.
>
> This fell down almost instantly, because animators asked for a 'global'
> parent bone. had there been an option to limit the hinge length - like
> in IK constraints - it would have been possible to use.
>
> Complexity in dealing with the Hinge during transform is probably
> similar to constraint offsets - which, (and this supports the
> naysayers) was broken until very, very recently, until somebody (maybe
> Bastien himself) fixed it.
>
> >From a python perspective, my code always works with hinge options and
> I'd support this, but I throw up my arms in frustration if there's
> constraints on a bone (I want to affect).
>
> My final comment:
> the complexity of this system is not fixable by removing options. That
> will just make it rigid (in general, not talking about this specific
> situation). To make it flexible and predictable/simple would probably
> take re-engineering a bit- for instance, pulling transform out as
> independent 'thing' that is stackable (or in the future nodable) along
> with constraints, which eliminates the need for specific offsets in
> constraints, dx,dy,dz graphs, parent offsets, heck, maybe parenting
> itself becomes a constraint and a transform.
>
> However, until that, or something similar happens, why not make this
> option actually usable? it would eliminate some level of complexity in
> rigs, which can't be a terrible thing after all.
>
>
>> I don't know about code complexity, but about usability, the hinge
>> option has the disadvantage of being toggleable only. A setup based
>> on constraints lets you decrease or increase the influence of the
>> effect, in the case that you need to.
>>
>> But well, you have to admit that having the hinge option available
>> might be useful for people who don't like or don't know much rigging.
>>
>> If this modification promised not to affect the performance of
>> complex armatures I wouldn't mind having it, I think I'd never use it
>> anyway, hehe, but that's just me, many people might be comfortable
>> with the hinge option. But well, if it depended on me, the only
>> condition would be that this didn't affect performance. So I guess it
>> should be tested with complex rigs.
>>
>>
>>
>> > Date: Sun, 4 Mar 2012 22:05:22 -0800
>> > From: ces...@cessen.com
>> > To: bf-committers@blender.org
>> > Subject: Re: [Bf-committers] Weekly developer meeting minutes,
>> > march 4 2012
>> >
>> > > However, at the other end of the spectrum, you
>> > > don't want the rigger doing too much stuff over
>> > > and over.
>> >
>> > 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.
>> >
>> > When a short-cut feature is very localized to a small area of code
>> > (e.g. the head/tail slider on copy location constraints) I am much
>> > more comfortable with it.  But to my eyes this looks like overkill.
>> >
>> > Quoting again:
>> >
>> > > you
>> > > don't want the rigger doing too much stuff over
>> > > and over.
>> >
>> > The other thing is that this doesn't actually reduce that much
>> > repetition.
>> >
>> > Maybe I'm biased because of Rigify, but improving the hinge feature
>> > to reduce repetition in rigging seems to me like giving someone a
>> > hand warmer when they're stuck in a violent snow storm.  It helps a
>> > little, I guess, but... not much.  There are so many sources of
>> > repetition in rigging.  Making this single specific case easier--at
>> > the expense of a lot of code complexity--doesn't really seem worth
>> > it to me.  It's not really a "sustainable" way to make rigging
>> > easier/faster.
>> >
>> > --Nathan
>> >
>> >
>> > On Sun, Mar 4, 2012 at 7:22 PM, Mike Belanger
>> >  wrote:
>> > > This new feature looks like it might re-validate Hinge. 

Re: [Bf-committers] ListBase vs. slots

[Tom Edwards]

OK, solved it in the RNA get function:

static PointerRNA rna_actlib_get(CollectionPropertyIterator *iter)
{
 return rna_pointer_inherit_refine(&iter->parent, &RNA_Action, 
((LinkData*)rna_iterator_listbase_get(iter))->data);
}

That's what needs to be offered by the API.

On 05/03/2012 10:48, Tom Edwards wrote:
> I'm trying to refactor some code from the "array of pointers" solution
> used by material/texture slots to ListBase, as a result of code review.
> But I'm beginning to think that Blender doesn't support that.
>
> The code in question is my Action Library patch from last October. It
> allows AnimData to store a list of associated Actions in addition to the
> single "active action" it currently stores.
> 
>
> ListBase usually takes IDs directly, but since I'm not creating a global
> list of IDs I am having to use LinkData instead. For reference:
>
> typedef struct LinkData
> {
>   struct LinkData *next, *prev;
>   void *data;
> } LinkData;
>
> This works fine in C, but accessing items with Python crashes. Python
> can walk the list just fine (*next and *prev are as it expects) but
> doesn't seem to understand the *data indirection of LinkData.
>
> Is there a RNA setting I've overlooked here? If not, I vote for
> supporting ListBase->LinkData collections. They are immediately
> applicable to material slots, texture slots, and I suspect particle
> system settings too. :)
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] ListBase vs. slots

[Tom Edwards]

I'm trying to refactor some code from the "array of pointers" solution 
used by material/texture slots to ListBase, as a result of code review. 
But I'm beginning to think that Blender doesn't support that.

The code in question is my Action Library patch from last October. It 
allows AnimData to store a list of associated Actions in addition to the 
single "active action" it currently stores. 


ListBase usually takes IDs directly, but since I'm not creating a global 
list of IDs I am having to use LinkData instead. For reference:

typedef struct LinkData
{
 struct LinkData *next, *prev;
 void *data;
} LinkData;

This works fine in C, but accessing items with Python crashes. Python 
can walk the list just fine (*next and *prev are as it expects) but 
doesn't seem to understand the *data indirection of LinkData.

Is there a RNA setting I've overlooked here? If not, I vote for 
supporting ListBase->LinkData collections. They are immediately 
applicable to material slots, texture slots, and I suspect particle 
system settings too. :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Cycles performance

[Mike Pan]

Not to start another OS debate. But...

I noticed that the performance of Cycles is very OS-dependent. With the old
rendering engine, the OS can influence the rendering time by ~10%. But with
Cycles, i am seeing a huge difference in performance between Windows and
Linux/Mac, where Linux/Mac is often twice as fast.

This cleaned up chart by
Olivierclearly
shows the discrepancy:
http://oenvoyage.files.wordpress.com/2012/02/benchmark_win_linux.png

I've done my own dual-boot test and the results as as follows:

Cycles Render: (huge difference in render time)
OS X: 3:27
Win 7: 6:14

Classic Render: (similar time, as expected)
OS X: 1:24
Win 7: 1:29

Both OS are running natively (not under virtual machine), using the 64bit
version of Blender 2.62.

My question is, Is there any technical reason behind this? thread
management? malloc overhead?

Mike
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44654] trunk/blender/source/blender/imbuf /intern/openexr/openexr_api.cpp: Fix for OpenEXR half float save function resulting in

[Campbell Barton]

The reason support for saving non-linear Imbufs was added is because
float sequencer buffers were not linear (internally AFAIK they are
still not - this is needed for sequencer float blending which differs
with linear buffers),
However I tested this change and it works ok - sequencer must become
linear before its passed to OpenEXR save now.

Just a note incase this issue crops up again.

On Tue, Mar 6, 2012 at 5:55 AM, Sergey Sharybin  wrote:
> Revision: 44654
>          
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=44654
> Author:   nazgul
> Date:     2012-03-05 18:54:57 + (Mon, 05 Mar 2012)
> Log Message:
> ---
> Fix for OpenEXR half float save function resulting in dark images saved
>
> Float buffers of ImBuf are always supposed to be linear space a,d ImBuf's
> profile means how byte array was constructed from float buffer.
>
> Modified Paths:
> --
>    trunk/blender/source/blender/imbuf/intern/openexr/openexr_api.cpp
>
> Modified: trunk/blender/source/blender/imbuf/intern/openexr/openexr_api.cpp
> ===
> --- trunk/blender/source/blender/imbuf/intern/openexr/openexr_api.cpp   
> 2012-03-05 18:05:06 UTC (rev 44653)
> +++ trunk/blender/source/blender/imbuf/intern/openexr/openexr_api.cpp   
> 2012-03-05 18:54:57 UTC (rev 44654)
> @@ -234,34 +234,17 @@
>                if(ibuf->rect_float) {
>                        float *from;
>
> -                       if(ibuf->profile == IB_PROFILE_LINEAR_RGB) {
> -                               for (int i = ibuf->y-1; i >= 0; i--)
> -                               {
> -                                       from= ibuf->rect_float + 
> channels*i*width;
> +                       for (int i = ibuf->y-1; i >= 0; i--)
> +                       {
> +                               from= ibuf->rect_float + channels*i*width;
>
> -                                       for (int j = ibuf->x; j > 0; j--)
> -                                       {
> -                                               to->r = from[0];
> -                                               to->g = from[1];
> -                                               to->b = from[2];
> -                                               to->a = (channels >= 4)? 
> from[3]: 1.0f;
> -                                               to++; from += 4;
> -                                       }
> -                               }
> -                       }
> -                       else {
> -                               for (int i = ibuf->y-1; i >= 0; i--)
> +                               for (int j = ibuf->x; j > 0; j--)
>                                {
> -                                       from= ibuf->rect_float + 
> channels*i*width;
> -
> -                                       for (int j = ibuf->x; j > 0; j--)
> -                                       {
> -                                               to->r = 
> srgb_to_linearrgb(from[0]);
> -                                               to->g = 
> srgb_to_linearrgb(from[1]);
> -                                               to->b = 
> srgb_to_linearrgb(from[2]);
> -                                               to->a = (channels >= 4)? 
> from[3]: 1.0f;
> -                                               to++; from += 4;
> -                                       }
> +                                       to->r = from[0];
> +                                       to->g = from[1];
> +                                       to->b = from[2];
> +                                       to->a = (channels >= 4)? from[3]: 
> 1.0f;
> +                                       to++; from += 4;
>                                }
>                        }
>                }
>
> ___
> Bf-blender-cvs mailing list
> bf-blender-...@blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-cvs



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada Patches in Tracker.

[Sergey Kurdakov]

Hi

BTW

https://collada.org/mediawiki/index.php/Open_Letter_March_2012

finally they started to approach the problems Blender devs discussed for
quite a time.

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada Patches in Tracker.

[angjminer]

the custom properties patch by dias works wonderfully. 
i used it in cryblend. 
and i didnt have the first problem out of it,and none of the
people who are using cryblend right now have complained about the 
custom props not working. 

i have switched to doing an addon but i thought you guys should know 
that one works great. 

btw if you guys do switch to python for collada, the addon i am writing 
is using the same formula's
you have in the internal(with some borrowed from the fbx exporter) 
notably the animation export. 
i am trying to make the output look identical to the internal export. 

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada Patches in Tracker.

[Tom M]

You might want to check the patches to see if any of them fix those bugs :)

LetterRip

On Sun, Mar 4, 2012 at 9:16 PM, Arystanbek Dyussenov
 wrote:
> Hi,
>
> I will be able to look into these patches after fixing this urgent bug (
> http://projects.blender.org/tracker/index.php?func=detail&aid=30440&group_id=9&atid=498)
> and other urgent bugs from this list:
> http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Import_Export#Import:_Bugs
> .
>
> On Mon, Mar 5, 2012 at 8:19 AM, Campbell Barton wrote:
>
>> There are 7 collada patches in the tracker, most not assigned to
>> anyone and some with no replies.
>>
>> After all the noise about collada support - is anyone able to review
>> these patches?
>>
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30070&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30111&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30112&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30149&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30199&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=30200&group_id=9&atid=127
>>
>> http://projects.blender.org/tracker/index.php?func=detail&aid=29357&group_id=9&atid=127
>>
>> --
>> - Campbell
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> Best regards,
> Arystanbek Dyussenov
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Makesdna fails with "wrong" pointer syntax

[Campbell Barton]

Added check r44651. this is now explicitly disallowed and wont compile
when its used.
Support for this syntax ends up with bigger changes then I'd have
liked so its not really worth it IMHO.

On Mon, Mar 5, 2012 at 11:45 PM, Campbell Barton  wrote:
> Agree this is horrible and incredibly frustrating when running into
> problems like this (especially with DNA).
> I'll look into a fix.
>
> On Mon, Mar 5, 2012 at 8:04 PM, Tom Edwards  wrote:
>> I don't mind if it throws an error, just so long as it throws one.
>>
>> On 05/03/2012 12:31, Joshua Leung wrote:
>>> Legal but semantically confusing:
>>> ID* a, b, c;<--- only a is pointer, b and c are not.
>>>
>>> IMO this is bad style, and I'm glad that makesdna actually ends up
>>> enforcing it, albeit with a confusing error message. So, a big -1 to
>>> this idea from me.
>>>
>>> On Mon, Mar 5, 2012 at 1:20 PM, Tom Edwards  wrote:
 Hi everyone. I just spent 1hr+ hunting an annoying bug down. The
 following declaration in a DNA header will cause makesdna to fail with a
 generic "strut unknown" error, despite being entirely legal:

 ID* data;

 Putting the space in front of the asterisk avoids the problem. Fix
 please? :)
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Bassam Kurdali]

The original hinge option was added by Ton as a simplifier for users;
the idea was to avoid using multiple bones and constraints when a
simple option could take care of it.

This fell down almost instantly, because animators asked for a 'global'
parent bone. had there been an option to limit the hinge length - like
in IK constraints - it would have been possible to use.

Complexity in dealing with the Hinge during transform is probably
similar to constraint offsets - which, (and this supports the
naysayers) was broken until very, very recently, until somebody (maybe
Bastien himself) fixed it.

>From a python perspective, my code always works with hinge options and
I'd support this, but I throw up my arms in frustration if there's
constraints on a bone (I want to affect).

My final comment: 
the complexity of this system is not fixable by removing options. That
will just make it rigid (in general, not talking about this specific
situation). To make it flexible and predictable/simple would probably
take re-engineering a bit- for instance, pulling transform out as
independent 'thing' that is stackable (or in the future nodable) along
with constraints, which eliminates the need for specific offsets in
constraints, dx,dy,dz graphs, parent offsets, heck, maybe parenting
itself becomes a constraint and a transform.

However, until that, or something similar happens, why not make this
option actually usable? it would eliminate some level of complexity in
rigs, which can't be a terrible thing after all.


> I don't know about code complexity, but about usability, the hinge
> option has the disadvantage of being toggleable only. A setup based
> on constraints lets you decrease or increase the influence of the
> effect, in the case that you need to.
> 
> But well, you have to admit that having the hinge option available
> might be useful for people who don't like or don't know much rigging.
> 
> If this modification promised not to affect the performance of
> complex armatures I wouldn't mind having it, I think I'd never use it
> anyway, hehe, but that's just me, many people might be comfortable
> with the hinge option. But well, if it depended on me, the only
> condition would be that this didn't affect performance. So I guess it
> should be tested with complex rigs.
> 
>   
> 
> > Date: Sun, 4 Mar 2012 22:05:22 -0800
> > From: ces...@cessen.com
> > To: bf-committers@blender.org
> > Subject: Re: [Bf-committers] Weekly developer meeting minutes,
> > march 4 2012
> > 
> > > However, at the other end of the spectrum, you
> > > don't want the rigger doing too much stuff over
> > > and over.
> > 
> > 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.
> > 
> > When a short-cut feature is very localized to a small area of code
> > (e.g. the head/tail slider on copy location constraints) I am much
> > more comfortable with it.  But to my eyes this looks like overkill.
> > 
> > Quoting again:
> > 
> > > you
> > > don't want the rigger doing too much stuff over
> > > and over.
> > 
> > The other thing is that this doesn't actually reduce that much
> > repetition.
> > 
> > Maybe I'm biased because of Rigify, but improving the hinge feature
> > to reduce repetition in rigging seems to me like giving someone a
> > hand warmer when they're stuck in a violent snow storm.  It helps a
> > little, I guess, but... not much.  There are so many sources of
> > repetition in rigging.  Making this single specific case easier--at
> > the expense of a lot of code complexity--doesn't really seem worth
> > it to me.  It's not really a "sustainable" way to make rigging
> > easier/faster.
> > 
> > --Nathan
> > 
> > 
> > On Sun, Mar 4, 2012 at 7:22 PM, Mike Belanger
> >  wrote:
> > > This new feature looks like it might re-validate Hinge.  From
> > > what I understand from the wiki, a bone inheriting from not its
> > > immediate parent, but from its earlier parent *could* be useful.
> > > Sure, like Nathan says, the behaviour can be done with trivial
> > > rig setups.  However, at the other end of the spectrum, you don't
> > > want the rigger doing too much stuff over and over.  In theory,
> > > the rigger *could* 'flatten' the entire hierarchy (minus the ik
> > > arms) and have basically no child bones, and define all
> > > relationships with constraints - but that'd be a lot of work.
> > >
> > > Interested in this feature.
> > >
> > > On 2012-03-04, at 7:53 PM, Nathan Vegdahl wrote:
> > >
> > >>> - Bastien Montagne worked on new/better definition for "Hinge"
> > >>> bone:
> > >>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
> > >>
> > >> In no way do I intend to disparage Bastien's work on this, but is
> > >> improving the hinge

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

[Juan Pablo Bouza]

I don't know about code complexity, but about usability, the hinge option has 
the disadvantage of being toggleable only. A setup based on constraints lets 
you decrease or increase the influence of the effect, in the case that you need 
to.

But well, you have to admit that having the hinge option available might be 
useful for people who don't like or don't know much rigging.

If this modification promised not to affect the performance of complex 
armatures I wouldn't mind having it, I think I'd never use it anyway, hehe, but 
that's just me, many people might be comfortable with the hinge option. But 
well, if it depended on me, the only condition would be that this didn't affect 
performance. So I guess it should be tested with complex rigs.

  

> Date: Sun, 4 Mar 2012 22:05:22 -0800
> From: ces...@cessen.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Weekly developer meeting minutes, march 4 2012
> 
> > However, at the other end of the spectrum, you
> > don't want the rigger doing too much stuff over
> > and over.
> 
> 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.
> 
> When a short-cut feature is very localized to a small area of code
> (e.g. the head/tail slider on copy location constraints) I am much
> more comfortable with it.  But to my eyes this looks like overkill.
> 
> Quoting again:
> 
> > you
> > don't want the rigger doing too much stuff over
> > and over.
> 
> The other thing is that this doesn't actually reduce that much repetition.
> 
> Maybe I'm biased because of Rigify, but improving the hinge feature to
> reduce repetition in rigging seems to me like giving someone a hand
> warmer when they're stuck in a violent snow storm.  It helps a little,
> I guess, but... not much.  There are so many sources of repetition in
> rigging.  Making this single specific case easier--at the expense of a
> lot of code complexity--doesn't really seem worth it to me.  It's not
> really a "sustainable" way to make rigging easier/faster.
> 
> --Nathan
> 
> 
> On Sun, Mar 4, 2012 at 7:22 PM, Mike Belanger
>  wrote:
> > This new feature looks like it might re-validate Hinge.  From what I 
> > understand from the wiki, a bone inheriting from not its immediate parent, 
> > but from its earlier parent *could* be useful.  Sure, like Nathan says, the 
> > behaviour can be done with trivial rig setups.  However, at the other end 
> > of the spectrum, you don't want the rigger doing too much stuff over and 
> > over.  In theory, the rigger *could* 'flatten' the entire hierarchy (minus 
> > the ik arms) and have basically no child bones, and define all 
> > relationships with constraints - but that'd be a lot of work.
> >
> > Interested in this feature.
> >
> > On 2012-03-04, at 7:53 PM, Nathan Vegdahl wrote:
> >
> >>> - Bastien Montagne worked on new/better definition for "Hinge" bone:
> >>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
> >>
> >> In no way do I intend to disparage Bastien's work on this, but is
> >> improving the hinge feature even necessary?  In my mind, the hinge
> >> feature is deprecated.  I never use it.  You can accomplish the same
> >> behaviors (including the behaviors that this patch would enable, and
> >> beyond) with trivial rig setups.  This just feels like unnecessary UI
> >> clutter and code complexity to me.
> >>
> >> I'm not saying we shouldn't have *any* shortcuts in Blender's rigging
> >> features.  I just think we should be selective.  Perhaps my
> >> selectivity threshold in this case isn't calibrated that same as
> >> other's...?
> >>
> >> --Nathan
> >>
> >>
> >> On Sun, Mar 4, 2012 at 9:23 AM, Ton Roosendaal  wrote:
> >>> Hi all,
> >>>
> >>> Here's the notes from today's meeting:
> >>>
> >>> 1) current projects
> >>>
> >>> - Today BCon2 starts, which means we should freeze the release targets 
> >>> now.
> >>>  http://wiki.blender.org/index.php/Dev:Doc/Projects
> >>>
> >>> - Lukas Toenne finished group nodes patch, awaits review still, added to 
> >>> release targets.
> >>>
> >>> - Cambell Barton fixed BMesh docs as agreed last week. Check his week 
> >>> report here:
> >>>  
> >>> http://wiki.blender.org/index.php/User:Ideasman42/WhatImWorkingOn#Week_80_.28Feb_27.29
> >>>
> >>> - Lukas also is working on custom nodes: (similar to pynode, as first 
> >>> step towards plugins)
> >>> https://www.gitorious.org/~lukastoenne/blenderprojects/blender-lukastoenne/commits/custom_nodes
> >>>
> >>> - Bastien Montagne worked on new/better definition for "Hinge" bone:
> >>> http://wiki.blender.org/index.php/User:Mont29/Dev/Pose_Bone_RotScale_Parenting
> >>>
> >>> - Nicholas Bishop: sculpt masking is getting closer to finished, there 
> >>> are patches and d

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

[Bastien Montagne]

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  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  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  
>>> 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
> 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@blender.org

Re: [Bf-committers] Makesdna fails with "wrong" pointer syntax

[Campbell Barton]

Agree this is horrible and incredibly frustrating when running into
problems like this (especially with DNA).
I'll look into a fix.

On Mon, Mar 5, 2012 at 8:04 PM, Tom Edwards  wrote:
> I don't mind if it throws an error, just so long as it throws one.
>
> On 05/03/2012 12:31, Joshua Leung wrote:
>> Legal but semantically confusing:
>> ID* a, b, c;<--- only a is pointer, b and c are not.
>>
>> IMO this is bad style, and I'm glad that makesdna actually ends up
>> enforcing it, albeit with a confusing error message. So, a big -1 to
>> this idea from me.
>>
>> On Mon, Mar 5, 2012 at 1:20 PM, Tom Edwards  wrote:
>>> Hi everyone. I just spent 1hr+ hunting an annoying bug down. The
>>> following declaration in a DNA header will cause makesdna to fail with a
>>> generic "strut unknown" error, despite being entirely legal:
>>>
>>> ID* data;
>>>
>>> Putting the space in front of the asterisk avoids the problem. Fix
>>> please? :)
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Makesdna fails with "wrong" pointer syntax

[Tom Edwards]

I don't mind if it throws an error, just so long as it throws one.

On 05/03/2012 12:31, Joshua Leung wrote:
> Legal but semantically confusing:
> ID* a, b, c;<--- only a is pointer, b and c are not.
>
> IMO this is bad style, and I'm glad that makesdna actually ends up
> enforcing it, albeit with a confusing error message. So, a big -1 to
> this idea from me.
>
> On Mon, Mar 5, 2012 at 1:20 PM, Tom Edwards  wrote:
>> Hi everyone. I just spent 1hr+ hunting an annoying bug down. The
>> following declaration in a DNA header will cause makesdna to fail with a
>> generic "strut unknown" error, despite being entirely legal:
>>
>> ID* data;
>>
>> Putting the space in front of the asterisk avoids the problem. Fix
>> please? :)
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Nathan Vegdahl]

> 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  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  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  
>> 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  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@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Nathan Vegdahl]

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  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  
> 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  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@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers