3.10 Release Candidate

[JeffR]

Hey Guys!

Was hoping to get this out the first week of December, but when ya find bugs, you wanna fix bugs.

So here it is, the RC for 3.10 (Updated to point to RC2)! The prime emphasis on this release was fixing bugs and shoring up some stuff like some of the lighting maths, but we also squeaked in a few new additions as well. This like updating the Recast lib to latest, as well as the initial implementation of Ipv6 support and swapping the main audio device to OpenAL-soft, which is much better than the old OpenAL, OpenVR support for the Vive and freaking MacOS support!

Tons of fixes went in, including getting collada exporting fixed up as well as some utlitiy functions to bake a bunch of static geometry like convex shapes or meshes, into a single mesh, which can help a lot on performance with complex scenes, lots of fixes and tweaks to lighting stuff, as some of it didn't play well with the new linearized math under certain conditions - especially dark maps.

As the last time, RC testing will probably run until the end of the month-ish unless some crazy stuff pops up, and then we'll push onto 4.0. I'll have the Linux build uploaded tomorrow.

I've been working on a 'master thesis' post about what's the target for 4.0 and what'll be going into it, what's already done and what's yet to do. Hopefully you guys'll like where things are headed, but untill then, test the crap out of 3.10 so we can make sure we've got a good, solid foundation for fording the rivers on the way to 4.0!

[RasterRon]

swapping the main audio device to OpenAL-soft, which is much better than the old OpenAL, OpenVR support for the Vive and freaking MacOS support!

 

Great update! Is there also a way or CMake switch to disable openal-soft build? I tried unchecking all openal related settings but I'm still getting errors. I'm trying to build only DirectSound/XAudio on Windows.

[andi_s]

Great! One question....is the old DirectX SDK still required, or does this compile using the Windows SDK only? I have setup a new machine and want rather not to install the old SDK.

[Timmy]

Still requires the old dx sdk unfortunately.

[andi_s]

I just tried the RC binaries. I hoped performace would be better, I am running on a I7 6700HQ 6th gen, 16 GB DDR4 RAM and a Nvidia 960M 4 GB videoram notebook. In the outpost Level I get only around 35fps, in the desert around 85fps., running in 1080p fullscreen. Are the fps supposed to be that low on such a system? I also tried an old demo of beamng, which uses torque3d as well, and there I get better frames (a little).

What kind of fps do you get?

[JeffR]

I just tried the RC binaries. I hoped performace would be better, I am running on a I7 6700HQ 6th gen, 16 GB DDR4 RAM and a Nvidia 960M 4 GB videoram notebook. In the outpost Level I get only around 35fps, in the desert around 85fps., running in 1080p fullscreen. Are the fps supposed to be that low on such a system? I also tried an old demo of beamng, which uses torque3d as well, and there I get better frames (a little).

What kind of fps do you get?

 

Are the settings maxed out? Also, what graphics API are you using? D3D9?

[Duion]

I noticed maybe a slight performance loss from 75 FPS to 65 FPS in 3.10 or 3.9.

It really depends on situation and settings, it would need a more accurate testing setup to determine the performance, but my game never went lower than 60 FPS on max settings and I have more stuff in the scene like parallax on terrain which is very expensive ,all postFX and pimped up max settings.

The performance loss makes me wonder, because first I thought it is a great advantage since with the engine update polygon and drawcall count went down by a lot maybe 50-80% less polycount and drawcalls depending on scene.

Since Jeff asked about the graphics API I tested again with D3D11 since I was using D3D9 and with D3D11 the FPS were similar to that before ranging on average 75 FPS again like in the old Version.

OpenGL is also fine at 70 FPS, which I think has improved.

So overall I don't see much of an issue there for now, they only thing I worry about is the missing app icon in the upper left corner of the window which got broken after switchting to the new SDL stuff.

[Timmy]

In T3D 3.9 it went from deferred lighting to deferred shading, i won't explain the details of this again because there is a lot of information on the topic floating about. In short, you will find a lot of smaller, simpler levels will indeed be faster using the older deferred lighting technique even though it is drawing a lot of scene geometry twice.The results will vary a lot however from system to system depending on cpu/gpu combo. The current gbuffer used in deferred shading is very large actually and far from ideal, it will be further optimised in future releases.

For example on my system:

Outpost: Deferred Lighting quicker

Empty Terrain: Deferred Lighting quicker

Pacific: Deferred Shading quicker

[andi_s]

i use dx9 and 11. performance is almost the same. the settings are maxed out.

[Duion]

I added more quality setting levels and now I can reach almost any performance I want, up to 700 FPS, which is kind of a physical max.

Especially basic lighting gives you an extreme performance boost and if you bake the lighting, you have the good performance and it looks good, only downside is, the lighting is static.

So you cannot say the performance in Torque in general is bad, you can reach almost any performance you want, by wisely choosing which techniques you use. The demo levels are just stuff put in an done, without much optimization.

[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 :shock:

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 :shock:

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

[JeffR]

Heh, yeah, fair enough.

It's obviously possible to push it higher, i think it was pretty much a memory/bandwidth consideration. 70 was figured as a relatively low, but acceptable number, I believe that's what Mango's team used as their max, which is why it's that number.

That said, fair point that it could be limiting from an artist perspective. Entirely a valid possibility to go ahead and bump that up - or heck, could look at making it a pref, so for games with less complex art, they can rein the number in and save on some memory and all that jazz.

Let us know if bumping it up worked for you then :)

[J0linar]

...to go ahead and bump that up - or heck, could look at making it a pref...Let us know if bumping it up worked for you then :)

 

Yes bumping it from 70 to a Max of 90 Skinned Bones fixed the issue.

Making it a pref sounds nice but honestly just bumping it up will solve upcoming issues with ppl comin and asking why, cuz i dont think that ppl will cross the line of 90 Bones.

70 Bones is enough for a Player Character and for some of us it should be enough for the view models as well.

Anyways thx JeffR for pointing me to the right direction.

[JeffR]

...to go ahead and bump that up - or heck, could look at making it a pref...Let us know if bumping it up worked for you then :)

 

Yes bumping it from 70 to a Max of 90 Skinned Bones fixed the issue.

Making it a pref sounds nice but honestly just bumping it up will solve upcoming issues with ppl comin and asking why, cuz i dont think that ppl will cross the line of 90 Bones.

70 Bones is enough for a Player Character and for some of us it should be enough for the view models as well.

Anyways thx JeffR for pointing me to the right direction.

 

I figure we can do both. Bump up the default a bit, and also possibly make it a pref so it's easier to tweak as needed.

And yeah, thanks for helping test stuff! :)

[Jason Campbell]

Wow, you guys are incredible. Thank you.

[Duion]

It could almost be released like it is according to my tests, there is a few issues left that I consider a bit problematic: https://github.com/GarageGames/Torque3D/issues/1869 , https://github.com/GarageGames/Torque3D/issues/1860 and this https://github.com/GarageGames/Torque3D/issues/1746

I think I release my game with them and fix the issues for the next version.