Hi, I came across this code recently too, and I think we should just remove it (and similar code for parenting). This is from before the dependency graph.
Also, I think it's a good rule to never change user edited data during evaluation, like setting these pointers to NULL, either the data is valid when it's set or the evaluation should cope with it. It's quite unpredictable for users and also not thread safe. Brecht. On Fri, Mar 26, 2010 at 2:11 AM, Joshua Leung <aligor...@gmail.com> wrote: > Revision: 27756 > > http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=27756 > Author: aligorith > Date: 2010-03-26 02:11:03 +0100 (Fri, 26 Mar 2010) > > Log Message: > ----------- > Bugfix #21757: Crash when setting up cyclic tracking dependencies (with old > tracking) > > Note that users should not be doing this anyway (and to some degree, I wish > that they have to learn this the hard way - i.e. a crash as was before) since > it is always bound to cause troubles of various sorts. > > Having said this, the old tracking code was previously crashing if this sort > of setup was created since a stack overflow would happen while bouncing > between each object being recursively recalculated. I've fixed this by > commenting out that recursive recalculation (solving the cyclic problems for > n >= 2, while n=1 should still be fine without this pre-depsgraph hack), and > also removing such cyclic dependencies in the n=2 case. > > (PS: Perhaps this is just a good opportunity to just remove this old feature > instead ;) > > Modified Paths: > -------------- > trunk/blender/source/blender/blenkernel/intern/object.c > > Modified: trunk/blender/source/blender/blenkernel/intern/object.c > =================================================================== > --- trunk/blender/source/blender/blenkernel/intern/object.c 2010-03-26 > 00:25:14 UTC (rev 27755) > +++ trunk/blender/source/blender/blenkernel/intern/object.c 2010-03-26 > 01:11:03 UTC (rev 27756) > @@ -2039,8 +2039,27 @@ > > /* Handle tracking */ > if(ob->track) { > - if( ctime != ob->track->ctime) where_is_object_time(scene, > ob->track, ctime); > - solve_tracking (ob, ob->track->obmat); > + /* Try to remove this tracking relationship if we can easily > detect that > + * it is cyclic (i.e. direct tracking), and bound to cause us > troubles. > + * For the other cases (i.e. a cyclic triangle, and higher > orders), we can't > + * easily detect or know how to remove those relationships, > safely, so just > + * let them be (with warnings). > + * Of course, this could also be a simple track that doesn't > do anything bad either :) > + */ > + if (ob->track->track == ob) { > + printf("Removed direct cyclic tracking between %s and > %s\n", ob->id.name+2, ob->track->id.name+2); > + ob->track->track = NULL; > + ob->track = NULL; > + } > + else { > + /* NOTE: disabled recursive recalc for tracking for > now, since this causes crashes > + * when users create cyclic dependencies (stack > overflow). Really, this step ought > + * not to be needed anymore with the depsgraph, > though this may not be the case. > + * -- Aligorith, 2010 Mar 26 > + */ > + //if( ctime != ob->track->ctime) > where_is_object_time(scene, ob->track, ctime); > + solve_tracking(ob, ob->track->obmat); > + } > } > > /* solve constraints */ > > > _______________________________________________ > Bf-blender-cvs mailing list > bf-blender-...@blender.org > http://lists.blender.org/mailman/listinfo/bf-blender-cvs > > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
