[Chelaru]

The following video is for blender games but the lessons can be applied to torque as well.


https://www.youtube.com/watch?v=MLdj6DwVETM

[Duion]

The following video is for blender games but the lessons can be applied to torque as well.

Not really.
Such things as reducing vertices count and reducing texture size might be correct, but they are basic knowledge or should be, if you don't know those you are pretty much lost to begin with.
Some other tips cannot be applied or do not need to be applied for Torque etc.
Even for basic advice such as vertices count the numbers are wrong for Torque, he says for example, keep vertices count as low as possible, like under 100 000, which is very low for a Torque game. My scenes have between 500 000 and 1 600 000 polygons on average, in vertices it is maybe half of that so 250 000 and 800 000 vertices. So you see, the nubmers are very much off.
Another reason the numbers cannot be applied to Torque is, that Torque can automatically scale mesh details, texture details, etc and it depends how much other stuff is in your scene, like shaders, postFX, lighting etc.
For example if all your other graphic settings are low or not used in your scene you can easily draw millions of polygons and it still runs super smooth. I did test scenes with like 20 million polygons and it still ran decently.

[JeffR]

The following video is for blender games but the lessons can be applied to torque as well.

Not really.
Such things as reducing vertices count and reducing texture size might be correct, but they are basic knowledge or should be, if you don't know those you are pretty much lost to begin with.
Some other tips cannot be applied or do not need to be applied for Torque etc.
Even for basic advice such as vertices count the numbers are wrong for Torque, he says for example, keep vertices count as low as possible, like under 100 000, which is very low for a Torque game. My scenes have between 500 000 and 1 600 000 polygons on average, in vertices it is maybe half of that so 250 000 and 800 000 vertices. So you see, the nubmers are very much off.
Another reason the numbers cannot be applied to Torque is, that Torque can automatically scale mesh details, texture details, etc and it depends how much other stuff is in your scene, like shaders, postFX, lighting etc.
For example if all your other graphic settings are low or not used in your scene you can easily draw millions of polygons and it still runs super smooth. I did test scenes with like 20 million polygons and it still ran decently.

While you're not incorrect, I think it's *always* good advice worth repeating to smash into people's heads to mind the polygon count - and more importantly the unique material counts.

While it's not hard to keep down as a course, if you're not careful that can get away from you - especially artist-types and level designers. Adding in all the cool detailwork and doodads is awesome, but if asset management isn't kept on top of, it can build up and kill performance, especially the drawcall side.

Even if you can crunch 50 million + polies a frame without issue - keeping the polycount as low as possible without harming the look is *always* good advice.

[Chelaru]

The following video is for blender games but the lessons can be applied to torque as well.

Not really.
Such things as reducing vertices count and reducing texture size might be correct, but they are basic knowledge or should be, if you don't know those you are pretty much lost to begin with.
Some other tips cannot be applied or do not need to be applied for Torque etc.
Even for basic advice such as vertices count the numbers are wrong for Torque, he says for example, keep vertices count as low as possible, like under 100 000, which is very low for a Torque game. My scenes have between 500 000 and 1 600 000 polygons on average, in vertices it is maybe half of that so 250 000 and 800 000 vertices. So you see, the nubmers are very much off.
Another reason the numbers cannot be applied to Torque is, that Torque can automatically scale mesh details, texture details, etc and it depends how much other stuff is in your scene, like shaders, postFX, lighting etc.
For example if all your other graphic settings are low or not used in your scene you can easily draw millions of polygons and it still runs super smooth. I did test scenes with like 20 million polygons and it still ran decently.

i am aware that not all things apply to t3d. Is a good think to keep in mind. To be honest i did not know that the lights that are not seen, are still rendered and can kill performance.

[Duion]

Its is not very wise to take advice from BGE into other game engines, since BGE is not a fully functional game engine and there has never been a 3D FPS multiplayer game released with it as far as I know.
Most of the problems you have to solve in BGE are already solved in all other major game engines, for example: Torque has its own system handling lighting through shadow cascades.
BGE is more for people with small projects or who like to re-invent the wheel and then going nowhere with it.
BGE does not look that bad, since you have nice shader effects and lighting and physics work out of the box unlike in Torque which has its issues with it here and there, but overall BGE does not scale well and you are limited to your 100 000 vertices count or whatever in one small scene, while in Torque you can go almost as big as you want.

If you build such small games/scenes in Torque there is hardly anything you have to optimize.

[Chelaru]

Its is not very wise to take advice from BGE into other game engines, since BGE is not a fully functional game engine and there has never been a 3D FPS multiplayer game released with it as far as I know.
Most of the problems you have to solve in BGE are already solved in all other major game engines, for example: Torque has its own system handling lighting through shadow cascades.
BGE is more for people with small projects or who like to re-invent the wheel and then going nowhere with it.
BGE does not look that bad, since you have nice shader effects and lighting and physics work out of the box unlike in Torque which has its issues with it here and there, but overall BGE does not scale well and you are limited to your 100 000 vertices count or whatever in one small scene, while in Torque you can go almost as big as you want.

If you build such small games/scenes in Torque there is hardly anything you have to optimize.

I understand. Thank you for clarification. Could you please add a small list of optimization or even a tutorial?

[JeffR]

One thing I'll toss in that's broadly relevant, but moreso with the recent release of T3D because we have a cool button to help with exporting meshes now, but a good bit of optimization can come from taking a bunch of separate static objects, and baking them into one, single mesh.

So if you use a bunch of tiles to assemble a multistory building, for example, if your building is made of 100 tile pieces, that's 100 * NumberOfMaterials draw calls for that building - assuming no occlusion is taking place. If your models have, say, 2 materials: 1 brick and 1 metal, that's 100 tile pieces * 2 materials = 200 drawcalls for that one building.

If you export all those to bake them into a single building mesh, you basically drop your draw calls down to 1 * NumberOfMaterials for that entire building. In the above example, it'd mean the building now only costs 2 drawcalls for the whole thing.
With this method, you can use lots of peices, tiles, detail meshes, etc to quickly iterate out shapes and parts of levels, and then when you're happy with it, export to bake them into a single mesh to drastically cut down on the draw overhead and see sizeable improvements. When @

Azaezel did this for his one map, i think he saw a 10x performance increase, because they heavily utilize tile-based prefab buildings, and all those separate drawcalls were killing performance that were handily fixed with the ability to bake export them to singular models.

[Duion]

Do you really need it to be optimized?
The most optimized way is having as much geometry as possible in one model instance and using as less textures as possible, by having the textures as big as possible.
But this reduces flexibility and increases overall work, so it is not always good to do it that way, many prefer modular stuff for flexibility, even though it is less optimized for performance.