[ODE] ODE-GIMPACT performance and advices

[Pierre Terdiman]

> 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