No visibility optimizations

[i30817]

Thinking about the optimizations that the game probably already does, i'm pretty sure that whenever a room is 'sealed' from the PoV of the player, animations and meshes are turned off. Pathfinding probably never is.

 

 

But what about:

a ) conversations/sounds that the player can't actually hear - say, not in the 'room' the player is or in the sealed rooms adjacent to it

b ) physics code that handles niceties like collision beyond the floor or momentum? In fact, why not make the AI 'immaterial' ghosts that can't fall down or collide with anything if the player can't actually see them (problem is, when the player opens a door and suddendly they are penetrating some other object - this needs to be avoided somehow).

Edited October 29, 2012 by i30817

[grayman]

The world beyond the player's view needs to continue functioning as if the player were around. There are spawnargs the mapper can place on AI that immobilize them when they're outside the player's PVS, but these have to be used carefully. I.e. you don't want to immobilize a patrolling guard when the player can't see him. The guard will become dormant until the player comes near again, which is wrong. (And this would defeat anyone trying to time a guard's patrol route in order to get past him.)

 

Trying to skip sounds or physics when the player isn't around isn't worth the effort. All the code you're trying to avoid is going to be replaced by new code that's trying to figure out if the other code can be skipped.

[i30817]

Not if the code that turns it off and on doesn't run continously (unlike physics, conversations, animations etc).

 

For instance, when a room is sealed, it needs to have some kind of callback to see if the player is not there and skip rendering. Why not append that disabling code there, if the check is already done?

Edited October 29, 2012 by i30817

[Springheel]

More importantly than whether it would help FPS is what it would do to gameplay, and the answer there is clearly not good.

 

If AI don't check physics when then player isn't around, then they'll walk through walls. If AI don't process their surroundings, they won't notice missing loot, extinguished lights, blood, bodies, or other things they should notice. If AI don't communicate with each other, they won't pass on warnings about things they've seen, nor will they be able to run and get help. Etc.

[grayman]

Not if the code that turns it off and on doesn't run continously (unlike physics, conversations, animations etc).

 

We do allow mappers to throttle the amount of time spent calculating physics. Rather than checking every frame, we can check every N frames, where the mapper defines N and also the distance the AI is from the player when throttling begins. Movement, etc. is scaled proportionately, and how high N is allowed to go depends on the geometry the AI is moving through. At one time, we had a "phantom killer" who seemed to kill AI randomly while they were out of sight of the player, and we traced the problem to the "move every N frames" code screwing up collisions and causing damage to the AI.

[i30817]

More importantly than whether it would help FPS is what it would do to gameplay, and the answer there is clearly not good.

 

If AI don't check physics when then player isn't around, then they'll walk through walls. If AI don't process their surroundings, they won't notice missing loot, extinguished lights, blood, bodies, or other things they should notice. If AI don't communicate with each other, they won't pass on warnings about things they've seen, nor will they be able to run and get help. Etc.

 

You notice that I cunningly didn't mention the AI on the first post, because i know that it's gameplay affecting.

 

And i find it pretty bizarre that the pathfinding is so temperamental that it needs physics support to actually work without penetrating walls. On the physics example i was assuming that the pathfinding could would calculate a path that wouldn't put npc's beyond edges of rooms obviously (mathematically for the routine that culls the mesh, who cares if the mesh would be outside if it never actually shows or interacts).

This would be by no means easy to actually make work though (it's probably the hardest suggestion, because the player could suddenly get into a room while they are actually penetrating a object on their route, so a 'fast forward' would have to be done until they are into a part of their path that doesn't have collisions and turn on the collisions code then).

 

On the other hand i think that tricks like this are the only sane way to increase the npc budget, look at a game like 2005 hitman. Do you think that this level:

 

Is doing collision to all of those hundreds of people? (in fact, it's probably doing a 'special' global pathfinding so they never actually collide with eachother, and skip the collision code entirely between themselves - this is a even more 'tricky' technique, because the player can actually see that - hell they all avoid the player, the police and a huge moving object in the level even - a parade car - so the code is not only avoiding npcs).

Edited October 30, 2012 by i30817

[grayman]

There are hundreds of bizarre temperamental relationships in this code. It's part of what makes it so fun.

[Partol]

More importantly than whether it would help FPS is what it would do to gameplay, and the answer there is clearly not good.

 

I agree. Don't bother with such tricks to increase FPS.

To increase FPS in TDM, some code from Doom 3 BFG is very much needed.

Thief 1,2 and System Shock 2 all run very smooth now since patch v1.19

Doom 3 uses an old engine and needs to be patched to use modern cpu instructions.

I played Doom 3 BFG and it runs fantastically smooth.

 

When Skyrim was first released, it ran very poorly in some areas.

In some original Skyrim benchmarks, it shows a core i5 or i7 is needed to achieve decent frame rates .... which is absurd.

One or two months after Skyrim launched, a patch was released which greatly improves cpu performance and eliminates the need for a cpu upgrade.

Some info on the skyrim patch.

http://gamingbolt.com/modders-release-patch-that-boosts-skyrims-performance-by-40

Edited October 30, 2012 by Partol

[Obsttorte]

On the other hand i think that tricks like this are the only sane way to increase the npc budget, look at a game like 2005 hitman. Do you think that this level:

 

Is doing collision to all of those hundreds of people? (in fact, it's probably doing a 'special' global pathfinding so they never actually collide with eachother, and skip the collision code entirely between themselves - this is a even more 'tricky' technique, because the player can actually see that - hell they all avoid the player, the police and a huge moving object in the level even - a parade car - so the code is not only avoiding npcs).

 

you may wanna replay this mission and take a deep look on how the npc's behave there and then look how the npc's behave in the dark mod:

 

- they are walking on snakelines nearly all the time, what looks really unnatural

- the scenerie holds much more space for them than in a normal TDM level

- also the geometric layout of the streets is much more simple

- the player has no possibilities to put moveable objects into their way to block their pathfinding

- they do almost not react to any changes in their enviroment (except any forms of violence, of course)

 

I think that the cons are really upweighting the pros in this matter

 

if one would really want to improve the game performance in reliance to cpu power, then by making use of the multi-core technology, cause IIRC Doom 3 only uses single-core

 

but I'm not even sure if this would be really necessary, as I didn't heard much complaints about AI performance impacts so far

[i30817]

Uh-uh:

 

http://www.youtube.com/watch?v=O8WJl7oDw5k

 

Looks damn fine to me. Look at they even react to 47 bumping into them and that affects the pathfinding of others.

 

Do you really think that the darkmod wouldn't choke on more than 30 AI's on the same room, no matter the computer using it? And i think that H5 is not using multithreading (haven't verified, but it would be unusual in 2005).

 

That H5 is good tech is besides the point, but that the doom3 was never meant to have permanent npcs on the map, and thus didn't really care about their scability, is pretty likely, considering they spawn - and that is important for the feel and performance of TDM. If you ever want to have a more populated city missions (outdoors), i'd suggest the cpu budget is more important than the gfx. (my suggestions wouldn't actually do anything for the 'same room scenario', but at least they attack the common FM structure today)

Edited October 30, 2012 by i30817

[nbohr1more]

I think that Func_Animate entities with a little AI for herding behaviors would work for that crowd scenario.

 

The idea of setting up LOD for thinking and physics for really huge maps has been discussed here and elsewhere before.

Whether it would be feasible to implement...? Unanswered question...