by mrennie » Fri May 20, 2016 7:00 am
I've always been reluctant to give out this information but I think it's time to do it.
As Kev says, that 20K polycount budget for a locomotive is, in my opinion, ridiculous and, if adhered to, leads to models that can be ugly when viewed up close (which is what I like to do). I particularly dislike low-poly cab views because when you're in the cab, everything is viewed in close-up, so things such as 16-sided gauges (that are meant to be round) are very noticeable.
3DC has a plug-in that counts faces and points, and also calculates how many triangles there would be if all the faces were triangulated (e.g. a four-sided face being split into two triangles with a common edge). I'm not sure which of those counts towards the "polycount" so I'll just give them all, for the "HD" version of the UP FEF-3:
Faces Triangulated Points
Engine: 286,690 543,827 311,601
Tender: 123,483 184,412 114,203
Total: 410,173 728,239 425,804
Most people say the FEF-3 runs smoothly, and comments about low frame rates are very rare, and come from players with laptops that struggle to play TS regardless of loco. I've also noticed that it tends to depend much more on the route anyway. In any case, for those people, I made the "SD" version that has far fewer rivets, nuts and bolts.
There are videos on YouTube of people running two or three FEF-3s at the same time, with silky smooth frame rates (and that is despite the frame rate hit from the recording software!).
That said, I wouldn't recommend going way above the figures I put there for the FEF-3. Somehow, I doubt a model with 7 million triangulated faces would do well.
There's also the matter of textures - size and number of files - and the choice of shaders used on different parts. The FEF-3 has a lot of them, but again, it hasn't caused a problem. However, I was always very careful to use simpler shaders, such as TrainBasicObjectDiffuse.fx, wherever it wasn't worthwhile using the more complex (and therefore more demanding) ones such as TrainBumpSpecEnvMask.fx.
By the way, I use bump mapping quite a lot. For example, I use it with the rivets on both the SD and HD version - the HD version has 3D rivets on top of the bump mapping that simulates the oxidation and metal-bending that occurs around the rivet). Mainly I use bump-mapping to achieve a realistic look to the surfaces of different materials, such as the "orange-peel" effects that you get on cast metal, partly from the sand in the pattern used to cast the piece and partly from the bubbling of the paint applied to the metal afterwards. Another good example is the bending of the sheet metal smoke deflectors, showing the way the metal bends around the framework of the smoke deflector. It was much more effective to use bump-mapping for that than to model the bends in 3D.
Something else I recommend is to build and export the model a few parts at a time, building it up in stages and seeing how it looks in-game, and checking its framerates, when viewed from various angles and distances.
I also make extensive use of LODs, so that, for instance, rivets, nuts and bolts disappear from the model at the exact distance where the eye wouldn't be able to distinguish them from the bump mapping underneath, or see them at all. That compensates for the fact that as you move the camera away from the model, more of the scenery comes into view, which impacts the frame rates.
Another thing that can impact frame rates is the scripting. I took enormous care over the optimization of the scripts. For example, there are some things that have to be done on every call to Update, such as all the calculates that govern the gauges, but some other things can be distributed over a 1-second interval, to lower the average CPU load of the script (did I ever mention that I used to develop safety-critical real-time embedded software for aircraft and spacecraft? ... optimization and efficiency is second nature to me).
I could go on and on about this topic (there's a lot more to it than the above) but I'd better leave it at that.
