MikeK wrote with regard to asset-block trees...
An entire hill of trees that vanish when you get close.
There are two issues involved. One is the asset block object's bounding volume, the other is its LOD.
Every scenery object has a bounding volume defined in its geometry file. A bounding volume is an imaginary, simplified set of continuous surfaces that encompass all parts of a model. Usually a bounding volume is made up of a few intersecting spheres. The game engine uses the bounding volume to determine whether an object should be drawn or not. If the view frustum (http://en.wikipedia.org/wiki/Viewing_frustum) intersects an object's bounding volume the object gets drawn. However, if the bounding volume happens for some reason to be smaller than the object, in other words if a portion of the object protrudes beyond the surface of the bounding volume, the object may disappear (i.e. cease to be drawn) before it's actually off screen.
The LOD also determines if an object will be drawn. Most of us know how LODs work, but here it is anyway. The LOD (Level Of Detail) is the farthest distance away from the viewer (meaning your eyes) that an object will be drawn. If something has an LOD of, for example, 500, it will not be drawn if it's more than 500 meters away from the viewer.
In the case of asset blocks, there is no geometry file for the asset block itself -- only for the asset whose multiple instances are contained within the block. The bounding volume dimensions for asset blocks are evidently hard coded and it appears there are times when the dimensions the game engine uses are insufficient. When the asset block disappears, the instanced asset contained in the block also disappears regardless of the contained asset's own bounding volume. For models we ourselves create, placing the pivot point at the centroid of each part usually avoids the disappearing act, but if we need to we can hack the GeoPcDx file to make the bounding volume larger. Can't do that with an asset block.
To me, distant mountains means distant trees, too. It would be nice if we could extend the view distance -- the LOD -- of selected asset blocks to suit the terrain conditions, but again there's no geometry file for an asset block so we can't do that. Normally, "fog" is used to hide the popup effect in which objects pass or fail the LOD test and suddenly come in or out of view. That works nicely when the weather is actually supposed to look foggy, but it doesn't help us on a clear day when the fog region is much farther away.
Rich_S wrote with regard to radiator fan animations...
I'm just wondering how much GPU / CPU time is being wasted on all of these fans running when they shouldn't be? Is this another reason frame rates are dropping, Four engines times 5 fans per engine is this just to much animation and the fans are killing frame rates? Something to think about?
The radiator fan animation has a negligible effect on frame rates. To begin with, only a single fan animation (BAN) file is used in RSC's diesels. If the fans were to run separately, a separate animation file would be required for each fan, which in turn would require more time for the CPU to iterate through each one of them. To make the fans run separately the locomotive's LUA script would have to sequence the fans on and off in response to some kind of mathematical calculation involving perhaps the parameters Amperes and RPM. Those parameters may not be the most direct indicator of engine temperature, but it's about all we have to work with. I suspect it would take more CPU power to run such a script and all the separate animations than it takes to simply animate all the fans simultaneously and run them continuously.
Worth a try, though.
As an aside, one of our esteemed RWA colleagues is developing a diesel locomotive where the grid fan does in fact operate in response to dynamic braking only. That may have been done before but it's the first time I've seen it.
