Atom Posted September 13, 2015 Share Posted September 13, 2015 (edited) Hi All, As I play around with adding more states to my crowd sim I am finding the current toolset somewhat limiting. Here is what I am trying to achieve. I have a dying animation which is 35 frames long, I want to use the last frame # as the "dead" animation so i have a 1 frame FBX just for that. This means that the various FBX animations used all have different lengths. Currently I have a statedurration test which changes my agent from the dying animation to the dead frame. Because this is a duration check I can only put in a constant time value (0.5). However, because my agents are running as Remapped Mocap To Particle Speed the fixed comparison value is not neccessarily going to work if the agent is running at twice or half the speed. My dying animation goes from standing up to faling down and laying flat. Then the laying flat becomes the final dead state. What I experience is that the constant value of 0.5 causes fast running animations to "jump" to the floor too quickly or slow running animation popback up for a second then drop back down. What I need is a way to actually examine the string values of the clip names to see if I am still dying and then also check crowdtransition_occurred to see if it is 1. When both those checks are True I can then activate the dying to dead transition. I assume the Custom VEX Expression type for the Crowd Trigger node is used for more complex state detection such as what I have described but I just don't know how to vex code that. Does anyone have any vex code for more complex state manipulation? Or can someone vexify my psuedo code? i@trigger = -1; obj = self.agent_I_am lst_clip_names = obj.get_attribute("clipnames") if lst_clip_names[0] == "dying": anim_complete = obj.get_attribute("crowdtransition_occurred") if anim_complete == 1: // Now I can transtion. i@trigger = 1; Edited September 27, 2015 by Atom Quote Link to comment Share on other sites More sharing options...
Atom Posted September 13, 2015 Author Share Posted September 13, 2015 (edited) This is close. However, now I am wondering if the crowd sim is actually updating these attributes correclty because it still does not work. For instance @crowdtransition_occured never gets set to 1 even though I have passed through many transitions..? // setting i@trigger to 1 will enable // setting i@trigger to 0 will disable i@trigger = 0; if (s@clipnames[0] == "rock_golem.dying") { if (@crowdtansition_occurred == 1) {@trigger = 1;} } I also tried this variation. // setting i@trigger to 1 will enable // setting i@trigger to 0 will disable i@trigger = 0; if (s@state == "dying") { if (@crowdtansition_occurred == 1) {@trigger = 1;} } Edited September 27, 2015 by Atom Quote Link to comment Share on other sites More sharing options...
edward Posted September 19, 2015 Share Posted September 19, 2015 The purpose of the trigger node is to *cause* the transition. So I don't think you can check whether a transition occurred because you're the one triggering it. It sounds like what you actually want is to first check if the state is dying and that the @cliptimes[0] value is close enough to the end of the dying animation to trigger it into dead? Quote Link to comment Share on other sites More sharing options...
Atom Posted September 21, 2015 Author Share Posted September 21, 2015 (edited) That is what I am trying to accomplish. So if we don't put our check code in the trigger, where should I put the VEX code that evaluates the system and activates transitions? Edited September 23, 2015 by Atom Quote Link to comment Share on other sites More sharing options...
edward Posted September 27, 2015 Share Posted September 27, 2015 I was only referring to your use of "@crowdtransition_occured" in the trigger which is too early in the process. Quote Link to comment Share on other sites More sharing options...
Atom Posted September 27, 2015 Author Share Posted September 27, 2015 (edited) Ok, I see what you mean. I am running a rather experimental setup. I don't actually have the code. if (s@state == "dying") { if (@crowdtansition_occurred == 1) {@trigger = 1;} } running in the same Crowd Trigger node that actually is activated by the above code. Instead each Crowd Trigger node controls a single Crowd Transition node setting it's i@trigger to it's self attribute. Then I add a final Crowd Trigger node (in gold), with VEX code, that attaches directly to the Merge node without passing through any Crowd Transition node, effectively it is code without a trigger. The index into the Merge node, for the gold VEX code, determines if this code runs PRE or POST triggering (orange nodes) . Each orange Crowd Trigger node has the same exact VEX code. The code sets the i@trigger to the value of an attribute that is named like itself. The gold code examines attributes, such as @crowdtransition, @stateduration and others to determine which transition should occur. Once a condition is met an attribute name is constructed and it's value is set to 1.0. The next time the system is evaluated the orange Crowd Trigger node code runs and fetches the newly changed value and the transitions begins. I am still experimenting with the setup it is working but debugging is kind of odd at this stage. And I guess I am always running 1 frame behind when using this technique. Edited September 27, 2015 by Atom Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.