#1 I've noticed a problem with 1.1b2 frame rate is low, but as soon as a sound is applied, like shooting a rocket, frame rate increases.. this has already been reported as a bug. I have seen a 10% increase on performance over 1.1b1

#2 As far as I know, hardware mesh instancing is on by default. You can test it by using a material that has glow and emissive enabled. Since hardware mesh instancing does not yet work with such materials, these would appear broken if instancing is turned on and working when it is off.

Set $pref::Video::disableHardwareInstancing to explicitly turn it off and on.

#3 Doesn't mesh instancing also not work on billboards? Due to the fact that they have to be individually rotate/animated to the camera ...

... goes off to test stuf

[edit]
Well, no discernable difference in fps in my Big Forest Scene ... but quite a difference in drawcalls ...

T3D1.1b1
polygons:      660694
drawcalls:       2318

T3D1.1b2
polygons:      595966
drawcalls:        461

And I work that out ... only had one cuppa teathis morning so bear with me ... as a saving of 78% drawcalls on a forest scene with 1178 meshes visible, 3 types of tree - each with 3 materials.

#4 nice one steve, and thats with no changes other than the torque version?

#5

Quote:Well, no discernable difference in fps in my Big Forest Scene ... but quite a difference in drawcalls ...

My programmer sent me a version to test, and yes, I noticed that the drawcall count is much lower, but FPS are the same...

1.0.1


1.1b2


If you can't see the numbers...

T3D 1.0.1
Polygons: 3784394
Drawcalls: 1893
FPS: 35.2

T3D 1.1b2
Polygons: 2905560
Drawcalls: 857
FPS: 33.3

So... Forgive my ignorance, but what is the point of lower drawcalls if the performance is the same? And even in some places I tested is lower...

It's exactly the same level loaded up in a clean project with 1.0.1 and 1.1

#6 Drawcall reduction will only help you in certain cases. In the end, the GPU still needs to render everything in the scene.

If your game is experiencing CPU overload from handling all those draw calls in the first place, instancing should help quite a bit.

If, OTOH, your performance bottleneck is the GPU vs. polycount, shadow rendering, VRAM consumption, shader processing, etc. then you probably won't see any improvement.

Other people more versed in modern rendering programming could probably explain the situation a little more accurately, but basically it's like upgrading your CPU -- it's only going to improve your framerate if the CPU was already maxed out. If the GPU, RAM, or system bus were the problem, it won't help at all.

As for why you might be seeing reduced performance in 1.1B2, this is just a theory but I'd propose it could have something to do with the defaults for the graphics options, many of which are "Custom" which could mean just about anything. Try setting everything to normal and see if anything improves.

*Edit: Just though of this, I think terrain shadow casting may have been broken in 1.0.1, so that could also be part of the performance shift. Terrain being added to the shadow casting adds a lot of extra shadow processing. Try a scene with a ground plane instead of terrain in both versions and see if that changes things up.

#7 Ah, good to know, now I see why I didn't see any improvement in the FPS department. Thanks! =)

Quote:*Edit: Just though of this, I think terrain shadow casting may have been broken in 1.0.1, so that could also be part of the performance shift. Terrain being added to the shadow casting adds a lot of extra shadow processing. Try a scene with a ground plane instead of terrain in both versions and see if that changes things up.

Nope, terrain does cast shadows in 1.0.1. As a matter of fact, for the type of game we are doing* we are planning on removing the shadows casting of the terrain

*It's an isometric game where most areas are completely flat.

#8 If your draw calls went down yet your framerate is the same... then your scene is GPU bound and not CPU bound.

If you reduce the size of your game window do you see the framerate go up? If so then your fillrate bound. This means too much overdraw, too many expensive shaders on your pixels, too big a shadow map, SSAO on highest settings, etc.

If hardware mesh instancing and reducing the size of your game window doesn't increase your performance then its possible your vertex bound. This means your GPU is bottlenecked by how many verts its processing thru the vertex shaders. Try using LODs on your models, reducing the terrain LOD, reducing the number of models drawn, etc.

@Oscar

Quote:Polygons: 3784394

That seems sort of reasonable... i suspect your probably fillrate bound. I hope some of the optimizations we're working on will help your case.

#9 @Tom

I guess that from your description I'm probably vertex bound. Changing the size of the game window (changing resolution, right?) doesn't affect performance... Except in scenes with lots of point lights. I'll see what I can do to reduce the number of vertexes =)

#10 @Oscar - If you enable wireframe mode... if your scene looks very solid... you probably have way too much vertex density.

#11 @Tom,
Appreciate that explanation of causes/impacts.
The HW mesh instancing seems to work nicely. One forested area of our game was 4115 drawcalls. Just changing the scene to beta 2 this dropped to 972. Very nice indeed.
And with the variation in quality settings my machine ranges from 15fps (highest everything) to 120fps on the lowest.

One happy camper here (as soon as TCPObject is sorted)

#12 It's all quite strange, actually. From all the tests I did in 1.0.1, reducing drawcalls yielded the best performance increase in my case. For example:

Barracks District

Polycount: 1500k
Drawcalls: 2218
FPS: 35

Polycount: 1550k
Drawcalls: 1723
FPS: 43

An increase of 8 fps by reducing 500 drawcalls, with polycount staying almost the same.

Now, in 1.1b2 it is:

Polycount: 1500k
Drawcalls: 858
FPS: 44

So, reducing by almost 900 drawcalls yielded practically no difference. For example, a reduction of 900 drawcalls yielded these results in 1.0.1:

Palace district

Polycount: 1400k
Drawcalls: 2286
FPS: 36

Polycount: 1630k
Drawcalls: 1376
FPS: 47

An increase of 11 fps by reducing drawcalls by 900, while increasing Polycount by 200k.

So I assumed that my bottleneck was mostly coming from drawcalls, since with similar polycount lower drawcalls drastically increased the fps, while similar drawcalls and lower polycount didn't do much difference.

I've been doing some tests with 1.1b2:

Barracks District Normal:

Polycount: 1500k
Drawcalls: 858
FPS: 44

Barracks District Terrain and high poly meshes hidden:

Polycount: 700K
Drawcalls: 711
FPS: 50

Barracks District normal without PSSM shadows:

Polycount: 1000K
Drawcalls: 684
FPS: 63

It seems that the biggest hit is the PSSM shadows, especially since depending where the camera is in relation to the sun, the shadows might calculate the drawcalls for all objects in the scene. I posted about it here, but we still haven't been able to implement Manoel's suggestion. Still there is something quite strange there. If I stand away from the sun (for example, the sun is near the SW corner of the map, and I go to the NE corner), the game renders all shadows in the level, even if shadow distance is low and there are no visible shadows at all.

For example, with distance set to 1000, using 2 splits, 0.9 logweight, last split terrain only, the shadow polycount is 440k and drawcalls 168:


Now we set the distance to 100, and the shadows aren't visible anymore, but they are still consuming polycount and drawcalls.


The only way to reduce the shadow polycount and drawcalls is to get "nearer" to the sun. I don't believe that changing the bound box is going to be of any difference (since modifying the variable inside it yields no results).

So... Two doubts I have:

- Why doesn't the drawcall decrease yields the same results as they did before?

- Why do PSSM shadows drawcall and polycount behave as I described?

#13 As a side note, I tested disabling hardware mesh instancing and my fps increased by 3-5 on average...

With mesh instancing:


Without mesh instancing:

#14 @Oscar - First check your audio settings in the options screen... change it to the null device and see if your framerate changes.

#15

Quote:@Oscar - First check your audio settings in the options screen... change it to the null device and see if your framerate changes.

Nope, no changes...

#16 Didn't expect it, but I'm also seeing an FPS improvement when I explicitly disable instancing.

Results are very similar to Oscar's above, but I'm including screenshot links for confirmation. Rigged up a test level with the example tree included for the forest kit.

Instancing disabled:
ubermonkey.phpwebhosting.com/qmedia/m_trees1.jpg
and enabled:
ubermonkey.phpwebhosting.com/qmedia/m_trees2.jpg

Disabling DSound did give me an across the board FPS increase, but trying different audio modes (including null) doesn't impact the difference in FPS between instancing on/off.

*edit: would probably help if I'd uploaded the files correctly. Should work now.

#17 Hi everybody, thanks for all your replies.
I tested 1.1B2 and I turned the flag to false:
$pref::Video::disableHardwareInstancing = "false";

In desert scene, under basiclighting situation, I created "turret02base" for several times. each time,the drawcall count increased,sometimes 1,sometimes 2.....
I doubt that the Instancing is on.
Anything I forgot?

#18 But the forest is under control.:)
paint the forest trees, the draw call count not increased.
why? only the forest can use instancing?

#19 the tree's instancing is working but how about the others.
thought the instancing is on, the framerate is not improved but has a little decrease. maybe the fillrate is the bottleneck in my system.

#20 Maybe, but it still feels strange. Every time I reduce drawcalls I get good fps increases, but in this case nothing... BTW, I have a Athlon X2 6000+, with a 9800GT, 4GB of RAM.

I'm not sure of submitting this as a bug, since I don't know how it should work... Perhaps it's working ok and the issue is in the expectations I had and my ignorance on the technology behind it.