Thread: Re: [Algorithms] Kinematic Collision (Page 3)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Mat N. <mat...@bu...> - 2009-09-11 17:26:28
|
I think you're comparing the best games from then to the worst games now. MSN -----Original Message----- From: James Robertson [mailto:ja...@fu...] Sent: Friday, September 11, 2009 12:14 AM To: Game Development Algorithms Subject: Re: [Algorithms] Kinematic Collision TV and movies have been progressively dumbed down over the years to the point now where 90% of programs are formulaic garbage that even the simplest of morons can understand. I don't see that the majority of games are much different to be honest. Back in the days of way back the people who played games were people who enjoyed learning all those damn combos and skills and wanted something challenging that they could spend hours and hours playing, mastering, and ultimately perfecting. Now that the market has broadened, more and more games have to appeal to newer types of gamer who consider games something to do when there's nothing on TV for half an hour. They want their quick fix of fun that their brains have been trained into demanding but really don't want to have to think about what they're doing. Danny Kodicek wrote: > > Danny Kodicek wrote: > >>>> Absolutely; I can't see myself playing Manic Miner any more >>>> >>> Actually, I recently played a port of MM for the first time >>> >> in 20 years, and >> >>> it was as addictive as ever. Sometimes simple gameplay is >>> >> as good as it ever >> >>> was. >>> >> OK, you tempted me :) I went here: >> >> http://www.darnkitty.com/manic/ >> >> ... But after a few minutes of repeated dying on the first >> level, I gave up! >> > > I wonder if that's the biggest change in gaming since those days: we're much > less willing to spend ages getting pixel-perfect on a game. I was looking at > a review of Arkham Asylum, talking about how great the combat was because it > did all the work for you and you just pressed two buttons, and it occurred > to me that lots of games have gone down this route recently, making combat > much more about movement and button-mashing than about mastering complicated > systems of combos. I'm not particularly saying one is better than the other, > but it's interesting how much these things have changed. The selling point > of most games is now about big worlds and exploration, rather than the kind > of micro-world pinpoint accuracy of those days. > > Obviously, there's still plenty of that going on in the casual game market, > though. > > Danny > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: pontus b. <her...@ho...> - 2009-09-12 09:13:38
|
This thread is really interesting (or was up to a point). Before it dies down I'd like to ask for some recommended reading. This is something that I find a true pain whenever I start a new project because there's animation and there's physics and they both want different things and are VERY rigid in how you can use them. In my experience which mostly dealt with fighting games, the attack animations will include a player translation which needs to be exact in order for it to look good, i.e. I must use translation on individual frames and NOT apply a force which delays and smudges movement. The animation being translated first poses the problem of not letting the player’s world position go out of sync with its pelvis (root joint) so various spatially based algorithms don't get thrown off. This can of course be solved by tricking around with spatial delta for each animation key frame and applying the correct translation/rotation on a per frame basis. After this step I end up taking the transformation from the pelvis bone on that particular key frame and instead apply it directly to the entity world position. When I've done this it feels like I've effectively contradicted the way I'm allowed to work with physics simulated objects though. Unless the physics integration method is an implicit one, as far as I understand it, I'm not supposed to move the object using translation, only by force or suffer the hell that is unstable physics... So if that's the case, and do point out if I'm wrong, what does this character controller that I keep hearing about do differently from this that make physics and animation, not only speak the same language but also like each other? Regards Pontus Birgersson _________________________________________________________________ Med Windows Live kan du ordna, redigera och dela med dig av dina foton. http://www.microsoft.com/sverige/windows/windowslive/products/photo-gallery-edit.aspx |
|
From: Jon W. <jw...@gm...> - 2009-09-13 03:57:08
|
First: Fighting games are somewhat special. I wouldn't expect you can use a "standard" character controller for that. 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). Now, you have another problem with fighters: that of an irresistible force hitting an immovable object. You *can* play back animations as force constraints on a rigged character/ragdoll. It doesn't have to look sloppy, if you use enough force in the joints, and also a little bit of look-ahead to get the velocity as well as the position right. Don't know if it's good enough for a fighter, though. The problem then is when the character runs into roadblocks that simply aren't in the animation. You might want to apply a limited amount of force (enough to get going with super-human speed, of course), and if the limbs are too far out of place after a while, cancel the animation/attack -- you probably tried to punch a mountain wall or something similar. And once you start to integrate animation and physics even more, you might start expressing animations as "desires" -- "I want to land my left fist on his nose in 400 milliseconds, and I think it will be *there* at that time." Similar to Natural Motion / Endorphin in real-time, with player guidance, perhaps. If you or anyone else learn anything more about this, I would be very interested in hearing about it! Sincerely, jw On Sat, Sep 12, 2009 at 2:13 AM, pontus birgersson <her...@ho...> wrote: > This thread is really interesting (or was up to a point). Before it dies > down I'd like to ask for some recommended reading. This is something that I > find a true pain whenever I start a new project because there's animation > and there's physics and they both want different things and are VERY rigid > in how you can use them. > > In my experience which mostly dealt with fighting games, the attack > animations will include a player translation which needs to be exact in > order for it to look good, i.e. I must use translation on individual frames > and NOT apply a force which delays and smudges movement. > > The animation being translated first poses the problem of not letting the > player’s world position go out of sync with its pelvis (root joint) so > various spatially based algorithms don't get thrown off. This can of course > be solved by tricking around with spatial delta for each animation key frame > and applying the correct translation/rotation on a per frame basis. After > this step I end up taking the transformation from the pelvis bone on that > particular key frame and instead apply it directly to the entity world > position. > > When I've done this it feels like I've effectively contradicted the way I'm > allowed to work with physics simulated objects though. Unless the physics > integration method is an implicit one, as far as I understand it, I'm not > supposed to move the object using translation, only by force or suffer the > hell that is unstable physics... > > So if that's the case, and do point out if I'm wrong, what does this > character controller that I keep hearing about do differently from this that > make physics and animation, not only speak the same language but also like > each other? > > Regards > Pontus Birgersson > > ________________________________ > Med Windows Live kan du ordna, redigera och dela med dig av dina foton. > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > -- -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. |
|
From: pontus b. <her...@ho...> - 2009-09-14 08:05:07
|
Hi, thanks for your reply! > Date: Sat, 12 Sep 2009 20:56:56 -0700 > From: jw...@gm... > To: gda...@li... > Subject: Re: [Algorithms] Kinematic Collision > > First: Fighting games are somewhat special. I wouldn't expect you can > use a "standard" character controller for that. > > 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? > Now, you have another problem with fighters: that of an irresistible > force hitting an immovable object. You *can* play back animations as > force constraints on a rigged character/ragdoll. It doesn't have to > look sloppy, if you use enough force in the joints, and also a little > bit of look-ahead to get the velocity as well as the position right. > Don't know if it's good enough for a fighter, though. If I understand you correctly this is exactly what I did my candidate thesis on, converting animation data into forces which are then applied to a ragdoll which correspond to the rig. I never managed to get it looking as well as I'd like though I only tried with explicit integration medthods, and an implicit method would probably lend itself much better to this. > The problem then is when the character runs into roadblocks that > simply aren't in the animation. You might want to apply a limited > amount of force (enough to get going with super-human speed, of > course), and if the limbs are too far out of place after a while, > cancel the animation/attack -- you probably tried to punch a mountain > wall or something similar. And once you start to integrate animation > and physics even more, you might start expressing animations as > "desires" -- "I want to land my left fist on his nose in 400 > milliseconds, and I think it will be *there* at that time." Similar to > Natural Motion / Endorphin in real-time, with player guidance, > perhaps. Maybe I should look into endorphin, kind of pricy though if I remember correctly. Pontus > > If you or anyone else learn anything more about this, I would be very > interested in hearing about it! > Sincerely, > > jw > > > > On Sat, Sep 12, 2009 at 2:13 AM, pontus birgersson > <her...@ho...> wrote: > > This thread is really interesting (or was up to a point). Before it dies > > down I'd like to ask for some recommended reading. This is something that I > > find a true pain whenever I start a new project because there's animation > > and there's physics and they both want different things and are VERY rigid > > in how you can use them. > > > > In my experience which mostly dealt with fighting games, the attack > > animations will include a player translation which needs to be exact in > > order for it to look good, i.e. I must use translation on individual frames > > and NOT apply a force which delays and smudges movement. > > > > The animation being translated first poses the problem of not letting the > > player’s world position go out of sync with its pelvis (root joint) so > > various spatially based algorithms don't get thrown off. This can of course > > be solved by tricking around with spatial delta for each animation key frame > > and applying the correct translation/rotation on a per frame basis. After > > this step I end up taking the transformation from the pelvis bone on that > > particular key frame and instead apply it directly to the entity world > > position. > > > > When I've done this it feels like I've effectively contradicted the way I'm > > allowed to work with physics simulated objects though. Unless the physics > > integration method is an implicit one, as far as I understand it, I'm not > > supposed to move the object using translation, only by force or suffer the > > hell that is unstable physics... > > > > So if that's the case, and do point out if I'm wrong, what does this > > character controller that I keep hearing about do differently from this that > > make physics and animation, not only speak the same language but also like > > each other? > > > > Regards > > Pontus Birgersson > > > > ________________________________ > > Med Windows Live kan du ordna, redigera och dela med dig av dina foton. > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > > on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > > > > > -- > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. > Nevertheless, whether we get there willingly or not, we shall soon > have lower consumption rates, because our present rates are > unsustainable. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list _________________________________________________________________ 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 |
|
From: Jon W. <jw...@gm...> - 2009-09-14 15:11:11
|
pontus birgersson wrote: > > 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. > If I understand you correctly this is exactly what I did my candidate > thesis on, converting animation data into forces which are then > applied to a ragdoll which correspond to the rig. I never managed to > get it looking as well as I'd like though I only tried with explicit > integration medthods, and an implicit method would probably lend > itself much better to this. > That'd be good to find out :-) > > > "desires" -- "I want to land my left fist on his nose in 400 > > milliseconds, and I think it will be *there* at that time." Similar to > > Natural Motion / Endorphin in real-time, with player guidance, > > perhaps. > Maybe I should look into endorphin, kind of pricy though if I remember > correctly. 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. Sincerely, jw -- Revenge is the most pointless and damaging of human desires. |
|
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 |
|
From: Jon W. <jw...@gm...> - 2009-09-14 16:23:44
|
pontus birgersson wrote: > > 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. > No, my reasoning is from the attacker's point of view: Attack -> intent -> physics -> movement -> animation. > 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. > Agreed -- a hard case. You could key the animation on movement of some bone that you specify (the fist, say) -- or just do what you said: drive a ragdoll using animated forces, and make sure that the integrator and/or kinematic controller makes it look good. Sincerely, jw -- Revenge is the most pointless and damaging of human desires. |
|
From: Pierre T. <pie...@gm...> - 2009-09-14 13:25:37
|
> > First: Fighting games are somewhat special. I wouldn't expect you can > use a "standard" character controller for that. > I think this thread proved that there is no such thing as a "standard" character controller ;) What kind of fighting games are we talking about here? Dead-or-alive/Tekken stuff? I know that Oni (and the remake whose link I previously posted) used vanilla Quake-style controllers (NxCharacter, in the second case). It was good enough for those 3rd person games where fighting is just one part of the gameplay. For me, the most painful issue was "throws", where one character has to grab and throw another. I think most games just author the 2 animations (for the player and the opponent) for a certain position, or rather relative position between the 2 characters. At replay time they just reposition the 2 characters so that they're at the right distance from eachother, and then just play the animations as usual. Do you guys know of games really doing more than that? The problem then is when the character runs into roadblocks that > simply aren't in the animation. You might want to apply a limited > amount of force (enough to get going with super-human speed, of > course), and if the limbs are too far out of place after a while, > cancel the animation/attack -- you probably tried to punch a mountain > wall or something similar. I think people just make sure the bounding volume is big enough to enclose the whole punch motion. So it is never possible for the character to punch a mountain wall. It sometimes makes you use 2 bounding volumes though: one to collide against the level, one to collide against the opponents (since you need to be close to opponents for the punch/kick attacks to reach them). > And once you start to integrate animation > and physics even more, you might start expressing animations as > "desires" -- "I want to land my left fist on his nose in 400 > milliseconds, and I think it will be *there* at that time." Similar to > Natural Motion / Endorphin in real-time, with player guidance, > perhaps. > > If you or anyone else learn anything more about this, I would be very > interested in hearing about it! > Same here. I wonder what's the most advanced thing done in games in that respect, or if all of this is really needed (I had the impression it wasn't, so far) - Pierre |
|
From: Jon W. <jw...@gm...> - 2009-09-14 15:16:39
|
Pierre Terdiman wrote: > > I think people just make sure the bounding volume is big enough to > enclose the whole punch motion. That means that the bounding volume expands as part of the animation. What do you do when the bounding volume pushes into the mountain? Sliding back the entire rest of the character is not ideal -- especially if something equally immovable is behind. Or the bounding volume of the longest animation determines where the character can walk, which means you can't pass through doors narrower than 5 meters... > > Same here. I wonder what's the most advanced thing done in games in > that respect, or if all of this is really needed (I had the impression > it wasn't, so far) If we have someone from Tekken or DoA here, that'd be nice! Personally, I find that the foot-backwards-sliding that traditionally happens when you punch into blocks, for example, is quite disconcerting. I believe that if someone could built a responsive fighter with integrated ragdoll physics and full collision detection, it could have the opportunity to lift the genre to the next level. (Cue: someone will now insert a reference to a fighter that does just that, and I just wasn't aware, as I come at this from maker-of-characters and player-of-fighters but not as maker-of-fighters) Sincerely, jw -- Revenge is the most pointless and damaging of human desires. |
|
From: metanet s. <met...@ya...> - 2009-09-14 18:06:56
|
> (Cue: someone will now insert a reference to a fighter that > does just that, and I just wasn't aware Probably you're aware of these -- not perfect, but steps in that general direction: http://www.fun-motion.com/physics-games/toribash/ http://www.fun-motion.com/physics-games/sumotori-dreams/ AFAIK the recent Fight Night demo I tried was doing some driven-ragdoll stuff, in that when your punch is blocked/deflected your arm seems to move aside in a more realistic way. But I don't think it feeds into the character's position though, it's just one-way/graphical :( raigan --- On Mon, 9/14/09, Jon Watte <jw...@gm...> wrote: > From: Jon Watte <jw...@gm...> > Subject: Re: [Algorithms] Kinematic Collision > To: "Game Development Algorithms" <gda...@li...> > Received: Monday, September 14, 2009, 11:16 AM > Pierre Terdiman wrote: > > > > I think people just make sure the bounding volume is > big enough to > > enclose the whole punch motion. > > That means that the bounding volume expands as part of the > animation. > What do you do when the bounding volume pushes into the > mountain? > Sliding back the entire rest of the character is not ideal > -- especially > if something equally immovable is behind. > Or the bounding volume of the longest animation determines > where the > character can walk, which means you can't pass through > doors narrower > than 5 meters... > > > > > Same here. I wonder what's the most advanced thing > done in games in > > that respect, or if all of this is really needed (I > had the impression > > it wasn't, so far) > > If we have someone from Tekken or DoA here, that'd be nice! > Personally, > I find that the foot-backwards-sliding that traditionally > happens when > you punch into blocks, for example, is quite disconcerting. > I believe > that if someone could built a responsive fighter with > integrated ragdoll > physics and full collision detection, it could have the > opportunity to > lift the genre to the next level. > > (Cue: someone will now insert a reference to a fighter that > does just > that, and I just wasn't aware, as I come at this from > maker-of-characters and player-of-fighters but not as > maker-of-fighters) > > Sincerely, > > jw > > > > -- > > Revenge is the most pointless and damaging of human > desires. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > __________________________________________________________________ Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/ |
|
From: Nisarg K. <lee...@gm...> - 2009-09-11 14:02:04
|
> > 90% of programs are formulaic garbage that even the > simplest of morons can understand. > This has always been the case. You just weren't paying attention before. |
|
From: James R. <ja...@fu...> - 2009-09-11 14:09:46
|
Actually it's more likely I was paying too much attention. Nisarg Kothari wrote: > > 90% of programs are formulaic garbage that even the > simplest of morons can understand. > > > This has always been the case. You just weren't paying attention before. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: Mike S. <mik...@gm...> - 2009-09-11 14:16:07
|
On Fri, Sep 11, 2009 at 6:54 AM, Nisarg Kothari <lee...@gm...> wrote: >> 90% of programs are formulaic garbage that even the >> simplest of morons can understand. > > This has always been the case. You just weren't paying attention before. Is there an algorithmic solution to this problem? Mike |
|
From: metanet s. <met...@ya...> - 2009-09-10 18:04:32
|
> Game development isn't about solving the general case; > it's > about ensuring the special (failure) cases don't > happen. It > is about the smoke and mirrors, the bang for buck. It's not really that general a case, all you need is to include a built-in level editor or and/or significant dynamic geometry and any sort of author-time restriction-based approach (such as the proposed "input geometry must be nice for character controllers to work") becomes unacceptable. To segue back to talking about physics-based character controllers: we're using a rigid body with kinematic constraints driving orientation, and we're driving the movement through the world via constraints (motorized velocity constraints between the player's center-of-mass and nearby points on the environment). This works great so far, but it's also a very sim-centric type of movement -- like Gish rather than Mario. One of the bigger unsolved problems for our controller is: how do you determine a consistent "down"/ground direction? In most games this is simplified by following the convention that only upward-facing surfaces can be walked on; if instead you want to allow smooth movement along any surface (walls, ceilings, ragdolls) this gets a lot harder because you can't use (0,1) as the a priori "down" direction -- all directions have to be considered equally valid. If there are only one or two closest/contact points this is relatively easy, but when e.g the player is surrounded by a pile of small objects.. things get messy. Raigan --- On Wed, 9/9/09, chr...@pl... <chr...@pl...> wrote: > From: chr...@pl... <chr...@pl...> > Subject: Re: [Algorithms] Kinematic Collision > To: "Game Development Algorithms" <gda...@li...> > Received: Wednesday, September 9, 2009, 3:02 PM > > Raigan wrote: > > In a more dynamic world, where there are lots of > physics-based > > objects and/or destructible shapes, it's not so > trivial (maybe > > impossible) to guarantee that the scene is nicely > behaved with no > > tiny channels or other problematic geometry. > Especially if you're > > trying to allow characters to move on/across such > dynamic shapes, > > rather than simply treating them as untraversable > obstacles. > > Game development isn't about solving the general case; > it's > about ensuring the special (failure) cases don't > happen. It > is about the smoke and mirrors, the bang for buck. > > > Christer Ericson, Director of Tools and Technology > Sony Computer Entertainment, Santa Monica > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca |
|
From: Gregory J. <gj...@da...> - 2009-09-09 18:05:42
|
chr...@pl... wrote: > James Robertson wrote: >>> Simple. You tell your art/design team not to design >>> geometry like that! (No, really.) >> That's only a solution for the most simplistic >> single player games these days. > > Perhaps God of War is simplistic to you, but it > works just fine for us. > > Programmers overengineer way too much. > Hear hear. Repeating something I had a chance to state in another forum recently, "Seriously, this is the sort of thing that happens when you let engineers design a solution in a vacuum -- it will always be far more complicated than necessary and usually solve the wrong problem..." Greg |
|
From: <Pau...@sc...> - 2009-09-02 08:22:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Johan, > Step 1: > If our current position is our target position we can end, otherwise > do a capsulesweep from our current position to our target position + a > small bias, if no collision is reported we can end otherwise continue to > step 2 This biasing is part of your problem, instead of biasing you need to do something similar yet different: When doing your swept shape-cast, you need an inner-hull shape of slighter smaller radius than the outer hull. Then, when you get a TOI intersection (which would obviously embed your outer hull in the ground, and the inner hull just touching), you can 'move back' the whole shape so that the outer hull is just touching. This means that next frame you won't find yourself initially embedded in the ground. Ideally, you wouldn't need to move the shape back and you'd have some kind of method for finding the TOI which puts your shape some known distance from the ground (i.e. the distance from the outer hull to the inner), but this routine is more expensive than a straight intersection test. > Step 3: > Find the vector from the new position and the target location and > retrieve the reflection/tangent components. Set new target position to > the new current position and add both components scaled by a > bounce/friction value [0, 1] to it.. > > * NormalMotion = NormalComponent * Bounce > * TangentMotion = TangentComponent * Friction > * NewTargetPosition = NewPosition + NormalMotion + TangentMotion Here, ideally, you'd give your character a velocity vector and then you can project his velocity into the plane of the normal of the contact point (and subtract friction in the tangential velocity direction, as you mentioned). As others have said you could make it a rigid body, but i don't think you need to go that far for just a character capsule. Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSp4rN3ajGqjtoMHxAQiUHgf+OXbrlifgpUTqi57rWlkY7EZFuN25BQv6 WznoeV8qB/araugRn1rXSJH5nU0VDR+MtbyxvBPWks9Ekx9RUcLJmaM++pYEeh4E MbaVsyITsbS97kMhQURjZwC2MdOaMAFSi93PEqrccZ1kH2IdhRFxTA8Dmke+DawN BTcgS85LUCmHom15W9pI6bpSrzEEZARZ9THaOgqJfNFP2ha9Eraac2bt4E9y/xpm 0NPOT8rMdsGCaRVicMK7Pc4KnaxwFih0byDL5K9n2VVXrjCp2WGKEuDQ9xuHe91H OAE9i+Ikc+uoO7k87AfUIZzKcyzemNYhqwU6/g5vrQeE/VthSTbluw== =MATM -----END PGP SIGNATURE----- |
|
From: Pierre T. \(GMail\) <pie...@gm...> - 2009-09-02 13:04:14
|
> I'm actually using PhysX SDK for collision detection and working under the assumption that it > should be very stable and problem free, but who knows. So... you're using the PhysX SDK already and you're trying to replicate NxCharacter which, as you noticed, "looks ALOT more advanced" than what you are doing. Why not simply using NxCharacter? Any problem with it? - Pierre |
|
From: Johan G. <spi...@gm...> - 2009-09-02 13:13:30
|
Because NxCharacter is not integrated with Gamebryo Lightspeed. Pierre Terdiman (GMail) wrote: >> I'm actually using PhysX SDK for collision detection and working under the >> > assumption that it > >> should be very stable and problem free, but who knows. >> > > So... you're using the PhysX SDK already and you're trying to replicate > NxCharacter which, as you noticed, "looks ALOT more advanced" than what you > are doing. > > Why not simply using NxCharacter? Any problem with it? > > - Pierre > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > > |
|
From: Pierre T. \(GMail\) <pie...@gm...> - 2009-09-02 15:46:36
|
(Hi Dave! It's great to hear from you!) > I found that the most important thing to make this work is a very robust > sweep test(including hit normal etc). The sweep should also handle > initial intersection (no matter what you do 8h1t Happens(tm)) giving a > sensible depenetration vector and a distance to move to depenetrate the > objects. Pair wise seems good enough, although it would probably be > possible to make this recursive as well. > > Since I added initial penetration handling my controller has not had any > problems, including moving lifts/platforms. I suppose it depends on your game. It's true that providing a "depenetration vector" can be useful, but I found it easier and more robust to just make sure it's never needed. In my small-game-at-home (http://www.codercorner.com/blog/?p=355) I more-or-less use the same code as NxCharacter, and so far it has been robust enough. Granted, I don't have big needs or requirements out there, but I do have moving platforms :) > About using the PhysX stuff, I would say the CCD is OK for demo/basic > use but is probably not modular enough to do something more > sophisticated (eg Tomb Raider style) it doesnt have the concept of > states/transitions I think there is a lot of IK in Tomb Raider that is clearly beyond the scope of a classic character controller. I would say that states/transitions are part of an animation engine, it's unrelated to "the CCT". (But maybe we are not talking about the same things here.). In the game above for example, I have some small IK, a hell of a lot of "states" and "transitions", and a "character controller". They all interact with each other, but I would say they are different things. In any case if you guys have requests/suggestions about this, what to improve, what to add, what to do better, etc, feel free to list them here. > plus it seems too tied to the underlying geometric > database. I have to strongly disagree about that one :) It's like the opposite. The game above uses "NxCharacter" but does *not* use PhysX otherwise. The character controller logic is the same, but the collision queries are performed against a completely different database than PhysX. > Plus I think that handling of initial > intersection is "undefined". Not sure if this is still the case? (Any > idea Pierre?) AFAIK it is still the case, yes. The rationale was that: - when used correctly (again, see small game above) penetration never happens - running an initial overlap check "just in case" seemed too costly I left the company 2 years ago (although I'm going back now), so take this with the proverbial grain of salt, things might have changed. - Pierre |
|
From: <Pau...@sc...> - 2009-09-02 17:22:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > AFAIK it is still the case, yes. The rationale was that: > - when used correctly (again, see small game above) penetration never > happens > - running an initial overlap check "just in case" seemed too costly In our projects we find that its essential to be able to recover from penetration, and we weren't able to rule it out... :/ It can happen for many reasons; our constraint solver runs for a fixed number of iterations, so it can terminate without fully resolving - stacks of objects will sink into each other over time, and the penetration vector is essential for resolving this. Also we have lots of motored joints like pistons etc which can force objects through each other. If you code the collision routines carefully, you should be able to pull out the penetration info at the same time as finding the TOI... Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSp6jcnajGqjtoMHxAQhpQQf+PfUOPGvZGRaO69slR7mNmlwq6pcSeOvZ ksS2efm9KiHujNu6cuDj26FuUqGkdGRYlnPF7DCQhIu/9AAFJFCis5+ziPjPDzbZ 5XDME6LEigCuQC3gb/zCh8KzUTZg6lnfvsBo7EAP9n2/i8gSJ7HxohJNdDbTWxqL WEJ2xVziB4pcFms2g6adzAQcCgKAlCoUA3PSRMcO+BN81Q+QUV06rHkDQ7UC8ZwL aTskWbP+PIUvPrkmBZpfpRq9SbYQtPgzJE13/1BCNgKqgEMXvNPq9qptNXfBnRIb 1Lv7SMnJVCIuEOlpxf8NZl+ou1yRXd7NBZkGLOyHUa/B4c+pGS5aeA== =vS+X -----END PGP SIGNATURE----- |
|
From: Pierre T. \(GMail\) <pie...@gm...> - 2009-09-02 17:56:37
|
(for some reasons I don't receive my posts to the list, but they still seem to go through. Weird.) > It can happen for many reasons; our constraint solver runs for a fixed > number of iterations, so it can terminate without fully resolving - stacks > of objects will sink into each other over time, and the penetration vector > is essential for resolving this. Also we have lots of motored joints like > pistons etc which can force objects through each other. ...but you are talking about a physics engine here. I was only talking about an old-style "character controller", a.k.a. collide-and-slide, à la Paul Nettle / Quake / etc. Typical "modern" physics engines certainly need penetration vectors. Character controllers, not necessarily - you can go a long way without. > If you code the collision routines carefully, you should be able to pull > out the penetration info at the same time as finding the TOI... Can you give more details here? I think you can find "a" penetration vector -in the direction of motion-, yes, but it is vastly different from "the" penetration vector, a.k.a. MTD, which can be in a completely different direction. I don't think I know a way to compute both with the same piece of code. - Pierre |
|
From: <Pau...@sc...> - 2009-09-03 08:24:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > ...but you are talking about a physics engine here. I was only talking about > an old-style "character controller", a.k.a. collide-and-slide, à la Paul > Nettle / Quake / etc. Typical "modern" physics engines certainly need > penetration vectors. Character controllers, not necessarily - you can go a > long way without. Ahhh, yes, you might get away with a lot more with a simple character controller. As long as nothing is allowed to 'push' the character into the ground or weigh it down, that is! :) > Can you give more details here? I think you can find "a" penetration > vector -in the direction of motion-, yes, but it is vastly different from > "the" penetration vector, a.k.a. MTD, which can be in a completely different > direction. I don't think I know a way to compute both with the same piece of > code. Ok, so if we're talking about a generic convex linear cast here, we can do the ray intersection (where the ray is the delta velocity vector of the two objects) against the minkowski difference of the two shapes (which is now static) iteratively as long as we have a utility function that will give us the closest point on the MD and the normal at that point. This information is actually already giving us penetration info if we start initially penetrated. Basically, you iterate (starting with the ray start position) asking the system for the closest point on the MD to the current ray pos and the normal. Then you intersect the ray with that normal and carry on. It usually converges very quickly, especially for poly objects and you get the TOI and the penetration info in one, should there be a TOI of 0. You can even use this to handle objects that rotate as well with slight modification of the algorithm. This is gino van den bergen's algorithm btw, where he uses GJK for the utility function - but we don't have to use GJK, we can use any custom written algorithm. So for two spheres, you just need closest point on sphere to given point, which is easy to write, or for triangle vs sphere you just need a distance to triangle function... Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: ISO-8859-1 wsBVAwUBSp99P3ajGqjtoMHxAQiBKQf8Ch+o3+FpA1QqT0KJBDVDQ3g26+UT6EvP lQO4KwCHlVFDKYMpxnP76W3JFNixxpfTo6vBWyuupau1ps5+Nhq+LJWUwIQoSI9l A4BFDekzcssFnR78MEffFyr6aLa/II0RclIcVl2tDCou6wLpLRSd6ojk29h6dW59 RhX5kIdTYPEZlqLtlh2bCGKxPMqT5q5l7JjPHdIesaEGws3pfSMtWFRIK4XDAm1q CUjmk6PcuNa+GZqzZ4JuMECW8xTGAZ4LITjKd4+aC/l4LP8Ewr2KGr47IHk6BLI0 dIrPmxB6zblEwK6U1spUsruPVJpPvgh3KhOZOg+6QfPVkrAudQ3PPQ== =PUTi -----END PGP SIGNATURE----- |
|
From: Johan G. <spi...@gm...> - 2009-09-02 18:02:00
|
How can you be sure that interpenetration never occurs then? Floating point errors seems to produce small but very relevant problems for me. As an example, when simply dropping a capsule to the floor using the 'inner skin' method without bias the solved position right before penetration should be 0.0 but the calculations will very often produce a number such as -2e-06, so in my world creating 'a perfectly stable' solver doesn't exist. Why is using a bias considered a 'hack', isn't it just to avoid this kind of problems? I also run with a bounce of 0, meaning I never apply a position vector away from the contact, maybe its not legal to have it zero? The code is not very long and if some extremely helpful soul with a better math/physics background then me would give it a look I'd be in heaven. |
|
From: Jeremiah Z. <jer...@vo...> - 2009-09-02 18:51:16
|
I haven't worked in this area in a long time but I remember numerical
problems were a major problem (along with subtle and difficult to find
bugs). I had to make the character bounce away from the surface a small
amount or else the character would get stuck. And you have to be very
careful and explicit about the bounce away part:
// Modify the velocity.
{
// Normalize the velocity and then project it into the
slide plane.
float32 const original_magnitude =
vm_VectorNormalize(&velocity);
if(original_magnitude == 0.0f)
{
velocity = Zero_vector;
}
float32 wall_part = velocity_slide_normal * velocity;
{
if(wall_part < 0.0f)
{
wall_part = fabsf(wall_part);
velocity += velocity_slide_normal *
(wall_part + wall_epsilon);
}
// Fractional velocity in the slide plane due to
the projection.
velocity *= original_magnitude;
if(velocity_param > 0.0f)
{
// Tweak the amount of velocity.
float32 const projected_magnitude =
vm_VectorNormalize(&velocity);
if(projected_magnitude == 0.0f)
{
velocity = Zero_vector;
}
else
{
// Scale the amount of velocity
between the original amount and the projected amount.
velocity *= projected_magnitude
+ velocity_param * (original_magnitude - projected_magnitude);
}
} // end if
}
}
Notice how the velocity is normalized before the bounce away epsilon is
added and then scaled back up as opposed to projecting the full velocity
into the plane and adding a small amount to it.
Another problem is sliding up against a wall on a slanted surface. You
need to make sure the resulting velocity is parallel to the surface yet
still sliding against a wall. You can think of this as being constrained
to the direction of a line defined by the intersection of the ground and
wall surface planes. Corners are another problem because you'll get
jitter as you transition back and forth between walls. You need to know
that you are in a corner and are affectively constrained to a point (the
intersection of 3 planes).
One more thing, the swept-test should ignore collisions that are
occurring as you move away from a surface (velocity dot normal > 0) so
that if you are initially penetrating, you can move away from the
surface without getting stuck.
-----Original Message-----
From: Johan Gustafsson [mailto:spi...@gm...]
Sent: Wednesday, September 02, 2009 1:02 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Kinematic Collision
How can you be sure that interpenetration never occurs then? Floating
point errors seems to produce small but very relevant
problems for me. As an example, when simply dropping a capsule to the
floor using the 'inner skin' method without bias the
solved position right before penetration should be 0.0 but the
calculations will very often produce a number such as -2e-06,
so in my world creating 'a perfectly stable' solver doesn't exist.
Why is using a bias considered a 'hack', isn't it just to avoid this
kind of problems?
I also run with a bounce of 0, meaning I never apply a position vector
away from the contact, maybe its not legal to have it
zero?
The code is not very long and if some extremely helpful soul with a
better math/physics background then me would give it
a look I'd be in heaven.
------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and
focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
|
|
From: <Pau...@sc...> - 2009-09-03 08:10:10
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > How can you be sure that interpenetration never occurs then? Floating > point errors seems to produce small but very relevant > problems for me. As an example, when simply dropping a capsule to the > floor using the 'inner skin' method without bias the > solved position right before penetration should be 0.0 but the > calculations will very often produce a number such as -2e-06, > so in my world creating 'a perfectly stable' solver doesn't exist. The idea with the inner hull is that even if (more like when, actually) you get a slight error like you mention, it doesn't matter because you can move the object back by the distance between outer hull and the inner hull which means that next frame you don't start penetrated. > Why is using a bias considered a 'hack', isn't it just to avoid this > kind of problems? Its a hack because it introduces other problems - just using the outer hull and then moving that back means you are moving the object to a point just before where it was the last time; this can push it through other objects (imagine being on the inside of a triangle (in 2d) in a corner). > I also run with a bounce of 0, meaning I never apply a position vector > away from the contact, maybe its not legal to have it > zero? No, thats perfectly legal :) Otherwise all your characters would bounce around the world like they were on pogo sticks! :) Cheers, Paul. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify pos...@sc... This footnote also confirms that this email message has been checked for all known viruses. Sony Computer Entertainment Europe Limited Registered Office: 10 Great Marlborough Street, London W1F 7LP, United Kingdom Registered in England: 3277793 ********************************************************************** P Please consider the environment before printing this e-mail -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.9.1 (Build 287) Charset: US-ASCII wsBVAwUBSp951XajGqjtoMHxAQjGkwf/V0yO90qpM1KlHGgAZsWELt4EqF1lQiBQ faApgU0iPGtmGHx8p8HSTAIMoSvtyBCN8klXzynNxeCgeQnqrdQJ27QMcYCSVGTA vN/PwRD/FPERoPis6yGSNwP510OAPh/kQZOdZ6YxBeHfqVYlUWAak7/zszLUziPh s4tafQRk877eIjzKu+Wc7mi2ElSOU+DnSoEB3WMtoHcxuQPpY2ZwTqSYKaisC96f /XMBnEqb/sqNKuhgPVIe2VMRr+yqzgQjYUlbBiKlAqidos6Jch0EZA5hwV9yDF+o SjOiHqxNpOyL1vO1kuODddnPITLgb0Ao1NOkXrqHk85E4WfkiFZZyA== =tDp5 -----END PGP SIGNATURE----- |
Thanks for helping keep SourceForge clean.
X