Basic Lightning vs. Advanced Lighting

#1 T3D is pretty slow, especially if you have alot of separate individual objects.

advanced lighting uses deferred rendering and basic lighting is a forward renderer. as you can see, they're both about the same in terms of quality and both are quite slow.

#2 If you're having to wait for the World Editor to load-up, I take it you're using 1.1b1 (it's a bug, allegedly fixed for next release).

-----

Try this for lighting performance.

In game/core/scripts/client/defaults.cs -- find new SimGroup( LightingQualityGroup ) and inside there change the "low" setting from:

new ArrayObject( [Low] )
   {
      class = "GraphicsQualityLevel";
      caseSensitive = true;
                  
      key["$pref::lightManager"] = "Advanced Lighting";
      key["$pref::Shadows::disable"] = false;
      key["$pref::Shadows::textureScalar"] = 0.5;
      key["$pref::Shadows::filterMode"] = "SoftShadow"; 
   };

to:

new ArrayObject( [Low] )
   {
      class = "GraphicsQualityLevel";
      caseSensitive = true;
                  
      key["$pref::lightManager"] = "Advanced Lighting";
      key["$pref::Shadows::disable"] = true;   		//yorks was false
      key["$pref::Shadows::textureScalar"] = 0.5;
      key["$pref::Shadows::filterMode"] = "None";   //yorks was "SoftShadow"  
   };

Now, reboot Torque and in Game Options ( CTRL O ) select Lighting Quality = Low. And see if it makes any difference to your fps.

-------

MeshCulling in a TsStatic culls submeshes that the camera cannot see - though it's currently listed as bugged.

-------

Basic Lighting has a stencil shadow for ShapeBaseObjects which isn't very good for performance (eventually I'm ripping that code out of my project when I get time).

-------

Just to note:
If you're using interiors/brush-based/BSP-style buildings (Constructor/Radiant/Quark/etc) I think that every surface takes a drawcall - as opposed to a mesh (TsStatic) which only takes one per texture.

eg:
a bsp/interior cube = 6 drawcalls
a mesh cube with 1 texture = 1 drawcall

And LOD everything.

#3 This is the first time I saw BL run slower than AL, and I cannot understand how, since in AL all objects are rendered at least twice.

Can you open the World Editor and post a screenshot of your mission contents?

@Sean: everything is "very slow" if you use "tons of individual objects". Only geometry instancing and area-based geometry merging can save a scene where the artist goes trigger happy and places thousands of individual models around.

#4 @Manoel
Actually, I have an AI test level (50 AI) which runs slower in BL than AL without shadowing ... I figured it might be down to the large number of stencil shadows being projected ... though to be honest, stencil shadowing only shows over a short distance around the camera ...

#5 @Manoel: Incorrect. I hope you don't think every engine is as slow as T3D. It's possible to slow down any engine given enough objects, but theres varying degrees of performance and T3D is quicker to slowdown than most engines.

Case in point, when Cai ported his project from TGEA to T3D, he's noticing a significant drop in performance in BL. aside from post fx, T3D offers almost no reasons for upgrading from TGEA.

and to put things properly into perspective, TGEA already performs poorly with a modest number of scene objects. T3D's even worse.

Anyone who *doesnt* think T3D has a performance problem is deluding themself.

#6 @Steve: if that's the case, then it's 99% certain that the BL shadows are the culprit here. Now I noticed the GuiShapeNameHud in Cai's screenshots is showing some names, which means there are some NPCs scattered around that city. I'll get into more detail bellow.

@Sean: T3D's core renderer almost as lean as it's humanly possible to do. Hardware geometry instancing (which will be in the next beta) is the only major performance feature missing, render-wise. Shadows in advanced lighting are in dire need of optimizations, but even then there are limits (GPUs below a certain threshold are simply unable to do full scene shadowmapping at practical framerates).

Most times I see people slowing the engine down to a crawl I see mistakes that shouldn't be done in *any* engine. The prime one is having hundreds and hundreds (if not thousands) of individual objects without LODs or without a final empty LOD that makes them disappear when far away enough. If you look at any high-profile game carefully, you'll see they aren't made this way: they either have small constrained areas with loading points between them or large areas with aggressive LOD'ing (carefully done to be as hard to perceive as possible).

Example: The Source Engine is known for its high performance. However it is incredibly easy to make a TF2 map that runs at terrible framerates if you are not careful enough.

The second mistake is not giving collision enough consideration. Collision performance is a weak point in T3D (as it was in TGE and TGEA), but at the end of the day there is no way an entire city using visible geometry as collision geometry will not bring down any computer to its knees.

I am almost sure that this is the problem with Cai's mission: the city's models are probably using visible mesh as collision, or using complex collision shapes. Maybe they do have simple collision shapes, but the TSStatics' decalType is set to "Visible Mesh" instead of "Collision Mesh". DecalType controls which mesh type will be used to project decals on.

Shadows in Basic Lighting are decals, created by clipping geometry (which is horribly expensive). So if you have a dozen characters casting BL shadows running around over a complex TSStatic-based city with decalType set to "Visible Mesh", the CPU will be completely strained by having to clip thousands of collision triangles to produce the decals every frame.

T3D's BL shadows use the same basic technique used by TGE's shadows, however TGE *never* offered ways for making highly complex collision geometry, forcing everyone to work with limited amounts of convex shapes or BSPs which were much faster to clip than T3D's polysoup collision.

T3D *does* need a different way for rendering BL shadows, dynamic decals are a bad approach. Triangle clipping is far from trivial, no matter how fast the CPU is. I am sure that simply re-drawing the meshes the shadow is being cast on using projective texturing plus using the stencil buffer to mask the pixels outside the shadow's bounding volumes would be much faster than clipping triangles, no matter how terrible the video card is.

#7 Here's how to nail down what is going slow in your game:

With your game running and your mission loaded, open the console and type:

profilerEnable(1);

Close the console and let your game run for a few seconds. Avoid moving the camera to not spoil the results. Now open the console again and type:

profilerEnable(0);profilerDumpToFile("profile.txt");

Now go to your game root folder and look for "profile.txt" and open it with any text editor that is not Notepad (notepad can't show the line breaks correctly - use WordPad instead).

You should see something like this:

Profiler Data Dump:
Ordered by non-sub total time -
%%NSTime  %% Time  Invoke #  Name
 25.940  25.940     3213 GFXD3D9OcclusionQuery_getStatus
  7.326  24.731    10211 RenderMeshMgr_render
  6.422   6.472     6797 TSSkinMesh_UpdateSkin
  4.216   9.049  1377768 ProcessedShaderMaterial_SetupPass
  3.781   6.113   512015 TSMesh_InnerRender
  2.575   4.160   694851 MatInstance_setTransforms
  2.492   9.453      459 RenderPrePassMgr_render
  2.473  25.153   609671 treeTraverseVisit_prepRenderImage
  2.408   2.408     6797 TSMesh_CreateVBIB
  2.136   3.931   524051 GFXDevice_updateStates
  2.009   2.572   688884 ProcessedShaderMaterial_SetTextureStages
  1.841   2.670  3761130 GenericConstBufferLayout_set
  1.794   1.794   225442 GFXD3D9StateBlock_Activate
  1.686  11.116  1387866 MatInstance_SetupPass
  1.668   1.668  1847325 RenderBinManager_setupSGData
  1.645   2.056   693933 ProcessedShaderMaterial_SetShaderConstants
  1.505   1.505  1229628 RenderPassManager_addInst
  1.482  16.475   512015 TSShapeInstance_MeshObjectInstance_render
  1.404   3.374   694392 MatInstance_setSceneInfo
  1.390   1.390      459 SwapBuffers
  1.373   1.373     1377 ParticleEmitter_copyToVB_Orient
  1.298   1.298     4876 RenderPassManager_Sort
  1.287  17.880   501175 TSShapeInstance_Render
  1.285   1.285     6529 ContainerFindObjects_Box
  1.149   1.782   535119 AdvancedLightManager_setLightInfo

(I cut only the beginning of the file, which is the most important part).

The most relevant information is on the left column that's how much % of the time your profiled was spent in the profiler block "name". In this case I ran a test in FPS Example in Burg, and the obvious performance hog here is GFXD3D9OcclusionQuery_getStatus (25% of my frame time - this is one legitimate bug).

If you see a disproportionate amount of time being spent in SwapBuffers, this means your GPU is the bottleneck. Huge time in TSSkinMesh_UpdateSkin means you need LODs in your characters. Lots of time in anywhere Decal related means decal clipping problems, and so on.

#8

Quote:
@Sean: T3D's core renderer almost as lean as it's humanly possible to do. Hardware geometry instancing (which will be in the next beta) is the only major performance feature missing, render-wise.

T3D's rendering code may be as lean as possible, but the shaders produced by genshader arent.

#include "shaders/common/lighting.hlsl"
#include "shaders/common/torque.hlsl"

using the include preprocessor directive combines the shader code from these files during compilation resulting in unnecessary shader resources being added during assembly. in most cases, the shaders will only use 1 or 2 functions from torque.hlsl, although the entire file(180 lines over 10 functions) is present. functions here either need to be spread out among more files or should be integrated as shader "features". in any case, this is NOT considered a "lean" shader implementation.

IMO, the other major reason for the decreased performance in T3D compared to TGEA is terrain. unlike TGEA, in T3D terrains can use multiple materials. T3D should give developers the option of using non-material terrain a la TGEA if they choose.

Quote:
Most times I see people slowing the engine down to a crawl I see mistakes that shouldn't be done in *any* engine.

the problem with this statement is that this isn't a project Cai created in T3D, it was created in TGEA where the performance *was* much better. this isnt a question of best standards, practices, or optimizations, the question is why the huge discrepancy in performance between TGEA and T3D BL given an identical scene. Cai seems to think he's missed something or messed something up while porting and I'm confirming that this isn't necessarily the case. T3D, in general, simply performs much worse than TGEA.

#9

Quote:using the include preprocessor directive combines the shader code from these files during compilation resulting in unnecessary shader resources being added during assembly. in most cases, the shaders will only use 1 or 2 functions from torque.hlsl, although the entire file(180 lines over 10 functions) is present. functions here either need to be spread out among more files or should be integrated as shader "features". in any case, this is NOT considered a "lean" shader implementation.

Are you entirely ignorant about how compiler technology works?

#10

Quote:
Quote:using the include preprocessor directive combines the shader code from these files during compilation resulting in unnecessary shader resources being added during assembly. in most cases, the shaders will only use 1 or 2 functions from torque.hlsl, although the entire file(180 lines over 10 functions) is present. functions here either need to be spread out among more files or should be integrated as shader "features". in any case, this is NOT considered a "lean" shader implementation. A quick look at the resulting assembly is all that takes to confirm this.

Now I'm sure you don't know how things work and is just throwing blanket statements around. A shader compiler will remove any and every function and variable that is not used to compute the main shader's output.

Quote:
the problem with this statement is that this isn't a project Cai created in T3D, it was created in TGEA where the performance *was* much better. this isnt a question of best standards, practices, or optimizations, the question is why the huge discrepancy in performance between TGEA and T3D BL given an identical scene. Cai seems to think he's missed something or messed something up while porting and I'm confirming that this isn't necessarily the case. T3D, in general, simply performs much worse than TGEA.

And now I see you glossed over my post (yeah, it was huge). I already pointed out the likeliest cause of the problem: it's the characters shadows in BL. TGEA never cast shadows on visible geometry unless you enabled the DTS-on-DTS shadow casting, which used the self-shadowing shader instead.

Advanced lighting renders the entire scene twice. If the problem was the terrain materials, then the GPU would be the bottleneck and the game should be slower in AL. The only feature that is rendered exclusively in BL are the decal shadows, which rely heavily on CPU to work.

#11 @Pat

You seem to be very knowledgeable about rendering code and shader tech so I'm going to pose a question I'm sure you'll be happy to answer. why do YOU think Cai's getting such bad performance in T3D BL, and much better performance in TGEA? ya know, the actual topic of the thread?

@Manoel

I didnt mean to "throw blanket statements around" although I'm not sure if that term would apply to what i said. if what i said was incorrect then, again, considering the fact that theres no shadows in the scenes Cai's posted what is the reason for Cai's poor performance when porting from TGEA to T3D?

after further thought I think I know the answer why:

Quote:
T3D, in general, simply performs much worse than TGEA.

#12 Dear Sean, Manoel, Steve and guys,

Thank you so much for your concern. No doubt that we all expect to make the engine better for usage.

As a newbie to game developing, I still need to learn a lot from you guys.

====================================================================
1. Profiler
I did the profiler, here are the results:
Advanced Lightning

Profiler Data Dump:
Ordered by non-sub total time -
%%NSTime  %% Time  Invoke #  Name
 36.837  37.947    39026 Player_UpdatePos
 18.988  56.969    39026 Player_PhysicsSection
  8.930 100.000       48 MainLoop
  4.523   5.441   251004 TSMesh_InnerRender
  2.943   9.956      672 RenderMeshMgr_render
  2.529   2.529       48 SwapBuffers
  1.756   2.909   264960 MatInstance_setTransforms
  1.436   1.512     8736 TSSkinMesh_UpdateSkin
  1.338   1.393   266736 GFXD3D9ShaderConstBuffer_activate
  1.205   9.382   357305 TSShapeInstance_MeshObjectInstance_render
  1.043   1.507  1348337 GenericConstBufferLayout_set
  1.042   1.042     8736 TSMesh_CreateVBIB
  0.932   1.073   122214 GFXDevice_updateStates
  0.902   0.912       48 ServerNetProcess

Basic Lightning

Profiler Data Dump:
Ordered by non-sub total time -
%%NSTime  %% Time  Invoke #  Name
 31.417  31.417    34646 TSMesh_buildPolyListOpcode
 21.948  23.036    37876 Player_UpdatePos
 21.025  44.093    37876 Player_PhysicsSection
  5.673  37.676    40478 ContainerFindObjects_Box
  4.258   4.258      909 ClippedPolyList_CullUnusedVerts
  2.142   2.142       54 SwapBuffers
  0.663  11.250       54 StdClientProcessList_AdvanceTime
  0.625   2.352      542 RenderMeshMgr_render
  0.591   0.812     3502 GFXDevice_drawTextN
  0.587   0.615     3224 TSSkinMesh_UpdateSkin
  0.511  50.805       54 CanvasRenderControls 
...

From the above result, the player updatePos is taking up a huge chunk, which might be related to one of my previous posts regarding Script optimization when i ported from TGEA to T3D (infact minor if any changes to the script was made, and mainly to redirect files to the new T3D file structure.)

=================================================================
2. Mission
The mission file can be downloaded at 155.69.101.53/sample/VS_Singapore_Banana_Village.mis

Same as what u have discussed, there are hundreds of objects inside the mission. The buildings are using the TSStatic (.dts format) rather than interior (.dif).

Currently only building objects have LOD. Small objects and NPCs don't have LODs.

There are around 20 NPCs at the gameplay, who walks around every 5 to 10 seconds.

For the TSStatic, I use
decalType = "Collision Mesh";
But as I use the visible mesh as collision mesh (as usePolysoup in TGEA), will it affect?

======================================================================
What I might do to improve
1. Add LOD to all objects and human characters, make them invisible when when they are too far away. (Questions: currently i have two: mesh128 and mesh1. how many meshes should i have normally? need mesh 0?)

=======================================================================
Please let me know if anything else I can provide. Thank you so much.

@Steve, i will test out your suggestions soon.

#13 What is the least you are seeing in draw calls? Disable decals as well to see if that makes a difference. We have placed manual decals once and moved a bunch of stuff and it just took an unholy vengenance out on BL because it had issues with the placement. I would put good money on decals (even if they are player/NPC shadows) and if that is not the issue then perhaps draw calls in BL as well.

#14 Your #1 profiler issue is the physics updating.

To reduce the time spent inside this method, have the artists create low-poly collision meshes for all collidable shapes. They should be convex, and have the fewest polygons needed to cover the collidable area of the mesh. You may also use this to create collision meshes which are shaped differently from the visible mesh. For example, instead of having steps, World of Warcraft uses a simple ramp for a collision mesh, while the visible mesh is a detailed staircase. You will need to decide what tradeoffs you want to make for performance, but collision meshes are critical.

If you have collision meshes, you need to insert profiler sub-blocks in Player::UpdatePos and see what is going on. My advice: Make sure you are always profiling in a release build. Measure your improvements in mspf, not FPS; FPS is a relative measurement of performance, making it impossible to compare improvements made. If you want to run at 60fps, you have a budget of about 16ms to draw a frame. Measuring optimizations you make in mspf will allow you to better gauge the effectiveness of your improvements.

Once 'SwapBuffers' becomes the #1 profiler item, you are probably GPU bound.

#15 Since this seems to be a Physics/Collision issue, does this imply a change in the way T3D calculates physics as opposed to TGEA (our TGEA scene is actually slightly more unoptimized, with tops of plant replicators, and individual objects. In T3D, entire buildings and their contents were actually combined into a single mesh. Or was that the wrong thing to do ?

#16 @Cai: T3D calculates physics the same way. But it supports using complex non-convex meshes as collisions, which is the cause of your problems. how did you setup your collisions in TGEA?

Don't use a duplicated version of the model as collision mesh! Like Pat said, create simple convex shapes (cubes, low-polycon cylinders, ramps, etc) and keep them as separated meshes! This is extremely important! Example: meshes Col_1, Col_2, Col_3, etc. That way collision meshes which aren't close to the player will be discarded from collision testing early.

Setting up your collision meshes in the same way they were done in TGE is the best way to get fast collisions.

You can also use invisible convex shapes created with the Sketch Tool to create large and cheap collision blocks.

#17 @ Manoel: In TGEA, we use polysoup for the collision of TSStatic, but for the characters, I am not sure, how can i check that?

I tried to use

function villagechiefdts::onLoad(%this)
{
%this.addMesh("cube", "bounds", "Col-1"); // collision mesh
}

but it doesn't seem to work. Must I change the 3D model of player?

May I know whether "Bounding Box" is used for the collision test? Must i have the Col-1 for collision test?
What is the usage for
1. BoundingBox mesh in the player model
2. BoundingBox = "1 1 1" inside the Player datablock.

As in the documentation, it says:

***************************************
Adding collision meshes and LOS meshes
Note: this section does not apply to player objects, as their collision
meshes are generated in script.
***************************************

Thank you so much.

UPDATE :
I Tried Setting the collision of ALL objects in my mission to None and tested by walking through them, yet Player update position and physics remains the top 2 in the profiler. Also tested with enableing/disabling shadow in scatter sky wit the same results.

#18 @Cai: Characters use bounding boxes, so you shouldn't worry about them. If you used polysoup in TGEA, then there might be a problem with collisions in T3D. TSStatic collision meshes should be done in your 3D modeling program.

Create meshes with Col_ in front of their names and they should export as invisible collision meshes.

Can you post a picture of your mission (showing a list of all objects)? Are you using PhysX?

#19 @Manoel

As currently we use the visible mesh for collision for the buildings, to create level with Torque Constructor is a bit difficult. Do you have any suggestion for the buildings?

We need to have both Col-1 and Collsion-1, right?

We did not use PhysX. I am not quite sure how to activate that as we use the ATI graphics card.

The mission hierarchy is


I am now trying to adding LOD to the objects, but headache about the collision mesh of the buildings.

#20 The collision mesh is a special type of LOD. You don't use constructor, you make it exactly in the same way you do LODs, but you pre-fix their names with "Col-". Example:

1) Open your model in MAX/Maya/Blender;
2) Create simple boxes to act as collision meshes;
3) Name these boxes "Col-1", "Col-2", "Col-3", etc;
4) Create corresponding dummy nodes called "Collision-1", Collision-2", etc, for each Col shape (if you're using Collada this isn't necessary, I think).