This dates back to X-Plane 8.0 - originally all scenery load was done when a DSF was loaded, with the sim paused. In that condition, keeping scenery load fast was a high priority. So I set roads up to be "pre-draped" (that is, their heights are pre-determined when building the DSF). Back in the day it was a win.
Now we have multiple cores and DSF loads in the background, so we very easily could "drape" a DSF...but it gets weirder. A road's sub-type is specified in the DSF - and sub-types are used to define bridges.
Now that's not incompatible with a "draped" scheme - imagine a road whose height is specified AGL, so a height of 0 means "run the road along the base mesh" and a height of 10 means "10 meters above the base mesh." Now you would set the road type to overpass as the height went from 0 up to 10 meters, then back to 0, forming a bridge.
The only problem is what happens if the ground is really weird looking. In practice what we want to do is keep the road's slope as constant as possible and build out bridges based on that. The effect can be hard to see, but if you look at bridges in the US scenery, you'll see that sometimes the banks to a river slope down but the road stays horizontal, forms a bridge, and then stays flat as the banks come up again. This happens because our road processing code (in the DSF builder) tries to limit road slope.
That's not an easy effect to create in an overlay...you'd basically have to increase the road AGL at the rate the base mesh's AGL is decreasing (if only you could know that).
So the questions I am debating now are:
- Are AGL-draped roads useful if we don't know what the base mesh will be like?
- Does it make sense to have some other abstraction to help smooth roads when the base mesh is bumpy (and can we make something that is both simple and useful)?
0 comments:
Post a Comment