Performance decrease from 1.1A to 1.1B
by Joshua Halls (Xerves) · in Torque 3D Professional · 02/19/2010 (3:30 am) · 11 replies
Perhaps someone can shed some light on this. We ported from 1.1A to 1.1B and started to take a look at performance with the variety of options now. When the options are on par with what they were before in the alpha in AL we are tending to see about 10-15% reduction in performance. BL seems to be faring a bit better and performing a bit better.
I tried a basic zone with only a terrain and things seem good on AL, but as soon as I add a structure it starts to trend downward from there compared to an exactly setup zone in 1.1A. Is there anything in AL perhaps we could be looking at that might be causing this? I think terrain is now casting shadows on itself, but I tested terrain only thinking that might be it and didn't get much of a change.
I tried a basic zone with only a terrain and things seem good on AL, but as soon as I add a structure it starts to trend downward from there compared to an exactly setup zone in 1.1A. Is there anything in AL perhaps we could be looking at that might be causing this? I think terrain is now casting shadows on itself, but I tested terrain only thinking that might be it and didn't get much of a change.
About the author
Part of the team that works on The Repopulation, a SciFi based MMO using a heavily modified version of the Torque MMO Kit - T3D. I also take care of the T3D version of the Torque MMO Kit.
#2
02/19/2010 (11:30 am)
@Netwyrm: it makes sense, since the amount of objects that need to be rendered to produce the shadows at low sun angles is pretty big: you need to render pretty much everything between the camera position and the edge of world's bounding box at the Sun direction. 
#3
02/19/2010 (11:57 am)
Not using ToD but just Scattersky with a big forest, I see that my fps with sun at height10 =125, and with height80 =105.
#4
02/19/2010 (12:44 pm)
A forest? Maybe something changed in the code that selects which LODs get rendered in the shadows and which don't. Doesn't the forest object itself has a control for this kind of stuff?
#5
02/19/2010 (1:02 pm)
I thought that LOD control was now done by OptionGui "mesh quality" - with normal being whatever LODs the model comes with.
#6
02/19/2010 (3:41 pm)
Today without changing anything things are matching up now from 1.1A to 1.1B. No idea what is going on with that, but I guess I will take the good news. I did get to test memory usage on an older video card with the smaller textures using the scalar and it was nice to see that dramatically reduce memory usage. Now, just need SM2 fallback to work properly and things should be a bit better for the lower end machines. 
#7
There should actually be a way to toggle shadows from terrain, as not all lighting arrangements warrant doing these calculations, while others demand it (late evening/early morning scenes, areas with large-scale dynamic lights, etc).
02/19/2010 (7:03 pm)
This might not be the issue, but shadows cast by terrain were completely off in 1.1a. With any lower-angle sun, these shadows add quite a bit of work for the shadow render pass, and it makes sense that, without them, there would be been some "accidental" performance increase in 1.1a that is now gone.There should actually be a way to toggle shadows from terrain, as not all lighting arrangements warrant doing these calculations, while others demand it (late evening/early morning scenes, areas with large-scale dynamic lights, etc).
#8
As Henry mentioned a way to turn of terrain creating shadows might be nice as an option if if is possible. I digged around a bit trying to see if I could catch where that got fixed, but didn't seem to find it to easily.
03/08/2010 (8:52 am)
After a bit more conversion work, still seeing about a 10-15% loss from 1.1a to 1.1b even with the shadows completely disabled. BL seems to be fine as I am getting fairly close results from before.As Henry mentioned a way to turn of terrain creating shadows might be nice as an option if if is possible. I digged around a bit trying to see if I could catch where that got fixed, but didn't seem to find it to easily.
#9
so you can have something like an else, and just return do not create the TerrainRenderInst.
03/08/2010 (4:48 pm)
If you look inside TerrRender.cpp, you will find this code// Only pass and use the light manager if this is not a shadow pass. LightManager *lm = NULL; if ( isColorDrawPass ) lm = LIGHTMGR;
so you can have something like an else, and just return do not create the TerrainRenderInst.
#10
Also the SM 2.0 issue is in my bug list... it will be fixed for beta 2.
03/09/2010 (10:33 pm)
We did a pretty big optimization pass here last week. You will see some of these in 1.1 beta 2.Also the SM 2.0 issue is in my bug list... it will be fixed for beta 2.
#11
I added a console preference on top of that so it can be toggled on/off. Even if there isn't much being applied to the terrain I tend to net a few FPS. If there is a shadow it is fair gain. Might consider placing it in as an option.
On another note, the camera rotation still causes issues with terrain shadows. If you rotate the camera around the shadow moves all over the place. Seems to be better with other objects compared to back in the early Alpha stages, but the terrain is still way out of whack in that department.
03/19/2010 (8:22 pm)
@Frank, what you posted didn't actually work.if (state->isShadowPass()) return;
I added a console preference on top of that so it can be toggled on/off. Even if there isn't much being applied to the terrain I tend to net a few FPS. If there is a shadow it is fair gain. Might consider placing it in as an option.
On another note, the camera rotation still causes issues with terrain shadows. If you rotate the camera around the shadow moves all over the place. Seems to be better with other objects compared to back in the early Alpha stages, but the terrain is still way out of whack in that department.
Torque Owner Netwyrm
Canopic Games