[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [29315] trunk/blender/source/blender/ modifiers/intern: Fixed bug #21540, Array Modifier Capping refresh on open problem.

[Nicholas Bishop]

After looking a bit more, I'm now thoroughly confused :)

Here's what I see so far:
1. Even without my patch, there's still a dependency cycle issue. If I
create two objects (ob1, ob2), and give both of them array modifiers,
then set ob1's cap to ob2, and set ob2's cap to ob1, it allows me to
do so. Then, if I cause both of them to update, e.g. by selecting both
of them and moving them around, they grow off into infinity (and
Blender hangs if I try to render.) Perhaps the depsgraph is removing
this cycle, but the array modifier doesn't know that, so it keeps
accessing cap->derivedFinal and recursing?

2. Is this situation what you meant by dependency cycles, or is there
another dep cycle issue? It seems like if the issue above was
prevented (as in, ob2 would not allow its cap to be set to ob1, since
that creates a cycle) there wouldn't be a problem with calling
mesh_get_derived_final, but perhaps I'm missing something.

3. As far as I can tell, the depsgraph just marks what needs to be
updated, it doesn't enforce the order objects get updated in. It looks
like scene.c traverses the object list in order and an object updates
itself if it's been tagged to do so. So it seems like a dependency
might not update itself until after the parent has already done
object_handle_update?

My knowledge of the depsgraph is clearly a bit sketchy :)

-Nicholas

On Mon, Jun 7, 2010 at 3:50 PM, Brecht Van Lommel <brecht at blender.org> wrote:
> I'm not working on this, if you want to fix it go ahead.
>
> Brecht.
>
> On Mon, Jun 7, 2010 at 9:18 PM, Nicholas Bishop
> <nicholasbishop at gmail.com> wrote:
>> Ah OK. Reverted that commit, will look at fixing this properly (unless
>> you are already doing this?)
>>
>> -Nicholas
>>
>> On Mon, Jun 7, 2010 at 2:52 PM, Brecht Van Lommel <brecht at blender.org> wrote:
>>> Hi Nicholas,
>>>
>>> This is not the right fix, the dependency graph should ensure that
>>> ob->derivedFinal is created before this modifier runs. Previously
>>> modifiers called mesh_get_derived_final, but with dependency cycles
>>> this can hang.
>>>
>>> Thanks,
>>> Brecht.
>>>
>>> On Mon, Jun 7, 2010 at 8:21 PM, Nicholas Bishop
>>> <nicholasbishop at gmail.com> wrote:
>>>> Revision: 29315
>>>>          http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=29315
>>>> Author:   nicholasbishop
>>>> Date:     2010-06-07 20:20:59 +0200 (Mon, 07 Jun 2010)
>>>>
>>>> Log Message:
>>>> -----------
>>>> Fixed bug #21540, Array Modifier Capping refresh on open problem.
>>>>
>>>> * Problem was that the modifier directly accessed ob->derivedFinal, but that wasn't being built if the object was on a different layer. Changed to mesh_get_derived_final.
>>>>
>>>> Notes:
>>>> * I fixed this for array and boolean, reported in the bug; there might be other places affected by this mistake. It's an easy fix if so.
>>>> * The datamask being passed in isn't especially correct. Possibly we should be accessing the datamask being used to build the array modifier DerivedMesh? Anyway, at least this will get the mesh to show up in the viewport.
>>>>
>>>> Modified Paths:
>>>> --------------
>>>>    trunk/blender/source/blender/modifiers/intern/MOD_array.c
>>>>    trunk/blender/source/blender/modifiers/intern/MOD_boolean.c
>>>>
>>>> Modified: trunk/blender/source/blender/modifiers/intern/MOD_array.c
>>>> ===================================================================
>>>> --- trunk/blender/source/blender/modifiers/intern/MOD_array.c   2010-06-07 17:38:52 UTC (rev 29314)
>>>> +++ trunk/blender/source/blender/modifiers/intern/MOD_array.c   2010-06-07 18:20:59 UTC (rev 29315)
>>>> @@ -211,9 +211,9 @@
>>>>
>>>>        /* need to avoid infinite recursion here */
>>>>        if(amd->start_cap && amd->start_cap != ob)
>>>> -               start_cap = amd->start_cap->derivedFinal;
>>>> +               start_cap = mesh_get_derived_final(scene, amd->start_cap, 0);
>>>>        if(amd->end_cap && amd->end_cap != ob)
>>>> -               end_cap = amd->end_cap->derivedFinal;
>>>> +               end_cap = mesh_get_derived_final(scene, amd->end_cap, 0);
>>>>
>>>>        unit_m4(offset);
>>>>
>>>>
>>>> Modified: trunk/blender/source/blender/modifiers/intern/MOD_boolean.c
>>>> ===================================================================
>>>> --- trunk/blender/source/blender/modifiers/intern/MOD_boolean.c 2010-06-07 17:38:52 UTC (rev 29314)
>>>> +++ trunk/blender/source/blender/modifiers/intern/MOD_boolean.c 2010-06-07 18:20:59 UTC (rev 29315)
>>>> @@ -85,7 +85,7 @@
>>>>   int useRenderParams, int isFinalCalc)
>>>>  {
>>>>        BooleanModifierData *bmd = (BooleanModifierData*) md;
>>>> -       DerivedMesh *dm = bmd->object->derivedFinal;
>>>> +       DerivedMesh *dm = mesh_get_derived_final(md->scene, bmd->object, 0);
>>>>
>>>>        /* we do a quick sanity check */
>>>>        if(dm && (derivedData->getNumFaces(derivedData) > 3)
>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-blender-cvs mailing list
>>>> Bf-blender-cvs at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>>>
>>> _______________________________________________
>>> 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
>