Re: [Algorithms] Kinematic Collision
Brought to you by:
vexxed72
|
From: pontus b. <her...@ho...> - 2009-09-14 15:43:01
|
> > > However, in general, you'll want the animation to be driven by the > > > movement, and not the other way around. Each frame, you determine how > > > far you've traveled since the last frame, and forward the animation an > > > appropriate amount to avoid foot sliding. (The animation is marked up, > > > or you measure this based on certain named bones). > > > Not sure exactly how this would benefit a fighting move though. Where > > would the initial movement come from if not from the animation? > > > > Physics. Because you wanted to include a physics engine. If you don't > use a physics engine, you don't have that option. Your reasoning seems to be from the perspective of reaction to an attack e.g. one character punches another character transfers a force upon that character which moves him and when doing that the appropriate frames of some animation will render. This makes perfect sense and is definetly an interesting solution to try out. However I'm more concerned with movement of the character that is throwing the punch, because the punch may be extra ordinary and in order to look good the character needs to be translated in a precise and non-linear fashion. When this is the case, the force based move is really hard to get exact enough because of it's smooth nature. The only solution I can see to this is to either not allow this kind of movement or doing it by predefined translation, in which case I seem to be loosing physics support for the character. But maybe the implicit integration method could be good for this...as you said it would be good to find out so I guess I have my next home project all layed out before me:) > Usually, it's the case that quality has to cost, because there is much > less competition the more specialization and higher quality you want. > The cheap generic crap is just that, cheap. That doesn't mean that > everything that's expensive is good, of course, but it does mean that > it's generally hard to be consistently good without being expensive. > > Middleware seems to start at the $250 range (old Torque, C4 engine, > etc), take a leap to the $5k-$10k+ range (Granny, FMOD, etc), take > another leap to the $50k range (physics packages etc), and then have a > top strata at $150k+ (full engines, scene graphs, integrated editors, > etc). Within that range, I wouldn't think endorphin is entirely out of > reason. Oh don't get me wrong it's pricey but rightfully so, I haven't worked with it but it seems to be a remarkable product. Pontus _________________________________________________________________ Använd nätet för att dela med dig av dina minnen till vem du vill. http://www.microsoft.com/sverige/windows/windowslive/products/photos-share.aspx?tab=1 |