[ODE] ODE-GIMPACT performance and advices

[erwin@erwincoumans.com]

>>Maybe total liberty works better in multiplayer mode...

Have you ever played Grand Theft Auto Vice City? Many players enjoy the 
large freedom just as much as the missions, so it is not restricted to 
multiplayer. 

Destructable physics environments will become more important in next-gen 
physics, see Pixelux/Lucas Arts 'Digital Molecular Matter'. So tools like 
Ageia's CreateDynamics for convex decomposition, and Finite Element Methods 
will be more commonly used. It's probably best to leave the gameplay 
discussion for another forum, and focus on the tech. Static structures are 
still useful, but more and more parts of game physics environments will 
become dynamic: Destruction is one of the next steps, next to Naturalmotion 
style balancing ragdolls (powered ragdolls constraints). 

I prefer dealing with moving volumes, like convex decompositions and 
tetrahedral meshes, instead of triangle meshes. But I'm still curious to see 
the new GImpact's concave-concave in action. 

Erwin
http://bullet.sf.net 

 

Pierre Terdiman writes: 

>> But if I want, I can take a crowbar or a bulldozer and break the wall
> down.
>> That's my point. It isn't always dynamic, but if I want I can do whatever
> I
>> want to it.
> 
> I understand that. But my original comment was just that you don't need a
> 3rd category for this... If it has to stay static for gameplay reasons, put
> it in the static bin. If it is always dynamic, or can be dynamic at some
> point, put it in the dynamic bin. End of story. 
> 
> I like AABB-trees because they are pretty good for a lot of cases:
> - if the object is static, you never update the tree, everything is perfect
> - if the object is dynamic, you always update the tree (O(n)), and it's
> difficult to be really faster than that when all the triangles really move
> - if the object is pseudo-static, you update the tree once in a while, and
> you don't pay the update price for all the frames where the object is really
> static 
> 
> The only issue with AABB-trees is when a mesh actually breaks in two or more
> parts, i.e. it's not just deformed like a piece of cloth. You really need N
> new trees for N parts in that case, so this is a situation where a
> brute-force approach (possiby GIMPACT) works "better". Unfortunately this
> case has a lot of other issues: you don't just need new trees, you need new
> rigid body objects, new inertia tensors that must be computed on-the-fly as
> well, new graphical objects that must be replicated in the culling database
> if necessary, etc, etc, etc. 
> 
> Another reason why you don't need a 3rd category is because if everything is
> possible, i.e. if you let all the objects eventually be dynamic, then you
> need algorithms fast and robust enough to handle this worst case. And if you
> have them, then you can just use them for all meshes, regardless of their
> state... 
> 
> Note that if "everything is dynamic", as you said, you don't even need two
> categories, just one :) So I don't see how your position is less "stiff"
> than mine, actually :) 
> 
> ...anyway, I think we basically agree... 
> 
> 
>> Many recent games put you in the environment and let you do what you want.
> Good
>> examples are the Grand Theft Auto series, Oblivion, Just Cause, etc.
> Imagine
>> those games if you could break down walls to get into a building...
> 
> They don't let you do what you want, they let you do a large amount of
> planned things. But you couldn't break down walls to get into a building,
> because it would ruin the missions, stories, cut-scenes, etc. Imagine a
> cut-scene where your character talks to another guy in his office. What
> happens if you destroy the office (or the whole damn building) before that?
> That's what I said: if you let the player do anything, it can create a few
> fun games, but it also creates a lot of gameplay and story-telling issues. 
> 
> I don't really believe in total liberty in games. The more you get, the
> better: sure. But I think players will still need guidelines, and a good
> story to drive them. And if you want to deliver your story in the expected
> way, you need the key events to be there when and where you designed them to
> be... 
> 
> It's probably a bit like "single player mode" vs "multiplayer mode". You
> need a good story in single player mode, but for the multiplayer mode it
> doesn't really matter - it's another kind of fun. Maybe total liberty works
> better in multiplayer mode... 
> 
> 
>> As providers of tools, I don't think we can start telling the game
> designers
>> what they can and can't do. We have to give them as much liberty as they
> need
>> to make the kind of game the gamers want.
> 
> ...provided the -gamers- want the same things as the -game designer-  :)
> I'm not convinced this is the case at all :)  ...but that's seriously
> off-topic now... 
> 
> 
>> But if
>> a game designer wants to do something and the tools don't allow it, that's
> bad. 
> 
> Certainly. I didn't say the opposite. But I think game designers will still
> want to keep some static stuff here and there, because their job would be a
> lot harder if the player can suddenly destroy everything... :) You know,
> it's the classical example where the player doesn't bother going for the
> carefully designed Quest For The Gold Key: he just blows up the whole damn
> door, and screw the game design. So, again, if the player can do everything,
> then the game designer has to think about, and plan everything as well. This
> is not easy, especially if you want to make sure the game can still be
> solved, no matter what the player ever does. 
> 
> 
>> As for your example, IMVHO making an NPC immortal is a crutch, because if
> the
>> player really cares about the story he won't *want* to kill him, so you
> don't
>> need to make him immortal. But some games still do it, and I've had to
> reload a
>> few times because I'd killed an essential NPC by mistake in a game that
> didn't
>> do it. It's a pros/cons situation and depends what kind of game you're
> making. 
> 
> For me it's pretty clear: any game forcing you to reload an old saved game
> because it became unsolvable has a serious game design problem. This
> shouldn't happen. This is frustrating, and a sign that the game designer
> failed doing his job properly. *Especially* if the poor player doesn't have
> an old saved game where the vital NPC is still alive! 
> 
> 
>> My position is just to give the best tools possible to the people making
> the
>> games, and then they can decide what they want. Restricting tools is
>> restricting creativity IMHO.
> 
> I think this discussion is silly. I didn't want to restrict their
> creativity, I just said you only need the static case (because, as you said,
> there are good optims there), and the dynamic one (for the future where
> "everything is dynamic"). That's all. 
> 
> Anyway, we probably agree overall. 
> 
> - Pierre 
> 
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode