[andi_s]

Then why such low performance in an almost empty level? I mean, the desert level has nothing except a terrain, scattersky and advanced lighting. This just does not give me much confidence in how it might behave in a bigger level with more art, and probably also other stuff like AI going on. Don't get me wrong , I am not bashing T3D.
Are there plans to make T3D support multicore processors better?

[JeffR]

Then why such low performance in an almost empty level? I mean, the desert level has nothing except a terrain, scattersky and advanced lighting. This just does not give me much confidence in how it might behave in a bigger level with more art, and probably also other stuff like AI going on. Don't get me wrong , I am not bashing T3D.

The idea is, effectively, that with Deferred Lighting(the older method), it had less up-front cost in rendering a scene, but didn't scale as well as more and more and more stuff was added into it.
For deferred shading, there's a higher up-front render cost to render a scene, but as more things are rendered in the scene, it scales better. Which is why a nearly empty level doesn't perfom as well compared to the older builds. However, as Timmy said, if compared, you should see better performance in a fully loaded level.

Try taking the pacific demo package and tossing it in there and seeing how it scales comparitively. http://ghc-games.com/SC/Pacific_Package.rar

Are there plans to make T3D support multicore processors better?

Yep, this is definitely the plan. I've already done some testing at threading the renderer itself, and we've also been looking at running a thread for the client and one for the server(as T3D always has both, even in singleplayer). This would effectively get us a thread for rendering, and then the server-side stuff, like physics and AI would be in a different one. This would help a ton with performance.

[Azaezel]

@

andi_s
To use an analogy: Dealin a deck of cards.
With deferred lighting, we deal out a pair of cards per person (depth&normal and lighting), then deal out another one (color).
With deferred shading, we deal out all three at once.
Takes longer to count out the three with few deals to make, but takes less time to actually deal the cards since you're not starting and stopping as much.

That's the basic concept of a gbuffer anyway.
Now to prevent artifacting (color banding and the like), we are using a fairly fat one at present, so the transmission size difference is a bit larger than that. That'll get slimmed down by about half once we kill off dx9 and can support srgb directly. (4.0)

[Duion]

The terrain is already the most expensive thing in the scene you can have it has hundreds of thousands of polygons depending on size, but it is always a lot.
And then there is the up front costs of course, that are always there and things like postFX systems which are also always there.
If you remove the terrain or LOD it stronger it will be much better, I modified my LOD system to be very aggressive on terrains, since it gives the most benefit without much visual impact.

[Chelaru]

GTX 1070.
Rez 2560x1440 (4xAA, 16x AF)
16gb
i7 3770k 4.4Ghz

T3D3.9 in dx9
T3D3.10 RC in dx11

Testing the Pacific level.

Test point 1:
T3D3.9: 59FPS
T3D3.10RC: 49FPS

Test point 2:
T3D3.9: 43FPS
T3D3.10RC: 32FPS

On the T3D3.10RC there is some type of frame skyping. Is like the gpu has no work to do for a few ms, and then start again.

The map that is default in T3d
Test point 1:
T3D3.9: 117FPS
T3D3.10RC: 98FPS

Running T3D3.10RC: in dx9 mode made the game more smooth but the frame rate is the same.

The game is much smoother.

[JeffR]

Definitely shouldn't be seeing a drop in performance. It should at least be the same.

I'll run some in-depth benchmarking between the two versions tomorrow and we'll try to isolate what's going on with that.

Thanks for the detailed info!

[Chelaru]

Definitely shouldn't be seeing a drop in performance. It should at least be the same.

I'll run some in-depth benchmarking between the two versions tomorrow and we'll try to isolate what's going on with that.

Thanks for the detailed info!

You are welcome. If you need more test just ask.

From what i see in the pacific map, there are a lot of polys on the screen. I don't really know how the LOD system on the objects( forest the most ) is working, but i think that there should be less polys on the screen.

[J0linar]

prime emphasis on this release was fixing bugs

Sry but 3.10 broke 2 things for me and maybe even more....

I have used 3.9 for my current Project and wanted to check out the 3.10 RC and i made sure that i add all and evryrthing in order but for some odd reasons i get the following Issues.

#1 Damage gets applied to the player when spawning - if weapon is a Melee weapon.
#2 DAE and DTS(cached)models - Model Parts are not being rendered - this happens with FPS_View Models.

Now am sure i have encountered Issue #1 some releases ago but i know that that Issue isnt happening in 3.9
and about #2 am just

Would like to hear if other ppl experienced stuff like that

[JeffR]

prime emphasis on this release was fixing bugs

Sry but 3.10 broke 2 things for me and maybe even more....

I have used 3.9 for my current Project and wanted to check out the 3.10 RC and i made sure that i add all and evryrthing in order but for some odd reasons i get the following Issues.

#1 Damage gets applied to the player when spawning - if weapon is a Melee weapon.
#2 DAE and DTS(cached)models - Model Parts are not being rendered - this happens with FPS_View Models.

Now am sure i have encountered Issue #1 some releases ago but i know that that Issue isnt happening in 3.9
and about #2 am just

Would like to hear if other ppl experienced stuff like that

Hey, thanks for the spot on these!
T3D doesn't have any stock weapons that are melee, so I don't have anything on hand to test that side with it. How are you doing the melee checks? Raycast? Collision mesh?
For the second bit, hardware skinning was implemented to improve on the performance of animated meshes, it could be running aground on that. Could you try going into tsShape.cpp and, near the top find

bool TSShape::smUseHardwareSkinning = true;

And set that to false? That forces the animated meshes to run in 'software mode' like how it used to. Try doing that, and seeing if the mesh peices render again as usual. We though we'd hammered out any oddball spots with it, but obviously this is why we do testing

[J0linar]

didnt compiled yet just took a look and saw
U32 TSShape::smMaxSkinBones = 70;

i mean was that serious? rly.... from an artist pov this a slap in the face
for example My FPS Hand Rig got 80 Bones and yes sure i could work with less but the look and feel of the animations would go down the retro train.

90 should be a Max and reasonable Setting but 70 is not enough, think about Player Models with actual eye/mouth movement as an example, dont get me wrong am not tryin to rant its just implementing a bottleneck like that in the src is a fail.

Anyways am gonna recompile and see if a setting of 90 fixes my issue.

Edit:
U32 TSShape::smMaxSkinBones = 70;
setting to
U32 TSShape::smMaxSkinBones = 90; // expanding the Max Bone Setting fixed Issue #2

and i dont know why but hell Issue #1 is gone as well :S

And now a Final Word, thanks Guys and Gurus of the SC
without you T3D wouldnt be alive