NHAT cavern fps

[duzenko]

So we have been using the NHAT cavern for general benchmarking.

Performance issues are obvious - I get 20 fps or less looking at the three spiders (notarget on).

And I have a problem with it - the problem is that the bottleneck here is not the graphics rendering.

I think I narrowed it down to physics simulation.

The map author appears to have assigned the smaller white spiders to be "chewing" on the corpses.

When you kill/gas the spiders or simply notarget off so that they move towards you then fps skyrockets.

My research shows that CPU is sweating in the debris of Collision Model Manager.

Quick questions:

1. How 'normal' is this? Do we need to do something about this issue? If it's exploitation of game mechanics to shock player with cannibal spiders then we probably should not use this scene for benchmarking.

2. Do we first kill spiders and benchmark then? I would not guess this unless I knew the spiders are the problem.

3. Do we need to blend animation frames each game tick for physics simulation? In my case, I have 20 graphics frames per second and 60 game ticks. If animation is 24 fps (judging by md5anim files) then would it not be enough to simply use the current frame? I understand that we want as much precision as possible for physics simulation but not at the expense of visual slideshow? Maybe introduce a new option - high precision vs low precision sims or something like that. Maybe automatically switch based on current fps.

Again, these scene is CPU limited and I have a 2.7 GHz Core i5. We should aim to achieve at least 30 fps on modern midrange CPUs, shouldn't we?

Edited October 16, 2016 by duzenko

[nbohr1more]

Interesting thoughts.

 

To evaluate the scene, we probably should be using killmonsters. I didn't do so because I was trying to make my CPU sweat

so that the CPU burden of the renderer was exaggerated.

 

Hmm. Are the spiders continually colliding with the corpse? I think that we need to look at why the code is being so realistic \ literal

about this scenario. They should just stop in front of the target and animate without thinking about collision or AI relations until they

are provoked by real AI or player relations.

 

Edit:

 

Oh, disabling blend based on FPS eh? Interesting thought too. It would make transitions and physics events look uglier but so is

sub-10 FPS (etc) rendering. Worth a look at that. The tdm_lg_interleave_min cvar has an example implementation of toggling

stuff based on FPS.

[Bikerdude]

I am fairly sure I Monster cliped the hell out of those locations, but am happy to revisit and tweak if required.
.

[nbohr1more]

Might not be MC Biker. If the spider chewing on the corpse is the main culprit then it's just the repeated collision checks with the complexity of

the spider model vs the complexity of the zombie model.

[Bikerdude]

I could just fix the zombie in place and place nowdraw over the body - this should get around this FPS killing seizure the engine is having. I could also reduce the complexity in the location to give the spider/s a bit more room to pathfind..

[duzenko]

A harder question.

How thread safe is the collision manager?

Putting physics in a separate thread looks so beautiful and exciting in theory but my uneducated attempts to QueueUserWorkItem anything related to collision manager from the gametick code crashed and burned with null ptr AV.

Ideally, SMP might easily double fps in the cavern, unless throttling kicks in.

 

It's funny, really, how killmonsters doubles the fps here.

We should absolutely put it in the Performance Tweaks wiki [trollface.png].

Edited October 16, 2016 by duzenko

[nbohr1more]

I believe that it was intended to be thread safe.

 

Here is a little background on SMP in general:

 

 

 

Fabien Sanglard - The rendering system is now broken down in a frontend/backend: It reminds me of the design of a compiler which usually has a frontend->IR->backend pipeline. What this inspired by the design of LCC which was used for Quake3 bytecode generation ? I wonder what are the advantages over a monolithic renderer like Doom, idTech1 and idTech2.

John Carmack - This was explicitly to support dual processor systems. It worked well on my dev system, but it never seemed stable enough in broad use, so we backed off from it. Interestingly, we only just found out last year why it was problematic (the same thing applied to Rage’s r_useSMP option, which we had to disable on the PC) – on windows, OpenGL can only safely draw to a window that was created by the same thread. We created the window on the launch thread, but then did all the rendering on a separate render thread. It would be nice if doing this just failed with a clear error, but instead it works on some systems and randomly fails on others for no apparent reason.

The Doom 4 codebase now jumps through hoops to create the game window from the render thread and pump messages on it, but the better solution, which I have implemented in another project under development, is to leave the rendering on the launch thread, and run the game logic in the spawned thread.

 

 

http://fabiensanglard.net/doom3/

[duzenko]

It looks like they were talking particularly about renderer there.

[nbohr1more]

Yes, as far as I can tell, SMP in Doom 3 is "frontend is one core, backend is the other" The work is syncronized via session markers like "latchedTicNumber".

To get AI or Collision on a different thread, you must also move the renderer frontend there.

[duzenko]

I wonder what makes the cavern spiders so slow.

Is it the corpses? The stalagmites? Does the spring water add any complexity into the calculation?

Maybe we could alter the map and see how fps responds to each of the factors.

Edited October 17, 2016 by duzenko

[nbohr1more]

Probably the skeletons. Might be worth making them immovable and setting them non-solid. ( @Biker) but ideally we would want

to be able to have prop skeletons in missions like this.

[Bikerdude]

Fair enough.

[duzenko]

Excluding the skeletons from physics would be an ultimate solution.

Another possibility would be to reduce poly count for their physical model?

[AluminumHaste]

That skeleton should probably be static if that's possible, with a simple monsterclip brush around him to simulate his physical body.

[nbohr1more]

Hmm.

 

I tried both killRagdolls and killMonsters in the scene and neither seemed to

improve performance that much for me. I'm probably more GPU limited now.

 

Just to double check, you're on NHAT 3.0 (latest build)?

 

(screenshot please?)

 

Gonna compare cm_backFaceCull 1 vs 0 cvar to see if physics drags me down at all.

 

Edit: Nope, no real change.

[duzenko]

Mine was downloaded in game last week end.

Here are the screenshots

 

 

Enter the cave

kill ragdolls

kill monsters

 

My hardware is i5 5200U/hd 5500, and yours?

Edited October 19, 2016 by duzenko

[nbohr1more]

Thanks.

 

I have an i3-2130 3.4ghz and GeForce GT 730.

 

One other thing that might help here is setting the interleaved thinking frames higher on the

Spiders. I got a Minimal boost from that but you might see better results.

[duzenko]

How do I set the interleaved thinking frames higher on the Spiders?

[Bikerdude]

See wiki -

 

http://wiki.thedarkmod.com/index.php?title=Cvars_in_The_Dark_Mod

 

Otherwise I think i would have to do that as the mapper -

 

http://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows

[nbohr1more]

Yes, you could set "tdm_ai_opt_interleavethinkframes" to 15 or higher in the console.

 

Or you'd need to open the politics.map and locate the atdm_ai_spider_child entities and give them

a value like:

"max_interleave_think_frames" "15"

then repack the mission.

 

http://wiki.thedarkmod.com/index.php?title=Interleaved_Thinking_optimization

[duzenko]

Hm, tdm_ai_opt_interleavethinkframes did not do anyting really for me too. I think there are a number of situation where interleavethink option is overridden and AI thinks each game tick, such as when its movement is blocked. It's all in idAI::SetNextThinkFrame.

On the other hand, _opt_nothink, again, doubles the fps.

I have been looking at where cpu is spending most of its clocks and I think while some of it is AI but a lot of it is idAFEntity_Base.

I have an idea which objects it could be.

Here's a low-quality video with a jittering model stuck between spider and bed: https://www.youtube.com/watch?v=ekZkOBnE2u4.

While TDM physics code may or may not be doing a great job handling narrow places like this I still think it would be easier to fix it on the map design level.

If we relieve the white spiders from getting stuck around the bed it should help a ton in terms of fps.

Edited October 20, 2016 by duzenko

[Bikerdude]

I might just create a cleaner version of that cave, as my thinking is the ai having issues path finding.