PTaylor's WebLog

So, in case you missed it, TS2 was publicly demoed at the National Train Show last week. And the web site at http://www.tsinsider.com had a major facelift. Plus some new information is now publicly available. See http://tsinsider.com/product/overview.aspx

From that link, for instance, it is now official; TS2 is due for "holiday 2009". Which makes sense if you think about it, 90% of entertainment titles go for the holiday rush. And this serves to confirm broad hints I have been making about TS2, and should provide similar hints to the savvy who can read between the lines about when FS11 is likely due.

There are some technical gleanings to be made from the same link and the demo.

For instance, "animated passengers and crew" is mentioned in the overview page.

Yes, animated characters in the train (cab and cars) and in the stations.

It just so happens that Aces Studio picked up most of the ShadowRun character team when that team was dissolved and we have made good use of them.

I cannot go into detail on all that we will use them for in Trains2, and it is way too early to talk about how they might be used in FS11. But this is a major advance in realism for the engine in terms of Living World.

Now, for those of you who immediately see the "bad side" of any announcement that Aces or I make, I have made similar "back of the envelope" performance calculations about characters and what the limits are just like I did for Autogen a while back. Just to prove we are thinking ahead, and the sky is not falling.

Overall Performance Issues

In our performance investigations over the last 2 years, we have found that bus throughput is most often the limiting factor. In many cases the CPU or the GPU is waiting for bus transfers to finish. Just to refresh people’s memory on bus throughput:

·         PCIe 16x 2.0 bus yields ~68M/frame at 60hz,

·         PCIe 16X 1.0 bus yields ~34M/frame at 60Hz,

·         PCIe 8x/AGP 8x yields   ~17M/frame at 60Hz.

I use 60Hz as a goal, that doesn’t mean we will reach it, but that is where the calculations start.

For PCIe, 16x refers to 16 lanes, 8x refers to 8 lanes. For AGP 8x,that refers to the 8x standard as opposed to the 4x standard. Note many PCIe motherboards drop slots from 16x to 8x when you add a second board. This can help make SLI/Crossfire less than effective, for instance. Watch out for that.

Character Performance Limits

There are 3 parts to understanding character performance impact on the engine:

1) Skinning data

2) Model data

3) Texture data

Skinning data is the transform data required to “move” the character, model data is the actual geometry data, and texture data is the textures that get wrapped around the geometry.

Character Performance Limits-Skinning Data

Animated models require one 3x4 transform matrix per bone in the skeleton. The character models in Train Simulator 2 have 46 bones. That gives a total of ((1 + 46) * 48 bytes) = 2,256 bytes per animated character.

PCIe 16 2.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 68 MB / 2,256 bytes per instance) = 3160 instances per frame at 60 Hz can be sent across a PCIe 16x 2.0 bus.

PCIe 16 1.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 34 MB / 2,256 bytes per instance) = 1580 instances per frame at 60 Hz can be sent across a PCIe 16x 1.0 bus.

PCIe 8

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 17 MB / 2,256 bytes per instance) = 790 instances per frame at 60 Hz can be sent across an AGP 8x or PCIe 8x bus.

Lesson #1

Cap Scenes at 800 characters, and that is before we look at model data or textures.

Character Performance Limits-Model Data

Animated models currently have 2 LODs, 2500 polys and 1500 polys, there is no billboard LOD.

With a single UV, the vertex data is 24 bytes ( 3*4 for position, 1*4 for color, 2*4 for uv ).

With 3 UVs, the vertex data is 40 bytes.

2500*40 bytes is 100k bytes per character, 100 characters is 10m bytes across the bus.

PCIe 16 2.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 68 MB / 100k bytes per instance) = 712 instances per frame at 60 Hz can be sent across a PCIe 16x 2.0 bus.

PCIe 16 1.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 34 MB / 100k bytes per instance) = 356 instances per frame at 60 Hz can be sent across an PCIe 16x 1.0 bus.

PCIe 8

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 17 MB / 100k bytes per instance) = 178 instances per frame at 60 Hz can be sent across an AGP 8x or PCIe 8x bus.

Lesson #2

Cap Scenes at 200 characters, and that is before we look at texture data.

Character Performance Limits-Texture Data

Animated models currently have 750k of body texture, 175k of head textre, and 60k of add-on texture for ~1m of texture per character.

PCIe 16 2.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 68 MB / 1m bytes per instance) = 68 instances per frame at 60 Hz can be sent across a PCIe 16x 2.0 bus.

PCIe 16 1.0

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 34 MB / 1m bytes per instance) = 34 instances per frame at 60 Hz can be sent across a PCIe 16x 1.0 bus.

PCIe 8

Assuming an additional 10% of the bus bandwidth is available for animated character data (0.10 * 17 MB / 1m  bytes per instance) = 17 instances per frame at 60 Hz can be sent across an AGP 8x or PCIe 8x bus.

Lesson #3

Cap Scenes at 30-60 characters

30 characters =  30m of texture,  3m of model data, 67.68k of skinning data which is just less than 34m or 10% of PCIe 1 bus bandwidth

60 characters =  60m of texture,  6m of model data, 135.36k of skinning data which is just less than 67m or 10% of PCIe 2 bus bandwidth

Overall Lesson

First, AGP and PCI of less than 16 lanes just suck for bandwidth. Do not buy hw that is less than PCIe 1 with 16 lanes ( 16x ). And watch for the mobos that drop your channels in half when you add a second board, those are not worth any savings you think you are getting.

Second, we need to either reduce texture costs or develop an imposter (1) system to have character densities in excess of 60 characters per scene.

Of course, we could reuse some characters and perform tricks with the textures so there is variation in the texture and they don’t look identical. That can get us back some density by texture and geometry sharing. That doesn’t seem likely to scale to 200 characters, though, which is what the art team desires.

Note 1: Imposters are essentially billboards for far-distance characters, in that case the full-blown animated character can be replaced by a flat billboard or “imposter” and it is very hard to tell. We are investigating storing normal maps with our imposters to give the lighting system more to work with, which should make it even harder to tell a billboard is used to represent the character.

Conclusion

That set of B-O-T-E calculations shows that we are being intentional about adding features, and not just adding them for additions sake or without understanding the deeper implications in terms of rendering performance.

These are steps that did not happen before FSX shipped, so that is a major change in the studio’s approach to development as we are viewing performance as a primary feature that needs to be developed for up-front.

Note 2: there is already a fair amount of discussion about the NTS demos on both http://www.train-sim.com in the MSTS-X forum and http://www.uktrainsim.com in the Microsoft Train Simulator 2 forum. Aces team members are active in both.

Update