dependency cycle
Kun vaikka riggaa sitä hahmoaan.. On hyvä olla selvillä jos synnyttää dependency cyclen.. Tämmönenhän voi syntyä kun luo riippuvuus suhteita vaikkapa ristiin. Cyclen syntyessä XSI kirjoittaa lokiin: "//WARNING : 3000 - PROBLEMATIC EVALUATION CYCLES ARE IN THE SPECIFIED GRAPH" alkuisen litanian.. Joka on syytä huomata ja yrittää selvittää cyclen aiheuttaja ja poistaa. Muuten xsi saattaa heittäytyä arvaamattomaksi.
Jos haluaa luoda dependency cyclen kokeeksi.
Niin luodaan box A ja B. Ja sitten vaikkapa:
1) position contrain A -> B
2) position contrain B -> A
Jonka seurauksena syntyy cycle ja lokiin ilmaantuu varoitus.
Myös esim. CycleChecking("Scene_Root") tai CycleChecking("obun nimi") tulostaa samaisen varoituksen.
Tässä ongelma korjaantuu dellaamalla tietty toinen constrain. Oikeassa scenessä syyllisen paikannus saattaa ollakkin haastavampaa. XSI SDK dokumentaatiosta löytyy vinkkiä tähän. Löytyy CycleChecking haulla.
"CycleChecking
Description
Checks the Graph For Operator Evaluation Cycles. An evaluation cycle is a looped graph dependency where an operation is dependent on itself.
This function determines if there is a cycle in a specified hierarchy and outputs to the script window the operators that are within the cycle, or are accessing the data within the cycle. Within each cycle traversed the script window outputs a name of a operator as 'Cycle Breaking Point' and outputs many operators names labeled as 'Cycle through' operators.
The 'Cycle Breaking Point' operator is the graph location where the evaluation check is terminated. This is dependent on where the evaluation was initiated from and may slightly vary. This is the critical location for scene evalution differences/odd results/odd behavior users see with problematic cycles in their graph. The reason, is that to avoid an infinite loop the data used to honour this evaluation request, is the evaluation upto that point in the connection stack. So in fact the result is not a re-evaluation of itself.
The 'Cycle through' operators are the contributers to the cycle and breaking one of these key dependencies will break the dependency cycle. Note: there are also other operators that will access the cycle and during a scene evaluation may end up with skewed cyclical results, but are not key contributers and as such removing one of these operators will not break the cycle.
To fix a cycle users should look for, narrow down and remove key contributers within the cycle. There are suggested approches for this. First to narrow down a cycle within a hierarchy isolating the breaking point and rerunning the cycle checking on it's data owner or other hierarchy's within it's cycled operators to get a handle on the depth and width of the cycle. Second, look for key contributers labeled within the cycle. To do this start with the 'Cycle Breaking Point' and trace down the output through the 'Cycle through' operators until the same 'Cycle Breaking Point' operator is found and labled as a 'Cycle through' operator. These are your contributers. Then look through the contributers for familiar cycle creators such as "Expression", "ScriptedOp" or "kine.Constraints". A key contributor for a problamatic cycle will not be of the form "kine.local.PoseCompensatorOp"or "kine.global.ParentPoseCns_E" or "kine.local.ParentPoseAndPoseCns_D" or "kine.global.SkeletonCtrlOpProp". Note: the operators labeled "*_D"'s and "*_E"'s are definers and enforcers of the "kine.Constraints". "
Aihe: Q&A Yleinen (Vinkkejä aloittelijoille) (Luettu 1325 kertaa)