[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/blenkernel/intern effect.c blender/source/blender/src buttons_object.c

[Jean-Luc Peurière]

Le 11 nov. 05 à 22:36, Martin Poirier a écrit :

>
>
> --- Alexander Ewering <blender at instinctive.de> wrote:
>
>>
>> On Fri, 11 Nov 2005, Martin Poirier wrote:
>>
>>> behavior, not only lag (for exemple, two copy loc
>>> constraints that point at one another), but this
>> is
>>> borderline situations, shouldn't happen often (if
>>> ever).
>>
>> I would say this isn't just a code-related question,
>> it's rather
>> a philosophical one. What behaviour *would* you
>> expect in this
>> example situation? :)
>>
>> There are just some situations that *can't* work,
>> because they're
>> undefined...
>
> Which is exacly my point, that's the kind of thing the
> depgraph should prevent (not only simple stuff like a
> cycle in parents) while still allowing stuff like
> tracking cycles without lag.

Hmm.

There is several things there.

First Ton implementation changes are good because they update only
what is needed, but he did use only partly my code as it was intended
  (the nqueue stuff ). sorting the base in not sufficient in all cases.
That makes cycles solving more difficult. My original intent was to  
allow
cycling resolve by inserting one element more than once in the nqueue,
hence breaking it while avoiding too much calculations.

Secondly all cycles cannot be solved . this can be done only if, at a  
finer
level, you can find a non cycling relation. Example, the mutual copyloc
cannot work, but the mutual track_to can if you do it this way :

Ob1 loc  > Ob 2 Loc & rot > Ob 1 rot

When this solution fails, it can be also solved iteratively by  
repeating the
cycles components evaluation. this does work only when things converge,
which is not always the case.

I had some code prepared for my original design, but it wont work now.
I will try to look if i can find how to put back my original ideas in  
the current
framework.

lukep