Submeshes--do they affect performance?

[Springheel]

You can do this test with static meshes. I don't see any reason why the renderer should treat animated AI and static meshes any differently from the perspective of draw calls and batching, since the animation has already been "done" by the time the renderer gets the data.

 

Just get some moderately complicated meshes, make a multi-material version and a single-material version (but make sure the actual UVs and images used are identical) and place several hundred of them in a room to test performance.

 

If Doom 3 is clever enough it might even realise that all of the triangles are using the same images, even though they are using separate material decls, and send them all in a single batch anyway with no performance drop whatsoever.

 

I found this thread, but not one where the idea was actually tested.

[Ishtvan]

I found this thread, but not one where the idea was actually tested.

A modeler (I think BlackThief?) made some test maps for it, called perftest and perftestmulti, but I think they've since been deleted. There were maybe 100 objects, and the FPS drop was only 2-5 on going from 1 mesh to 4 sub-meshes. Gildoran also linked to a thing on Quake4's dev site that explained how each extra texture slows down the renderer compared to having them all in one texture.

 

To test the performance, you can still stress-test it without the need for animated models. Just put in a bunch (~20-100) of AI models as func_static or something, one set with as many sub-meshes as you planned to use and one with all one mesh. Don't know how hard it would be to fuse them all into one mesh, but the texture doesn't have to be fixed to look right or anything since this is just a performance test. Someone who knows more about the renderer might be able to elaborate on that, but IMO that could work as a test.

[ascottk]

I don't think those tests were done after I added shadowmeshes. If every submesh is casting shadows, it will hurt performance.

[Springheel]

There were maybe 100 objects, and the FPS drop was only 2-5 on going from 1 mesh to 4 sub-meshes.

 

Oh, well, that's not too bad, considering most maps will probably have less than 30 AI in them. I wonder if it's the number of meshes or number of texture files? I'll run a test and see.

[Springheel]

Ok, I ran a simple test, with interesting results.

 

1 room, 40 AI models (static), with two lights.

 

Test 1: Shadow-casting lights, 10 meshes on AI, several meshes cast shadows

 

AI out of FOV: 55-60

AI in FOV: 10

 

Test 2: Shadow casting lights, 1 shadow-casting mesh on AI

 

AI out of FOV: 53-58

AI in FOV: 8-9

 

 

Test 3: Non-shadow casting lights, 10 meshes on AI

 

AI out of FOV: 52-57

AI in FOV: 30

 

 

Test 4: Non-shadow casting lights, 1 mesh on AI

 

AI out of FOV: 48-58 (why lower I don't know)

AI in FOV: 30

 

Strangely, the FPS went DOWN when changing to one shadow-casting submesh. My guess is because not ALL of the ten meshes were shadowcasting, so the renderer was actually calculating fewer shadows. When shadows are not involved, the number of meshes seems to have no affect at all.

 

One thing that puzzles me, however, is why the FPS fluctuated so much when I was looking away from the AI. When the AI were in view, it was pretty consistant, fluctuating 1 FPS at most. But while looking away, the numbers went up and down by almost 10 FPS. What would cause that? There were no working AI in the map other than the player so I'm not sure what calculations were being done--isn't it a little strange to get that kind of range? I don't think it's my system doing anything in the background, because then I'd expect it to vary when looking at the AI models as well.

 

I found (and renamed) the thread of the original test. My test certainly doesn't seem to support the earlier ones, so I don't know what to make of that.

 

http://forums.thedarkmod.com/index.php?showt...st=0#entry75446

[OrbWeaver]

I don't think those tests were done after I added shadowmeshes. If every submesh is casting shadows, it will hurt performance.

 

I don't see why the number of submeshes would make a difference to the shadow volume calculation, assuming that the overall geometry complexity was identical. The renderer still has to generate all of the shadowvolumes for a light before that light is rendered, so whether these come from a single large mesh or several smaller ones shouldn't make a difference.

[Ishtvan]

Do non-shadow casting lights still activate the normal maps? I think the answer is yes, but just wanted to make sure.

 

One thing that puzzles me, however, is why the FPS fluctuated so much when I was looking away from the AI. When the AI were in view, it was pretty consistant, fluctuating 1 FPS at most. But while looking away, the numbers went up and down by almost 10 FPS. What would cause that? There were no working AI in the map other than the player so I'm not sure what calculations were being done--isn't it a little strange to get that kind of range? I don't think it's my system doing anything in the background, because then I'd expect it to vary when looking at the AI models as well.

 

My guess is that it's a question of what's the bottleneck for the frame rate, and what is that bottleneck frame rate. If you are looking at the AI, the frame update cycle is probably limited by the GPU rendering 40 AI. For one thing, the CPU might not be limited, but it has to wait for the GPU to finish before it can update the frame. Forgetting about that tough, think about what's needed to cause a 1 FPS drop at 30 FPS: Fluctuating processes would have to add 1/30 - 1/29 = 1.1 milliseconds longer to cause a 1 FPS drop.

 

When you're looking away from the AI, the GPU is no longer limiting the frame update rate to 30. You'rep retty close to 60 FPS. At 60 FPS, a background process just has to add a delay of 1/59 - 1/60 = 0.3 ms to cause a 1 FPS drop. That's less than 1/3 the delay that was required to drop FPS at 30 FPS. So it's easier for the frame rate to fluctuate the higher it is.

[OrbWeaver]

Do non-shadow casting lights still activate the normal maps? I think the answer is yes, but just wanted to make sure.

 

Yes, shadow rendering is unrelated to normal maps.

[Springheel]

So it's easier for the frame rate to fluctuate the higher it is.

 

True, that makes sense.

[OrbWeaver]

It's better to consider framerate fluctuations as a percentage of the framerate, rather than in absolute FPS terms.

 

I.e. 60 FPS +/- 6 is equivalent to 10 FPS +/- 1 in fluctuation terms.