AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
<!--quoteo(post=1880034:date=Oct 15 2011, 07:38 PM:name=Raneman)--><div class='quotetop'>QUOTE (Raneman @ Oct 15 2011, 07:38 PM) <a href="index.php?act=findpost&pid=1880034"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What is the new animation system going to entail? Will it help finally unify hitboxes and the model, and make turning less jerky?
What do you guys think?<!--QuoteEnd--></div><!--QuoteEEnd-->
hitboxes and the model are already unified, at least for player models. go and test it :)
Can someone post a youtube video to compare? Or is it like: Marine walks and jumps so the animation changes smooth from walk to jump(mixed like in half-life 2?)?
The new animation system is mainly switching over to using new animation graphs. It simplifies game code that was managing animations transitions before and it allows us to add more animations much more easily. It means less programming is required to define each state of animation, blends and transitions.
The result is not going to be hugely noticeable on the outside. However, as part of the new system, and also merely as a byproduct of having to go back and in re set up every single animation in the game, things should be a little smoother, and less glitchy. Over the course of the development animations have broken, blending and transitioning have gotten off, things don't loop properly, etc. So, this is sort of a gutting of all that stuff, so we can go back in and re implement it all more cleanly. Additionally, the animations used to be much more tied up with all the code, meaning that if one unrelated thing changed it might break an animation, so with this new system being more independent is should mean that once the animations are set up, they will be less likely to break again.
<!--quoteo(post=1880876:date=Oct 20 2011, 12:56 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Oct 20 2011, 12:56 PM) <a href="index.php?act=findpost&pid=1880876"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->... things should be a little smoother, and less glitchy --Cory<!--QuoteEnd--></div><!--QuoteEEnd--> <img src="http://chrisblattman.com/files/2011/07/facebook_like_button_big1.jpg" border="0" class="linked-image" />
<!--quoteo(post=1880876:date=Oct 20 2011, 05:56 PM:name=Squeal_Like_A_Pig)--><div class='quotetop'>QUOTE (Squeal_Like_A_Pig @ Oct 20 2011, 05:56 PM) <a href="index.php?act=findpost&pid=1880876"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The new animation system is mainly switching over to using new animation graphs. It means less programming is required to define each state of animation, blends and transitions.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure many people here understand what the term "animation graphs" entails. I have a background in game art/animation and I'm not 100% sure. I'm guessing its a GUI for setting up state machine definitions. If UW wouldn't mind going into some detail, I'm sure a few people looking at the art side of the modding aspect of NS2 would appreciate.
<!--quoteo(post=1880953:date=Oct 21 2011, 03:56 AM:name=zex)--><div class='quotetop'>QUOTE (zex @ Oct 21 2011, 03:56 AM) <a href="index.php?act=findpost&pid=1880953"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If UW wouldn't mind going into some detail, I'm sure a few people looking at the art side of the modding aspect of NS2 would appreciate.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm pretty sure Brian, the programmer who has worked on the new system, is planning on putting together a post at some point which will go into more detail and explain this far better then I could.
<!--quoteo(post=1881272:date=Oct 22 2011, 09:58 PM:name=zex)--><div class='quotetop'>QUOTE (zex @ Oct 22 2011, 09:58 PM) <a href="index.php?act=findpost&pid=1881272"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So "animation graphs" is a code tool rather than an art tool? Or useable by a technical artist? Can you forsee it being useful to modders?<!--QuoteEnd--></div><!--QuoteEEnd--> Well, generally it simplifies the code in a way that the programmers don't have to be as involved in setting up and making the animations work, and puts more control into the hands of the animators and technical artist. It should be very useful to modders as well.
I assume the animation graphs are something like the curves editor in 3ds max, it's basically a visual way of describing various aspects of animation, blending between animations, that sort of thing. It's useful for artists because artists tend to prefer visual things, plus it's usually a lot easier than going into the code and changing a bunch of variables to describe how two particular animations should interpolate.
<!--quoteo(post=1881423:date=Oct 23 2011, 05:40 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Oct 23 2011, 05:40 PM) <a href="index.php?act=findpost&pid=1881423"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I assume the animation graphs are something like the curves editor in 3ds max, it's basically a visual way of describing various aspects of animation, blending between animations, that sort of thing.<!--QuoteEnd--></div><!--QuoteEEnd-->
I am tempted to make that same analogy but from the way Cory describes it, it doesn't necessarily sound like a GUI. It may be more back-end, maybe some kind of LUA framework to script animation states. Looking forward to the future blog post about it.
<!--quoteo(post=1881471:date=Oct 23 2011, 09:12 PM:name=zex)--><div class='quotetop'>QUOTE (zex @ Oct 23 2011, 09:12 PM) <a href="index.php?act=findpost&pid=1881471"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I am tempted to make that same analogy but from the way Cory describes it, it doesn't necessarily sound like a GUI. It may be more back-end, maybe some kind of LUA framework to script animation states. Looking forward to the future blog post about it.<!--QuoteEnd--></div><!--QuoteEEnd--> No, there's a GUI for it. Kind of a node based graph setup, that is more visual then what we currently have.
Listening to ns2hd's interview, I figured it basiclly works like this:
You got nodes, that is the different animations, and those can have "arrows" to other animations, which basiclly works like cases (which is why I will call them that hereforth). So if you got the walk animation, and then start idling, a case would catch the idle event and start a transition animation which leads into the idle animation. If you didnt decide to idle, but instead went from walking to jumping, another of the walk animations cases would catch the event and run a transition animation from walk to jump.
So I assume it is like a node is an animation, then the "arrow" is a transition animation, and the arrow ends at another node (animation).
dont know where else to voice this...why does the animation of the runnning marine have the gun held pointed up, but the first person marine run has the gun pointed down.. i know its pretty nit picky but i think its a good idea to have the gun pointed up and block some of the marines perspective while running...
Comments
What do you guys think?<!--QuoteEnd--></div><!--QuoteEEnd-->
hitboxes and the model are already unified, at least for player models. go and test it :)
Or is it like:
Marine walks and jumps so the animation changes smooth from walk to jump(mixed like in half-life 2?)?
The result is not going to be hugely noticeable on the outside. However, as part of the new system, and also merely as a byproduct of having to go back and in re set up every single animation in the game, things should be a little smoother, and less glitchy. Over the course of the development animations have broken, blending and transitioning have gotten off, things don't loop properly, etc. So, this is sort of a gutting of all that stuff, so we can go back in and re implement it all more cleanly. Additionally, the animations used to be much more tied up with all the code, meaning that if one unrelated thing changed it might break an animation, so with this new system being more independent is should mean that once the animations are set up, they will be less likely to break again.
--Cory
--Cory<!--QuoteEnd--></div><!--QuoteEEnd-->
<img src="http://chrisblattman.com/files/2011/07/facebook_like_button_big1.jpg" border="0" class="linked-image" />
I'm not sure many people here understand what the term "animation graphs" entails. I have a background in game art/animation and I'm not 100% sure.
I'm guessing its a GUI for setting up state machine definitions. If UW wouldn't mind going into some detail, I'm sure a few people looking at the art side of the modding aspect of NS2 would appreciate.
I'm pretty sure Brian, the programmer who has worked on the new system, is planning on putting together a post at some point which will go into more detail and explain this far better then I could.
--Cory
Well, generally it simplifies the code in a way that the programmers don't have to be as involved in setting up and making the animations work, and puts more control into the hands of the animators and technical artist. It should be very useful to modders as well.
--Cory
I am tempted to make that same analogy but from the way Cory describes it, it doesn't necessarily sound like a GUI. It may be more back-end, maybe some kind of LUA framework to script animation states. Looking forward to the future blog post about it.
No, there's a GUI for it. Kind of a node based graph setup, that is more visual then what we currently have.
--Cory
You got nodes, that is the different animations, and those can have "arrows" to other animations, which basiclly works like cases (which is why I will call them that hereforth).
So if you got the walk animation, and then start idling, a case would catch the idle event and start a transition animation which leads into the idle animation.
If you didnt decide to idle, but instead went from walking to jumping, another of the walk animations cases would catch the event and run a transition animation from walk to jump.
So I assume it is like a node is an animation, then the "arrow" is a transition animation, and the arrow ends at another node (animation).
Please correct me if I am wrong.