[Bf-committers] Make Parent - shouldn't it work differently?

[Bartek Skorupa (priv)]

In one of the previous posts I explained what I do to get proper relation between parent and child and not to lose the position, rotation and scale of the child at the moment of parenting.

The script that I use does this:
1. Stores the current world matrix of the child.
2. Makes parent without inverse
3. sets world matrix of child to previously stored world matrix of the child.

a - parent
b - child
m = b.matrix_world
b.parent = a
b.matrix_world = m

Tested it, it works great, I made an operator from it, assigned keyboard shortcut and I use it regularly.
I can live with current behavior, especially that I don't use it :-) I have my own hack, but I simply think that this should be default.

Bartek Skorupa

www.bartekskorupa.com

On 22 wrz 2012, at 00:14, Bassam Kurdali <bassam at urchn.org> wrote:

> I don't think it should happen by default. it could be especially nasty
> for animation data, linked data, etc. Also it doesn't store as much
> information (the relationship between child and parent at the time of
> parenting) which could come in handy later. However, it is not hard to
> do!
> 
> You need for that is to multiply the inverse transform matrix with the
> world transform matrix. I think - I may have gotten the order wrong.
> so, an easy way :
> 1- do a normal parent operator (creates inverse transform matrix)
> 2- multiply the inverse transform and the regular matrix for the object
> 3- clear inverse transform
> 4- put the matrix from 2 into the transform for the object.
> 
> I think 4 is a bit more complicated, because I *think* that the matrices
> are read-only, so you'll have to decompose into
> translation/rotation/scale (mathutils provides all those functions
> anyway)
> bundle that up into an operator and you're home free.
> Another good option is just to calculate the inverse parent and avoid
> doing the parent-clear inverse dance. If this is done in blender
> internally the same code could be used to avoid having two code paths.
> 
> one possibility for blender behavior is to have a parent menu, with a
> few choices, similar to the un-parent, and keep the current behavior the
> top/default choice.
> 
> On Fri, 2012-09-21 at 21:11 +0200, Bartek Skorupa (priv) wrote:
>> Thank you.
>> However we are only half way there. It solves the major issue as we at least don't have weird properties of the child.
>> The question still remains:
>> How to make a parent such that the child stays at it's current location, rotation and scale, but the values of loc/rot/scale change.
>> This is what should happen by default.
>> 
>> @Bassam Kurdali:
>> You wrote:
>>> the default behaviour should be kept, of course. Most users want this.
>> 
>> 
>> I wouldn't agree with that. I'm scratching my head trying to figure out at least one benefit of current default behavior and can't find anything.
>> Is there any good reason for destroying the order in the scene? Having objects with locations, rotations and scales set in relation to who-the-hell-knows what?
>> What do I miss?
>> 
>> Bartek Skorupa
>> 
>> www.bartekskorupa.com
>> 
>> On 21 wrz 2012, at 20:44, Remigiusz Fiedler <migius at gmx.net> wrote:
>> 
>>> no ctrl needed, it is "alt p - clear inverse parent"
>>> 
>>> 2012/9/21 Bartek Skorupa (priv) <bartekskorupa at bartekskorupa.com>:
>>>> Ctl-Alt-P ??????
>>>> When I hit it I get a warning: "Can only make proxy for a referenced object or group"
>>>> What do I miss?
>>>> 
>>> _______________________________________________
>>> 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